从 DDD、TDD 到 SDD：适配 AI 的开发范式

作为古法程序员，一般都经历过很多开发范式。

DDD，领域驱动，让我们先看业务边界和领域模型。

TDD，测试驱动，让我们先写验证条件，再写实现。

现在 AI 编程开始普及，可以认真聊一个更适配 AI 的范式：SDD，Spec-Driven Development，规格驱动开发。

过去一年，SDD 从一类博客话题，变成了 AI Coding 里的默认架构选择。 Thoughtworks 、 Martin Fowler 、 GitHub 、 Amazon 、 Red Hat 、 InfoQ，以及一份覆盖 67 个来源的学术综述，都在 2025 到 2026 年把注意力放到了同一个方向：先把软件应该做什么写清楚，再让 AI 去生成、修改和验证代码。

问题已经从“要不要写规格”，变成了“用哪种规格体系”。

为什么 AI 编程更需要 SDD

AI 写代码的效率提升是真实的，副作用也是真实的。

一项 95 名开发者参与的随机对照实验显示，AI 工具能让任务完成速度提升 55.8% 。但 METR 针对成熟代码库的研究发现，有经验的开发者使用 AI 后反而慢了 19% 。 DORA 的报告也提到，AI 采用率每提升 25%，交付稳定性会下降 7.2% 。 Faros AI 追踪一万多名开发者后看到：合并 PR 增加 98%，评审时间增加 91%，Bug 增加 9% 。

这几个数字放在一起，意思很清楚：AI 能把产出推高，也会把偏差推高。

微软研究院的 Shuvendu Lahiri 给过一个很准确的说法：AI 生成的代码是“看起来合理”，并非“天然正确”。用户真正想要什么，程序实际做了什么，中间有一段语义距离。 AI 编程的可靠性问题，很多就卡在这里。

SDD 要处理的就是这段距离。

它把“需求、设计、任务、测试、约束”变成 AI 必须遵守的合同。 AI 可以写得更快，但它不能只凭上下文感觉往前冲。每一步都要回到规格，检查生成的代码是否符合约定。

SDD 怎么工作

可以把 SDD 压缩成三件事。

第一，四阶段工作流：先写规格，说明软件应该做什么；再写计划，说明怎么做；然后小步实现；最后验证代码是否满足规格。每个阶段都会产出一个工件，用来约束下一步。

第二，三种严格程度：

• Spec-first：先写规格再写代码，但规格后面可能漂移。
• Spec-anchored：规格和代码一起维护，测试负责检查二者是否对齐。
• Spec-as-source：人只改规格，代码由系统重新生成。

第三，治理强度可以分层：

• 事后评审：AI 写完后，人再看。
• 自然语言规格：先写需求，再让 AI 生成。
• 可执行合同：用测试和结构化规格限制 Agent 。
• 宪法式治理：把不可违反的原则写成元规格，每次变更都要遵守。

临时原型可以只做事后评审。成熟生产系统、频繁调用 AI 的代码库，就需要更强的约束。

五类 SDD 工具，各自把复杂度放在哪里

Spec Kit：把复杂度放进宪法。

这是 GitHub 的 MIT 许可工具包。核心文件是 .specify/memory/constitution.md，它位于所有规格和实现之上。 Agent 每次变更都要遵守这份“宪法”。它的命令包括 /speckit.constitution、/speckit.specify、/speckit.plan、/speckit.tasks、/speckit.analyze、/speckit.implement 等。规格、计划、任务和实现被串成一条链。

它适合约束强、代码库成熟、需要长期维护的团队。代价是启动成本更高。

BMAD-METHOD：把复杂度放进角色。

BMAD 用一组具名角色协作：分析、产品、架构、开发、 UX 、文档，每个角色负责不同工件。它还有 .decision-log.md，记录关键决策；进入编码前会经过 implementation-readiness gate，结果可能是 PASS 、 CONCERNS 或 FAIL 。

这套方法更像一个小型 AI 研发组织。规格在里面承担的是跨角色沟通协议。

OpenSpec：把复杂度放进变更文件夹。

OpenSpec 面向已有代码库。每个功能变更都有自己的目录，里面放 proposal.md、specs/、design.md、tasks.md。变更完成后，通过归档命令把增量规格合入长期文档。

它的优势是轻量，适合棕地项目：不用全盘重来，只围绕每次变更建立可追踪合同。

GSD：把复杂度放进上下文管理。

GSD 的判断很直接：AI 会随着会话变长而退化，所以主会话只保留 30% 到 40% 上下文，重活交给新开的子 Agent 。它用 PROJECT.md、REQUIREMENTS.md、ROADMAP.md、STATE.md、CONTEXT.md 保存跨会话状态。

这类工具关心的重点不在流程仪式，重点在上下文窗口本身。对个人开发者和高频 Agent 工作流很有吸引力。

Superpowers：把复杂度放进 Agent 行为。

Superpowers 通过技能自动触发工作流。用户不用手动判断该调用哪个命令，系统在合适的时候加载技能。它包含 brainstorming 、 writing-plans 、 subagent-driven-development 、 test-driven-development 、 requesting-code-review 等流程。

它最激进的地方是 TDD 约束：如果代码先于测试出现，就删除代码，重新走红灯、绿灯、重构。

反对意见也值得听

Matt Pocock 的 Skills For Real Engineers 经常被放进同一批 SDD 工具里，但它其实在反驳这个分类。

他的观点是：软件基本功比过去更重要。坏代码从来都贵，在 AI 加速后更贵。规格到代码的运动，如果让团队减少对系统设计的投入，风险会被放大。

他的工具更关注接口设计、共享设计概念、 DDD 的统一语言、 TDD 的节奏、模块边界等基本功。默认模式是“灰盒”：人设计接口，AI 负责实现。

这条反对意见不能忽略。 METR 的研究显示，成熟代码库里的资深开发者使用 AI 反而变慢，这说明瓶颈可能不在规格质量，而在代码库质量和系统设计质量。

SDD 可以减少“看起来合理但不合规”的代码。它解决不了所有架构债。

该怎么选

把这几类工具当成不同的可靠性理论来看，会更清楚。

• 你的问题是原则容易漂移：看 Spec Kit 。
• 你的问题是角色协作混乱：看 BMAD 。
• 你的问题是老代码库改动难追踪：看 OpenSpec 。
• 你的问题是上下文越来越脏：看 GSD 。
• 你的问题是 Agent 经常忘流程：看 Superpowers 。
• 你的问题是系统设计和代码质量本身很差：先看 Pocock 那条路线。

SDD 的价值不在于换一个缩写。它把 AI 编程从“让模型多写点代码”，拉回到工程世界里熟悉的东西：边界、约束、验证、可追溯。

古法程序员应该很容易理解这件事。

DDD 关心业务语言，TDD 关心可验证行为，SDD 关心 AI 参与开发时的规格合同。

AI 写代码越快，这份合同越重要。

来源：https://x.com/alphasignalai/status/2057523186766377470?s=52