OpenSpec、Spec Kit、Superpowers 深度对比：AI 编程时代的「规范驱动开发」三剑客

在 AI 编程助手能一口气写出几百行代码的今天，真正的问题往往不是「能不能写」，而是「写的是不是你要的」。三个开源项目都在解决同一件事：在代码落地之前，先把意图对齐、把过程管住、把上下文留住——但它们的切入点截然不同。

---

一、它们分别是什么？

OpenSpec — 轻量级的「规范即真相」层

OpenSpec 由 Fission AI 推出（Y Combinator 孵化），定位是 coding agent 的通用规划层。核心理念只有五个字：先对齐，再开工（agree first, then build confidently）。

仓库里会出现 openspec/ 目录，包含两部分：

• openspec/specs/：按能力域组织的「活文档」，描述系统当前应该如何工作
• openspec/changes/：每次变更一个文件夹，内含 proposal、design、tasks、以及 delta specs（规范增量）

典型工作流：

/opsx:explore  →  /opsx:propose  →  /opsx:apply  →  /opsx:archive
（可选探索）      （生成计划）       （实施）         （归档合并）

安装：

npm install -g @fission-ai/openspec@latest
openspec init

---

Spec Kit — GitHub 出品的「规范驱动开发」工具箱

GitHub Spec Kit 是 GitHub 官方开源的 Spec-Driven Development (SDD) 工具包。它不只面向「写代码」，而是一个可扩展的 intent-driven harness，能编排整个 SDLC，甚至非软件流程（社区已有小说写作、.NET 迁移等 preset）。

核心流程：

Constitution → Specify → Clarify → Plan → Checklist → Tasks → Analyze → Implement → Converge

安装：

uv tool install specify-cli
specify init my-project --integration cursor

社区生态庞大：35+ agent 集成、138+ 扩展、25+ preset、240+ 贡献者。

---

Superpowers — Jesse Vincent 的「技能强制」方法论

Superpowers（obra，Prime Radiant）是一套 agentic skills framework，GitHub 上增长极快。它不强调你记住一堆 slash command，而是通过 SKILL.md 技能文件 在会话中自动触发、强制遵循工程纪律。

核心理念：

1. 先设计、后实现（苏格拉底式对话）
2. 严格 TDD（RED-GREEN-REFACTOR，硬门禁）
3. 系统化调试（四阶段根因分析）
4. 子 agent 驱动开发（每个任务独立 subagent + 两阶段 review）
5. 证据优于宣称（verify before declaring success）

安装（Claude Code 示例）：

/plugin marketplace add obra/superpowers-marketplace
/plugin install superpowers@superpowers-marketplace

Cursor 等平台可手动链接 skills 目录。

---

二、核心差异一览

维度	OpenSpec	Spec Kit	Superpowers
出品方	Fission AI（独立）	GitHub 官方	obra / Prime Radiant
核心隐喻	规范是真相，变更是 delta	规范是可执行的 SDLC 流程	技能是强制行为约束
主要产物	specs/ + changes/ + delta	spec.md / plan.md / tasks.md	SKILL.md + 工作流技能
交互方式	Slash commands（/opsx:*）	Slash commands（/speckit.*）	自动触发，几乎无需记命令
流程刚性	低（enablers, not gates）	中高（可选 quality gates）	高（mandatory workflows）
活文档	✅ 强（archive 后合并进 specs）	⚠️ 弱（以 feature 为单位，非系统级 spec 库）	❌ 弱（侧重过程，不维护规范库）
Brownfield	✅ 强（delta spec 专为存量系统设计）	⚠️ 中（更适合 feature 级迭代）	⚠️ 中（TDD 在遗留代码上成本高）
TDD 强制	❌ 不强制	❌ 不强制	✅ 硬门禁
质量门禁	人工 review proposal	checklist + analyze + converge	两阶段 code review + verify
子 agent	不内置	不内置	✅ subagent-driven-development
可扩展性	中等（schema、stores beta）	✅ 极强（extensions/presets/workflows）	中等（可 fork skills）
企业/离线	规划中 Workspaces	✅ 支持 air-gapped	✅ 纯 Markdown，无 API
CLI 依赖	npm（openspec CLI）	uv + specify-cli	无（或 plugin shim）

---

三、工作流对比（同一场景：给登录加「记住我」）

OpenSpec 的做法

1. /opsx:explore：读现有 auth-session spec 和代码，讨论 30 天 vs 24 小时策略
2. /opsx:propose add-remember-me：生成 changes/add-remember-me/，内含：
   • proposal.md（为什么做）
   • specs/auth-session/spec.md（delta：ADDED/MODIFIED requirements）
   • design.md（技术决策）
   • tasks.md（任务清单）
3. 人工审阅 delta spec——只看规范变更，不必翻代码
4. /opsx:apply：按 tasks 实施
5. /opsx:archive：delta 合并进 openspec/specs/auth-session/spec.md

特点：变更可 review、规范持续演进、适合 PR 里附带「规范 diff」。

Spec Kit 的做法

