三段式提示 | 与 AI 协作 | 做产品
三段式提示
目标、约束、验收标准。三段写全，返工次数会明显减少。
你会遇到的现象
-
做出来的东西能跑，但不是你想要的方向
-
它顺手加了一堆你没要的功能
-
收到结果之后不知道该说「好了」还是「再改改」
三段各写什么
段写法常见错误
目标 用户能达成什么状态，为什么需要 写成技术任务：「加一个 useEffect」
约束 技术栈、已有组件、必须遵守的规范、明确不做的 只写要做的，不写不做的
验收标准 可以逐条勾的清单，最好包含边界情况 写成「做得好一点」这类没法验的话
目标那一段写成技术任务是最常见的失误。说「加一个 useEffect」，你就放弃了让它提出更好方案的机会；说「进入页面时自动加载最近的记录」，它可能给你一个更合适的做法。
三段各自管一件事，缺一段就得多返工一轮
① 目标 决定方向
② 约束 决定边界
③ 验收标准 决定什么时候算完
最常见的失误在第一段：把目标写成了技术任务
「加一个 useEffect」
「进入页面时自动加载最近的记录」 你已经替它选好了做法 它可能给你一个更合适的做法
第三段最值钱也最容易被跳过：它同时是它的自检清单，和你的收货依据。 写成能逐条判断的句子——「点击提交后按钮变为不可点」可以验，「体验流畅」不能。
验收标准里包含边界情况是个高杠杆动作：把零条数据、超长内容、网络失败这三条写进去，四态就自动被覆盖了。再加两条反向标准——「控制台不能有报错」「不能新增未使用的依赖」——基本就够用了。
验收标准怎么写
这一段最值钱，也最容易被跳过。它有两个作用：给它一个自检的清单，给你一个收货的依据。
-
写成能逐条判断的句子。「点击提交后按钮变为不可点状态」可以验，「体验流畅」不能。
-
**包含边界情况。**零条数据、超长内容、网络失败。这几条一写，四态就自动被覆盖了。
-
写清什么不算完成。「控制台不能有报错」「不能新增未使用的依赖」这类反向标准很有用。
-
**让它做完自检并报告。**逐条对照，说明哪几条做到了、哪几条有偏差。成本极低，能省掉一轮来回。
一份可以直接改的模板
复制 PROMPT · 三段式
目标
[用户能达成什么状态]。这一步要解决的问题是 [具体的卡点]。
约束
- 技术：[框架、语言、已有的库]
- 复用：优先使用 src/components/ui 下的已有组件和设计令牌， 不要新造同类组件、不要硬编码颜色和间距
- 规范：[项目里必须遵守的几条]
- 明确不做：[列出来，包括看起来顺理成章的那些]
验收标准
- [ ] [可以逐条判断的行为]
- [ ] 零条数据时显示空态并有引导按钮
- [ ] 请求失败时显示原因和重试按钮
- [ ] 超长内容不会撑破布局
- [ ] 控制台无报错，无新增未使用的依赖
先说你的实现方案，我确认后再写代码。 写完之后逐条对照验收标准自检，报告结果。
这份模板配合项目里的约束文件用效果最好：通用的规矩沉淀在文件里，这里只写这一次特有的部分（见规格、提示、约束的分工）。
接着看
先规格后代码 比三段式更前面一步。任务复杂时先要一份规格，再用三段式去实现其中一块。
参考锚定 约束那一段里最有效的一种写法：给具体对照物，别给形容词。
约束沉淀 约束那一段里反复出现的内容，应该往上挪进项目文件，不必每次重写。