SDD：AI编码新的默认方式

AI模型价格对比 | AI工具导航 | ONNX模型库 | Vibe Coding教程 | PLC在线仿真器 | Tripo 3D | Meshy AI | ElevenLabs | KlingAI | ArtSpace | Phot.AI | InVideo

规范驱动开发在过去 12 个月内从博客话题跨越成为 AI 编码的默认架构。

Thoughtworks、Martin Fowler、GitHub、Amazon 和一篇 67 个来源的学术综述在 2025 年和 2026 年都达成了一致。

问题不再是是否使用 SDD，而是使用哪种实现。

1、发生了什么

多个独立来源在 18 个月内汇聚到同一个建议上。

Thoughtworks 在 Technology Radar Vol. 32 中将规范驱动开发列为值得采用的技术。Martin Fowler 在他的网站上对此进行了报道。

GitHub 发布了 Spec Kit，这是一个 MIT 许可的工具包，被定位为应对氛围编码的答案。Amazon 推出了 Kiro，一个引导用户完成需求、设计和任务之后再生成代码的智能体工具。Tessl 激进地推出了，将规范定位为新的源代码。

Red Hat 发布了企业级 SDD 指南。InfoQ 在架构层面进行了报道。

Bryan Finster 提出了正确的批评。SDD 不是革命，它只是加了品牌包装的 BDD。

这个批评反而加强了论据。这个想法并不新。但上下文是新的。

BDD 是团队可以选择采用或忽略的自律实践。随着 84% 的专业开发者在使用或计划使用 AI 工具（Stack Overflow，2025），以及 46% 的代码输出现在是 AI 生成的（GitHub，2025），规范自律在结构上变得必要了。

2、为什么它变得必要

四篇学术论文在 12 个月内发表，从不同角度映射了同一个问题。

东伦敦大学的 Sabry Farrag 对生产力悖论进行了 67 个来源的系统综述。AI 编码工具同时带来真实的个体层面收益和真实的系统层面损害。

Peng 等人在一项 95 名开发者的随机对照试验中测量到 55.8% 的完成速度提升。Becker 等人的 METR 研究发现在成熟代码库上工作的有经验开发者慢了 19%。

DORA 报告称 25% 的 AI 采用率与交付稳定性下降 7.2% 相关。Faros AI 跟踪了超过 10,000 名开发者，看到合并的 PR 增加 98%，审查时间增加 91%，bug 增加 9%。

微软研究院的 Shuvendu Lahiri 命名了底层的差距。AI 生成的代码在构造上是合理的，但在构造上不是正确的。用户意图与程序行为之间的语义距离是核心可靠性瓶颈。

一篇 AIware 2026 愿景论文命名了第二个差距。代码审查评估的是合理性，而不是合规性。大多数 AI 生成的更改通过了测试，看起来合理，但仍然偏离了它们本应遵循的规则。

Deepak Babu Piskala 写了将这一切联系在一起的从业者手册。他将 SDD 框架化为三个严谨级别和一个四阶段工作流。

Farrag 的经济学论据完成了闭环。为特定代码库生成的代码具有高资产专用性。LLM 引入了高行为不确定性。

开发者每天调用 AI 数百次。在交易成本经济学术语中，这种组合使书面可执行合同成为理性的治理回应。SDD 就是那个合同。

3、它实际上如何运作

SDD 可以压缩为从业者需要掌握的三件事。

四阶段工作流。 指定软件应该做什么。计划如何构建它。以小的、经过验证的增量实现。验证代码是否满足规范。每个阶段产生一个约束下一个阶段的产物。

三个严谨级别。 规范优先意味着在编码之前编写规范，但之后可能会偏移。规范锚定意味着规范与代码共存，测试强制对齐。规范即源意味着规范是唯一的人类编辑产物，代码被重新生成而不是手动修改。

治理光谱。 Farrag 的论文按约束强度排列了四种机制：

• 事后审查是最松散的，开发者在事后审查 AI 输出。
• 自然语言规范是下一步，在生成之前提出要求。
• 可执行合同紧随其后，有测试和结构化规范文档，智能体必须满足。
• 宪法治理是最严格的，一个不可协商原则的元规范，每个更改都必须遵守。

资产专用性、行为不确定性和频率越高，在光谱上的理性选择就越靠上。成熟代码库中的生产代码，被 AI 每天调用数百次，落在宪法级别。一个一次性原型落在事后审查级别。

4、五个 SDD 仓库，按理念分类

每个仓库编码了一个关于复杂性应该放在哪里的不同理论。

4.1 Spec Kit：宪法即权威

GitHub 的官方工具包，MIT 许可，Python CLI（specify init）。

