Skip to main content
← All posts
作者：Sagasu
AI编码范式SDD生态规范驱动开发

#9 SDD 生态全景——2026 年的版图与你的下一步

📌 本文是「AI 时代的编码新范式」系列的第 9 篇，也是最后一篇。全系列共 9 篇，基于 43 篇行业文献、学术论文与一线实践报告，探讨 Spec-Driven Development 如何在 AI Agent 时代从边缘实践变为工程的基础设施。每篇可独立阅读。前八篇讲了 spec 为什么重要、怎么写、怎么用、边界在哪里、流程怎么适配、人的角色怎么变。本篇收束全局：2026 年的 SDD 生态长什么样，标准定型了没有，以及——你今天下班前能做什么。

30+ 框架，一片繁荣也一片混乱

2025 年 7 月，GitHub 宣布开源 Spec Kit——一个把需求变成 spec、再把 spec 变成代码的工具包。六个月后，SDD 工具生态爆炸了。

Spec Kit 本身已经拿下了超过 100,000 个 GitHub stars，支持 30+ AI 编码 Agent 集成——Claude Code、Copilot、Cursor、Codex CLI、Gemini CLI、Windsurf、Qwen Code，你能想到的都接了。它定义了四阶段工作流：Specify → Plan → Tasks → Implement，配合 /constitution、/specify、/clarify、/plan、/tasks、/implement 等 slash 命令，在任何主流 Agent 中跑同一条流程。

但 Spec Kit 不是唯一的选择。到 2026 年中，SDD 生态已经长成三层：

第一层：定义需求与架构层。 这一层解决「做什么」的问题。GitHub Spec Kit 是参考实现，提供了 constitution（宪法）、specify（规格）、clarify（澄清）三步。Constitutional SDD 论文把安全约束嵌入 spec 层，用 CWE 漏洞映射做强制门禁。AWS 推出了 Kiro，把 SDD 流程打包成产品级体验。BMAD-METHOD（Breakthrough Method for Agile AI-Driven Development）从另一个角度切入，用模块化生态管理 spec 生命周期，已到第六版，47,000+ stars。OpenSpec、Tessl、Google Antigravity 各有各的 spec 格式和流程哲学。

第二层：规范转任务图层。 这一层解决「怎么做」的问题。Spec 写完后，需要被拆成可执行的任务。Cursor 的 Plan Mode 走了一条不同的路——不提供 slash 命令，而是用只读模式让 Agent 先探索代码库再出计划，配合 AGENTS.md 作为项目级约束文件。Claude Code 的 Skills 是中间路径——可复用的、可分享的工作流规范，介于 vibe coding 和完整 SDD 之间。Spec Kit 的 /plan 和 /tasks 命令则把这一步内置到流程里。

三层：代码生成层。 这一层解决「做」的问题。Claude Code、Codex、Copilot、Cursor、Windsurf——每一个都在争当代码生成的默认 Agent。它们的差异化越来越小——都能读 spec、都能写代码、都能跑测试。真正的差异在上一层：谁更能接住结构化的 spec 输入，谁就赢。

三层各自在演化，但接口尚未标准化。Spec Kit 的 spec 格式和 BMAD 的不一样，BMAD 的和 Tessl 的又不一样。一个团队如果从 Spec Kit 切换到 BMAD，spec 文件几乎要重写。这就像 2010 年代的微服务生态——每个人都在做，但每个人的 API gateway 都不兼容。

定义权还在开放

Thoughtworks 在 2025 年的行业洞察里说了一句话，值得反复读：「行业对‘规范该是什么’尚无共识。」

这不是负面评价——这是对现状的精确描述。SDD 不是 Agile。2001 年十七个人在雪鸟滑雪场签了 Agile Manifesto，从那以后「什么是 Agile」有了官方答案。SDD 没有这个时刻。没有人签了 SDD Manifesto。GitHub、Microsoft、Anthropic、OpenAI、AWS、Thoughtworks——每家都有自己的定义，每家都在用自己的方式推动。

