规格驱动开发：让 agent 不再瞎猜

你已经把该调的都调好了：权限模式选对了，CLAUDE.md 写了，上下文也懂得及时清理。然后你敲下一句「给设置页加一个导出功能」，十分钟后 agent 交回三百行代码、两个新文件、一条绿色的测试通过提示。

你打开一看：功能是有了，但导出的是 JSON，你要的是 OPML；文件写在了项目根目录，你以为它会走系统的保存对话框；顺手还改了三个和这件事无关的组件。

这时候最容易得出的结论是「模型不行」。但把同一句话交给一位没见过这个项目的人类工程师，结果大概率一样。问题不在执行者，在于那句话里，你脑子里的一半信息从来没被写下来——文件格式、落盘位置、允许改动的范围、什么算做完。agent 没有瞎猜的余地时才不会瞎猜；你没写，它就必须猜。

规格驱动开发（Spec-Driven Development，下文简称 SDD） 就是把这一半信息挪出脑子、写成可以评审、可以验收、可以随需求一起演进的东西，再让 agent 照着它干活。

这篇教程会带你完成一条完整链路：

1. 先看清 agent 到底在什么地方开始猜（第1章）。
2. 写出第一份能用的规格，而不是一份漂亮的文档（第2、3章）。
3. 把规格拆成计划和任务，让每一步都能单独验收（第4章）。
4. 用采访的方式把规格从你脑子里问出来，而不是自己憋（第5章）。
5. 给 agent 一个它自己能跑的检查，让循环自己收敛（第6章）。
6. 处理规格失效、工具选型，以及最重要的一件事——判断这次到底该不该写规格（第7、8、9章）。
7. 用一个真实小需求把整条链路跑一遍（第10章）。

读之前的两个说明

这不是瀑布模型的复辟。 瀑布的问题是「一次把所有东西定死，然后不许改」。SDD 的规格是小的、按需求切片的、可以在实现过程中被推翻重写的。第7章专门讲规格被现实推翻时该怎么办——那是常态，不是意外。

这篇和《上下文工程》是一对。 上下文工程管的是「agent 的注意力预算」：它能看见什么、看见多少、什么时候该清理。规格驱动开发管的是另一半：它到底该做什么、做到什么程度算完。两件事互不替代——上下文再干净，意图模糊照样跑偏；规格再精确，上下文塞爆了照样执行不下去。

全篇会用同一个例子：给一个 RSS 阅读器加一个功能——把用户的订阅列表导出成 OPML 文件。它足够小，能在一章之内讲完；又足够真实，有格式、有边界、有异常分支。