三段式提示

目标、约束、验收标准，缺一段就会跑偏。

目标、约束、验收标准。三段写全，返工次数会明显减少。

你会遇到的现象：

• 做出来的东西能跑，但不是你想要的方向
• 它顺手加了一堆你没要的功能
• 收到结果之后不知道该说「好了」还是「再改改」

三段各写什么

目标那一段写成技术任务是最常见的失误。说「加一个 useEffect」，你就放弃了让它提出更好方案的机会；说「进入页面时自动加载最近的记录」，它可能给你一个更合适的做法。官方提示工程指南里的结构原则也是同一个意思：把要达成的结果写清楚，而不是预设实现路径。prompt-guide

三段之间是递进的关系：目标说清楚要什么，约束说清楚不能碰什么，验收标准说清楚怎么判断做到没有。写目标时想的是用户，写约束时想的是项目，写验收时想的是测试——三个视角缺一个，输出就会往那边偏。

验收标准写得好不好，有个简单检验：把标准拿给另一个人看，问他照着这条能不能判断「做完没有」。能，就合格；不能，就还太模糊。写标准的时候只写可观察的结果，别替它写实现。

验收标准怎么写

这一段最值钱，也最容易被跳过——跳过它，你就只能凭感觉说「好了」。它有两个作用：给它一个自检的清单，给你一个收货的依据。

• 写成能逐条判断的句子。「点击提交后按钮变为不可点状态」可以验，「体验流畅」不能。
• **包含边界情况。**零条数据、超长内容、网络失败。这几条一写，四态就自动被覆盖了。
• 写清什么不算完成。「控制台不能有报错」「不能新增未使用的依赖」这类反向标准很有用。
• **让它做完自检并报告。**逐条对照，说明哪几条做到了、哪几条有偏差。成本极低，能省掉一轮来回。

举个例子。「零条数据时显示空态并有引导按钮」这一条写进验收标准，实现的人会去做空态页和按钮，你验收时也只查这一条，两边说的是同一件事；而「体验流畅」这类话，两边各自理解，验收时就变成了争论。

一份可以直接改的模板

模板里方括号的地方都要替换成你这次的具体内容，别整段原样贴。

PROMPT · 三段式

## 目标
[用户能达成什么状态]。这一步要解决的问题是 [具体的卡点]。

## 约束
- 技术：[框架、语言、已有的库]
- 复用：优先使用 src/components/ui 下的已有组件和设计令牌，
  不要新造同类组件、不要硬编码颜色和间距
- 规范：[项目里必须遵守的几条]
- 明确不做：[列出来，包括看起来顺理成章的那些]

## 验收标准
- [ ] [可以逐条判断的行为]
- [ ] 零条数据时显示空态并有引导按钮
- [ ] 请求失败时显示原因和重试按钮
- [ ] 超长内容不会撑破布局
- [ ] 控制台无报错，无新增未使用的依赖

先说你的实现方案，我确认后再写代码。
写完之后逐条对照验收标准自检，报告结果。

这份模板配合项目里的约束文件用效果最好：通用的规矩沉淀在文件里，这里只写这一次特有的部分（见规格、提示、约束的分工）。任务更大时，先在目标之前加一步先规格后代码，把整块的范围定下来，再用三段式实现其中一块。如果 AI 返回的结果里，它自己都说不清哪几条验收标准做到了，说明第三段写得太模糊——回去补标准，别在代码上讨价还价。