Microsoft 的定义最系统：SDD 是 spec-first 方法，spec 是业务意图与代码/测试之间的 shared source of truth，通过 GitHub Spec Kit 的七步生命周期（Constitution → Specify → Clarify → Plan → Tasks → Implement → Validate）落地。他们的实践数据显示，onboarding 新功能的时间从 2-3 周缩短到几天。

Anthropic 的定义最务实：不谈理论，直接给工具。Claude Code 的 Skills 体系让团队把约定编码成可复用的工作流——不是「写一份完美 spec」，而是「把团队经验变成 Agent 能读的指令」。

学术界的定义最严格：arXiv 上的 Constitutional SDD 论文把 spec 定义为「可执行的验证门禁」——spec 不是给人读的说明书，而是 CI 流程中会阻断合并的机器检查。Constitutional SDD 实验显示，把安全约束嵌入 spec 层后，安全缺陷减少了 73%。

三个定义不矛盾，但也不统一。你今天写的 spec，是给 Claude Code 看的 markdown 文件？是 Spec Kit 的 /specify 输出？还是 Constitutional SDD 的可执行验证规则？取决于你用哪套工具。

这意味着什么？意味着你写的每一份 spec 都在参与定义「什么是好的 spec」。 这不是跟随潮流——这是参与定义潮流。SDD 的 Manifesto 还在被写，而每一个实践者的 spec 文件都是草案的一部分。

历史回响：文档驱动不是 AI 时代的发明

在 SDD 这个词出现之前，文档驱动的实践已经存在了。

2014 年，Zach Supalla 在一篇 Gist 里提出了 Documentation-Driven Development（DDD）的核心哲学：「从用户的视角看，如果一个功能没有被文档记录，它就不存在；如果被错误地记录了，它就是坏的。」 他主张先写公开文档，再写代码——因为文档迫使你在写代码之前就想清楚用户会怎么用这个功能。

2024 年，Ubuntu 团队发表了一篇题为《A Year of Documentation-Driven Development》的文章，记录了他们一年的实践。他们的结论很朴素：文档不是开发完成后的补充，而是开发过程本身的一部分。把文档提到开发流程的前端，让功能设计有了更清晰的序列，让团队协作有了更坚实的基础。他们说：「文档驱动不是解决了我们所有的问题，但它给了我们一个基础去构建其他实践。」

这个历史回响提醒我们一件事：文档驱动不是 AI 时代的发明。 它是人类工程师在长期实践中总结出来的好习惯。但 AI 时代让它从「好习惯」变成了「生存必需」。

在人的编码速度下，文档驱动是加分项——你写了文档，团队协作更顺畅；你不写，代码也能跑。在 Agent 的编码速度下，文档驱动是必需品——你不写 spec，Agent 用默认假设填补你的每一个模糊，产出翻倍但方向性返工也翻倍。速度放大了一切：好的 spec 让 Agent 飞起来，坏的 spec 让 Agent 飞错方向。

这就是本系列九篇文章的共同主题：AI 时代没有改变工程的核心原则——它只是让违反原则的代价变得不可承受。 Spec 驱动、小批量、快速反馈、松耦合架构——这些都不是新概念。但 AI 时代让它们从「最好有」变成了「必须有」。

九篇串联：一条从口喷需求到范式定义的线

让我们把九篇文章的核心论点串成一条线：

第 1 篇：Vibe Coding 的尽头是规划先行。口喷需求的系统性失败不是 Agent 不够聪明，是自然语言不够精确。Spec 是人机之间的对齐锚点。

第 2 篇：Specification 即协议。Spec 从「给人看的说明书」变成「给 Agent 读的执行协议」，从静态文档变成 living document，从人类散文变成机器接口。

第 3 篇：速度的真相。AI 不是万能加速器——它是结构化任务放大器。任务越清晰，AI 增益越大。SDD 的本质作用是把每个任务从模糊推向清晰。

第 4 篇：文档编排 Agent。文档是 Agent 的外部记忆系统。需求文档告诉 Agent「做什么」，进度文件告诉它「做到了哪」，git log 告诉它「做对了没」。

