Spec-Driven Development (SDD): The Definitive 2026 Guide

规范驱动开发（SDD）：2026 年权威指南

规范驱动开发（SDD）是一种软件开发方法论，其中可执行、受版本控制的规范------而不是代码------成为唯一的真实来源。团队（或 AI 编码代理）首先编写详细规范，描述系统应该做什么，然后衍生实现计划，将其拆分为原子任务，最后再生成代码。规范保持活跃：当需求变化时，你先编辑规范，再重新生成相关代码。

SDD 起源于 2025 年，是对大型语言模型"随性编码"失败模式的直接响应------这种模式会产生看似合理但偏离意图的代码、幻觉式 API，并随着项目规模增长而退化。到 2026 年，每个主要 AI 编码工具------GitHub Spec Kit、AWS Kiro、Claude Code、Cursor、OpenSpec、BMAD、Tessl、Google Antigravity------都已经发布了自有形式的 SDD。

本指南是 2026 年规范驱动开发的权威参考：它是什么、为何重要、与 TDD 和随性编码相比如何、使规范可被 AI 读取的 EARS 记法，以及针对 Claude Code、GitHub Copilot 和 Cursor 的具体工作流头对头评测。

快读摘要 - 60 秒了解规范驱动开发

它是什么：一种将规范视为工件、将代码视为构建产出的做法，类似于 .c 文件编译为二进制文件。
为什么现在：AI 编码代理功能强大但缺乏上下文。精确规范为它们提供了约束，使其能交付不偏离的可运行代码。
四个阶段：规范（Specify）→ 计划（Plan）→ 任务（Tasks）→ 实现（Implement），每个阶段都设有人类检查点。
主要工具：GitHub Spec Kit（开源、与模型无关）、AWS Kiro（智能 IDE）、Claude Code skills、Cursor Plan Mode、OpenSpec、BMAD-METHOD、Tessl。
记法：EARS（Easy Approach to Requirements Syntax）------五种模式，将模糊需求转换为可测试、可被 AI 解析的语句。
结果：早期采用者报告显示，在非平凡任务中，AI 代理的第一次成功率提高约 3--10 倍。

什么是规范驱动开发？

规范驱动开发（SDD）是一种方法论，其中书面规范被视为软件项目的主要、可执行工件，代码则由人类、AI 代理或两者共同从该规范再生生成。规范以结构化形式记录意图、行为、边缘情况和非功能性需求，人类和语言模型都能读取并据此行动。这与结构化内容的原理相同：信息遵循清晰模型时更加可复用、更可靠。

在规范驱动工作流中：

规范与代码一起版本管理（通常位于同一仓库中的 specs/ 或 .specify/ 目录）。
规范是唯一真实来源。当出现 bug 或功能请求时，先更新规范；然后重新生成或修改代码以匹配规范。
规范是结构化的。它使用固定模式------用户故事、EARS 记法的验收标准、架构约束、项目级规则"宪法"------而不是自由格式的散文。
规范在某种意义上是可执行的，代理可以驱动它。编码代理可以读取规范，生成计划，将其拆分为任务，编写代码，并根据原始验收标准验证结果。

这颠覆了传统流程。在传统开发中，需求是扔过墙的 Word 文档，代码变成真实来源，规范在一个 sprint 内腐烂。SDD 中，规范留在仓库中，随着项目演进，代码可以从规范拆掉重建。

规范驱动开发定义（简短版）

规范驱动开发是一种软件方法论，其中受版本控制的结构化规范------而非代码------是真实来源，代码由人类和 AI 编码代理根据这些规范生成或维护。

为什么规范驱动开发在 2026 年很重要

转向 SDD 不是一种时尚潮流。这是对 2024--2025 年当基于 LLM 的编码代理成为主流后出现的三种失败模式的直接回应：

意图漂移。像"添加登录"这样的提示严重不完整。模型会选择合理的默认行为------但这些默认行为很少匹配团队实际想要的结果。
上下文衰减。当代码库超过代理的有效上下文窗口时，它会忘记早期决策并默默地与之矛盾。
输出不可验证。没有明确的验收标准，就无法判断代理生成的代码是否"正确"。代码审查会变得无休止。

