SDD 不是三个工具——它是一个八阶段的技术栈
Martin Fowler 关于 SDD 工具的文章值得一读。Fowler 有一种罕见的能力——能够精确地命名事物，他将规格驱动开发框架为对 AI 辅助编码中"上下文坍塌"问题的回应，这是我见过的对核心问题最清晰的阐述。
但分析止步于三个工具。而这个停止点模糊了 SDD 在实践中为何困难。
Fowler 说得对的地方
Fowler 识别出大多数 SDD 实现所收敛的三个工具：规格格式、验证机制和审批门控。他正确地指出这三个原语是必要的。没有验证的规格是一张愿望清单。没有审批门控的验证会产生混乱——智能体实现了半批准的需求，然后又不得不撤销。
他关于瓶颈已从代码生成转移到正确性验证的观察也是准确且被低估的。问题不在于 AI 智能体写代码慢。问题在于当需求模糊时，它们会自信地朝错误方向写——而且没有人注意到，直到功能上线。
三工具框架的不足之处
Fowler 描述的三个工具——规格、验证、审批——涵盖了实现循环。它们没有覆盖实现之前发生的事，也没有覆盖之后发生的事。
实现之前，存在一个问题。开发者有一个想法。这个想法需要被外化（头脑风暴）、结构化为验收标准（规格）、进行完整性压力测试（挑战），并在任何智能体触碰代码之前验证实现就绪性（就绪检查）。这四个阶段发生在审批步骤之前，跳过它们正是为什么规格到达审批门控时带着过于模糊、无法正确实现的标准。
合并之后，存在另一个问题。在合并时通过验收标准的代码，可能在几周后随着相邻变更的积累而偏离规格。Fowler 的三个工具对此没有任何说明。审批-验证周期在合并时结束。
八个阶段
完整的 SDD 生命周期有八个阶段：
1. BRAINSTORM → 在想法消散之前捕获它
2. SPEC → 将其结构化为可测试的验收标准
3. CHALLENGE → 对规格进行对抗性探测，寻找差距和矛盾
4. READINESS CHECK → 在开始编码之前验证规格的可实现性
5. APPROVE → 人类签署合同
6. IMPLEMENT → 智能体根据规格执行
7. VALIDATE → 根据每个标准验证实现
8. HEAL → 回溯检测并纠正合并后的漂移Fowler 的三个工具对应阶段 5、6 和 7。这留下了五个未覆盖的阶段。
团队最常跳过的阶段是第 3 阶段（挑战）和第 8 阶段（修复）。跳过挑战意味着验收标准到达审批时带有隐藏的歧义，这些歧义只在实现过程中才会浮现。跳过修复意味着漂移在合并后悄悄积累，规格变成了历史文物而非活的合同。
这对工具选择的意义
如果你通过询问"它是否有规格格式、验证机制和审批门控"来评估 SDD 工具，当前生态中几乎所有工具都能通过。这是错误的问题。
正确的问题是：哪个工具覆盖所有八个阶段，哪些阶段需要手动干预？
覆盖阶段 5–7 但不覆盖 1–4 的工具，迫使开发者在工具之外管理实现前的工作流。挑战和就绪检查阶段——它们存在的目的恰恰是捕捉人类遗漏的东西——缺失了。
覆盖阶段 5–7 但不覆盖阶段 8 的工具，将合并视为生命周期的终点。对于频繁有相邻变更的长期代码库来说，这是一个显著的缺口。
Fowler 的框架仍然有用
这些并非对 Fowler 分析的批评。三工具框架是对最小可行 SDD 工作流的准确描述。对于首次采用 SDD 的团队，阶段 5、6 和 7 是正确的起点——它们以最小的开销提供了大部分价值。
当团队尝试扩展时，该框架变成了天花板。在更高速度、使用并行智能体和长期规格的情况下，三工具窗口之外的阶段产生的摩擦限制了吞吐量。
完整的技术栈
SDD 工具不是功能清单。它是一条流水线。问题不是工具是否支持规格——而是工具是否端到端地覆盖了流水线，包括大多数分析所忽略的阶段。
从头脑风暴到修复，没有间隙。
延伸阅读：更多规格驱动开发文章 · 自主模式：使用 /autonomous-sdd 实现端到端 SDD · Planu 与 SDD 工具对比