规格驱动开发实战：一个需求从规格跑到验收

10.1 起点：一句话需求

场景：你在维护一个 RSS 阅读器，用户提了一句——

能不能让我把订阅列表导出来？

按第9章的决策表判断：改动跨 2-3 个文件，涉及对外的文件格式（导出的文件会被别的软件读，格式定错了要返工），但你对「该做什么」基本清楚。落在高不可逆 + 低不确定，对应轻规格：重点写非目标和验收标准。

进入计划模式，防止它一边聊一边改文件：

claude --permission-mode plan

然后发第5章的采访提示词。两轮问答后，被问出这些原本没定的点：

定稿后的 SPEC.md 就是第2章 2.4 节那一份。注意它是被问出来的，不是憋出来的——上表五行里，至少有三行是你在自己写规格时会漏掉的。

规格落盘后，/clear 或开新会话，让它读 SPEC.md 生成计划：

读 SPEC.md，生成实现计划写入 PLAN.md。
技术方案部分给出两种做法并说明取舍，不要直接下结论。
明确列出涉及文件和风险。先不要写代码。

它给出两种方案（引入 XML 构建库 vs 模板字符串手写），你按规格里「不引入新依赖」的非目标选了后者——这次选择只花了十秒钟，因为非目标已经写在纸上了。如果规格里没这一条，你会看到一份用了新库的实现，然后在代码审查时才发现。

计划确认后生成任务，就是第4章 4.3 节那三张卡。

按任务卡逐张执行，每张卡自带验收方式：

执行 T1：实现 src/lib/opml.ts 的 serializeToOpml。
先按 SPEC.md 的验收标准 1、2、4 写测试，让我确认测试是否正确表达了标准，
确认后再写实现，然后运行 npm test 直到全绿。
把你运行的命令和输出贴出来。

三处细节值得注意：

T1、T2 完成后，交付前跑一次独立审查：

用一个子代理对照 SPEC.md 审查本次改动。检查每条验收标准是否实现、
异常路径是否有测试、有没有改动范围外的文件。
只报影响正确性或违反规格的问题。

假设它报回来一条：folder 名里的特殊字符没有转义——规格的验收标准 4 只写了「标题」，实现也就只处理了标题。这条值得修，而且顺手要把规格的标准 4 改成「标题或分组名」。规格漏了，实现就会漏。这正是规格作为检查基准的价值：它让漏洞变得可指认。

功能上线两周后，用户反馈想按分组导出。按第7章：这是需求本身变了，写变更提案，不是直接改规格。提案就是 7.2 节那一份，五分钟写完，它明确告诉你 T1 要补测试、T2 要返工——在动手之前你就知道了成本。

阶段	你做什么	agent 做什么	产物
判断	按象限判断严格度	—	「这次写轻规格」
采访	回答问题	提问、整理	SPEC.md
计划	选方案	给备选方案与取舍	PLAN.md
拆分	扫一眼粒度	拆任务、回链标准	任务卡
实现	评审测试、看证据	写测试、写实现、跑检查	代码 + 测试输出
审查	判断哪些要修	独立上下文对照规格	问题清单
变更	判断值不值得	写提案	变更提案

你在整条链路里的位置很清楚：做判断、做选择、评审标准。具体的写作和执行都交出去了。

给应用加一个离线模式，网络不好的时候也能用。

交付前逐条打勾。全部通过，说明这次的规格是有效的，不只是有。

如果 14 条里你只做得到 5 条，也远好过一条都没有。这套流程的收益是渐进的，不是全有或全无。

到这里，你手上应该有：一份最小规格模板、一套 EARS 改写方法、一个采访提示词、一张严格度决策表、一份自检量表。

接下来最有价值的一步，不是读更多资料，而是把这套流程固化成你自己的工具：

这四件事都不难，加起来一个下午能做完，之后每一个需求都在受益。

最后回到开头那句话：agent 不是在瞎猜，它是在填你留下的空白。 规格驱动开发不是给它戴上镣铐，而是把你脑子里那份本来就存在的规格，写到一个它和你都能看见的地方。