精确的规范可以修复这三点。它是人类意图与机器执行之间缺失的一层。2025--2026 年 GitHub 和 AWS 帖子中反复出现的短语是："规范就是提示"。

数据支持

GitHub 报告称，使用 Spec Kit 的团队在内部项目上交付功能时，与临时提示相比，"从头重新生成"周期约少一个数量级。
AWS Kiro 记录的真实客户案例显示，当功能先写成规范后，40 小时的功能可以在不到 8 小时的人类时间内交付。
DeepLearning.AI 在 2025 年末推出了"使用编码代理的规范驱动开发"短期课程，由 Sandeep Dinesh 授课，这表明该方法论已经从实验阶段进入主流。

规范驱动开发与随性编码

"随性编码"------由 Andrej Karpathy 在 2025 年初推广------描述了用自然语言提示 AI 代理并接受其产出的工作流。它对原型非常快，但扩展性很差。

	Vibe Coding	Spec-driven development
真实来源	生成代码	版本化规范
最佳场景	一次性脚本、原型、演示	生产代码、数月项目、团队协作
失败模式	沉默漂移、幻觉 API、上下文丢失	过度规范、起步慢、若不维护则规范腐烂
可审查性	比较代码（人类未必编写）	比较规范（人为编写）
AI 代理自治	高但脆弱	高且受限
新工程师入门	读代码，祝你好运	读规范，然后读代码

Vibe编码对于SDD来说，就像"只需将其键入终端"对于shell脚本和版本控制的部署自动化一样。他们不是敌人------vibe编码是一种很好的探索方式------但生产系统需要一个规范层。

这也是为什么团队在选择面向生产的工具时会把 AI 编码平台与传统页面构建器进行比较。

规范驱动开发与 TDD、BDD 的区别

SDD 常被误解为与 TDD（测试驱动开发）和 BDD（行为驱动开发）相同。它们有共同基因，但在什么被视为规范工件方面不同。

	TDD	BDD	SDD（规范驱动）
规范工件	失败单元测试	Gherkin 场景（Given/When/Then）	版本化规范 + EARS 验收标准
操作顺序	测试 → 代码 → 重构	场景 → 步骤定义 → 代码	规范 → 计划 → 任务 → 代码（通常由代理完成）
主要执行者	开发者	开发者 + QA	开发者 + 代理
关注点	单元级代码正确性	用户视角的行为与协作	在编码前的需求清晰与可追踪性

TDD 表示"先写测试"。BDD 表示"先写业务语言描述的行为"。SDD 表示"先写完整规范------行为、架构、边界情况、约束------然后让代理根据它生成代码、测试和文档"。

SDD 包含了 BDD 的部分内容：EARS 风格的验收标准本质上是 Gherkin 的更严格兄弟。良好的 SDD 工作流仍会产出单元和集成测试------但它们是从规范生成的，而不是反过来。

规范驱动开发如何工作：四个阶段

每个主要的 SDD 框架------GitHub Spec Kit、Kiro、OpenSpec、BMAD------都归结为相同的四阶段循环。名称不同，结构相同。

阶段 1 - 规范（"做什么"和"为什么"）

你（或处于面试模式的代理）编写一份规范文档，包含：

用户故事------"作为一个 $角色$ ，我希望 $能力$ ，以便 $成果$ 。"
EARS 记法的验收标准------可测试、无歧义的语句（稍后详述）。
功能性需求------系统必须执行的动作。
非功能性需求------性能预算、可访问性目标、安全约束、可观测性。
范围外说明------系统不会做什么，以便约束代理。

这是最慢但最重要的阶段。花在这里的时间在后续阶段会获得 10 倍回报。

阶段 2 - 计划（"怎样做"）

代理（或人类+代理）将规范转化为技术计划：

架构选择与理由。
数据模型与 schema。
API 合约。
库与框架选择，并遵守项目"宪法"的约束（例如"没有 ADR 不得新增运行时依赖"）。
如果涉及现有代码，还要制定迁移策略。