第 5 篇：写好一份 Spec 的实战手册。Spec 的五要素：目标、约束、边界、验收标准、技术上下文。从根目录的一个 CLAUDE.md 开始。

第 6 篇：文档的边界。SDD 不是银弹。Context grounding 不足会幻觉，spec-code drift 会腐烂，安全约束不能靠 Agent「理解」。知道边界才能正确使用。

第 7 篇：流程的阵痛。AI 让代码产出翻了三倍，但 review、测试、部署的速度没跟上。瓶颈从「写代码」转移到「审代码」。DORA 和 Faros 的数据证实了这是行业级现象。

第 8 篇：角色重构。工程师从「写代码的人」变成「编排 Agent 的人」。新能力栈：约束设计 + spec 编写 + harness 构建 + 产出审阅。从演员变成导演。

第 9 篇（本篇）：SDD 生态全景。30+ 框架，三层生态，定义权还在开放。你不是跟随潮流——你是在参与定义潮流。

一条线串起来：你在 Claude Code 里的一句口喷需求（第 1 篇）→ 你写了一份 spec（第 5 篇）→ Agent 的产出飞起来了（第 3 篇）→ 但流程接不住这个速度（第 7 篇）→ 你的角色从演员变成了导演（第 8 篇）→ 你在用 spec 参与定义工程的未来（本篇）。

你的下一步

这篇文章不收束于「SDD 的未来预测」——预测未来是算命的事。这篇文章收束于你今天就可以做的两件事。

给开发者：今天下班前，做这一件事

在你的项目根目录建一个文件，叫 CLAUDE.md（如果你用 Claude Code）或 AGENTS.md（如果你用其他 Agent）。写下三件事：

  1. 这个项目是做什么的——一句话，不超过 30 个字。

  2. 技术栈是什么——语言、框架、数据库、CI 工具，列出来。

  3. Agent 必须遵守什么约束——比如「所有外部输入必须经过 sanitize」「敏感数据不得写入日志」「每个 PR 不超过 300 行改动」。

就这三件事。不需要 Spec Kit，不需要 BMAD，不需要任何框架。三句话，一个文件，你已经开始了。

这就是你的第一份 spec。它不完美——但它比没有强一万倍。因为从这一刻起，Agent 的每一次产出都有了一个参照系。它不再是盲飞，而是带着地图飞行。

然后迭代。下次你让 Agent 做一个功能时，先花十分钟把这个功能的需求写成 spec——目标、约束、验收标准。你会发现 Agent 的产出质量立刻不同。不是 Agent 变聪明了——是你的输入变清晰了。

给管理者：下周开会前，想清楚一个问题

你的团队当前最大的瓶颈在哪里？

  • 写代码慢？ 那 SDD 不是你的首要解法——你需要的是更好的 AI 编码工具和培训。

  • Review 积压？ SDD 可以帮——spec 把大功能拆成小任务，小 PR review 更快。但你还需要调整 CI 配置和 review 流程（第 7 篇）。

  • 稳定性下降？ SDD 可以帮——Constitutional SDD 的安全约束层能减少 73% 的安全缺陷。但你还需要松耦合架构和快速反馈回路。

  • 方向性返工？ 这是 SDD 最直接解决的——spec 让 Agent 在正确的方向上产出，而不是用默认假设填补你的模糊。

SDD 解决的是「方向性返工」和「review 积压」。但你要先确认自己的瓶颈在哪里，否则你会用错误的工具解决错误的问题。

确认了瓶颈之后，做一个 pilot——选一个功能，写一份完整的 spec，让 Agent 在 spec 约束下实现，对比以前的产出。Microsoft 的实践数据显示，这种 pilot 通常能在一个 sprint 内看到可量化的改善。

别等标准答案

2026 年的 SDD 生态像 2008 年的云计算——所有人都在讨论，少数人在实践，标准还没定。AWS 那时候不叫 AWS，叫 EC2——一个让你租虚拟机的服务。没人知道它会变成什么样。但那些在 2008 年就开始用 EC2 的人，后来定义了什么叫「cloud-native」。

