聊一聊AI时代的规范驱动开发（SDD）

今天想和大家聊一聊一个新的驱动开发形式：规范驱动开发（SDD）

我们正处在一个 AI 编程几乎无处不在的时代。写代码、补逻辑、生成模块、重构工程，AI 好像什么都能做。很多人第一次用到 AI 编程的时候，都会有一种非常强烈的震撼感，觉得"好像写代码这件事情突然变简单了"。

但是很快，问题也随之而来。

你会发现，AI 在写一些零散的小逻辑、小函数的时候，表现得非常好。但一旦进入真实工程，一旦需求变复杂，一旦任务变多、变长、变持续，你就会开始频繁地遇到各种问题。它要么不能精确理解你的需求，要么写着写着就开始偏离方向，要么改了一个地方，其他地方全都坏掉，要么在一次又一次的修改中逐渐失控。

很多人会把这些问题归结为一句话：

"现在的 AI 还不够聪明。"

但我越来越觉得，这其实并不完全是 AI 的问题。

因为如果我们冷静下来想一想，会发现一件非常有意思的事情——这些问题，其实在人类工程中早就存在了。

如果一个工程项目里，没有统一的规范，没有清晰的结构，没有明确的边界和约束，那这个项目对任何一个新加入的人来说，都是极其痛苦的。

每个人都有自己的编码风格，每个人都有自己的抽象方式，每个人都按照自己的理解去组织目录、命名变量、拆分模块。短期内也许还能推进，但只要时间一长，这个项目就会变得越来越难理解、越来越难维护，最终变成一个谁都不敢动的"黑盒"。

所以你会发现一个非常残酷但又非常真实的事实：

AI 在工程中的表现，其实和人是高度一致的。至少在"对上下文、规范和约束的依赖"这一点上，AI 和人是高度一致的。

你完全可以把 AI 当成一个人。一个非常依赖上下文、极度依赖说明、完全按照你给他的材料去理解世界的人。

如果你给一个人一堆零散的信息、模糊的需求、不完整的说明，却期望他能做出一个结构清晰、长期可维护的工程，那本身就是不现实的。AI 也是一样。

这也是我今天想讲的核心主题：规范驱动开发。

在我看来，规范驱动开发并不是一个因为 AI 时代才突然出现的新概念。它早就存在了。

我们过去可能叫它工程规范、架构设计、文档驱动、接口契约，只是现在，在 AI 编程的背景下，它被重新推到了舞台中央。

为什么？

因为 AI 把所有"不规范"的问题都放大了。

你可以容忍一个同事写得随意一点，你可以靠沟通、靠经验、靠时间慢慢对齐。但 AI 不会。它只会严格按照你给它的上下文和指令去行动。如果你给它的是混乱的，它反馈给你的，一定也是混乱的。

所以我认为，规范驱动开发至少可以拆成两个方向来看。

第一个方向，是我们如何对 AI 进行说明，如何让它更好地载入上下文，理解当前工程，并且在一个清晰的约束体系中进行开发和编程。

第二个方向，是我们作为人，如何更好地与 AI 沟通，如何像对待产品、对待团队成员一样去描述需求，通过多轮对话、多种形式的表达、配合文档输出，不断地对齐理解。

这两件事，其实是一体的。

你会发现，当我们说"AI 总是写错"的时候，换一个角度看，本质上是我们没有把需求说清楚，没有把规范说清楚，没有把边界说清楚。

但这里马上就会遇到一个现实问题。

但现实是，并不是每一个开发者，都具备搭建整个工程骨架的能力。也不是每一个人，都已经形成了一套成熟的架构哲学和工程思想。

大多数开发者，其实更偏向于一个"逻辑实现者"的角色。我们很擅长把产品经理的需求翻译成代码，很擅长写业务逻辑、处理流程、实现功能，但并不一定具备完整的产品视角和工程视角。

那问题来了。

是不是只有具备高深架构能力的人，才能进行规范驱动开发？

是不是普通开发者就只能"随缘用 AI"？

我觉得也未必。

因为在代码世界里，我们早就遇到过类似的问题，而解决方式大家都非常熟悉——脚手架。

脚手架并不会帮你写业务逻辑，但它会帮你定义目录结构、模块边界、封装方式和基本的工程规范。它把一个原本高度依赖个人经验的事情，变成了一套可复用的、可传承的工程结构。

