规格驱动开发实践：把需求评审还给AI工作流

一、当结构化工作流遇上大模型

过去一两年，“规格驱动开发”（Spec-Driven Development，SDD）逐渐成为大模型辅助编程的主流方法论之一。它的核心思想并不复杂：不再指望一句“帮我实现某功能”就能换来高质量代码，而是先让模型充分理解上下文，产出结构化的规格与变更提案，经过确认后再进入代码实施，最后通过验证与归档沉淀为项目资产。

以我们团队的实践为例，完整的工作流是一个五阶段闭环：

1. 探索：模型通读现有代码库与历史规格，梳理现状、约束与潜在技术债务；
2. 提案：模型输出变更提案，包括目标、方案设计、影响范围与验收标准；
3. 实施：严格按照提案落码，不做提案之外的自由发挥；
4. 验证：运行测试，逐条对照验收标准确认达成；
5. 归档：将本次变更沉淀为规格历史，供后续迭代引用。

这套结构带来了肉眼可见的改善：模型的输出不再天马行空，跨文件的大改动有了全局依据，复杂项目从“完全不可用”变成了“基本可跑”。对于长期被大模型“一次性脚本”式输出折磨的团队来说，这几乎是一次范式跃迁。

二、新的问题：流程对了，质量还是不行

然而好景不长，实践很快暴露出新的短板。无论换用哪一代旗舰模型，也无论工作流本身设计得多精细，最终产出依然反复出现两类典型问题：

• 隐藏缺陷：正常路径跑得通，但边界条件、异常分支、并发与超时等场景没有覆盖，上线后不定时引爆；
• 结构劣化：为了快速交付不断打补丁，代码逐渐演变成无人敢动的“屎山”，可维护性断崖式下跌。

换句话说，工作流解决了“模型乱写”的问题，却没有解决“写什么”的问题。这些代码让人始终不敢直接推上生产环境。

三、第一次自救：实施之后的代码审查

我的第一反应是给工作流打补丁：在实施阶段完成后，追加一个专职负责代码审查的子智能体，对每次变更做一轮评审。这个方案在一定程度上有效——它确实能拦下部分架构层面的不合理设计和实现层面的低级错误，作为兜底机制有其存在价值。

但从统计意义上讲，它治标不治本。大量问题依然要等到项目运行一段时间后才暴露出来：场景没考虑全、边界情况没处理、改了A模块却忘记同步调整依赖它的B模块。更让人沮丧的是，事后审查发现的问题越多，返工成本越高——因为此时代码已经写完，推翻规格意味着大面积重写。

四、复盘：我们一直在审查错误的对象

跳出具体工具，重新审视整条AI编程工作流，我才意识到症结所在：

作为程序员，我们太关注“代码写得好不好”，于是下意识地从代码层面去审视一切；却完全忽略了模型生成的规格文件本身的质量。

团队的常态是：讨论完需求、生成完提案文件后，默认“文档即真理”，直接放行进入实施。模型忠实执行了一份有问题的规格，产出自然是有问题的代码——出了事再怪模型能力不行，其实是找错了责任人。这类缺陷的本质是“输入型缺陷”：错的不是模型的翻译能力，而是喂给它的输入。

这也解释了为什么事后代码审查收效有限：代码审查的对照物就是规格本身，它只能发现“代码与规格不符”的偏差，却永远无法发现“规格本身就是错的”。规格中的模糊表述、遗漏场景和自相矛盾，会被模型忠实地翻译成代码；而审查者拿着同一份有问题的规格做对照，当然看不出问题。

五、古法编程的启示：需求评审不可省略

回想传统的软件研发流程，当产品经理提交一份需求时，开发团队在动手编码之前，有一个雷打不动的环节——需求评审。需求文档里的每一处模糊表述、每一个未定义的边界、每一条互相冲突的约束，都要在评审会上被揪出来。老一辈工程师有句话：“文档没审清楚，我们绝不干活。”这是用无数延期与事故换来的纪律。

讽刺的是，把编码工作交给大模型之后，我们反而把这个环节弄丢了。人类工程师写代码之前尚且需要评审需求，凭什么假设模型生成的规格文件天然完备且正确？模型不会主动质疑你的需求，它只会把需求里所有的坑照单全收。

六、把评审前移：给规格文件做一次“代码级”审查

结论由此得出：应当用审查代码的同等力度去审查规格文件，而且这种审查必须发生在实施之前。具体落地时，我们在“提案”与“实施”之间引入一个独立的规格评审环节，由与提案生成者相互独立的评审子智能体（或人机协作）逐项检查，四个维度如下：

1. 完整性：需求描述的功能点是否全部体现？每个功能点的输入、输出、前置条件是否明确定义？边界条件是否穷举——空值、极大值、极小值、并发、超时、失败重试？
2. 一致性：规格内部是否存在自相矛盾的描述？是否与代码库中已有的规格历史冲突？本次变更会影响哪些既有模块，是否逐一列出？
3. 可验证性：每一条需求是否都能转化为明确的验收标准？是否附带了可执行的测试场景清单？
4. 假设显性化：模型在生成规格时做了哪些隐含假设（例如默认单线程、默认数据量在某个量级、默认上游服务永远可用）？这些假设是否需要与需求方确认？

评审不通过的规格一律打回重写，绝不带病进入实施阶段。一份可落地的检查清单示意如下：

# 规格评审检查清单（示意）
completeness:            # 完整性
  - 所有功能点均定义了输入/输出/前置条件
  - 边界场景已枚举：空值、极值、并发、超时、重试
consistency:             # 一致性
  - 规格内部无自相矛盾之处
  - 与历史规格无冲突，受影响模块已逐一列出
verifiability:           # 可验证性
  - 每条需求可转化为明确验收标准
  - 附带可执行的测试场景清单
assumptions:             # 假设显性化
  - 隐含假设已列出并与需求方确认

七、评审前移之后，工作流的体感变化

把规格评审补进工作流后，实践体感发生了质变：

• 缺陷拦截点前移：大量原本要到运行期甚至线上才会暴露的问题，在纸面上就被拦截，修复成本从“回归测试+热修复”降为“改几行文档”；
• 跨模块遗漏显著减少：一致性检查强制枚举影响面，“改了东忘了西”的老毛病大幅缓解；
• 验证不再流于形式：评审通过的验收标准，天然成为验证阶段的测试清单，规格、测试与验证形成闭环；
• 规格库成为团队资产：经过评审的高质量规格归档后，后续迭代可以放心引用，模型对存量逻辑的幻觉也明显减少。

八、可以复制的五条实践建议

最后，把这段时间踩过的坑浓缩成几条可复制的做法：

1. 像对待生产代码一样对待规格文件：给它版本号、评审记录与变更历史，规格即代码；
2. 评审必须发生在实施之前：事后审查只能兜底止损，事前评审才能从源头免疫；
3. 评审者与生成者必须解耦：无论是换人还是换一个独立的模型实例，避免“自己审自己”带来的确认偏误；
4. 用固定检查清单替代自由发挥：完整性、一致性、可验证性、假设显性化四大维度逐项过，不依赖评审者的灵感与状态；
5. 让评审产出物直接变成验收标准：避免规格、实现、测试变成三张互不相干的“皮”。

结语

规格驱动开发的真正价值，不在于让大模型“照着文档写代码”，而在于让团队重新拥有了工程化的抓手。工具链可以更换、模型可以迭代，但“文档没审清楚绝不干活”这条古法纪律，在AI时代不仅没有过时，反而因为执行者换成了模型而变得更加重要——毕竟，模型永远不会质疑你的需求，所以质疑需求的任务，必须由流程与评审来承担。