复杂性理论：把它放在宪法里。一个不可协商原则文件在 .specify/memory/constitution.md 位于每个规范和每个实现之上。智能体在每次更改、每个会话中都遵守它。

工作流通过九个斜杠命令运行：

• /speckit.constitution
• /speckit.specify
• /speckit.clarify
• /speckit.plan
• /speckit.tasks
• /speckit.taskstoissues
• /speckit.checklist
• /speckit.analyze
• /speckit.implement

宪法和分析步骤是正式治理所在的地方。

Farrag 的论文将 Spec Kit 评估为宪法治理的直接实例化。报告的结果：上游产物（PRD、设计、结构、技术规范、测试计划）的生产从 12 小时缩短到 15 分钟。

一项试点研究看到后期热修复从每个冲刺 3-5 个降到 1-2 个，回滚从每月 2-4 个降到 0-1 个。

30+ AI 智能体集成，包括 Claude、Codex、Copilot、Cursor、Gemini。

这是唯一具有明确宪法治理的仓库。Farrag 光谱上的最高层级，设置成本也最高。

4.2 BMAD-METHOD：命名智能体即权威

BMad Code LLC，MIT，npm（npx bmad-method install）。V6，拥有 34+ 工作流。

复杂性理论：把它放在角色里。六个命名角色，每个都有领域专业知识：

• 分析师 Mary 负责头脑风暴和研究。
• PM John 拥有 PRD。
• 架构师 Winston 运行 8 步架构工作流。
• 开发者 Amelia 负责开发故事、冲刺计划和代码审查。
• UX 设计师 Sally 拥有界面决策。
• 技术文档编写者 Paige 拥有文档。

Party Mode 将多个角色带入一个会话，从不同专业角度进行辩论。

生命周期有四个阶段：分析、规划、解决方案、实现。每个阶段都有自己的工作流。

一个 decision-log.md 将每个决定记录为审计跟踪。一个实现就绪门（PASS、CONCERNS 或 FAIL）在有任何缺失时阻止进入代码阶段。

规划深度根据项目风险自动调整。一个业余项目获得 2 页 PRD。一个发布项目获得完整规范。bmad-help 技能回答关于下一步做什么的自由格式问题。

模块生态系统通过专业领域扩展核心：BMM（核心）、BMB（自定义智能体）、TEA（测试架构）、BMGD（游戏开发）、CIS（创意智能）。

这是唯一将规范视为多智能体组织内部智能体间通信协议的仓库。

4.3 OpenSpec：变更文件夹即单元

Fission AI，MIT，npm（openspec init）。

复杂性理论：把它放在变更中。每个功能获得自己的文件夹，包含 proposal.md（为什么做这个变更）、specs/（需求和场景）、design.md（技术方案）和 tasks.md（实现清单）。

当变更交付时，/opsx:archive 将变更规范归并到一个不断增长的真相源文档中。

核心界面是三个命令：

• /opsx:propose 创建变更文件夹。
• /opsx:apply 让 AI 实现任务清单。
• /opsx:archive 关闭它。

一个可选的扩展配置文件增加了六个命令：/opsx:new、/opsx:continue、/opsx:ff、/opsx:verify、/opsx:bulk-archive、/opsx:onboard。

定位明确是棕地优先。大多数 SDD 工具针对绿地项目优化。OpenSpec 旨在改造现有代码库。增量规范格式（按变更跟踪的添加、修改、删除）使这成为可能。

通过斜杠命令与 25+ AI 助手协作。

以最轻的权重交付可执行合同。没有宪法，没有命名智能体，没有仪式。规范纪律在流程之外存续。

4.4 GSD：上下文即瓶颈

TÂCHES，MIT，npm（npx get-shit-done-cc@latest）。由一个独立开发者为独立开发者构建。

复杂性理论：把它放在上下文工程中。主会话上下文保持在 30% 到 40%。繁重的工作在新的子智能体上下文中运行，每个获得完整的 200K token 窗口。

其余架构所基于的假设：随着会话增长，AI 输出退化，因此架构应该保持会话小型化。

循环是六个命令：

• /gsd-new-project 运行问题、研究、需求、路线图。
• /gsd-map-codebase 对现有代码做同样的事。
• /gsd-discuss-phase 在规划之前捕获决策。
• /gsd-plan-phase 循环运行研究、计划、验证。
• /gsd-execute-phase 分发并行的子智能体波次。
• /gsd-verify-work 遍历构建的内容并诊断失败。

五个持久状态文件跨越会话边界：PROJECT.md（愿景）、REQUIREMENTS.md（范围）、ROADMAP.md（方向）、STATE.md（当前位置）、CONTEXT.md（每阶段决策）。