输出是一个 plan.md（或等价文件），与规范一起提交。

阶段 3 - 任务（"按什么顺序"）

计划被拆分为原子、可独立交付的任务。每个任务包含：

单一目标。
输入（要阅读的文件、相关规范）。
输出（要创建/修改的文件、要编写的测试）。
验收检查。

一份好的任务清单看起来像一个初级工程师都能执行的清单。这就是重点：代理实际上变成了一个快速的初级工程师。

阶段 4 - 实现（"开始做"）

代理逐个完成任务。每个任务都以验证步骤结束：生成的代码是否满足验收标准？如果没有，代理会迭代------这是受规范约束的迭代，而不是无边界地自由运行。

最关键的是：每个阶段边界都有人类审查。规范先审，计划再审，任务再审，然后才进入实现。这是 SDD 可预测性的核心。

EARS 记法：让 AI 代理真正遵循的规范写法

EARS（Easy Approach to Requirements Syntax）由 Alistair Mavin 及其在 Rolls-Royce 的同事于 2009 年提出。它成为 SDD 的秘密武器，因为它生成的需求对 LLM 来说足够无歧义。

EARS 定义了五种模式：

普适型------始终为真。"系统应记录每次认证尝试。"
事件驱动型------WHEN [trigger] THE [system] SHALL [response]。"当用户提交登录表单时，系统应将凭证与认证提供商验证。"
状态驱动型------WHILE [state] THE [system] SHALL [behavior]。"当同步进行时，系统应显示不可取消的进度指示器。"
非期望行为型------IF [condition] THEN THE [system] SHALL [response]。"如果凭证验证在 60 秒内失败三次，则系统应锁定账户 15 分钟。"
可选功能型------WHERE [feature is included] THE [system] SHALL [behavior]。"如果启用了多因素认证，则系统应在密码验证后要求 TOTP 代码。"

这对 AI 代理很重要：每个模式都折叠为单一、可测试的断言。触发条件、范围和响应没有歧义。代理可以读取 EARS 需求、生成代码并编写测试来验证它------无需猜测。

GitHub Spec Kit 和 BMAD 核心的"宪法"文件，本质上就是关于项目本身的一系列普适 EARS 语句："系统应使用 TypeScript 严格模式。系统应拒绝降低测试覆盖率的 PR。系统应避免对不再维护的软件包产生运行时依赖。"

2026 年最顶尖的规范驱动开发工具

2025 年 7 月（GitHub Spec Kit 发布）至 2026 年初，SDD 工具生态迅速爆发。下面是头对头比较。

1. GitHub Spec Kit

参考实现，由 GitHub 于 2025 年 9 月开源。

它是什么：一个 CLI（specify）加上一组提示、模板和斜杠命令，可与 Claude Code、GitHub Copilot、Cursor、Codex CLI、Gemini CLI、opencode、Windsurf 和 Qwen Code 配合使用。
是否与模型无关：是的，这是核心特性。
斜杠命令：/constitution、/specify、/clarify、/plan、/tasks、/analyze、/implement、/checklist。
擅长场景：希望在多个 AI 编码工具之间保持标准 SDD 工作流、避免被供应商锁定的团队。
仓库：GitHub 上的 github/spec-kit。

2. AWS Kiro

Amazon 的智能 IDE，从零开始为 SDD 构建。

它是什么：一个独立 IDE（VS Code 分支），规范、计划、任务和代码共存于同一工作区，并与 AWS 深度集成。
杀手功能："Hooks"------在每次代理动作后运行的自动护栏（测试、lint、安全扫描）。
最适合：已经在 AWS 生态中的团队，尤其是构建无服务器应用的团队。
注意事项：可移植性低于 Spec Kit；绑定于 Kiro 应用。

3. Claude Code 与 cc-sdd

Anthropic 于 2025 年底通过 Claude Code 的"skills"系统率先提供了一级 SDD 支持。

