分工
AI 承担什么，我保留什么
AI 承担
把散落的材料变成结构化的东西
在同一组约束下生成大量候选
穷举我会漏掉的边界情况
把已定的规则批量应用到存量内容上
我保留
定义约束本身——判断真正发生的地方
决定哪条证据算数、哪条只是听起来对
选择放弃什么
为结果负责
建立需求上下文
先确定谁、在什么场景、要完成什么任务。这一阶段不出方案，只把事实、偏好、假设和限制分开。
Check Prompt
我如何指挥 AI
提供已知材料，划定这次的范围与非目标
让它分清楚：哪些是事实，哪些是谁的想法，哪些还只是猜测
每一条都要落到：给谁、什么时候、想做什么、怎样算成功
AI 返回
结构化的需求初稿，以及它自己没能理清的部分：信息冲突、缺失背景、待确认问题。
我的判断
核对每条信息的来源
拒绝 AI 补写未经确认的需求
决定哪些问题必须先回答，才允许进入下一步
Step 01
“需求上下文说明”
已确认的事实、被表达的偏好、待验证的假设、明确写下的非目标。每一条后面都跟着它的出处。
Deliverable 01
没参加前期讨论的人，能说出用户是谁
能说出用户要完成什么
能说出这次不解决什么
Criteria 01
规划并整理证据
把「不确定什么」转化为「应该怎样确认」。先选问题，再选方法。
Check Prompt
我如何指挥 AI
先定这一轮要回答的问题，再选方法
圈定允许使用的资料范围与时间窗
要求同一结论至少来自两类不同来源
AI 返回
材料的分类、跨用户的共同模式，以及与模式矛盾的反例；还有它判断不了真伪的部分。
我的判断
决定哪些问题值得继续调查
只认发生过的例子，不认「觉得可能」
核对模式是否真有原始记录支撑
Step 02
“证据计划”
列出这一轮要回答的问题，每个问题配一个具体方法，并写明什么结果算够。
“可追溯证据图”
每条结论都连回它的来源。来源分三种并且长得不一样：真实记录、暂时顶上、仍然空缺。
Deliverable 02
每个重要结论都能回到原始记录
反例还在文档里，没有被结论盖掉
缺少支持的解释，标的是假设，不是结论
Criteria 02
Check Prompt
我如何指挥 AI
要求从不同角度重组问题
比较用户 / 情境 / 障碍 / 后果的关系
标出证据薄弱或表述过度的部分
AI 返回
多个可选的问题框架，各自的因果假设与设计机会，以及证据薄弱处。
我的判断
拒绝只有现象、没有用户后果的问题
不把预设方案包装成问题
选有证据支持、且允许多种解法的方向
Step 03
01 · A
建立需求上下文
把零散需求整理成所有人都能准确复述的设计起点。这一阶段不出方案，只把事实、偏好、假设和限制分开。
查看这一步的 prompt →
承接输入
需求信息
会议记录
现有方案
截图
限制与反馈
01 / 我如何指挥 AI
提供已知材料，划定这次的范围与非目标
要求区分事实、偏好、假设与未知项
按用户 / 情境 / 任务 / 成功标准归位
02 / AI 返回
结构化的需求初稿，以及它自己没能理清的信息冲突、缺失背景和待确认问题。
03 / 我的判断
核对每条信息的来源
拒绝 AI 补写未经确认的需求
决定哪些问题必须先回答才能继续
关口
01 → 02
这一阶段留下
《需求上下文说明》
全部满足才进入下一步
・没参加前期讨论的人，能说出用户是谁
・能说出用户要完成什么
・能说出这次不解决什么
未达成 → 不进入 02
02 · B
规划并整理证据
把「不确定什么」转化为「应该怎样确认」。先选问题，再选方法。
查看这一步的 prompt →
承接输入
《需求上下文说明》
其中仍未确认的问题
01 / 我如何指挥 AI
确定需要回答的问题与证据边界
圈定允许使用的资料范围
要求整理已有材料并发现重复
02 / AI 返回
证据缺口与收集建议、材料的分类与共同模式，以及与之矛盾的反例。
03 / 我的判断
决定哪些问题值得继续调查
判断哪些材料可以算作证据
核对模式是否真有原始记录支撑
承接 02 · 这一步的内部机制
每条结论都带着它的证据来源
真实项目经常缺数据。我不假装没缺，也不让生成的材料冒充真实的——三种来源在文档里始终可见，而且长得不一样。
真实记录
来自访谈、日志、可复查的原始材料。结论可以建立在它上面。
暂时顶上
缺口处用生成材料把流程先跑通。只用于搭结构，拿到真实数据立刻替换。
仍然空缺
没有材料，也没有生成。相关结论标记为待定，不进交付。
操作上的那一条：一条结论下面如果全是「暂时顶上」，这条结论就标记为待定，不写进交付物。生成材料可以帮我把流程跑通，不能帮我把话说满。
关口
02 → 03
这一阶段留下
《证据计划》
《可追溯证据图》
全部满足才进入下一步
・每个重要结论都能回到原始记录
・反例仍然可见，没有被抹掉
・缺少支持的解释已标记为假设
未达成 → 不进入 03
03 · A+B
定义问题与目标
从大量信息中找出真正值得设计介入的问题。看得见的症状不等于原因。
查看这一步的 prompt →
承接输入
经过整理的观察
模式
反例
待验证假设
01 / 我如何指挥 AI
要求从不同角度重组问题
比较用户 / 情境 / 障碍 / 后果的关系
标出证据薄弱或表述过度的部分
02 / AI 返回
多个可选的问题框架，各自的因果假设与设计机会，以及证据薄弱处。
03 / 我的判断
拒绝只有现象、没有用户后果的问题
不把预设方案包装成问题
选有证据支持、且允许多种解法的方向
关口
03 → 04
这一阶段留下
《问题框架》
全部满足才进入下一步
・说清谁在什么情境下受什么阻碍
・说清造成什么后果
・问题陈述里不预设答案
未达成 → 不进入 04
04 · C
确定体验策略
先决定体验应该带来什么改变，再讨论界面长什么样。
查看这一步的 prompt →
承接输入
经过确认的问题框架
目标
限制
01 / 我如何指挥 AI
设定比较维度
要求生成真正不同的体验机制
逐个分析收益 / 风险 / 依赖 / 取舍
02 / AI 返回
候选策略与机制对比，附带风险清单和需要验证的关键假设。
03 / 我的判断
拒绝只改表现、不改理解或行为的方案
按问题匹配度、可行性与影响排序
选定方向，并写下不做什么
关口
04 → 05
这一阶段留下
《体验策略声明》
《方案比较记录》
全部满足才进入下一步
・预期改变与实现机制可查
・非目标已写下
・拒绝其他方向的原因可查
未达成 → 不进入 05
05 · C
搭建结构与原型
把体验策略转化为一条可以实际操作的任务路径。顺利完成只是其中一部分。
查看这一步的 prompt →
承接输入
选定的体验策略
内容需求
关键使用情境
01 / 我如何指挥 AI
锁定核心任务与业务规则不变
要求生成信息结构与流程候选
检查遗漏、断点与缺失状态
02 / AI 返回
信息架构与用户流程、页面清单与状态覆盖报告，以及一份可操作原型。
03 / 我的判断
重排内容层级，删掉多余步骤
补齐错误、空状态与恢复路径
决定原型需要多高保真度
关口
05 → 06
这一阶段留下
《信息架构与关键流程》
《可测试原型》
《状态说明》
全部满足才进入下一步
・关键任务能从入口走到完成
・主要异常可恢复
・没有无法解释的死路
未达成 → 不进入 06
06 · D
建立界面系统并完成构建
这一阶段的顺序和多数人相反：先把规范立起来，再让 AI 在规范里生产。规范没绑定完就生成的页面，一律不采纳。
查看这一步的 prompt →
承接输入
经过确认的流程
原型
状态
内容结构
01 / 我如何指挥 AI
规定内容与功能不可改动
从参考图与存量页面反向提取规则，建成变量并绑回存量稿
规范稳定后，才让它用规范和组件生成新页面
02 / AI 返回
视觉候选与设计规则、组件初稿与关键页面，以及可运行代码。
03 / 我的判断
拒绝只有装饰差异的视觉方案
按阅读顺序、可访问性与复用性选择
逐项审查代码是否保持设计意图，规范要落到代码资产里
承接 06 · 这一步的内部机制
规范先行：先立约束，再让 AI 生产
多数 AI 设计流程从「生成页面」开始，然后回头收拾一致性。我从反方向进：先把规则从已有的东西里提出来，绑定回去，让偏差自己暴露，规范稳定之后才允许生成。
01
反向提取
从参考图和存量页面里把已经存在的规则抽出来，建成颜色、字体、间距、圆角四组变量。
02
绑回存量
把变量绑回已有页面。所有不符合规范的地方会自己暴露出来——这一步不能跳。
03
规范内生成
规范稳定之后，才让 AI 用已定义的变量和组件生成新页面。
04
转成代码资产
规范落进代码，不只落在设计稿里。下一个人接手时拿到的是同一套东西。
为什么第 02 步不能跳
不绑定回存量稿的规范，只是一份没人遵守的文档。绑定这一步会逼出所有历史遗留的例外，那些例外才是真正要做的决定——是改页面，还是改规范。这个决定 AI 做不了，但它必须在 AI 开始生成之前做完。
关口
06 → 07
这一阶段留下
《视觉方向说明》
《界面系统与关键页面》
《可运行前端》
全部满足才进入下一步
・重复设计已成为公共规则
・关键状态被覆盖
・核心流程在目标尺寸和键盘下可用
未达成 → 不进入 07
07 · E
验证并迭代
分别确认产品是否被正确实现，以及真实用户是否能完成任务。这是两件事。
查看这一步的 prompt →
承接输入
可运行产品
关键任务
成功标准
待验证假设
01 / 我如何指挥 AI
先区分产品检查与用户验证
要求检查代码、响应式、键盘与状态
整理真实测试记录中的问题
02 / AI 返回
分开列出的技术问题与体验问题，各自的严重程度、可能来源和修改建议。
03 / 我的判断
不把自动检查当作用户证据
按真实任务表现解释问题、排优先级
决定改设计、改流程还是改代码
关口
07 → 08
这一阶段留下
《验证与迭代记录》
全部满足才进入下一步
・严重产品问题已修复
・每个体验结论都有真实证据
・缺证据的已标记为待定
未达成 → 不进入 08
08 · F
交付与沉淀
不仅交付当前结果，也留下下一次可以安全复用的经验。
查看这一步的 prompt →
承接输入
经过验证的设计
实现文件
决策记录
证据
01 / 我如何指挥 AI
检查交付完整性与版本差异
生成说明初稿
提取可能复用的规则与模板
02 / AI 返回
交付清单与变更记录、维护说明，以及可复用规则的候选。
03 / 我的判断
确认责任归属与使用边界
区分项目事实与方法模板
避免把一次经验包装成普遍结论
承接 08 · 这一步的产物之一
学习契约：这个项目改变了我哪些默认做法
每个项目结束时我会写一条。它不是总结——总结是写给过去的，契约是写给下一个项目的。写下来之后，我的默认起点就变了。
⬚ 占位 · 一条真实的学习契约
需要三段：① 这个项目之前，我的默认做法是什么；② 发生了什么让它站不住；③ 从现在起默认改成什么，以及在什么条件下不适用。
第 ③ 段里的「不适用条件」是关键。没有边界的经验，就是我在下面「哪些决定不外包」里说的那种「把一次经验包装成普遍结论」——那一条会自己打自己。
关口
08 闭环
这一阶段留下
《交付包》
《学习契约》
全部满足才进入下一步
・其他人能理解、实现、维护和验收
・每个公开结论可追溯
・每项复用都有适用条件
未达成 → 这个项目不算闭环
这条路不是每次都一样走
八个阶段都在，但重心跟着项目类型移动
上面按顺序讲完了八步，只是因为顺序最好讲清楚。实际接到一个项目，我先判断它属于哪一类，再决定把时间压在哪几段——以及这一类最容易在哪里出错。
数据提升型
数据稳定，目标是把某个指标推上去。
重心
02 证据 · 07 验证
这一类最容易犯的错
先有方案再找数据支持它。这类项目的证据口径必须在方案之前锁死，否则验证只是在自我确认。
数据下滑型
某个指标突然掉了，先要找到原因。
重心
01 上下文 · 03 问题
这一类最容易犯的错
把最近一次改版当成原因。时间点重合不等于因果，这一类项目在 03 上花的时间应该比平时多一倍。
上新验证型
新功能已经上线，要确认它是否成立。
重心
04 策略 · 05 结构
这一类最容易犯的错
验证「用户会不会用」，而不是验证「当初那个策略假设成不成立」。前者永远能得到一个好看的答案。
未来探索型
没有现成数据，方向本身就是待验证的。
重心
03 问题 · 04 策略
这一类最容易犯的错
用生成数据撑起结论。这类项目里 07 几乎跑不动——与其假装验证过，不如把结论明确标成待定。
