📌 本文是「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 文件都是草案的一部分。