1. /speckit.specify：描述「记住我」的用户故事和行为
2. /speckit.clarify：追问边界（多设备？退出所有设备？）
3. /speckit.plan：选定 Cookie 策略、Redis session 方案
4. /speckit.checklist：生成「需求质量检查单」（如：是否定义了 token 刷新行为？）
5. /speckit.tasks → /speckit.analyze（只读一致性检查）
6. /speckit.implement：若 checklist 未勾完会询问是否继续
7. /speckit.converge：对照 spec/plan/tasks 查漏，追加剩余任务

特点：流程完整、门禁多、适合「严肃 feature」；但规范随 feature 目录存在，不像 OpenSpec 有全局 spec 库。

Superpowers 的做法

1. 你说：「给登录加个记住我」
2. brainstorming 技能自动触发：苏格拉底式追问，分块展示设计，等你 approve
3. writing-plans 技能：拆成带 verification steps 的微任务
4. using-git-worktrees（可选）：隔离 worktree 开发
5. test-driven-development 技能：先写失败测试，再写最少代码
6. subagent-driven-development：每个 task 派独立 subagent，两阶段 review（spec 合规 → 代码质量）
7. verification-before-completion：跑测试、看证据，才宣布完成

特点：几乎零命令记忆成本；TDD 和 review 是硬约束；但不会在仓库里留下持久的「系统规范库」。

---

四、各自优缺点

OpenSpec

优点

• Brownfield 友好：delta spec 是最大亮点——在 5 万行老项目里改一个功能，不必先文档化整个世界
• 活文档：archive 后 specs 库持续增长，新人和新会话都能读「系统应该做什么」
• 轻量：默认 4 步循环，explore 可选；强调 enablers not gates，实施中发现设计不对可直接改 design.md
• Agent 无关：目标成为 universal planning layer，换 Cursor/Claude/Copilot 都不丢规范
• Review 友好：PR 里附 proposal + delta spec，reviewer 不用考古 chat history

缺点

• 不强制工程纪律：没有 TDD 门禁、没有自动 analyze/converge，靠人自律
• 规范维护成本：specs 库需要持续 archive，否则会 drift
• trivial fix 尴尬：改一行 bug 也要走 change 文件夹，可能过度
• 团队能力在 beta：多 repo、大单体 Workspaces 还在建设
• npm 生态：CLI 走 Node，和 Python 为主的 AI 工具链略割裂

适合场景

• 存量系统持续迭代（微服务、ERP、内部平台）
• 需要「系统级活文档」的团队
• 规范要进 Git、要 PR review 的工程文化
• 多 agent 切换、规范要跨工具持久化
• 微服务 AGENTS.md + api-contracts 体系，OpenSpec 的 specs/ 可以与之互补

---

Spec Kit

优点

• 流程最完整：从 constitution 到 converge，覆盖 SDLC 全链路
• 质量门禁内置：checklist（测需求质量）、analyze（跨 artifact 一致性）、converge（实现后查漏）
• 生态最强：138 扩展、25 preset（AIDE、MAQA、Fiction Writing…），可完全替换默认 SDD
• GitHub 原生：taskstoissues 转 GitHub Issues、企业 air-gapped 部署
• 组织级扩展：CI Guard、Architecture Guard 等合规门禁
• feature 状态管理：.specify/feature.json 跟踪活跃 feature，不依赖 git branch

缺点

• 上手门槛高：完整路径 9 步，小 feature 也可能觉得重
• 无全局 spec 库：以单次 feature 为单位，不像 OpenSpec 维护「系统真相」
• 依赖 uv/Python CLI：specify init 是入口，环境要配好
• 流程感强：即使可选 gates，整体仍偏「阶段制」，和 vibe coding 文化有冲突
• implement 阶段风险：agent 批量执行 tasks，大 feature 可能一次改太多

适合场景

• 从 0 到 1 的新项目 / 新 feature（Taskify 式 greenfield）
• 需要标准化 SDD 流程的团队或组织
• 要和 GitHub Issues / PR / CI 深度集成
• 非软件流程（产品、QA、内容）也想用同一 harness
• 需要 preset/extension 定制自己流程的企业

---

Superpowers

优点

• 零命令成本：skills 自动触发，agent「天然有纪律」
• TDD 硬门禁：解决 AI「先写代码再假装有测试」的顽疾
• subagent 编排：长任务可自治数小时，每 task 独立 context + 两阶段 review
• 系统化调试：四阶段根因分析，减少「猜一下改一下」
• 平台无关：SKILL.md 是纯 Markdown，Claude/Cursor/Codex/Gemini 都能用
• MIT、无 API、无订阅：完全本地，隐私友好

缺点

• 无持久规范库：过程管得严，但不积累「系统应该如何工作」的 specs
• TDD 在遗留代码上痛苦：老项目缺测试基础设施时，强制先写测试可能卡住
• 子 agent 依赖平台：subagent-driven-development 在 Claude Code 上最完整，Cursor 支持参差
• 流程刚性：mandatory 可能让简单任务变慢；「改个 typo」也会触发 brainstorming
• 可观测性弱：没有统一的 changes/ 文件夹，事后 audit 要靠 git log 和 chat
• 技能冲突：和其他 skills/rules 叠用时，可能出现「该听谁的」

