让 AI 编写代码的方式正在迅速分化。
一边是通过对话即兴构建的氛围编程；另一边则是本文的主题——规范驱动开发（Spec Driven Development，SDD）。
用一句话概括：SDD 会在让 AI 编写代码之前，先把规范（spec）写入文档并确定下来。
这份文档作为唯一事实来源，引导 AI 完成规划、实现和验证。
本文将整理 SDD 的工作机制、代表性工具 spec-kit 和 Kiro，以及它与氛围编程的使用边界。工具信息截至 2026 年 8 月。
先来看核心摘要。
- SDD 先通过 spec 文档确定“要构建什么”，并将代码视为其产物。
- 流程分为四个阶段：spec（需求）→ plan（技术设计）→ tasks（任务拆分）→ 实现。
- GitHub 的 spec-kit 和 AWS 的 Kiro，是将这套流程工具化的代表产品。
- 通常的边界是：原型使用氛围编程，需要长期维护的产品代码使用 SDD。
为什么规范再次受到重视
先写文档再开发并不是什么新想法。瀑布模型时代的需求规格说明书就是这么做的，但因为过于沉重而被敏捷开发取代。
然而，AI 代理的出现改变了局面。即使面对含糊的需求，人类开发者也会通过提问逐步补充上下文。
相比之下，AI 收到含糊的提示时，会用看似合理的猜测填补空白。结果与需求不符，表面上却看起来正常，形成最棘手的缺陷。
因此产生了“要让 AI 工作，就必须先消除歧义”的需求，规范也再次成为答案。不同之处在于，这次文档是 AI 的执行依据，而不只是给人阅读的材料。
四阶段流水线：从 spec 到 tasks
不同工具的名称略有差异，但基本结构相同。
| 阶段 | 产出物 | 确定内容 |
|---|---|---|
| Specify | spec.md | 构建什么、为什么构建（需求・场景） |
| Plan | plan.md | 如何构建（技术栈・架构） |
| Tasks | tasks.md | 按什么顺序构建（拆分工作单元） |
| Implement | 代码 | 按顺序实现每个 task |
核心规则有两条。
第一，只有在人员审查并批准每个阶段的产出物后，才能进入下一阶段。这样可以在文档阶段过滤歧义，避免它进入代码。
第二，如果实现过程中需求发生变化，应修改 spec 而不是代码，并重新执行后续阶段。因为 spec 必须始终代表最新事实。
换个角度看，代码不再是源头，而是编译 spec 后得到的产物。真正的源代码是文档。
两种工具：spec-kit 和 Kiro
GitHub 的 spec-kit 是一个不依赖特定代理的开源工具包。
它在 Claude Code、Copilot、Gemini CLI 等工具之上加入 /specify、/plan、/tasks 斜杠命令，从而强制执行上述流水线。
它的另一个特点是使用 constitution 文档记录项目不可变的原则。
AWS 的 Kiro 是一款从设计之初就以 SDD 为核心的代理型 IDE。它会创建三种文档：requirements.md、design.md 和 tasks.md。
它的优势在于需求表示法，会使用 EARS（Easy Approach to Requirements Syntax）表示法对需求进行结构化。
这种方法会将需求整理成“系统在某种情况下应当做某事”的句子。
如果你已经在使用 Claude Code 这类通用代理，添加 spec-kit 的引入成本更低。如果想要 IDE 集成体验，Kiro 更合适。
与氛围编程的边界
SDD 并非总是正确选择。创建和审查三种文档确实需要成本，因此将它用于周末原型或一次性脚本，可能会本末倒置。
判断标准是代码的生命周期。如果代码本周就可以丢弃，就用氛围编程快速迭代。
如果代码需要维护和扩展数个月或更久，先用 SDD 消除歧义反而能降低总成本。
实际运行时还要注意一点：spec 与代码不一致却被长期搁置的 drift。
“需求变更必须先改 spec”这条规则一旦失效，spec 就会变成没人信任的文档。这样一来，整个 SDD 就会沦为形式流程。
总结
归根结底，SDD 主张“AI 时代真正的编程语言是自然语言规范”。它将原本用一行提示带过的意图传达，提升为可审查的文档。
下次开发功能时，先别急着写提示，试着先写一份 spec 文档。一天之内就能判断这种方法论是否适合你的工作。