OpenSpec vs Superpowers vs Spec Kit：对比与组合用法

先说结论：OpenSpec 和 Spec Kit 决定做什么，Superpowers 决定 agent 怎么做。所以“OpenSpec 还是 Superpowers”多半是个伪命题。在真实仓库里站得住的组合，是一个规划工具（改动灵活、老项目多就用 OpenSpec，想要更严格的生命周期就用 Spec Kit）加上 Superpowers 负责执行，中间用桥接起来。本文按 2026 年 9 月的版本对比这三个项目，并把两种组合用法完整走一遍。

OpenSpec vs Superpowers vs Spec Kit 一览

下表的版本号和命令都在 2026-09-24 对照各项目的 README 和文档核对过。三个项目都是 MIT 协议，每隔几周就发一次版，所以命令名请理解为“当前写法”，不是永久不变的。

最后一行就是组合使用的全部理由。OpenSpec 自己的社区 schema 目录里有一段说明写得很直白：“OpenSpec only checks that artifacts exist”，也就是只管文件在不在。所以只用规划工具，执行环节是没人盯的。Superpowers 把执行盯得很紧，但它的设计和计划放在临时位置，不在评审者可以拿来和 diff 对照的变更记录里。想单独深入了解 Superpowers，可以看 Superpowers 与 Spec-First AI 编码。

SDD 有价值的不是名字，而是 artifact 链

Spec-driven development 已经变成一个很拥挤的词。有人指形式化规格，有人指可执行验收标准，也有人指让 AI agent 从产品想法生成 spec、plan、tasks 和实现代码的工作流。真正有用的问题不是哪个名字赢了，而是：代码开始前有什么可评审文件，谁批准它，最后的 diff 如何证明它遵守了这个文件。

这也是为什么 OpenSpec、Superpowers 和 GitHub Spec Kit 值得放在一起看。它们不是同一种产品，Spec Coding 也不是它们的包装层。但它们暴露出一组很有价值的模式，能让 AI 辅助交付少一点模糊、多一点可评审，而且其中两个显然就是为了叠在第三个上面而设计的。

应该选择哪条 SDD 路径？

如果你是从搜索进来的，大概率不需要一个理论排名，而是想知道这周该搭什么。原则是：用最小的一套组合，挡住那些会悄悄进入 PR 的隐性决策。

OpenSpec 和 Superpowers 可以一起用吗？

可以，这也是大家问得最多的组合。但两个都装上、直接叠加，效果并不好。目前用得最多的那个桥接项目，维护者总结了两者共处一个仓库时马上会出现的三个问题：

1. 设计文档重复。Superpowers 的 brainstorming 把设计写到 docs/superpowers/specs/，OpenSpec 又在变更文件夹里写 proposal.md 和 design.md，同一个决策有了两份文档。
2. 两份任务清单。OpenSpec 的 tasks.md 是粗粒度清单，Superpowers 的计划是一串 TDD 小步骤。同一件事在两个地方各记一遍，很快就对不上。
3. 要人工编排。每一步都得有人决定接下来调用哪个工具的 skill。

方案一：superpowers-bridge schema

superpowers-bridge 是一个自定义的 OpenSpec schema，已被收录进 OpenSpec 官方文档的社区 schema 目录。它用的是 OpenSpec 原生的 schema 机制，两个工具都不用改：把整个目录复制到 openspec/schemas/superpowers-bridge/，运行 openspec schema validate superpowers-bridge，之后每个变更自己选用哪个 schema。它的 artifact 依赖图是这样的：

brainstorm ─┬─→ proposal ─→ specs ─┐
            └─→ design ────────────┴─→ tasks

tasks ─→ plan ─→ [apply] ─→ verify ─→ retrospective

和原版 OpenSpec 相比，变化在这几处：变更从 Superpowers 的 brainstorm 开始，而不是手写 proposal；tasks.md 下面多了一份 Superpowers 的 plan.md；apply 在 git worktree 里通过 subagent-driven-development 执行，顺带启用 TDD 和代码评审；apply 之后新增两个 artifact，verify.md 和以证据为先的 retrospective.md。brainstorming 和 writing-plans 的产出都被重定向进变更文件夹，前面说的问题 1 和 2 就解决了。

/opsx:new refund-retry --schema superpowers-bridge   # 或 /opsx:ff refund-retry
/opsx:apply      # worktree + subagent-driven-development（TDD、代码评审）
/opsx:verify     # 生成 verify.md
/opsx:continue   # 生成 retrospective.md，然后归档并开 PR

采用之前要知道四件事：

