Three-Part Prompt
Goal, constraints, acceptance criteria. Write all three and your rework drops noticeably.
What you'll run into
- 做出来的东西能跑，但不是你想要的方向
- 它顺手加了一堆你没要的功能
- 收到结果之后不知道该说「好了」还是「再改改」
What to write in each part
| 段 | 写法 | 常见错误 |
|---|---|---|
| 目标 | 用户能达成什么状态，为什么需要 | 写成技术任务：「加一个 useEffect」 |
| 约束 | 技术栈、已有组件、必须遵守的规范、明确不做的 | 只写要做的，不写不做的 |
| 验收标准 | 可以逐条勾的清单，最好包含边界情况 | 写成「做得好一点」这类没法验的话 |
How to write acceptance criteria
This part is the most valuable and the easiest to skip. It does two things: gives the AI a self-check list, and gives you a basis for acceptance.
- Write it as sentences you can check item by item. "After clicking submit, the button becomes disabled" is verifiable; "smooth experience" is not.
- Include edge cases. Zero records, extra-long content, network failure. Write these three and the four states get covered automatically.
- State what doesn't count as done. Reverse criteria like "the console must have no errors" and "no unused dependencies added" are very useful.
- Have it self-check and report when done. Check item by item and state which ones passed and which had deviations. The cost is tiny and it can save a round trip.
A template you can edit directly
PROMPT · three-part
## 目标 [用户能达成什么状态]。这一步要解决的问题是 [具体的卡点]。 ## 约束 - 技术：[框架、语言、已有的库] - 复用：优先使用 src/components/ui 下的已有组件和设计令牌， 不要新造同类组件、不要硬编码颜色和间距 - 规范：[项目里必须遵守的几条] - 明确不做：[列出来，包括看起来顺理成章的那些] ## 验收标准 - [ ] [可以逐条判断的行为] - [ ] 零条数据时显示空态并有引导按钮 - [ ] 请求失败时显示原因和重试按钮 - [ ] 超长内容不会撑破布局 - [ ] 控制台无报错，无新增未使用的依赖 先说你的实现方案，我确认后再写代码。 写完之后逐条对照验收标准自检，报告结果。
This template works best alongside the project's constraints file: the general rules live in the file, and here you only write what's specific to this round (see Spec, Prompt, Constraints: Who Does What).