它是什么：一组技能（/sdd:specify、/sdd:plan 等），使 Claude Code 在终端内即可执行 SDD 工作流。
最适合：已经使用 Claude Code 的独立开发者和小团队。
可与之搭配：GitHub Spec Kit（Spec Kit 提示可原生在 Claude Code 中使用）。

4. Cursor（Plan Mode + AGENTS.md）

Cursor 采用稍有不同的路径：它不是发布专门的斜杠命令，而是依赖 Plan Mode 和 AGENTS.md 约定。

Plan Mode：只读模式，Cursor 在进行任何编辑前先探索代码库并生成计划。
AGENTS.md：项目级宪法，每次代理操作都必须遵守。
MCP 支持：Spec Kit 和 OpenSpec 均可通过 MCP 服务器在 Cursor 中使用。
最适合：想要最大灵活性和 IDE 优先工作流的团队。

5. OpenSpec

一个轻量级、框架无关的 SDD 库，在独立开发者社区中获得了认可。

它是什么：一个 CLI 加上规范格式（Markdown + YAML frontmatter），任何代理都能读取。
最适合：想要使用 SDD 但不想绑定到供应商工具链的团队。

6. BMAD-METHOD

一个社区方法论，早于 GitHub Spec Kit 出现并影响了其设计。

什么是 BMAD 方法：一套惯例和提示包，用于规范优先开发。
特点：高度强调项目"宪法"，以及在同一路径中进行多代理角色扮演（Architect、PM、QA、Dev）。

7. Tessl

一个专注于企业合规性的商业 SDD 平台。

它是什么：一个具备审计轨迹、受监管行业模板和 CI 集成的规范驱动开发环境。
最适合：金融科技、健康科技和其他受监管领域。

8. Google Antigravity

Google 于 2025 年末推出的产品------一个围绕"代理优先"模型构建的桌面 IDE，每个操作都来自规范。

最适合：探索受规范约束的深度自治代理的团队。

如何选择工具：30 秒判断标准

已在 Claude Code 中？→ Spec Kit + cc-sdd skills。
使用 Cursor？→ Plan Mode + AGENTS.md + 通过 MCP 使用 Spec Kit。
AWS 阵营？→ Kiro。
在 VS Code 中使用 GitHub Copilot？→ Spec Kit（这实际上是微软的参考路径）。
需要审计轨迹 / 合规？→ Tessl。
不想被供应商锁定？→ OpenSpec 或 Spec Kit。

使用 Claude Code 的规范驱动开发（逐步指南）

以下是与 Claude Code 和 GitHub Spec Kit 一起的标准工作流。这是在 2026 年初摩擦最小的路径。

步骤 1 - 初始化

BASH 复制代码

uvx --from git+https://github.com/github/spec-kit.git specify init my-project --ai claude cd my-project

这会生成一个 .specify/ 目录，其中包含 memory/constitution.md、templates/ 和 scripts/。

步骤 2 - 编写宪法

在 Claude Code 中：

/constitution

Claude 会询问你项目级规则（语言、风格、测试、依赖），并将它们写入 .specify/memory/constitution.md。这将成为每次后续代理动作的不可变背景。

步骤 3 - 编写功能规范

Claude 会生成 specs/001-magic-link-auth/spec.md，包含用户故事、EARS 验收标准和范围外说明。你以纯 Markdown 格式审查并编辑它。

步骤 4 - 澄清

/clarify

Claude 会针对它发现的歧义提出有针对性的问题，例如"魔法链接是一次性使用，还是在到期前可重复使用？"、"我们应按电子邮件还是按 IP 限制频率？"你回答后，规范会更新。

步骤 5 - 计划

/plan

Claude 会生成 plan.md，包含架构、数据模型和库选择。审查它，编辑它。如有必要，拒绝并重新运行------在计划上进行廉价迭代胜过在代码上进行昂贵迭代。

步骤 6 - 任务

/tasks

Claude 会将计划拆分为编号清单。每个任务都是独立可交付的。

步骤 7 - 实现

/implement

Claude 会执行每个任务，在每步之后运行测试，并以逻辑块提交。你审查 PR。

