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