代码不再是源代码:Spec-Driven Development 完全指南

GitHub Spec Kit 12.8 万星背后，AI 编程正在经历一场范式转向

先问一个问题：你上一次写代码之前，把需求写下来了吗？

不是写在聊天记录里那种，而是写成一个结构清晰、有验收标准、能进 Git 版本控制的文件。

如果没有，你大概率正在经历这些场景：

AI 帮你写的第 10 轮代码，已经和第 1 轮的需求对不上号
你说"加个登录功能"，AI 自作主张选了一套你根本不想用的方案
代码能跑，但没人说得清它到底对不对

这不是你的问题，这是 Vibe Coding（氛围编程）的天然缺陷。而 2026 年，整个行业给出的答案是：Spec-Driven Development（规格驱动开发，简称 SDD）。GitHub 官方工具包 Spec Kit 上线不到一年拿下 12.8 万 stars，OpenSpec 也有 6.5 万。今天这篇文章，就把概念、工具和落地方法一次讲透。

一、什么是 SDD？规范是新的源代码

SDD 的核心思想一句话就能概括：在写代码之前，先写一份结构化、可验证、可演进的规范，让规范成为人和 AI 的"单一事实来源"。

GitHub 官方对此的表述很精辟："在这个新世界里，维护软件意味着演进规范。开发的通用语言上移到了更高层次，代码只是最后一英里的解决方案。"

Tessl 的定义更直白：规范而不是代码，是主要的产物。规范用结构化、可测试的语言描述意图，Agent 负责生成代码以匹配它们。

理解 SDD，抓住三个关键词就够了：

关键词	含义
Spec-First（规范先行）	规范是开发中最早产生、最具权威性的工件，决定了系统的"基因"
Intent-Driven（意图驱动）	人定义 WHAT 和 WHY，AI 实现 HOW；你从"代码生产者"转型为"意图架构师"
先对齐再编码	写代码前先对"要做什么"达成共识，规范成为人和 AI 的共同语言

换句话说：代码不再是"唯一事实来源"，而是规范的一个实现结果。 就像编译器的输出之于源码——你改代码不如改规范，规范一变，代码重新生成即可。

这个类比值得细品：传统开发里，源码是"源"，编译产物是"果"；在 SDD 里，规范成了"源"，代码降级为"果"。谁握着源，谁就握着系统的演进权——这正是"代码不再是源代码"这句话的真正含义。

还需要知道一个由 Thoughtworks 工程师 Birgitta Böckeler（发表于 Martin Fowler 博客）提出的层级框架，它帮你判断自己处在 SDD 的哪一层：

层级	名称	特征
Level 1	Spec-first（规范优先）	先写规范用于当下任务，任务完成后规范可能被丢弃（大多数工具目前所在层级）
Level 2	Spec-anchored（规范锚定）	规范纳入版本控制、长期保留，随功能演进持续更新（工具们的目标层级）
Level 3	Spec-as-source（规范即源）	规范是唯一可编辑的源文件，代码完全由规范生成（未来愿景）

理解了这三层，后面看工具对比时，你就知道它们在往哪个方向努力了。

二、SDD 和 TDD/BDD/DDD 是什么关系？

很多人的第一反应是：又来一个 XXD？TDD 还没整明白呢。

这里要澄清一个关键认知：SDD 不是替代 TDD/BDD/DDD，而是叠加在它们之上的元方法论。 它解决的是"系统从意图到实现始终对齐"的问题，粒度更大、层级更高。

为什么说它是"元方法论"？因为 TDD/BDD/DDD 各自规定的是"用什么载体表达意图"——测试、行为场景、领域模型；而 SDD 规定的是"意图如何组织、如何驱动实现、如何验证对齐"这一整套机制。它不取代任何载体，而是把已有的方法论编排进同一条流水线。

方法	驱动核心	规范载体	粒度	在 SDD 中的角色
TDD	测试	单元测试	代码级	执行层验证工具（保证"代码对"）
BDD	行为	Gherkin 场景（Given/When/Then）	功能级	规范层业务场景描述（保证"事情对"）
DDD	领域模型	统一语言	业务级	规范层语义基础（保证"概念对"）
SDD	规范	结构化 Spec + EARS 验收标准	系统级	元方法论，整合前三者