.planning/config.json 控制模式（交互式或 yolo）、模型配置（质量、均衡、预算）和质量智能体开关。包合法性检查内置在安装路径中。

通过上下文纪律而非流程仪式交付可执行合同。该仓库将上下文窗口视为瓶颈，而不是方法论。

4.5 Superpowers：自动触发即纪律

由 Jesse Vincent 和 Prime Radiant 构建。MIT，零依赖插件。

复杂性理论：把它放在智能体的行为塑造中。技能在正确的时刻自动触发。无需手动调用。强制性工作流，而非建议。

using-superpowers 技能在会话开始时加载，是自动触发工作的原因。仅复制技能文件不是真正的集成。

七个核心技能运行工作流：

• brainstorming 在任何代码之前完善粗略想法。
• using-git-worktrees 隔离工作空间。
• writing-plans 将工作分解为 2 到 5 分钟的任务，包含精确的文件路径和完整代码。
• subagent-driven-development 每个任务分发一个新的子智能体，进行两阶段审查（规范合规性，然后代码质量）。
• test-driven-development 删除在其测试之前编写的任何代码。
• requesting-code-review 阻止关键问题。
• finishing-a-development-branch 验证测试并呈现合并选项。

TDD 强制执行是不寻常的举措。大多数 TDD 工具鼓励这个循环。Superpowers 的技能会删除违反它的代码。

通过官方 Claude 插件市场、官方 Codex 插件市场、Factory Droid、Gemini 扩展、Cursor、GitHub Copilot CLI 和 OpenCode 分发。

在智能体层面而非用户层面强制执行可执行合同。用户永远不需要记住调用正确的技能。

5、第六个仓库，以及对这个类别的反对

Matt Pocock 的 Skills For Real Engineers 碰巧出现在同一个仓库列表中。他反对这个类别。

他的演讲 Software Fundamentals Matter More Than Ever 直接传达了论点。"代码并不便宜。事实上，糟糕的代码比以往任何时候都更昂贵。"

关于规范驱动运动的具体评论："从规范到代码，我们没有在投资系统设计。我们在从中撤资。"

他的立场建立在一个软件工程论断上。糟糕的代码库一直很昂贵，因为它们抗拒变更。AI 加速了这一点。一个被 AI 吞吐量复合的糟糕代码库是新时代最昂贵的失败模式。

他的仓库是可组合实践，而不是工作流框架。每个技能独立运行：

• /grill-me 运行无情的访谈，以建立 Frederick Brooks 所谓的共享设计概念。
• /grill-with-docs 添加一个领域驱动设计的通用语言文件，人类和 AI 都参考它。
• /tdd 强制红-绿-重构作为 AI 速度的速率限制器。
• /improve-codebase-architecture 根据 John Ousterhout 的方法将浅模块重建为深模块。

默认模式是灰盒子：设计接口，委托实现。

支持他的数据：METR 的发现表明在成熟代码库上有经验开发者使用 AI 慢了 19%，这表明瓶颈是代码库质量，而不是规范质量。他的论点是五个 SDD 仓库优化了错误的东西。

他的仓库仅凭 /grill-me 就火了。这个立场值得认真对待。

6、AlphaSignal 的观点

五个 SDD 仓库和 Pocock 的异议并没有回答同一个问题。

SDD 优化的是合理性到正确性的差距。Pocock 优化的是设计熵的差距。两个差距都是真实的。两个数据集都支持两种立场。

一个选择其中一个而忽略另一个的团队只解决了一半的问题。

SDD 的可靠性论据在宪法和可执行合同层面最强。Spec Kit 的宪法机制和 BMAD 的实现就绪门是数学真正见效的地方。

论据在自然语言端最弱，SDD 在那里退化为重命名的提示工程。

从四篇论文的开放问题部分得出的六个仓库都没有解决的三个问题。

预言充分性。 当前的评估将模型质量、工具可靠性和工具质量合并为一个端任务数字。没有衡量规范实际价值的指标。

证据捆绑。 每个被接受的更改都应该附带一份记录：检查了什么、没有检查什么、哪些风险仍然存在。当前没有 SDD 工具产生这个。

自我演进的工具。 SDD 框架本身是软件。它们会改变。它们中没有一个是为自己的演进而设立变更合同的。

把每个仓库读作一个关于可靠性从何而来的具体理论。选择那个理论与你实际瓶颈匹配的。如果你不知道你的瓶颈，Pocock 的批评首先适用。

原文链接: Spec-Driven Development is the New Default for AI Coding

汇智网翻译整理，转载请标明出处