当 AI 编程 Agent 从"能写代码"进化到"能承担工程"，我们真正缺的不是更强的模型，而是一套能让 AI 的产出可验证、可维护、可交接的工程纪律。 本文先拆解三个框架共同回答的底层问题——规范驱动开发（Spec-Driven Development, SDD）到底在解决什么；再横向对比 GitHub Spec Kit、obra/superpowers、Fission-AI/OpenSpec 在模板、命令、适用场景上的差异；最后给出选型矩阵与落地建议。
一、引言：为什么"规范驱动"突然成了 AI 编程的显学
2026 年的 AI 编程已经跨过了一个临界点：问题不再是"AI 能不能写出能跑的代码"，而是"AI 写的代码能不能被信任、被评审、被长期维护"。
当我们让一个 Agent 直接"实现这个功能"时，它给出的结果往往是一个黑盒——我们不知道它为什么这么做、改动了哪些范围、是否破坏了既有行为、后续如何回滚。这种"快但不可控"的体验，在个人原型阶段尚可接受，一旦进入企业级代码库（尤其是那些已经运行多年的"棕地"系统），就会迅速演变成灾难。
于是，业界不约而同地走向同一个方向：把"意图"前置，把"实现"后置。 先让 Agent 产出一份可评审的规范（Spec）、一份技术计划（Plan）、一份任务清单（Tasks），确认无误后再让 Agent 动手写代码。这套方法论就是 规范驱动开发（Spec-Driven Development, SDD）。
而本文要对比的三个框架——GitHub 官方的 Spec Kit、Jesse Vincent (obra) 的 Superpowers、Fission-AI 的 OpenSpec——正是这套方法论在 2026 年最主流的三个实现。它们不是竞争关系，而是从不同维度回答了同一个底层问题。
二、深度原理：三个框架共同回答的底层问题
在对比模板和命令之前，我们必须先搞清楚：规范驱动开发到底在解决什么本质矛盾？ 只有理解了这一点，你才能判断哪个框架适合你的项目，而不是被表面的功能清单迷惑。
2.1 核心矛盾：AI 的"生成速度"与工程的"可验证性"之间的断裂
传统软件开发中，"写代码"是成本最高、最需要小心的环节。但在 AI 编程时代，这个环节的成本几乎归零——Agent 可以在几分钟内生成一个功能。
但工程成本并没有消失，它只是转移了：
| 传统开发 | AI 编程时代 |
|---|---|
| 写代码是瓶颈 | 写代码不再是瓶颈 |
| 需求分析、设计相对轻 | 意图确认、范围控制、行为验证成为新瓶颈 |
| 人通过代码评审把关 | 代码评审的对象变成了"Agent 生成的代码"，人很难逐行审查 |
这就产生了一个断裂：AI 生成得越快，我们越难确认"它做的是不是我们想要的"。
规范驱动开发的核心洞察是：与其让 AI 先写代码、我们再发现问题，不如让 AI 先写规范、我们确认规范，再让 AI 写代码。 把"验证"从代码层面提前到"意图层面"，从而用一份可读的文档，把 AI 的不可控性关进笼子里。
2.2 SDD 的本质：一次"意图契约"的建立与执行
规范驱动开发可以拆解为一条完整链路：
这条链路回答了几个关键问题：
- Spec（规范）：回答"我们要做什么、为什么做"。它是给人和 AI 共同阅读的"意图契约"，不涉及具体实现细节。
- Plan（技术计划）：回答"我们打算怎么做"。这是技术方案的论证，需要评估备选方案、权衡取舍。
- Tasks（任务清单）：回答"拆成哪些可执行的步骤"。每个任务应当足够小，能被 Agent 独立完成并验证。
- Converge（收敛）：回答"实现是否兑现了规范"。这是最关键的一步——把最终行为与最初意图对照，防止 Agent 跑偏。
2.3 三个框架：同一问题的三种回答
理解了这个底层问题，三个框架的差异就清晰了——它们分别从不同维度切入：
- Spec Kit：模板驱动。它把 SDD 的每一步都固化成模板和命令，强调"产出规范产物"。你运行
/specify、/plan、/tasks等命令，每个命令产出一份标准化的文档。它最像"官方教科书"，把 SDD 的标准流程给你封装好。 - Superpowers：流程驱动。它不关心你产出的文档长什么样，而是强制规定开发流程——从头脑风暴、独立工作树、写计划、子 Agent 执行、TDD、代码评审到收尾验证，每一步都有对应的 skill，并用"铁律"（Iron Laws）硬性约束。它更像"工程纪律教练"，逼着 Agent 按工程方式行事。
- OpenSpec：增量驱动。它的核心概念是 Delta Spec（增量规范）——不重述整个系统规范，只描述"这次变更改了什么"。这使它天然适配**棕地（brownfield）**代码库：你不需要为整个系统写一份大而全的规范，只需为每次改动写一份增量规范。它更像"外科手术工具"，专门处理存量代码上的精准改动。
一句话总结：Spec Kit 给你"标准答案"，Superpowers 给你"纪律约束"，OpenSpec 给你"增量手术"。
三、横向对比：模板、命令、适用场景
理解了底层差异，我们来看三个框架在具体操作层面的差异。这是你选型时最关心的部分。
3.1 GitHub Spec Kit：官方教科书
定位：GitHub 官方出品的 SDD 工具集，把规范驱动开发的完整流程封装成可执行的命令和模板。
核心工作流：一次项目初始化 + 每特性执行 Specify → Plan → Tasks → Implement → Converge。
关键命令（通过 /speckit.* 斜杠命令或 specify CLI 触发）：
| 命令 | 作用 |
|---|---|
/speckit.constitution | 初始化项目宪法（Constitution），定义项目的技术偏好、约束、编码规范 |
/speckit.specify | 生成规范（Spec），定义"做什么、为什么" |
/speckit.clarify | 澄清需求（质量门），处理歧义 |
/speckit.plan | 生成技术计划（Plan），定义"怎么做" |
/speckit.checklist | 质量检查清单（质量门） |
/speckit.tasks | 拆解任务清单（Tasks） |
/speckit.analyze | 跨产物分析（质量门），检查一致性 |
/speckit.implement | 按任务实现 |
/speckit.converge | 收敛验证，对照规范检查实现 |
模板结构：.specify/templates/ 目录下包含 spec-template.md、plan-template.md、tasks-template.md 等标准模板，以及对应平台的执行脚本（如 bash/、powershell/）。
适用场景：
- 新项目（绿地 greenfield）或需要建立标准 SDD 流程的团队
- 团队希望有一套"官方认可"的标准流程，方便新人上手
- 需要产出标准化、可评审的规范文档（适合审计、交接）
优点：模板标准化、流程完整、有 GitHub 官方背书、质量门（clarify/checklist/analyze）完善。 缺点：对棕地项目偏重——每个特性都要走完整流程，文档产出量大；模板偏"教科书"，需要团队自行裁剪。
3.2 obra/superpowers：工程纪律教练
定位：一个完整的软件开发方法论，基于一组可组合的 skills 和初始指令，强制 Agent 按工程方式开发。由 Jesse Vincent (obra) 创建，是目前 GitHub 上最受关注的 Agent skills 框架之一。
核心工作流：七步流程，每一步对应一个 skill：
铁律（Iron Laws）：这是 Superpowers 最独特的设计。它把关键规则压缩成 Agent 能在工作记忆中记住的"单条铁律"，例如：
- NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST（没有根因调查之前不修 bug）——源自
systematic-debuggingskill - 强制测试——源自
test-driven-developmentskill - 收尾必须验证——源自
verification-before-completionskill
核心 skills（约 14-15 个）：
brainstorming：先澄清需求，不直接写代码using-git-worktrees：用独立工作树隔离改动writing-plans：写细粒度计划subagent-driven-development：子 Agent 执行 + 两阶段评审test-driven-development：严格红-绿-重构systematic-debugging：四阶段根因排查code-review：代码评审verification-before-completion：收尾验证
适用场景：
- 追求"工程级可靠性"、希望 AI 严格遵循工程纪律的团队
- 需要处理新功能、特性增强、bug 修复等多种场景
- 愿意接受"流程更重、执行更慢但更稳"的团队
优点：铁律强制约束、流程完整、强调测试与根因排查、可靠性高。 缺点：流程较重，文档产出不如 Spec Kit 标准化；skills 依赖 Claude Code 生态；对团队协作（多 Agent 并发）支持相对弱。
3.3 Fission-AI/OpenSpec：棕地手术刀
定位：为真实世界的棕地代码库和多 Agent 开发环境设计的轻量 SDD 框架。核心是 Delta Spec（增量规范）。
核心工作流：Propose → Apply → Archive 循环。
核心概念：
- Delta Spec：不重述整个系统规范，只描述"这次变更改了什么"。这是 OpenSpec 能在棕地代码库上工作的关键。
- changes/ 目录：每次变更是一个目录，包含
proposal.md（提案）、specs/（增量规范）、tasks.md（任务）。 - archive/ 目录：变更完成后归档，增量规范合并进主规范（source of truth）。
关键命令（通过 openspec CLI 触发）：
openspec init：初始化项目openspec change：创建变更openspec validate：校验增量规范openspec archive：归档变更- 集成 25+ 工具（Claude Code、Cursor、Kiro、Pi 等）
适用场景：
- 棕地（brownfield）代码库——已有大量存量代码，需要精准改动
- 多 Agent 并发开发——每个 Agent 处理一个变更，互不干扰
- 不希望为整个系统写大而全规范、只想为每次改动写增量规范的团队
优点：Delta Spec 天然适配棕地、轻量、多 Agent 友好、工具集成广。 缺点：对绿地项目（从零开始）可能不够"全面"；增量规范需要团队自律维护；规范粒度较细，需要一定的维护成本。
四、选型矩阵与落地建议
4.1 选型矩阵
| 维度 | Spec Kit | Superpowers | OpenSpec |
|---|---|---|---|
| 核心驱动 | 模板驱动 | 流程驱动 | 增量驱动 |
| 核心概念 | Constitution + 标准模板 | 七步流程 + Iron Laws | Delta Spec |
| 适用代码库 | 绿地（greenfield）优先 | 通用（新功能/增强/修复） | 棕地（brownfield）优先 |
| 文档产出 | 高（标准化文档） | 中（计划 + 测试） | 低（仅增量） |
| 流程重量 | 中 | 重 | 轻 |
| 多 Agent 支持 | 中 | 弱 | 强 |
| 生态依赖 | 通用（多平台脚本） | Claude Code 为主 | 25+ 工具集成 |
| 官方背书 | GitHub 官方 | 社区明星项目 | Fission-AI |
| 学习成本 | 中（模板多） | 高（流程重） | 低（概念简单） |
4.2 落地建议：按项目阶段选择
如果你在做新项目（绿地）：
选 Spec Kit。它的标准模板和完整流程最适合从零建立工程规范，GitHub 官方背书也让团队接受度更高。你可以用 Constitution 统一团队技术偏好，用 Specify→Converge 让每个特性都走标准流程。
如果你在维护存量系统（棕地）：
选 OpenSpec。Delta Spec 让你不必为整个系统重写规范，只需为每次改动写一份增量规范。这对已有大量代码、需要精准改动、且多 Agent 并发的团队尤其友好。
如果你追求工程可靠性和严格纪律：
选 Superpowers。它的 Iron Laws 和七步流程能硬性约束 Agent 的行为，强制测试、根因排查、收尾验证，特别适合对代码质量要求极高、愿意接受更重流程的团队。
4.3 组合使用：不互斥，可叠加
这三个框架不是竞争关系，而是可以叠加的。一个成熟的团队可以这样组合：
- OpenSpec 负责"每次变更的增量规范"，适配存量代码。
- Spec Kit 负责"标准 SDD 流程"，产出可评审的规范产物。
- Superpowers 负责"工程纪律"，用 Iron Laws 约束 Agent 的测试与验证行为。
4.4 关键提醒：别让"规范"变成负担
最后，我想提醒一个容易踩的坑：规范驱动开发的目的是让 AI 可控，而不是让流程变重。
如果你发现团队在"写规范"上花的时间超过了"写代码"，说明流程过重了。此时应该：
- 裁剪模板——只保留必要的部分（Spec + Tasks 往往足够）
- 用 OpenSpec 的 Delta Spec 替代大而全的规范
- 只在"有歧义、有风险"的特性上走完整流程，简单改动直接实现
规范是工具，不是目的。 它的价值在于让 AI 的产出可验证、可维护、可交接，而不是制造新的流程负担。
五、总结
规范驱动开发的兴起，本质上是 AI 编程从"生成代码"走向"承担工程"的必然结果。当 AI 生成代码的成本趋近于零，工程的重心就转移到了意图确认、范围控制、行为验证上——这正是三个框架共同回答的底层问题。
- Spec Kit 用"标准模板"给出了教科书式的答案，适合绿地项目。
- Superpowers 用"工程纪律"给出了硬约束的答案，适合追求可靠性的团队。
- OpenSpec 用"增量规范"给出了适配存量代码的轻量答案，适合棕地项目。
选型时，不要被功能清单迷惑，先问自己：我的项目是绿地还是棕地？我更需要标准流程还是工程纪律？我能否接受更重的流程？
想清楚这三个问题，答案自然浮现。