• 只有通过 /opsx:* 命令才会生效。如果你在聊天里随口说一句“我们来头脑风暴一下架构”，Superpowers 会走默认流程，又写回 docs/superpowers/specs/。README 把这列为最主要的失败方式。
• 需要支持子代理的 agent。它故意没有退回到更便宜的 executing-plans，因为那条路径不会带上 TDD 和代码评审。
• 注意版本漂移。截至本文写作时，README 标注的兼容基线是 OpenSpec 1.4.1 和 Superpowers v5.1.0，而当前版本已经是 1.13.2 和 6.4.1。正式依赖之前，先跑一遍 validate，再看看仓库里还开着的 “upstream-version-check” issue。
• 不是每个改动都需要它。桥接项目自己的建议是：bug 修复、补测试、改配置、升级依赖，直接走普通 PR。流程的重量要和风险匹配。

方案二：手写一条路由规则

如果不想引入第三方 schema，在 AGENTS.md 或 CLAUDE.md 里加一小段规则，也能拿到大部分好处。它更弱，因为没有东西校验它，agent 也可能不遵守，但能消掉重复文档，让评审者只看一个地方：

## Planning vs execution
- New capability, breaking change, or architecture change:
  open an OpenSpec change first (/opsx:propose <name>).
- Superpowers brainstorming output goes into
  openspec/changes/<name>/design.md, not docs/superpowers/specs/.
- writing-plans output goes into openspec/changes/<name>/plan.md;
  tasks.md stays the checklist reviewers tick.
- Bug fixes, typos, dependency bumps: no change folder, normal PR.
- A task is done when its tests pass and every diff hunk maps
  to a line in tasks.md.

这段该放在哪个文件、文件里还该写什么，见 面向 Spec-First 团队的 AGENTS.md。

Spec Kit 和 Superpowers 一起用

同样的分工也适用于 Spec Kit。speckit-superpowers-bridge 已被收录进 Spec Kit 的社区扩展目录，它对自己的概括是 “Spec Kit writes WHAT. Superpowers enforces HOW.”（Spec Kit 写做什么，Superpowers 管怎么做）。Spec Kit 仍然是 constitution、spec、plan、tasks 的唯一事实来源。/speckit-tasks 之后，一个 hook 会写出小小的交接文件 .specify/superpowers-handoff.json，桥接命令再把 tasks.md 交给 Superpowers 原生的 skills 去执行、验证、评审和收尾分支。

specify init my-project --integration claude
specify extension add speckit-superpowers-bridge \
  --from https://github.com/lihan3238/speckit-superpowers-bridge/releases/latest/download/speckit-superpowers-bridge.zip
# 然后：/speckit-specify → /speckit-clarify → /speckit-plan → /speckit-tasks → /speckit-superpowers-bridge

这个桥的出发点是：Spec Kit 自带的 implement 只是一次性的 agent 运行，没有 TDD、没有子代理分派、也没有结构化评审。这在 Spec Kit 1.0 加入 /speckit-converge 之前更成立。converge 会拿实现回头对照 spec、plan 和 tasks，把漏掉的工作追加到 tasks.md。converge 回答的是“东西做全了吗”，Superpowers 回答的是“是不是先写测试、有没有经过评审”，两者的重叠比看上去少。截至本文写作时，这个桥验证过的基线是 Spec Kit 0.16.4 和 Superpowers 6.3.0，比当前版本旧，建议先在一个一次性的功能上试用。

一体化插件

第三种做法是用一个插件把两边的思路合在一起。我们找到的最活跃的是 spec-superflow（npm 包名 spec-superflow，中文文档为主），它把 OpenSpec 式的规划和 Superpowers 式的验证纪律合进一个插件。v2 把新任务收敛成两条路径：direct 用于范围明确的小改动，planned 用于需要一份 proposal.md 和 tasks.md 并确认一次的改动。代价是依赖关系变了：你不再直接拿到 OpenSpec 和 Superpowers 的上游更新，而是依赖一个维护者把它们合进来。

Superpowers 里的 “SDD” 是另一回事

如果你搜的是 “Superpowers SDD”，你找的可能是一个 skill，而不是一种方法论。在 Superpowers 里，SDD 通常指 subagent-driven-development：为计划里的每个任务派一个新的子代理，每个任务完成后做两轮评审，先查是否符合 spec，再查代码质量。它更省的替代方案 executing-plans，是在当前会话里把所有任务做完，最后统一评审一次。

这不是 spec-driven development，但两者正好在桥接的位置衔接上：spec 和任务清单来自 OpenSpec 或 Spec Kit，subagent-driven-development 按它们执行。

真实小需求：退款失败发票

我们用这个小需求来判断该走哪条路径：“让客服管理员可以退款失败发票。”它听起来很小，但会碰到权限策略、计费 API、账务导出、审计日志和 agent 的实现范围。只写一段聊天 prompt，这些决策很容易被模型直接写进代码。

