小鹅通聊一个最近在技术社区里出现频率越来越高的词：Spec-Driven Development，中文一般叫规格驱动开发。我第一次看到这个概念时，第一反应是“这不就是 TDD 换了个马甲？”毕竟测试先行、行为驱动这些提法已经够多了。但真正在一个跨团队项目里把它当成一种工作流程去跑之后，我才发现这玩意儿和 TDD、BDD 的差别，比字面上看起来要大得多。它解决的已经不是“代码怎么写”的问题，而是“需求怎么传导、边界怎么对齐、验收怎么定义”的问题。
这篇文章不打算写成一版理论科普，更像是我自己从理解到落地的一次复盘。我会直接讲规格驱动到底在解决什么，一条完整的规格闭环该怎么跑，哪几种规格形态在实践中最常见，以及真正把它塞进日常开发流程时，哪些地方最容易翻车。
1. 先别急着写代码：规格驱动到底在解决什么问题
1.1 需求到代码之间的“断层”是怎么产生的
做过几年项目的人基本都见过这个现象：产品经理脑子里想的是一套规则，写进 PRD 的时候简了一部分，开发理解的时候又丢了一部分，测试写用例的时候再猜了一部分，最后上线后用户操作了一个没被任何人讨论过的边界场景，系统直接给出错误结果。
这不是某个人的态度问题，而是信息在多次转述中天然会发生衰减。传统的开发流程里，需求、设计、编码、测试分别由不同角色在不同时间点完成，每个环节的产物又是天然“不可执行”的文字描述。PRD 里写“库存扣减要以订单提交结果为准”，这行字不会被任何自动化工具验证。它只能靠人反复开会、反复问，最终能不能对齐，很大程度依赖运气。
规格驱动开发想改变的，就是这种靠默契和口头共识维持的协作方式。它的核心思路是：在需求和代码之间插入一层“规格层”。这层规格既不是纯自然语言文档，也不是散落的单元测试，而是用结构化方式描述的、可被自动化验证的契约。规格在代码编写之前先被团队评审，然后在编码后被机器检查。这样做的直接结果，是把“大家觉得应该是一样的”变成“大家确认过确实是一样的”。
1.2 Spec-Driven Development 和 TDD、BDD、契约测试的边界在哪
很多人会把规格驱动和这几个相邻概念搞混，我一开始也分不太清。为了讲清楚，我做了个比较表，直接说明它们关注的层级和产物有什么不同。
| 方法论 | 核心关注点 | 主要产物 | 验证时机 |
|---|---|---|---|
| TDD | 代码单元的输入输出与行为 | 单元测试用例 | 写实现之前先写测试，测试驱动实现 |
| BDD | 业务行为与用户可见价值 | Given-When-Then 场景 | 从行为描述驱动实现与验收 |
| 契约测试 | 服务/模块之间数据交换的一致性 | 消费者与提供者之间的契约文件 | 契约先定，双方按契约开发与验证 |
| Spec-Driven Development | 需求规格从描述到执行的全链路共识 | 可执行规格文件 | 规格先行，实现后持续回归验证 |
可以这样理解：TDD 回答的是“这段代码在某个输入下应该返回什么”；BDD 把关注点从代码单元上移到用户故事，但它更多是一种协作和表达方式；契约测试覆盖的又只是系统间接口这个局部。而规格驱动更像一个容纳层，它把行为要求、接口结构、业务不变量都收拢到一份份规格里，并让这些规格成为开发前评审的对象、开发后验证的依据。
一个更直观的区别是：在 TDD 里，测试写坏了可以改，因为它服务的是代码质量；在规格驱动里，规格是上下游共同确认过的“合同”，一旦发现实现和规格不一致，第一反应不应是让规格迁就代码，而是先判断规格本身是否已经被业务确认过。如果确认过，说明实现有问题；如果没有确认过，说明规格该补流程，而不是偷偷绕过。
1.3 “规格”到底是什么
说到规格，很多人第一反应是“接口文档”或者“需求文档”。这有一点接近，但不完全一样。真正在规格驱动中起作用的规格