整个循环对于一个非平凡功能，通常需要 2--6 小时的人类时间------大部分时间用于审查和澄清，而不是敲代码。

使用 GitHub Copilot 的规范驱动开发

GitHub Copilot 的 SDD 路径与 Claude Code 路径基本相同，因为 Spec Kit 是它们共同的规范层。区别在于绑定方式：不是传入 --ai claude，而是传入 --ai copilot，并且斜杠命令在 VS Code 的对话面板中可见。

BASH 复制代码

uvx --from git+https://github.com/github/spec-kit.git specify init my-project --ai copilot

然后在 VS Code 中：

Spec Kit 设计上是最不具意见性的 SDD 层------这也是微软、Anthropic 和 Google 都将其视为可互操作标准的原因。

在 Cursor 中的规范驱动开发

Cursor 具有稍微不同的形态。常见的三条惯用路径是：

Plan Mode + AGENTS.md------在仓库根目录编写 AGENTS.md（Cursor 对应的宪法），进入 Plan Mode 生成规范和计划，再退出 Plan Mode 进行实现。
通过 MCP 使用 Spec Kit------安装 Spec Kit 并通过 MCP 将其命令暴露给 Cursor。你会获得相同的 /specify、/plan、/tasks、/implement 流程。
OpenSpec------指向 openspec.yaml 文件。轻量，非常适合小型仓库。

Cursor 的优势在于：内联 diff UX 让审查代理生成的 PR 比终端工具更快。

一个真实的规范驱动开发示例

下面演示一个简洁的端到端示例：为电商站点添加"保存以便稍后购买"功能。

规范（摘要）

计划（摘要）

任务

结果

在 Claude Code 或 Cursor 中执行此列表的代理，会生成一个包含约 8 次提交的单一 PR，测试全部通过，审查者可以在 15 分钟内读懂 diff------因为审查者已经看过规范。

常见陷阱（以及如何避免）

过度规范。不要规范实现细节（"使用 Map 而不是 Object"）。规范行为和约束。让计划阶段处理实现细节。
规范不足。"它应该运行良好"不是需求。没有 EARS 就不算。
跳过宪法。没有项目级规则，每个规范都会重新争论相同决策。
认为规范不可变。规范会演进。更改行为时，先更新规范，再更改代码。
没有人类检查点。让代理从提示直接生成并合并 PR，只不过是穿着万圣节服装的随性编码。
规范在 Notion，代码在 Git。规范必须留在仓库中，并与代码一起版本控制，否则它会腐烂。

2026 年规范驱动开发最佳实践

一个功能 = 一个规范目录------specs/NNN-feature-name/{spec.md, plan.md, tasks.md}。
先写宪法------在编写第一个规范之前，先提交 AGENTS.md（或 .specify/memory/constitution.md）。
每次都用 EARS 写验收标准。
在阶段边界审查------绝不跳过规范直接写代码。
保持规范简短------1--3 页。如果规范太大，就拆分它。
规范负空间------"范围外"与"范围内"一样重要。
在提交和 PR 中引用规范------feat(auth): magic link，refs specs/004-magic-link/spec.md。
运行 /clarify 轮次------让代理在猜测之前暴露歧义。
使用检查清单------Spec Kit 的 /checklist 命令会根据你的规范生成预检查列表（安全、可访问性、可观测性）。
将规范视为持久文档------它们比从规范生成的代码更持久；未来的代理（和人类）会把它们视为规范参考。

规范驱动开发是软件工程的未来吗？

诚实的回答是：对某些软件来说是，但不是对所有软件都适用。

对于面向生产的代码------任何面向用户、客户或受监管环境的东西------SDD 会在 24 个月内成为默认方式。其经济性太强：多花一小时写规范，可以节省三天的代理折腾和三周的代码审查。

对于探索性、一次性或一次性脚本，随性编码依然更快、更有趣。SDD 不会取代它；它会补充它。成熟工程师在 2027 年会对原型进行随性编码，对所有要发布的内容进行规范驱动。

