写代码最贵的不是 bug，是返工。需求说「做个登录」，做完发现客户要的是手机号+验证码、不要邮箱；改完又发现要支持企业微信扫码。一周的活白干。根因不在代码，在需求没对齐--模糊想法直接进 IDE，等于蒙眼跑高速。
Spec（需求规格说明）就是那段「先对齐再动手」的缓冲区。但手写 Spec 反人类：产品经理写成流水账，工程师写成伪代码，最后谁都不看。这套 Prompt 包把 Spec 写作拆成六步：先访谈挖需求，再画边界，然后填结构、补约束、写验收、做评审。每一步都有明确的输入输出，让大模型当你的需求分析搭档，而不是替你瞎编。
一、需求澄清访谈
最危险的不是不知道，是「以为对方知道了」。需求方嘴里的「简单加个搜索」，到他脑子里可能是 Elasticsearch 全文检索 + 分词 + 排序。这步让 AI 当 interviewer，反问逼出隐藏假设。
你是资深需求分析师。我要做一个「{{一句话描述功能}}」，但我自己也没想全。
请用访谈的方式帮我澄清，规则如下：
1. 一次只问一个问题，等我回答后再问下一个
2. 优先挖三类盲区：
- 隐藏假设（我默认成立但没说出口的前提）
- 硬约束（时间 / 预算 / 技术栈 / 合规要求）
- 成功标准（做完后怎么判断「成了」）
3. 不要替我做决定，只提问和复述
4. 连续问 5-7 轮后，把我的回答整理成「已明确的事实清单」，标出仍未回答的开放问题
开始：先问我「这个功能服务谁、解决什么麻烦」。要点：访谈别让 AI 一次抛五个问题，人会偷懒随便答。一对一追问才能挖到真约束。我自己用这招最常挖出来的是「哦其实还要考虑离线场景」「这个数据不能存境外」--这些一开始谁都没提。
二、用户故事与边界
需求清楚了，下一步是写下来，而且要写「不做什么」。Spec 最常见的漏洞是只写正常流程，异常和边界全靠开发时拍脑袋。
基于以下需求描述，帮我拆成用户故事 + 边界说明。
需求描述：
{{粘贴上一步的事实清单或原始需求}}
输出格式：
1. 用户故事：As a {{角色}}，I want to {{动作}}，so that {{价值}}
2. 正常流程：编号步骤，从入口到完成
3. 异常流程：列出每一步可能失败的情况（权限不足 / 数据缺失 / 超时 / 并发冲突）
4. 明确不做什么：本期不实现的功能，写清楚原因（避免后期被「顺手加一下」绑架）
5. 边界值：输入长度 / 数量上限 / 并发量 / 超时阈值的具体数字
约束：异常流程数量至少是正常流程的 1.5 倍；不做什么至少列 5 条。为什么异常流要强制 1.5 倍？因为人天然只想着「顺」的路径。逼 AI 多产异常，你再删，比靠自己想全。而「不做什么」这栏是我吃过亏才加的--做过一个项目，客户一句「这个不是本来就该有吗」让范围无限膨胀。
三、功能 Spec 结构
访谈和用户故事是原料，这步把它们灌进一个固定骨架。结构化 Spec 的好处是评审有抓手，开发有对照。
把以下内容整理成功能 Spec，严格用这个结构：
来源材料：
{{粘贴用户故事 + 边界}}
结构：
## 目标
一句话说清这个功能解决什么问题，不提实现方案。
## 目标用户
谁用、什么场景下用、使用频率。
## 核心流程
用编号步骤描述主流程，每步标注输入和输出。
## 接口定义
列出对外暴露的接口（API / 函数 / UI 入口），每个接口写：入参、出参、错误码。
## 数据模型
涉及哪些实体、字段、关系，标出哪些是新增哪些是复用现有。
## 验收标准
每条以「可以 ___」开头，可被测试验证，不写「体验好」这种主观词。
约束：每节不超过 8 行；接口和验收标准必须可被工程师直接对照实现。关键在「验收标准必须可被测试验证」和「接口定义可对照实现」--Spec 不是写散文，是写契约。AI 容易把目标写成「提升用户体验」，要逼它落到「用户在 3 秒内看到加载结果」这种能测的句子。
四、技术约束与风险
功能 Spec 说清「做什么」，技术约束说清「在什么限制下做」。这步最容易偷懒跳过，也最容易后期爆雷。
基于以下功能 Spec，列出技术约束与风险清单。
Spec 摘要：
{{粘贴功能 Spec 的核心部分}}
输出：
1. 性能约束：响应时间 / 吞吐量 / 数据量级，给出具体指标（不是「要快」）
2. 安全与合规：数据存储位置、是否涉及 PII、鉴权方式、合规要求（GDPR / 个保法等）
3. 依赖项：依赖哪些内部服务 / 第三方 API，它们的 SLA 和降级策略
4. 迁移与兼容：是否有历史数据要迁移、是否影响现有功能、回滚方案
5. 风险登记：按「发生概率 x 影响程度」标出 Top 3 风险，每条给一个缓解措施
约束：每项给具体数字或方案，不写「需要关注」「视情况而定」这种废话。踩过坑的都知道，这步的价值在「依赖项的 SLA」和「回滚方案」--集成第三方时默认它永远可用，挂了才发现没降级；上线没回滚预案，出问题只能硬回退代码。让 AI 先把这两项逼出来。
五、验收用例
Spec 写得再漂亮，没验收用例就是废纸。这步把验收标准翻译成可执行的 Given-When-Then，开发照着写测试，QA 照着验。
把以下验收标准转成可测试的验收用例。
验收标准：
{{粘贴功能 Spec 里的验收标准}}
每个用例用 Given-When-Then 格式：
- Given：前置条件（数据状态 / 用户身份 / 系统状态）
- When：触发动作（具体操作或 API 调用）
- Then：预期结果（可断言的状态变化 / 返回值 / 副作用）
要求：
1. 每条验收标准至少 1 个正向用例 + 2 个反向用例（错误输入 / 无权限 / 边界值）
2. Then 里写可断言的结果，不写「显示合理」「体验流畅」
3. 标注哪些用例可以自动化、哪些只能人工验
输出：表格形式，列为「用例 ID | 验收标准 | Given | When | Then | 自动化」Given-When-Then 是 BDD 的老套路，但好用。关键是 Then 必须可断言--「返回 200 且 body 含 orderId」是好的，「页面显示正常」是坏的。AI 默认会写后者，要逼。
六、评审与迭代
Spec 写完不是终点，是评审的起点。这步让 AI 切换角色当挑刺的 reviewer，专找漏洞。
你是严苛的技术评审。请审查以下 Spec，只挑问题不夸优点。
Spec 全文：
{{粘贴完整 Spec}}
检查清单：
1. 歧义：找出 2 处以上可被多种解读的描述，指出歧义并要求澄清
2. 遗漏：对照用户故事，列出 Spec 中未覆盖的场景
3. 矛盾：找出互相冲突的约束或验收标准
4. 不可测：标出无法用测试验证的验收标准
5. 过度设计：标出超出当前需求范围的「顺便实现」
输出：按严重程度排序的问题清单，每条标「必须修 / 建议修 / 可选」三级。
最后给一个「是否可以进入开发」的结论：Yes / No / 有条件 Yes。评审 Prompt 的灵魂在「只挑问题不夸优点」--AI 默认会先夸再挑，把真问题稀释了。强制只说问题，才逼出干货。我自己每次都在这步发现 2-3 个真遗漏，省下后面返工的时间。
怎么用
六步不是线性跑完就完，是循环：
- 第一轮：拿一个模糊想法，跑「需求澄清访谈」5-7 轮，拿到事实清单。
- 第二轮：事实清单喂给「用户故事与边界」，产出结构化故事。
- 第三轮：故事灌进「功能 Spec 结构」，再依次过「技术约束」和「验收用例」。
- 第四轮：完整 Spec 丢给「评审与迭代」，按问题清单改，改完再评一轮。
工具上 Claude 和 DeepSeek 都行。Claude 长上下文适合把完整 Spec 一次喂进去做评审；DeepSeek 写结构化文档很稳，访谈追问也到位。如果你用 Claude Code，可以配合 /spec skill：先用这套 Prompt 出 Spec 初稿，再用 /spec 把 Spec 落成脚手架代码，Spec 和实现就不会脱节。
踩坑
- 让 AI 全编 Spec：AI 不知道你的业务事实，只会编听起来合理的假数据。访谈那步必须你亲自答，领域知识人工补，AI 只负责问对问题和排版。
- 验收标准不可测：「系统应稳定运行」这种没法验。逼 AI 写成「100 并发下 P99 响应 < 500ms」。
- 把方案当需求：需求是「用户要什么」，方案是「怎么做」。Spec 常犯的错是把「用 Redis 缓存」写进需求，锁死实现。目标层写需求，技术层才写方案。
- 评审一轮就收：第一轮评审一定有遗漏。至少跑两轮，第二轮专门盯第一轮改的地方有没有引入新问题。
参考来源
- Anthropic《Prompt engineering》：docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/overview
- Atlassian《Writing effective product specs》：atlassian.com/agile/product-management/product-specs
- Martin Fowler《Specification By Example》：martinfowler.com/bliki/SpecificationByExample.html
- Cucumber《BDD Introduction (Given-When-Then)》：cucumber.io/docs/bdd/