一个推荐的组合拳：DDD 定义领域模型 → BDD 描述业务场景 → SDD 管理结构化规范 → TDD 验证单元实现。四者各司其职，而不是互相打架。

所以别再纠结"SDD 是不是要取代 TDD"了。TDD 依然负责保证代码正确，SDD 负责保证从一开始就做对的事情。前者是"把事情做对"，后者是"做对的事情"。

三、为什么 2026 年 SDD 突然爆火？

SDD 的思想其实源远流长——上世纪 80 年代的 Z Language、TLA+，90 年代的契约式编程，2010 年代的 OpenAPI，都是"先定义再实现"的变体。但直到 AI 编程普及，它才真正迎来爆发。

直接导火索，是 Vibe Coding 的三大失败模式：

1. 意图漂移（Intent Drift）：一句"加个登录功能"严重欠定义，模型会自行选择"合理默认值"，而这些默认值很少符合团队的真实意图。

2. 上下文衰减（Context Decay）：需求只存在于聊天记录里。当代码库增长超过 Agent 的有效上下文窗口，AI 会遗忘早期决策并悄悄与之矛盾——第 10 轮修改的代码与第 1 轮需求之间，可能已经没有对应关系。

3. 输出不可验证（Unverifiable Output）：没有明确的验收标准，就无法判断 Agent 的代码是否"正确"，代码审查变成无休止的拉锯。

GitClear 2025 年报告（分析了 2020-2024 年 2.11 亿行改动代码）给出了数据支撑：复制粘贴代码行占改动的比例从 8.3% 升至 12.3%，而"移动"代码（重构代理指标）从 2021 年的 25% 降至 2024 年的不足 10%——2024 年，复制粘贴首次超过移动代码。AI 在帮我们"堆代码"，而不是"理代码"。

SDD 的解法很直接：把真相写进磁盘文件，AI 才不会每次都忘。 规范成为持久化的真相源，约束 AI 在边界内创作，用规范审查取代逐行 code review，让审计变得可行。

Microsoft 有一句很精辟的点评："SDD is version control for your thinking."（SDD 是思考的版本控制）——当代码可以被 AI 秒级重写时，真正有价值的不是代码本身，而是代码背后的决策。

一句话总结 Vibe Coding 与 SDD 的本质分野：前者把上下文放在聊天记录里（易失、不可追溯），后者把上下文放进版本控制里（持久、可审计）。这不是工具之争，而是"上下文放在哪"之争。

四、2026 年 SDD 工具生态全景

现在进入实战环节。先看一张总览表（Star 数为 2026-08-15 通过 GitHub API 实时获取）：

工具	开发者	Stars	定位	安装方式
GitHub Spec Kit	GitHub 官方	128,726	重规范、企业级工具包	`uv tool install specify-cli`
OpenSpec	Fission-AI	64,949	轻量级、存量项目优先	`npm install -g @fission-ai/openspec`
AWS Kiro	AWS	4,187	Spec 驱动 IDE	官网下载桌面应用
SpecD	specd-sdd 社区	12	代码图谱 + 上下文编译	`npm install -g @specd/specd`
SpecDD	specdd 社区	28	开源框架、.sdd 文件	`npm install --global specdd`

⚠️ 注：SpecD（12⭐）和 SpecDD（28⭐）为极早期项目，功能描述基于其 README 自述，生产使用需谨慎评估。

4.1 GitHub Spec Kit：官方出品的"重规范"派

GitHub 官方工具包，核心维护者是 Den Delimarsky 和 John Lam。它的最大特点是流程完整、仪式感强：引入"项目宪法"（constitution.md，一组不可变的架构原则，如 Library-First、测试优先等九条宪章）约束所有技术决策，再用七个斜杠命令驱动完整工作流：

命令	目标产物	说明
`/speckit.constitution`	项目宪法	项目治理原则
`/speckit.specify`	spec.md	功能规格（只写 WHAT 和 WHY）
`/speckit.plan`	plan.md、contracts/	技术实现计划
`/speckit.clarify`	澄清区	需求澄清（在 plan 之前）
`/speckit.tasks`	tasks.md	可执行任务分解
`/speckit.analyze`	一致性分析报告	跨文档一致性校验（实现前质检闸门）
`/speckit.implement`	代码 + 测试	按任务顺序执行实现

