规范驱动开发SDD2026 年权威指南规范驱动开发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。记法EARSEasy 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 CodingSpec-driven development真实来源生成代码版本化规范最佳场景一次性脚本、原型、演示生产代码、数月项目、团队协作失败模式沉默漂移、幻觉 API、上下文丢失过度规范、起步慢、若不维护则规范腐烂可审查性比较代码人类未必编写比较规范人为编写AI 代理自治高但脆弱高且受限新工程师入门读代码祝你好运读规范然后读代码Vibe编码对于SDD来说就像“只需将其键入终端”对于shell脚本和版本控制的部署自动化一样。他们不是敌人——vibe编码是一种很好的探索方式——但生产系统需要一个规范层。这也是为什么团队在选择面向生产的工具时会把 AI 编码平台与传统页面构建器进行比较。规范驱动开发与 TDD、BDD 的区别SDD 常被误解为与 TDD测试驱动开发和 BDD行为驱动开发相同。它们有共同基因但在什么被视为规范工件方面不同。TDDBDDSDD规范驱动规范工件失败单元测试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 代理真正遵循的规范写法EARSEasy 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 月开源。它是什么一个 CLIspecify加上一组提示、模板和斜杠命令可与 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 KiroAmazon 的智能 IDE从零开始为 SDD 构建。它是什么一个独立 IDEVS Code 分支规范、计划、任务和代码共存于同一工作区并与 AWS 深度集成。杀手功能“Hooks”——在每次代理动作后运行的自动护栏测试、lint、安全扫描。最适合已经在 AWS 生态中的团队尤其是构建无服务器应用的团队。注意事项可移植性低于 Spec Kit绑定于 Kiro 应用。3. Claude Code 与 cc-sddAnthropic 于 2025 年底通过 Claude Code 的“skills”系统率先提供了一级 SDD 支持。它是什么一组技能/sdd:specify、/sdd:plan等使 Claude Code 在终端内即可执行 SDD 工作流。最适合已经使用 Claude Code 的独立开发者和小团队。可与之搭配GitHub Spec KitSpec Kit 提示可原生在 Claude Code 中使用。4. CursorPlan Mode AGENTS.mdCursor 采用稍有不同的路径它不是发布专门的斜杠命令而是依赖 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 AntigravityGoogle 于 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 - 初始化uvx --from githttps://github.com/github/spec-kit.git specify init my-project --ai claude cd my-project这会生成一个.specify/目录其中包含memory/constitution.md、templates/和scripts/。步骤 2 - 编写宪法在 Claude Code 中/constitutionClaude 会询问你项目级规则语言、风格、测试、依赖并将它们写入.specify/memory/constitution.md。这将成为每次后续代理动作的不可变背景。步骤 3 - 编写功能规范Claude 会生成specs/001-magic-link-auth/spec.md包含用户故事、EARS 验收标准和范围外说明。你以纯 Markdown 格式审查并编辑它。步骤 4 - 澄清/clarifyClaude 会针对它发现的歧义提出有针对性的问题例如“魔法链接是一次性使用还是在到期前可重复使用”、“我们应按电子邮件还是按 IP 限制频率”你回答后规范会更新。步骤 5 - 计划/planClaude 会生成 plan.md包含架构、数据模型和库选择。审查它编辑它。如有必要拒绝并重新运行——在计划上进行廉价迭代胜过在代码上进行昂贵迭代。步骤 6 - 任务/tasksClaude 会将计划拆分为编号清单。每个任务都是独立可交付的。步骤 7 - 实现/implementClaude 会执行每个任务在每步之后运行测试并以逻辑块提交。你审查 PR。整个循环对于一个非平凡功能通常需要 2–6 小时的人类时间——大部分时间用于审查和澄清而不是敲代码。使用 GitHub Copilot 的规范驱动开发GitHub Copilot 的 SDD 路径与 Claude Code 路径基本相同因为 Spec Kit 是它们共同的规范层。区别在于绑定方式不是传入 --ai claude而是传入 --ai copilot并且斜杠命令在 VS Code 的对话面板中可见。uvx --from githttps://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.mdCursor 对应的宪法进入 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 linkrefs 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 Kit2025 年 9 月开源、AWS Kiro2025 年 7 月发布、BMAD-METHOD 社区框架以及先前关于基于意图编程的文章逐渐成型。EARS 记法——大多数 SDD 框架使用的需求语法——由 Alistair Mavin 于 2009 年在 Rolls-Royce 提出。Martin Fowler 关于“探索生成式 AI”的文章为该领域提供了现代词汇。什么是 EARS 记法EARSEasy 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 中运行它。那种体验与等效的随性编码之间的差距就足以让你得出结论。