先说结论：需求描述的质量，决定 AI 编程返工的次数
同一个智能体、同一个模型，有人一次到位，有人改七八轮还不对——差距通常不在模型，在需求描述。把「做一个登录页」换成含七要素的完整描述，一次通过率能翻倍。本文这七要素来自大量真实项目的返工教训，可直接当 checklist 用。
七要素清单
| 要素 | 烂写法 | 好写法 |
|---|---|---|
| 1. 目标 + 验收标准 | 「做个搜索」 | 「文章标题/正文模糊搜索，500ms 内返回，空结果有提示」 |
| 2. 技术约束 | （不提） | 「 PHP 8.3 + WP 7.1，不用第三方依赖，遵守 WPCS 」 |
| 3. 输入上下文 | 「按我的项目改」 | 「相关文件是 inc/search.php，现有逻辑见 @file 」 |
| 4. 输出物定义 | 「优化一下」 | 「只改 inc/search.php，不改模板，输出 diff 」 |
| 5. 反例 | 「别乱来」 | 「不要引入新 CSS 框架，不要动既有 URL 结构」 |
| 6. 边界条件 | （不提） | 「搜索词含 HTML 标签时要转义；结果为 0 的分支也要处理」 |
| 7. 验证方式 | 「能用就行」 | 「改完跑 php -l 和现有测试；没有测试就给 curl 验证命令」 |
为什么这七条恰好有效
拆开看，七要素对应模型最容易出错的四类信息缺口：目标缺口（要素 1 、 6，不知道「对」长什么样）、边界缺口（要素 2 、 5，把不该动的东西动了）、上下文缺口（要素 3，凭空猜测项目结构）、验证缺口（要素 4 、 7，改完不知道谁来确认）。 Anthropic 官方提示词工程指南的核心建议——给模型明确任务描述和成功标准——在这里同样成立。
反例（要素 5）的优先级经常被低估。告诉智能体「不要重构无关代码」「不要升级依赖版本」，能挡掉一半的越界改动。
实操：把七要素变成日常流程
- 先用一句话写目标，再立刻跟一条「完成的判定标准」，没有判定标准就不算写完需求。
- 列出技术约束和禁区（版本、框架、不许动的文件），宁可多列一条，不要事后返工。
- 附上相关文件路径或代码片段，让模型读真实代码而不是猜。
- 写清边界条件：空输入、超长输入、异常分支各怎么处理。
- 结尾固定写验证方式：跑什么命令、看什么输出。复杂任务先要求模型出方案再动手。
两个进阶技巧
- 先 Plan 后 Act：大改动先让智能体输出实现计划，你确认计划无误再放行写码，这一步能把方向性返工几乎清零（详见本站的 Plan/Act 分离文）；
- 报错时带全上下文：贴完整报错栈 + 相关代码 + 你已尝试的动作，只贴一句「跑不通」只会得到瞎猜式修复——AI 生成代码调试有专门的四步定位法。
需求描述能力本质上是「把模糊意图翻译成可验证契约」的能力，这恰恰是工程师在 AI 时代最值钱的技能。
延伸阅读（站内）
需求描述太长会不会反而降低效果？
长不是问题，噪声才是。七要素每一条都是高信号信息；真正要砍的是重复表述和情绪化描述（「上次就写错了」这类）。一屏以内的结构化描述效果最好。
小改动也要七要素齐全吗？
不用。一次性的小修小补，目标 + 约束 + 验证三要素就够。七要素是复杂任务的 checklist，简单任务按需取用，否则流程成本超过收益。
验收标准写不出来怎么办？
这正是最该警惕的信号——你自己都不知道「对」长什么样，模型更不可能知道。先花五分钟把验收标准想清楚（哪怕就是「打开页面点按钮 X，出现 Y 」），再开始对话。
参考来源：Anthropic 提示词工程官方指南；本站实战项目经验总结。本文为原创整理。
评论 (0)