安装也很简单（需要先装 uv）：

uv tool install specify-clispecify init <PROJECT_NAME> --integration copilot

优点：GitHub 官方背书、不绑定特定 AI 工具（支持 30+ 种）、流程完整清晰、宪法治理机制强、可高度定制。缺点：仪式感强，对个人开发者或小改动"太重"；命令多、概念多，学习成本约 1-2 周；Martin Fowler 团队评测认为其 Markdown 产物冗长重复，审查负担大。适用场景：企业标准化 AI 开发流程、多 AI 代理混合环境、金融/医疗等高质量要求场景。

4.2 OpenSpec：轻量灵活的"存量项目"派

如果说 Spec Kit 是重型装甲，OpenSpec 就是轻骑兵。它的哲学写在 README 里：流动而非僵化、迭代而非瀑布、简单而非复杂、为存量项目而生。

核心设计是双区域：openspec/specs/ 存放稳定长期规格，openspec/changes/ 存放具体变更提案。一条命令就能启动整个流程：

npm install -g @fission-ai/openspec@latestcd your-projectopenspec init   # 交互式选择 AI 工具（支持 30+ 种）

然后在你的 AI 助手里执行 /opsx:propose，一步创建变更并生成所有规划制品（proposal.md、specs/、design.md、tasks.md）。之后用 /opsx:apply 实现、/opsx:verify 验证对齐、/opsx:archive 归档。

优点：轻量灵活、无刚性阶段门、支持 30+ AI 助手、对存量项目友好、非侵入式（不修改现有代码）、上手成本最低。缺点：无内置 TDD 循环；规范粒度控制依赖使用者自觉；不同 AI 工具命令语法有差异（Claude Code 用 /opsx:propose，Cursor 用 /opsx-propose）。适用场景：存量项目增量引入 SDD、个人/小团队、多 AI 工具混用环境。

4.3 AWS Kiro：把 SDD 内嵌进 IDE

AWS 出品的 Agentic AI IDE（基于 VS Code fork），官方口号是"Beyond Vibe Coding"。它的特色是把整个 SDD 工作流内嵌进 IDE：.kiro/specs/ 目录下用 EARS 记法（WHEN ... THE SYSTEM SHALL ... SO THAT ...，被 Airbus/NASA 采用的需求语法）写需求，再生成设计文档和追溯到需求编号的任务清单。

还有 Agent Hooks 自动化（保存文件自动 lint、新建文件自动生成测试）和 Steering 项目级指令（类似 CLAUDE.md）。定价从 Free（50 credits/月）到 Power（$200/月，10000 credits）不等。

优点：开箱即用、零工具链搭建成本、EARS 记法让需求可执行、Hooks 自动化能力强。缺点：不支持自带 API Key（无法接入 GPT/Gemini）；credit 消耗不透明；Spec 模式对小任务太重（修一个小 bug 会被拆成 4 个 user story、16 条验收标准）；国内网络延迟明显。适用场景：AWS 生态团队、从零开始的新功能、需求模糊需要结构化梳理的场景。

4.4 SpecD 与 SpecDD：前沿探索方向

这两个都是极早期项目（Star 数只有两位数），但思路值得关注。

SpecD 主打"上下文编译，而非发现"——不给 Agent 文件列表让它自己找，而是在每个生命周期步骤用 specd context 计算并交付 Agent 所需的完整指令块；同时把代码库和 specs 索引成可查询的代码图谱，支持影响分析和热点检测。适合追求上下文精确性的微服务团队。

SpecDD 走极简路线：在代码旁边放小的、人类可读的 .sdd 文件（约 20 个章节，类似 Gherkin 风格），通过路径解析自动关联（itinerary.sdd ↔ itinerary.js），语言无关、无厂商锁定。它的 README 自述"修正循环从 10-20 轮降至 1-2 轮"，但这是内部测试数据，未经独立验证。

4.5 怎么选？一张决策表

