OpenSpec vs Superpowers：别再把它们当竞品了，它们是兄弟俩
前一个文章详细说了一下我如何使用OpenSpec来做需求实现和知识传递的。但是用的时候难免让我把它和一个传奇的skill库
SuperPower来对比。当我仔细思考、对比和实践之后发现这是一个神器的组合，这篇先给大家说说我的认知过程，下一篇会把我的融合经验介绍一下。
我为什么想写这篇
前两篇我已经把 OpenSpec 的核心思路和实战流程走了一遍。
- 第一篇，我讲了为什么 AI 编码真正缺的不是提示词，而是规范
- 第二篇，我用一个真实案例把
/opsx:new → /opsx:ff → /opsx:apply → /opsx:archive跑了一遍
但写到这里，我发现一个问题越来越绕不过去：
很多人在接触 OpenSpec 之后，都会很自然地问一句：
“那它和 Superpowers 到底是什么关系？”
我最开始的理解也很直线：
- OpenSpec 是一个 AI 编码框架
- Superpowers 也是一个 AI 编码框架
- 那它们大概率是竞品
后来真正用下来，我发现这个判断从起点就偏了。
它们确实都在解决 AI 编码可靠性 的问题，但解决的根本不是同一层。
所以如果硬要把它们塞进一张“谁更好”的对比表里，结论大概率会跑偏。
因为：
OpenSpec 更擅长把 change 讲清楚，Superpowers 更擅长把执行过程做扎实。
如果再说得更精确一点：
OpenSpec 更强在“变更计划”，Superpowers 更强在“执行计划”。
这才是我写这篇文章真正想讲明白的东西。
先给结论：它们不是替代关系，而是分层关系
如果你只想看一段最短结论，那就是下面这几句：
- OpenSpec 更像是“变更治理层”
- Superpowers 更像是“执行质量层”
- 前者解决的是：规格驱动、设计沉淀、任务挂靠、影响可追溯
- 后者解决的是：任务细化、并发推进、TDD、验证、review、收尾纪律
换句话说：
OpenSpec 重点解决的问题是：
- 这次变更为什么要做？
- 到底要改什么？
- 哪些行为被新增、修改、删除了？
- 这次 change 的设计依据是什么？
- 任务如何挂靠在这次 change 上？
- 几个月后回头看，还能不能知道当时为什么这么改？
Superpowers 重点解决的问题是：
- 这份计划拆得够不够细，能不能真的执行？
- 哪些任务适合并发推进，哪些必须串行？
- 有没有先写测试再写实现？
- 遇到 bug 是不是在系统性调试，而不是胡试？
- 代码写完之后，是否真的验证过？
- 分支收尾是不是有纪律，而不是“感觉差不多了就算完成”？
所以它们根本不是“同一层的框架”。
更准确的说法应该是：
OpenSpec 让 AI 不容易把 change 的方向做错，Superpowers 让 AI 在方向对的前提下，把执行过程做得更稳。
为什么很多人会误以为它们是竞品？
因为从表面上看，它们确实很像：
- 都是给 AI 编码助手用的
- 都强调工作流
- 都在试图减少“AI 写代码跑偏”的问题
- 都不是那种单纯靠 prompt engineering 的做法
但你真正把它们用进项目之后，会发现两者关注点完全不同。
OpenSpec 更关心“变更”
它把一次开发视为一个 change，围绕这个 change 建 proposal、specs、design、tasks，并且归档。
Superpowers 更关心“行为”
它把一次开发视为一组 skills 驱动的执行过程，强调 brainstorming、writing-plans、TDD、debugging、review、finishing。
所以如果一定要用一句更工程化的话来描述：
- OpenSpec 是 change-centric
- Superpowers 是 behavior-centric
前者围绕“变更工件”组织流程，后者围绕“编码行为规范”组织流程。
这个差别非常关键。
我现在怎么理解 AI 编码里的“分层问题”
用了这两个框架之后，我越来越觉得，AI 编码里至少有三层问题。而且这三层问题经常被我们混在一起谈，最后就很容易把工具也看错。
第一层：需求与变更对齐
这是最容易被忽略、但代价最大的一层。
很多人会把 AI 写废代码归因于：
- 提示词不够好
- 模型不够聪明
- 上下文没给够
但很多时候真正的问题是：
- 需求本身没讲清楚
- 边界没定义
- 非目标没说明
- 为什么要这么改也没写
- 影响范围不明确
结果就是：
AI 不是不会做，而是它只能根据模糊输入去脑补。脑补一多，偏差就出来了。
这层问题，OpenSpec 很强。
因为它会逼着你在写代码前先回答这些问题：
- Why
- What
- Impact
- Design
- Tasks
- Delta Specs
它的价值不只是“多写几份文档”，而是：
把本来藏在脑子里的模糊共识，变成对人和 AI 都可读的显式约束。
这就是为什么我现在越来越把 OpenSpec 理解成一种 变更治理机制，而不只是一个命令行工具。
第二层：执行质量控制
就算需求说清楚了，AI 也不等于就会把代码写好。
这也是我后来才真正意识到的一点：
AI 理解对了，不代表它执行得就干净。
而且这里有个很容易被误解的点：
Superpowers 不是完全不做计划。它也会做计划，而且做得还挺强。
但它更擅长的不是像 OpenSpec 那样把需求、规格、设计和 change 历史沉淀下来，而是：
- 把任务拆到适合执行的粒度
- 决定哪些任务适合并发、哪些要串行
- 用 TDD 推着任务往前走
- 在执行过程中不断验证和 review
也就是说，OpenSpec 和 Superpowers 都会参与“计划”，只是计划的层级不同：
- OpenSpec 更像在做变更级规划
- Superpowers 更像在做执行级规划
常见问题太多了：
- 任务没拆细，结果一口气改一大片
- 没写测试，出了问题只能回头补
- 调 bug 没方法，全靠猜
- 说“完成了”，但根本没跑验证命令
- 代码能跑，但风格、结构、边界都不稳
这一层，Superpowers 很强。
因为它的重点从来不是“把规格沉淀下来”，而是把执行过程拧紧：
- 让执行过程有纪律
- 让计划真的能落到每一步实施上
- 让验证变成默认动作
- 让 review 和收尾不再靠自觉
比如它那些 skills：
brainstormingwriting-planstest-driven-developmentsystematic-debuggingverification-before-completionfinishing-a-development-branch
这些东西的共同点不是“多”，而是它们都在解决一个现实问题：
人和 AI 一样，做复杂任务时都容易偷懒、跳步、脑补和自我感觉良好。
Superpowers 做的事情，本质上就是用流程把这些风险压下去。
第三层：团队协作与长期沉淀
这一层平时不容易被拿出来说，但到了项目变复杂、团队人数变多时，影响会越来越大。
比如你要考虑：
- 这次变更以后还能不能回溯？
- 新人接手时能不能看懂？
- 这套做法能不能被团队复制？
- 文档和代码之间有没有长期脱节？
- 规范是一次性的，还是能沉淀成组织资产？
这一层上，两者各有强项。
OpenSpec 更强的地方
- proposal/design/specs/tasks 是天然可沉淀的
changes/archive/让每次变更都有历史- specs 能成为团队的“当前真相”
Superpowers 更强的地方
- 能把执行纪律固化下来
- 能让 review / verify / TDD 成为习惯，而不是口号
- 更像一套“研发行为规范插件”
如果把它们放在同一个图里看，我现在的理解大概是这样：
需求与变更对齐 → OpenSpec
执行质量控制 → Superpowers
团队协作与长期沉淀 → OpenSpec + Superpowers 共同补位
回到框架本身：它们到底分别是什么？
它们都能做“计划”，但计划的层次不一样
如果只看表面，OpenSpec 和 Superpowers 都会在写代码前介入，也都会参与“计划”这件事。
但真正用下来，我觉得最容易被讲糊涂、也最值得说清楚的一点就是：
- OpenSpec 规划的是 change
- Superpowers 规划的是 execution
OpenSpec 的计划，偏“变更级”
它会关心：
- 为什么做这次变更
- 改哪些行为
- 影响哪些模块或能力
- 设计依据是什么
- 任务如何挂靠在这次 change 上
- 最后如何归档回 specs
Superpowers 的计划，偏“执行级”
它会关心：
- 任务有没有拆到足够细
- 是否适合并发推进
- 哪些步骤该先写测试
- 每一步如何验证
- 什么时候插入 review
- 最后如何决定合并、提 PR 还是继续保留分支
所以它们不是“一个负责计划，一个负责执行”这么简单。
更准确的说法应该是：
OpenSpec 管变更计划，Superpowers 管执行计划。
这个区分一旦想清楚，很多误会就没了。
OpenSpec：文档驱动，但不是文档主义
很多人一看到 OpenSpec 的 proposal/specs/design/tasks，就会本能警惕：
“这不就是另一种流程文档负担吗？”
我一开始也有这个顾虑。
但真正用下来后，我觉得 OpenSpec 最有价值的地方，不是让你多写文档，而是它把“工件”变成了 AI 编码的 稳定锚点。
它的核心工作流
/opsx:new → /opsx:ff（或 /opsx:continue）→ /opsx:apply → /opsx:archive
它的核心工件
proposal.md：为什么做、做什么specs/：行为层面的变更说明design.md：技术方案tasks.md：实施清单
它最好的设计之一：Delta Specs
我前两篇已经讲过，这里只提一句核心价值：
它不是让你重写全部规范，而是只记录“变化的部分”。
这使得它非常适合老项目。
因为现实里大多数项目不是从零开始，而是在一个复杂、历史包袱很重的系统里一点点改。
OpenSpec 正好适合这种场景。
所以如果非要给 OpenSpec 一个更准确的定位，我会说：
它不是那种“帮你自动写代码”的框架，而是一套适合 AI 协作时代的变更治理机制。
Superpowers：流程驱动，而且是“带强约束”的流程驱动
Superpowers 给我的第一感觉不是“文档很完整”，而是：
它对执行阶段非常有掌控欲。
你会明显感受到它不想让 AI 直接冲进去写代码，而是想把开发过程拆成一套可重复、可约束、可验证的动作。
它典型的思路是：
brainstorming → writing-plans → executing-plans / subagent-driven-development
→ test-driven-development → code-review → finishing-a-development-branch
这里面最重要的不是某一个 skill，而是这套系统背后的信念：
- 先想清楚
- 再拆计划
- 再按计划执行
- 执行过程中用测试约束
- 完成后必须 review
- 最后必须做收尾决策
这和很多开发者平时的工作方式正好相反。
现实里的常见流程往往是：
- 先上手改
- 觉得差不多了再补点测试
- 自己看一眼没问题就提 PR
- 真出问题了再 debug
Superpowers 本质上就是在和这套“经验主义工作流”作对。
所以如果要给它一个更准确的定位，我会说：
它不是那种专门沉淀需求和规格的框架，而是一套 AI 编码行为规范系统。
用工程语言重新对比一次
如果只保留最关键的对比维度，我会用下面这张表：
| 维度 | OpenSpec | Superpowers |
|---|---|---|
| 主要解决的问题 | 变更对齐与规范沉淀 | 执行质量与流程约束 |
| 核心产物 | proposal / specs / design / tasks | skills + workflow |
| 工作流性质 | 工件驱动 | 行为驱动 |
| 强项 | 规格驱动、change 沉淀、影响可追溯、团队协作友好 | 任务细化、并发推进、TDD、debug、verify、review、收尾纪律 |
| 最适合的场景 | 中大型功能、老项目改造、多人协作、需要长期积累规格 | 高质量实施、复杂调试、长期自主编码、需要稳住执行过程 |
| 最大盲区 | 不强制执行质量 | 不天然沉淀变更工件与长期规格资产 |
如果你认真看这张表，会发现一个很重要的事实：
它们并没有在同一个维度上直接冲突。
这也是为什么我现在越来越不喜欢“OpenSpec vs Superpowers 谁更好”这种问法。
因为这问题本身就没把层级区分开。
一个最直观的例子：添加暗黑模式时，它们各自会补哪里？
为了不和第四篇的“组合实战”重复，这里我只做一个最直观的拆解。
假设你要给一个前端项目加暗黑模式。
如果你先用 OpenSpec
它会帮你明确：
- 为什么要加暗黑模式
- 范围是什么
- 是否支持系统主题跟随
- 是否持久化用户偏好
- 会影响哪些 UI 规范
- 任务该怎么拆
也就是说，它会让这次 change 的边界清晰下来。
如果你先用 Superpowers
它会更像在问：
- 你现在的实现计划够不够清楚？
- 任务拆得够不够小？
- 测试该怎么先写？
- 有没有验证路径？
- 做完之后要不要 review 和收尾？
也就是说，它会让实施过程本身更可靠。
你会发现，两边问的问题都重要，但不是一回事。
这就是我说“不是同一层”的最直观体现。
那什么时候更适合先用 OpenSpec？
我自己的经验是，下面这些场景，OpenSpec 单独上就已经很值：
1. 需求复杂，边界不清
比如：
- 老项目模块重构
- 中大型功能新增
- 跨团队协作需求
- 一堆历史行为要梳理
这种时候你最怕的不是“代码写得不够优雅”，而是方向一开始就错了。
这时 OpenSpec 的 proposal/specs/design/tasks 非常有用。
2. 需要把变更历史留下来
比如：
- 团队要 review proposal
- 后续要审计为什么这么改
- 你想让 specs 变成长期知识资产
3. 项目是 brownfield，不是 greenfield
OpenSpec 对老项目真的很友好。
因为它不要求你先“把世界重建一遍”，而是允许你围绕 change 做增量治理。
那什么时候更适合先用 Superpowers？
也有很多场景，需求本身其实已经很清楚了，这时你真正怕的不是方向错，而是执行失控。
比如：
1. 当前任务本质上是执行型问题
- 修 bug
- 补测试
- 优化局部逻辑
- 按既定设计落地实现
2. 当前最需要的是质量约束
- 强制 TDD
- 调试必须系统化
- 完成前必须跑验证
- 提交前必须做收尾决策
3. 你已经知道要做什么，但不信任“直接开写”的过程
说白了就是：
你不担心方向错，你担心的是 写着写着变脏、变乱、变不可控。
这种时候 Superpowers 非常顺手。
真正最有价值的场景：两个一起用
这也是我现在实际工作里最常用的方式。
尤其是下面这几类任务：
1. 老项目重构
- 先用 OpenSpec 对齐 change 的范围、影响和设计
- 再用 Superpowers 保证实施质量
2. 中大型功能上线
- OpenSpec 保证需求、设计、任务清楚
- Superpowers 保证测试、验证、review 不掉链子
3. 既怕跑偏，又怕返工的任务
这是现实里最常见的任务类型。
你既担心：
- 需求理解错
- 设计不完整
也担心：
- 任务没拆细
- 代码质量失控
- 最后验证不严谨
这种时候两者一起用，是最自然的。
我现在最常用的一句话就是：
OpenSpec 负责“写清楚”，Superpowers 负责“做干净”。
这不是口号，是真的很符合日常开发体验。
这也解释了我为什么后来没有二选一
如果把时间线拉开来看，我自己的认知其实经历了三个阶段。
第一阶段：把它们当竞品
那时候我会想：
- OpenSpec 好，还是 Superpowers 好？
- 哪个更完整？
- 哪个更值得学？
第二阶段：意识到它们解决的问题不同
这时候我开始发现：
- 一个偏前置治理
- 一个偏执行控制
- 不能简单放在一个维度上 PK
第三阶段：形成组合策略
到了真正落地的时候，我的思路就变成了：
- 需求复杂度高时，先 OpenSpec
- 执行风险高时，拉 Superpowers
- 复杂任务直接组合跑
也就是从“比较工具”变成了“设计工作流”。
这对我来说是一个很大的变化。
因为我后来越来越觉得：
AI 编码真正难的，从来都不是“让它写代码”，而是“让它在整个研发过程里尽量少犯系统性错误”。
OpenSpec 和 Superpowers，分别补的正是不同类型的系统性错误。
如果你现在就想做选择，我的建议很简单
你现在最缺“需求对齐、变更沉淀、团队协作规范”
先学 OpenSpec。
你现在最缺“TDD、debug、验证、review、收尾纪律”
先学 Superpowers。
你已经开始把 AI 真正用进工作项目了
不要纠结二选一，直接开始研究怎么组合。
因为当任务变复杂之后，你大概率会同时需要：
- 一个能帮你稳住方向
- 一个能帮你稳住执行
这就是为什么我现在已经不再把它们当作竞品，而是把它们当作一套 AI 编码工作流里的两种不同能力。
总结
如果一定要用一句话总结我现在的观点，那就是：
OpenSpec 解决的是“变更治理”，Superpowers 解决的是“执行质量”。
再说得更直白一点：
- 前者尽量防止 change 一开始就走歪
- 后者尽量防止 方向没错，但执行做烂
我最后没有在它们之间二选一。
因为真正把这两个框架都用进项目之后，我发现它们最合理的位置，从来不是互相替代，而是互相补位。
如果说这篇文章解决的是：
“我到底该怎么理解 OpenSpec 和 Superpowers 的关系？”
那下一篇我会继续往前走一步，聊聊更实际的问题：
怎么把 OpenSpec 和 Superpowers 真正组合成一套企业级 AI 编码工作流。