可以明确的是，SDD 是让 AI 编码代理从令人印象深刻的演示转变为可靠队友的桥梁。正如一位 GitHub 工程师所说："你不能交付我们没有的规范。"

规范驱动开发常见问答

什么是 AI 中的规范驱动开发？

AI 中的规范驱动开发是先编写结构化、受版本控制的规范，然后再调用 AI 编码代理，使代理拥有明确目标、约束和验收标准。它用规范 → 计划 → 任务 → 实现的有纪律循环取代了随性提示（"随性编码"），并由 GitHub Spec Kit、AWS Kiro 或 Claude Code skills 等工具驱动。

SDD 与 TDD 有什么区别？

TDD（测试驱动开发）将失败单元测试视为主要工件：先写测试，再写通过测试的代码，最后重构。SDD 将规范本身视为主要工件：测试、代码和文档都是从规范生成的。SDD 更广泛（包括架构、非功能需求、约束），并且设计为可被 AI 代理执行，而 TDD 是更紧凑的仅针对开发者的循环。大多数 SDD 工作流仍会生成类似 TDD 的测试作为输出。

SDD 是瀑布式开发吗？

不是。瀑布式开发在多月阶段开始时锁定规范并阻碍变更。SDD 将规范视为一个持续编辑的、受版本控制的活文档，并随着变化重新生成代码。规范与代码位于同一仓库、同一 PR 中。

谁创建了规范驱动开发？

没有单一发明者。现代 AI 中心的 SDD 形式在 2025 年围绕 GitHub Spec Kit（2025 年 9 月开源）、AWS Kiro（2025 年 7 月发布）、BMAD-METHOD 社区框架以及先前关于基于意图编程的文章逐渐成型。EARS 记法------大多数 SDD 框架使用的需求语法------由 Alistair Mavin 于 2009 年在 Rolls-Royce 提出。Martin Fowler 关于"探索生成式 AI"的文章为该领域提供了现代词汇。

什么是 EARS 记法？

EARS（Easy Approach to Requirements Syntax）是一组五种句子模式------普适型、事件驱动型、状态驱动型、非期望行为型和可选功能型------将模糊需求转变为无歧义、可测试的语句。每个主要 SDD 工具都使用 EARS（或近似克隆）作为验收标准，因为这种结构既容易让人理解，也容易让大语言模型解析并验证。

规范驱动开发中的"宪法"是什么？

宪法是一个项目级规则文档，每个规范、计划和代理动作都必须遵守。它包含团队做出的持久决策------语言、框架、测试、可访问性、安全、依赖策略------并以普适 EARS 语句书写。它通常存储为仓库根目录的 AGENTS.md 或 .specify/memory/constitution.md，并提交到版本控制中。

我可以在现有项目上使用规范驱动开发吗？

可以。先编写一个宪法，将项目现有惯例编码为规则（这是一个可与代理一起完成的一个小时练习）。然后对新功能采用 SDD，保持现有代码不变。随着时间推移，你可以为代码库中高价值区域补充规范。

哪个是规范驱动开发的最佳工具？

没有单一"最好"的工具------适用工具取决于你的栈。GitHub Spec Kit 是最可移植、与模型无关的选项。AWS Kiro 是最集成的智能 IDE。Claude Code 加上 cc-sdd skills 是摩擦最小的终端工作流。Cursor 结合 Plan Mode 和 AGENTS.md 最适合 IDE 优先的团队。对于受监管行业，Tessl 可开箱提供审计轨迹。

SDD 会取代随性编码吗？

不会------它们是互补的。随性编码适用于原型、一次性脚本和探索。SDD 适用于生产代码、数月项目以及多人维护的任何内容。大多数团队会收敛到这样的模式：用随性编码完成一个 spike，然后将结果提炼为规范，再用 SDD 驱动生产版本。

下一步去哪儿

如果你已经读到这里，最有价值的下一步是：挑一个本周会交付的小功能，花 30 分钟把它写成 Spec Kit 风格的规范，包含 EARS 验收标准，然后在 Claude Code 或 Cursor 中运行它。那种体验与等效的随性编码之间的差距，就足以让你得出结论。