你的情况	推荐工具
0→1 新项目、需要强流程控制、团队协作	GitHub Spec Kit
存量项目增量引入、个人/小团队、多工具混用	OpenSpec
追求上下文精确性、微服务架构	SpecD （前沿，谨慎评估）
最小仪式感、规范就近放置	SpecDD （前沿，谨慎评估）
AWS 生态、想要开箱即用 IDE	AWS Kiro
受监管行业、需要审计轨迹	Tessl （商业闭源）

五、标准工作流：从提案到归档的完整闭环

不管用哪个工具，SDD 的标准工作流是相通的。以 OpenSpec 为例：

/opsx:explore（探索，可选）→ /opsx:propose（提案）→ 人工审查制品 → /opsx:apply（逐任务实现）→ 验证对齐 → /opsx:archive（归档）

七个阶段的核心分工如下：

阶段	主导者	核心产出	关键动作
Proposal（提案）	人	proposal.md	定义 WHY：问题陈述、目标、范围（含/不含）、风险与回滚
Specs（规格）	人 + AI	specs/	定义 WHAT：需求 + 验收场景（Given/When/Then 或 EARS）
Design（设计）	人 + AI	design.md	定义 HOW：架构、接口、数据设计
Tasks（任务）	AI	tasks.md	Checklist：原子化实施清单，标注依赖和测试策略
Implement（实现）	AI	代码 + 测试	按 tasks.md 逐任务执行，每次只读一个任务及其相关规格
Verify（验证）	人 + AI	测试报告	自动化测试 + 规格比对，确认符合验收标准
Archive（归档）	AI	归档目录	迁移到 archive/ 并附时间戳，留存审计痕迹

记住核心原则：人定义 WHAT，AI 实现 HOW。 这不是僵硬的瀑布——OpenSpec 无刚性阶段门，可随时修改任何制品；Spec Kit 则有明确门禁（analyze 在 tasks 后、implement 前充当质检闸门）。

一个变更的制品结构长这样（OpenSpec）：

openspec/changes/add-dark-mode/├── proposal.md   # WHY：为什么做、改了什么├── specs/        # WHAT：需求和验收场景├── design.md     # HOW：技术方案、架构设计└── tasks.md      # Checklist：原子化实施清单

写规范时，一份好规范应包含六个要素：预期结果（用结果陈述描述目标，而非"做一个登录流程"）、范围边界（明确范围外，一句"OAuth 不在本任务范围内"能省下无数次返工）、约束和假设（技术栈、第三方 API 限制）、已定决策（数据库 schema、加密库等）、任务拆分（离散子任务，边做边验）、验证标准（哪些测试要过、哪些边界情况要处理）。

六、最佳实践与踩坑经验

最佳实践清单：

先试点再推广：1-2 名开发者在非关键新特性上实践 4 周 → 团队扩展 5-12 周 → 全组织推广
渐进式引入：新特性用 SDD，旧模块触发式补规范，比全量重构现实得多
规范纳入 Git 版本控制，随系统一起演进（活文档，不是一次性产物）
验收标准是最重要的部分，用表格/EARS/Gherkin 等结构化格式
每个功能 PR 附上对应规格链接，评审时先看规格再看代码
模型分层：写规范用最强模型（规范错误会向下游传播）、实现用中档模型、验证用快速模型
收窄上下文：每次只给 Agent 一个任务及其相关规格，减少跑偏和幻觉

常见踩坑：

误区	后果	正确做法
把 README 当规范	规范无法验证	使用结构化格式（模板/DSL/Schema）
规范写成散文	AI 无法稳定解析	结构化格式 + 验收标准
规范与实现不做 Diff 校验	规范与代码脱节	引入漂移检测（/opsx:verify、/speckit.analyze）
没有版本化策略	无法回溯	规范纳入 Git 管理
跳过人工审查直接实现	退回"氛围驱动"	审查步骤是 SDD 价值的核心
过度细化规范	效率低下	平衡粒度，别为每个函数写规格

最后提醒一句：SDD 不是万能的。快速原型、探索性开发、简单 Bug 修复、一次性脚本，这些场景用 SDD 反而是"杀鸡用牛刀"。社区的共识模式是：先用 Vibe Coding 探索原型，等它值得保留时再写规格并对照重新生成——"vibe-code a spike, distill the result into a spec, then spec-drive the production version."