那同样的问题，我们为什么不能问一句：

文档、需求、规范，本身是不是也需要脚手架？

不同团队、不同社区，给出的解法并不一样。

这也是为什么最近一段时间，大家会看到一些围绕"规范驱动开发"的工具和方法开始出现，比如 OpenSpec、Spec Kit、BMad。

我先说 OpenSpec。

在我理解里，OpenSpec 并不是一个用来"写代码"的工具，它更像是一套规范驱动的文档骨架。它关注的是一件事：如何把系统的当前状态、行为约束和演进方式，明确地写下来，并且让这些内容成为 AI 和人共同遵守的事实来源。

你不再是通过零散的对话去告诉 AI"这个系统大概是怎样的"，而是通过一份明确的规格文档，让系统的行为边界变得清晰、稳定、可审查。每一次变更，都是在已有规格之上的显式修改，而不是隐式漂移。

这对于 AI 来说非常重要。因为它最怕的，不是复杂，而是模糊。因为复杂可以被拆解，但模糊无法被推理。

再来看 Spec Kit。

如果说 OpenSpec 更偏向于规范的"描述层"，那么 Spec Kit 更偏向于把规范真正带到工程里去。它关注的是从零到一，如何通过一套标准化的规范模板和流程，把一个想法转化为一个具备清晰结构的工程起点。

它不要求你一开始就具备完整的架构哲学，而是通过一套流程，引导你先把"要做什么""为什么做""边界在哪里"这些事情讲清楚，再进入实现阶段。

而 BMad，则是另一个层面的东西。

在我看来，BMad 解决的并不是"规范写成什么样"，而是"谁在什么时候，用什么方式参与规范的生成、拆解和执行"。它通过方法论，把 AI 拆解成多个具备明确职责的角色，把原本杂糅在一起的思考过程拆分开来。

在这种工作流中，AI 不再只是一个统一的"助手"，而是多个角色的衍生。需求分析、方案设计、实现执行，各自遵循不同的规则和节奏。这种方式，本质上是在用工程化的方法，约束 AI 的思考路径。

再往前一步，当这些规范和方法论开始和编辑器结合，比如像 Kiro 这样的工具，你会发现效果会进一步放大。

因为编辑器本身具备对工程的感知能力。它知道文件结构，知道代码的静态错误，知道你正在编辑的上下文。当规范和工程感知结合在一起，AI 就不再是"盲人摸象"，而是能够在一个真实、可感知的环境中工作。

但说到这里，我必须强调一件非常重要的事情。

这些工具，不是万能的。

规范驱动开发并不是说，只要你选对了某个框架、某个工具，就一定能得到完美的结果。如果你使用 AI 的方式，是让 AI 引导你思考，而不是你去规划 AI 的工作方式，那你永远无法发挥出 AI 在工程层面的真正价值。

你的思想高度，决定了 AI 的工程高度。

我一直很喜欢一个比喻。一个真正的武侠高手，哪怕手里只有一根树枝，那也是一把锋利的剑。但如果是一个书生，就算给他一把绝世神兵，他也很难发挥出万分之一的力量。

规范驱动开发也是一样。再好的框架，它始终只是一个工具。它不能替代你的思想，也不能自动补全你的工程能力。它所能做的，只是尽可能帮你把思考显性化、结构化，让 AI 更容易理解你的意图。

甚至在很多时候，一份你亲手写的、结构清晰、逻辑严密的文档，对 AI 的约束效果，可能比任何工具都要好。因为归根结底，这些工具本身，也是在通过文档和上下文，把信息注入给 AI。

所以我想表达的并不是：你一定要用哪一个工具。

我真正想说的是，不管你使用什么样的 AI 编程工具，思想一定要先行。规范不是为了限制创造，而是为了让创造在一个可控的空间里发生。

当你的思想足够清晰，你对工程、对产品、对需求有足够深的理解时，你会发现，AI 会变得非常好用。你可以非常自由地调度它，让它承担不同角色，完成不同层次的工作。

而如果思想本身是混乱的，那么再强大的 AI，也只会把混乱放大。

规范驱动开发，和 AI 编程的真正价值，从来不在于工具本身，而在于我们如何思考、如何表达、如何把复杂的问题讲清楚。

当你能做到这一点的时候，AI 才真正成为你的工程能力的延伸。