spec.md excerpt:
- Goal: allow support admins to refund failed invoices once.
- Non-goals: partial refunds, ledger schema changes, email template changes.
- Acceptance: duplicate click returns the same refund_id.

tasks.md excerpt:
- Add POST /api/invoices/:id/refund within billing/refunds.ts.
- Add idempotency fixture and audit-log assertion.
- Do not modify ledger export fields.

evidence.md excerpt:
- test: refund_failed_invoice_once
- log: audit_event_type = invoice_refund_requested
- reviewer: billing owner signs off on role boundary

最容易漏掉的失败场景是：没有规格包时，AI 可能“贴心地”加上部分退款，或者顺手改账务导出字段，因为 prompt 从来没说不能这样做。artifact 链的价值，就是把这些隐形产品决策变成可评审的一行文字。

模式 1：实现前先生成稳定文件

OpenSpec 围绕 proposal.md、写着需求和场景的 specs/ 目录、design.md 和 tasks.md 组织一次变更，归档时把通过的 specs 合并回 openspec/specs/。Spec Kit 在项目层先写一次 constitution，之后每个功能写 spec、plan 和 tasks。Superpowers 则先从对话里把设计问出来，再切成读得完的小段给你确认。术语不同，但动作一样：agent 不应该从一句聊天 prompt 直接跳到 diff。

对团队来说，规则可以很简单：在代码生成前，一个功能至少要有一份稳定文件，写清目标、非目标、验收标准、owner、依赖和证据要求。聊天记录不够，因为它很难被评审、复用或和最终代码比对。轻量做法可以参考 Spec as Code 专题，这份文件该包含哪些字段，见技术规格模板指南。

模式 2：把产品意图和技术计划分开

Spec Kit 明确要求先定义做什么和为什么，再决定怎么做。OpenSpec 也把 proposal、specs 和 design、tasks 分开。这一点对 AI 编码很重要，因为模型很容易把产品不确定性直接压缩成实现细节。一旦模型在产品问题没确认之前就决定了数据库结构、API 边界和 UI 行为，团队就失去了对决策路径的控制。

模式 3：按风险选择流程重量

OpenSpec 公开的理念是 “fluid not rigid, iterative not waterfall”（灵活而非僵硬，迭代而非瀑布），并且面向已有代码的老项目，而不只是新项目。这是对最糟糕的 SDD 版本的纠正：一堆 Markdown 堵住工作，却没有提升评审质量。登录、支付、数据迁移、公开 API 和 AI 生成改动需要更强门禁，改错别字则不需要。上面两个桥接项目也从另一侧说明了同一件事：小修直接走普通 PR。

最小可用版本可以只是一页规格包；最大可用版本才包含 constitution、需求、技术设计、任务拆解、迁移计划、风险登记和测试证据。关键是选择足够小、但仍能阻止隐性决策进入代码评审的产物组合。

模式 4：任务必须能被验证

Superpowers 在这一点上尤其强。它的 writing-plans skill 把工作拆成每个几分钟就能完成的小任务，写明确切的文件路径和验证步骤，写到一个毫无项目背景的实现者也能照着做。执行时再强制红绿 TDD。很多 AI 编码流程缺的正是这一步：只有 spec 还不够，如果下一步是一个“把所有东西都做完”的大 prompt，模型仍然会自由发挥。

Task: add timeout retry to refund worker
Write scope:
- src/billing/refund-worker.ts
- src/billing/refund-worker.test.ts

Acceptance:
- timeout once -> retry with same idempotency key
- timeout twice -> keep pending status, no duplicate refund_id

Evidence:
- test: refund_timeout_replay
- log query: duplicate_refund_attempts remains zero

这样的任务给 agent 留出了实现空间，但没有把产品策略的决定权交给它。

模式 5：评审证据是流程的一部分

三个项目本质上都在缩小“AI 写出了代码”和“团队可以信任这次改动”之间的距离，而且现在三者都在实现之后设了显式检查：OpenSpec 扩展配置里的 /opsx:verify、Spec Kit 的 /speckit-converge，以及 Superpowers 的 verification-before-completion 和代码评审 skills。缺的那个词仍然是证据。spec 应该写清评审者期待什么证明：测试、fixture 名称、日志、截图、契约检查、迁移演练或上线指标。

ticket.md
  -> spec.md
  -> design.md
  -> tasks.md
  -> tests + evidence.md
  -> PR review

如果某一环缺失，团队应该知道原因。如果 AI 生成的 PR 无法把改动映射回任务和验收标准，这个 PR 就还没准备好。我们在第一个任务开始前用的门禁是 编码前的 Spec 评审清单。

三个项目各自最值得借鉴的点

不绑定任何工具也能先落地

/specs
  /active
    refund-retry/
      spec.md
      design.md
      tasks.md
      evidence.md
  /archive
    2026-05-11-refund-retry/