SDD 现在就在那个时刻。Spec Kit 100k stars，30+ Agent 集成，Constitutional SDD 论文证明了 73% 的安全缺陷减少，OpenAI 用 harness engineering 证明了 100 万行代码零行手写。但「什么是好的 spec」还没有官方答案——Thoughtworks 说的，不是谦虚，是事实。

所以别等标准答案。现在开始写 spec 的人，就是将来定义标准的人。

你今天写的那份 CLAUDE.md——三句话，一个文件——它不只是你的第一份 spec。它是 SDD Manifesto 的一行草稿。

而这个 Manifesto，还在被写。

参考文献

  1. GitHub. (2025). Spec-Driven Development with AI: Get Started with a New Open Source Toolkit. GitHub 官方博客。Spec Kit 四阶段工作流（Specify → Plan → Tasks → Implement），支持 30+ AI 编码 Agent 集成。100k+ GitHub stars.https://github.blog/ai-and-ml/generative-ai/spec-driven-development-with-ai-get-started-with-a-new-open-source-toolkit/

  2. Microsoft. (2026). Spec-Driven Development: A Spec-First Approach to AI-Native Engineering. Microsoft Developer Blog. SDD 七步生命周期（Constitution → Specify → Clarify → Plan → Tasks → Implement → Validate）。实践数据：onboarding 时间从 2-3 周缩短到几天。https://developer.microsoft.com/blog/spec-driven-development-ai-native-engineering

  3. Thoughtworks. (2025). Spec-Driven Development: Unpacking One of 2025's Key New AI-Assisted Engineering Practices. 「行业对‘规范该是什么’尚无共识。」SDD 定义为「用写好的需求规范作为 AI Agent 提示词」。https://www.thoughtworks.com/en-us/insights/blog/agile-engineering-practices/spec-driven-development-unpacking-2025-new-engineering-practices

  4. Farrag, A. (2026). Constitutional Spec-Driven Development: Enforcing Security by Construction. arXiv:2602.02584. 安全约束嵌入 spec 层，CWE/MITRE Top 25 映射。安全缺陷减少 73%。银行微服务案例研究。https://arxiv.org/abs/2602.02584

  5. Ubuntu. (2024). A Year of Documentation-Driven Development. 文档驱动不是开发后的补充，而是开发过程本身的一部分。「不是解决了所有问题，但给了基础去构建其他实践。」https://ubuntu.com/blog/a-year-of-documentation-driven-development

  6. Spec-Driven Development Is Eating Software Engineering. (2026). 30+ 框架全景图：Spec Kit、OpenSpec、GSD、Devika、Tessl、BMAD-METHOD 等。三层生态：定义需求层 → 规范转任务层 → 代码生成层。

  7. Lopopolo, R. (2026). Harness Engineering: Leveraging Codex in an Agent-First World. OpenAI Engineering Blog. 三人团队 5 个月产出约 100 万行代码（0 行手动），1,500 个 PR.「Humans steer. Agents execute.」https://openai.com/index/harness-engineering/

  8. Anthropic. (2026). 2026 Agentic Coding Trends Report. 工程师角色从实现者变为编排者。开发者 60% 工作用 AI，但仅 0-20% 可完全委派。非技术人员用 Agent 编码趋势。https://resources.anthropic.com/hubfs/2026 Agentic Coding Trends Report.pdf

  9. Supalla, Z. (2014). Documentation-Driven Development. DDD 核心哲学：「从用户视角看，未被文档记录的功能不存在，被错误记录的功能是坏的。」先写文档，再写代码。https://gist.github.com/zsup/9434452

  10. DORA. (2024-2025). Impact of Generative AI in Software Development / State of AI-assisted Software Development. AI adoption 与 delivery throughput 从负相关（2024）转为正相关（2025），但 stability 负相关持续。90% 受访者使用 AI。https://dora.dev/ai/gen-ai-report/