适合场景

• 个人开发者，希望 AI 自动慢下来、做对
• 新项目、测试基础设施齐全
• 长任务自治（「帮我实现整个模块，我去开会」）
• 强 TDD / 代码 review 文化的团队
• 已用 Claude Code 且需要官方 marketplace 一键安装

---

五、哲学层面的三条路

可以用一张图理解三者站位：

                    规范持久化
                        ↑
                   OpenSpec
                        |
    流程编排 ←—— Spec Kit ——→ 行为约束
                        |
                   Superpowers
                        ↓
                    工程纪律

• OpenSpec：问的是「系统现在应该怎样？这次变更改动了什么？」— 规范即真相
• Spec Kit：问的是「从意图到交付，走哪几步？每步产出什么？」— 流程即产品
• Superpowers：问的是「agent 每一步必须遵守什么纪律？」— 技能即法律

三者都反对「一句 prompt 直接开写」，但着力点不同：

	OpenSpec	Spec Kit	Superpowers
防什么	做错需求	跳过关键阶段	跳过 TDD/review
留什么	规范库	feature 工件链	无（靠 git）
谁驱动	人 review 计划	人 + 门禁	技能自动驱动

---

六、怎么选？决策树

你的首要痛点是什么？
│
├─ 「老系统改功能，怕 AI 理解错现状」
│   → OpenSpec（delta spec + brownfield）
│
├─ 「团队要统一 SDD 流程，要能扩展、能企业部署」
│   → Spec Kit（constitution + gates + extensions）
│
├─ 「AI 写太快、不写测试、不 review、瞎宣称完成」
│   → Superpowers（TDD + subagent review + verify）
│
├─ 「要多 repo / 多服务规范对齐」
│   → OpenSpec Workspaces（beta）或 OpenSpec + 自建 platform-docs
│
└─ 「小修小补、探索性原型」
    → 三者都可能过重；直接 agent + 简短 plan 即可

组合使用（实践中常见）

三者并非互斥：

组合	思路
OpenSpec + Superpowers	OpenSpec 管「做什么、规范怎么变」；Superpowers 管「怎么做、必须 TDD」
Spec Kit + Superpowers	Spec Kit 走 specify→plan→tasks；implement 阶段由 Superpowers 的 TDD/review 技能接管
OpenSpec + Spec Kit	较重；OpenSpec 作系统 spec 库，Spec Kit 作单次 feature 流程——需约定目录不冲突

注意：叠加会增加 token 消耗和「流程打架」风险，建议从一个为主、另一个只补缺口。

---

七、与 AGENTS.md / Cursor Rules 的关系

AGENTS.md 模板（服务边界、依赖、编码约定）属于 静态上下文注入——告诉 agent「这个仓库长什么样」。

工具	与 AGENTS.md 的关系
OpenSpec	互补：AGENTS.md = 仓库级约定；openspec/specs = 功能级行为真相
Spec Kit	可合并：constitution 可引用 AGENTS.md 原则
Superpowers	平行：skills 管过程；AGENTS.md 管上下文；可能需避免重复约束

理想分层：

AGENTS.md / .cursor/rules     →  仓库结构、编码风格、服务边界（静态）
openspec/specs/ 或 spec.md    →  功能行为、需求真相（动态演进）
Superpowers skills            →  TDD、review、调试（过程强制）

---

八、总结表

如果你…	首选
维护大型存量代码，要活文档 + 可 review 的规范变更	OpenSpec
搭建团队 SDD 标准流程，要门禁、扩展、GitHub 集成	Spec Kit
个人或小团队，要 AI 自动 TDD + 长任务自治	Superpowers
微服务多仓库，规范要进 Git、跨服务对齐	OpenSpec（+ platform-docs）
0→1 新产品，从 constitution 开始	Spec Kit
Claude Code 深度用户，讨厌记命令	Superpowers
改一行 bug、写个脚本	都不用，或只用 explore

---

九、一句点评

• OpenSpec：给 AI 编程加上了 Git 式的规范版本管理——最有「工程文档资产」价值。
• Spec Kit：给 AI 编程加上了 可定制的 CI/CD 流水线——最有「组织标准化」价值。
• Superpowers：给 AI 编程加上了 资深工程师的职业习惯——最有「单兵作战质量」价值。

规范驱动开发不是 waterfall 回归，而是在 AI 能秒写代码的时代，把 10 分钟的对齐 换成 少改 400 行错代码。选哪个，取决于你更缺的是：对的记忆（OpenSpec）、对的流程（Spec Kit），还是 对的纪律（Superpowers）。

---

参考链接

• OpenSpec: https://openspec.dev/
• OpenSpec GitHub: https://github.com/Fission-AI/OpenSpec
• Spec Kit: https://github.github.com/spec-kit/
• Spec Kit GitHub: https://github.com/github/spec-kit
• Superpowers: https://github.com/obra/superpowers
• Superpowers 文档: https://obra-superpowers.mintlify.app/introduction