七、趋势判断：SDD、MCP 与 Agent Skills 的关系

2026 年，SDD 生态里还有一个容易混淆的问题：MCP、Agent Skills、SDD 到底什么关系？

一句话：三者是不同层次、互补关系。

层次	角色	类比
MCP （连接协议）	定义 Agent 如何访问外部世界（数据库、API、文件系统）	USB 接口 / 门禁卡
Agent Skills （知识格式）	SKILL.md 文件夹，教 Agent 如何完成一类工作	新员工入职手册
SDD （方法论）	规范如何组织、如何驱动开发全流程	工程纪律 / 生产流水线

MCP 是"手"（够得着外部世界），Skills 是"操作手册"（知道怎么用），SDD 是"工程流程"（决定先做什么、按什么顺序做）。三者并不冲突，SDD 工具本身也通过 MCP Server 暴露能力、以 Skills 形式分发（比如 OpenSpec 会生成 .claude/skills/）。

展望 2027：短期看，SDD 大概率会成为生产代码的默认方式，成熟工程师的典型模式是"Vibe Coding 做原型，SDD 驱动一切上线的东西"。中期看，可能出现"规范层统一"——SDD 创建功能规范，AI-BDD 消费生成 Gherkin，AI 契约工具生成 API 规范，AI 充当层间编译器。长期看，开发者角色会从"代码工匠"转型为"意图架构师"——最有价值的不是写最聪明代码的人，而是写最清晰规范的人。

不过也要泼一盆冷水：Thoughtworks 技术雷达目前只把 SDD 放在"评估"环，并警告"为 AI 手工编写详细规则最终无法规模化"；也有社区声音认为它是"Waterfall 2.0"（marmelab 的 François Zaninotto 直言 SDD 试图解决错误的问题）；Birgitta Böckeler 则提醒存在"虚假的控制感"——即使有模板和检查清单，Agent 仍可能忽略指示或执行过头。工具仍在快速演进，现在投入大量时间学特定工具不一定有长期回报，但"先写规格再写程序"的核心概念不会变。

写在最后

SDD 的本质，是把"上下文放在哪"这个问题给出了一个更可靠的答案：放进版本控制，而不是聊天记录。 它不取代 TDD/BDD/DDD，而是把它们编排进同一条流水线；它不否定 Vibe Coding，而是让它回归"探索原型"的本职。

如果你被 Vibe Coding 的翻车现场困扰过，不妨从 OpenSpec 开始——一条命令初始化，30 分钟跑通第一个变更。先写规格再写程序，这个习惯一旦养成，你的 AI 会第一次变得"可预期"。

💡 觉得有用就点个"在看"，让更多被 Vibe Coding 坑过的朋友看到～你在用哪个工具实践 SDD？评论区聊聊。

参考来源

GitHub Spec Kit 仓库（128,726⭐，2026-08-15 实测） - https://github.com/github/spec-kit
OpenSpec 仓库（64,949⭐，2026-08-15 实测） - https://github.com/Fission-AI/OpenSpec
Martin Fowler：Understanding Spec-Driven-Development: Kiro, spec-kit, and Tessl（Birgitta Böckeler） - https://martinfowler.com/articles/exploring-gen-ai/sdd-3-tools.html
Thoughtworks 技术雷达：规范驱动开发（评估环） - https://www.thoughtworks.com/zh-cn/radar/techniques/spec-driven-development
marmelab：Spec-Driven Development: The Waterfall Strikes Back - https://marmelab.com/blog/2025/11/12/spec-driven-development-waterfall-strikes-back.html
GitHub 官方 SDD 博客 - https://github.blog/ai-and-ml/generative-ai/spec-driven-development-with-ai-get-started-with-a-new-open-source-toolkit/
Kiro 仓库（4,187⭐，2026-08-15 实测） - https://github.com/kirodotdev/Kiro
SpecD 仓库（12⭐）、SpecDD 仓库（28⭐） - https://github.com/specd-sdd/SpecD 、https://github.com/specdd/specdd
腾讯云：规范驱动开发深入解析 - https://cloud.tencent.com/developer/article/2631688