/templates
  feature.spec.md
  api-contract.spec.md
  ai-coding-review.md
/docs
  engineering-principles.md

这个结构借鉴了 OpenSpec 的变更文件夹、Spec Kit 把项目原则和单个功能分开的做法，以及 Superpowers 先计划再执行的要求。它也保持可迁移：以后团队采用其中任何一个工具，文件形态已经对了，把 specs/active/<name>/ 挪到 openspec/changes/<name>/ 基本只是改个名。

团队落地时先选一个高频场景

不要一开始就把所有研发流程都改成 SDD。更稳的方式是选一个反复出问题的高频场景，比如 API 字段变更、支付重试、数据迁移、后台批量操作，或者 AI 生成代码进入 PR 前的审查。先把这个场景固定成一套小流程：谁写 spec，谁确认非目标，谁把任务拆成可执行项，谁负责提供测试证据。

第一次试点时，只要求三个文件：spec.md、tasks.md 和 evidence.md。如果这个组合已经能减少澄清评论和返工，就不要急着加更重的 governance。如果仍然有人在评审时争论产品策略，再补 design.md 或 constitution。流程不是越完整越好，而是要刚好覆盖团队最容易漏掉的决策。

AI 编码场景下的评审门禁

当 SDD 用在 AI coding 上，最重要的不是模型能力，而是评审门禁是否清楚。一个合格的 AI 任务应该写清允许修改的文件、禁止触碰的接口、验收标准、失败路径和必须运行的测试。模型可以提出实现方案，但不能决定是否新增依赖、改变公开 API、扩大范围或跳过回滚说明。

评审者应该先看 artifact 链，再看代码风格。第一步确认 diff 是否只改了允许的文件。第二步确认每条验收标准是否对应测试、日志、截图或人工检查。第三步确认没有“顺手重构”“顺手改字段”“顺手补功能”。如果这些问题没有过关，代码再整洁也不应该合并。

一份可执行的 SDD 检查清单

• 需求是否从一句话变成了可评审的 spec.md？
• 非目标是否能阻止范围漂移，而不是只写“暂不考虑”？
• 任务是否小到可以独立实现、测试和回滚？
• 每个任务是否有明确的文件边界和验收标准？
• 证据是否在 PR 前准备好，而不是发布后补充？
• AI 生成的代码是否能逐条映射回 spec 和 tasks？
• 如果同时用了 OpenSpec 和 Superpowers，设计文档和任务清单是否只有一份？

决策建议

改动范围窄、风险低、一个 PR 就能评审完，就从轻量规格包开始。改动需要 proposal、design、任务拆分和归档记录，尤其是在已有代码库里，就加上 OpenSpec。组织希望每个功能都走同一套生命周期和关卡，就改选 Spec Kit。如果问题出在实现阶段 agent 的行为上，就在两者任一之上加 Superpowers，并用桥接或路由规则把它们连起来，确保只有一份计划，而不是两份。

最重要的是不要让流程变成表演。好的 SDD 应该减少澄清评论，让测试更容易写，让 PR 评审更少主观争论。如果它只是制造更多文档，就继续收紧，直到每个文件都能改变一个决策或证明一个行为。不管这些文件由哪个工具生成，让它们在每次改动上都被执行的检查机制，见 Harness Engineering 与 Spec-Driven Development 的区别。

2026 年 9 月复核：有哪些变化

本文最早在 2026 年 5 月对比这三个项目。根据各项目的 README 和文档，此后的主要变化是：

• OpenSpec 重建为以 artifact 为引导的工作流，用 /opsx:propose、/opsx:apply、/opsx:archive 调用，新增 /opsx:explore 用于在正式开变更前先想清楚，扩展配置里还有 /opsx:verify、/opsx:ff 等命令。新增了 Stores（beta），可以把规划放进一个独立仓库供整个团队共享；还有社区 schema 目录，superpowers-bridge 就在其中。官方称支持 30 多种 AI 工具。
• Spec Kit 进入 1.0。流程改为以 /speckit-* agent skill 调用（部分 agent 写作 /speckit.*），每个功能以 /speckit-converge 收尾，bug 修复和想法评估作为可安装扩展与 SDD 并列。
• Superpowers 进入 6.x，可以从 Claude Code 和 Codex 的官方插件市场安装，另外支持十多种 agent 环境。工作流新增了比 subagent-driven-development 更省的 executing-plans，以及用于排查会话异常的 diagnosing-superpowers skill。

参考资料

• Fission-AI/OpenSpec 及其社区 schema 目录
• github/spec-kit 及 SDD 命令参考
• obra/superpowers 及最初的发布说明
• JiangWay/openspec-schemas：superpowers-bridge
• lihan3238/speckit-superpowers-bridge
• MageByte-Zero/spec-superflow