Superpowers 不是 vibe coding 的对立面

最近 GitHub 上 spec-driven 工具一片虚火。OpenSpec、SpecKit、BMAD 一字排开，每个都说自己是”让 AI 不再 vibe coding 的那一个”。WorldofAI 频道这周又加了一个叫 Superpowers 的，号称”100x better than vibe coding”。视频很短，11 分钟讲完了上手流程，但口径一上来就把 Superpowers 跟 OpenSpec、SpecKit 并排比较，我觉得这个比较本身是错的。

Superpowers 到底装了什么

Superpowers 是一个挂在 Claude Code 上的 plugin，GitHub 仓库是 obra/superpowers，视频里说过去两个月涨了 74k star（我看 wiki 里五月份的快照已经是 18 万 star，曲线确实陡）。它跟 OpenSpec/SpecKit 不一样的地方在于，它不止给你一个写 spec 的模板，而是把整条工作流串了起来：

• brainstorm：在动笔前先让 agent 跟你来回澄清需求
• design + spec：把澄清结果落成一份可审的规格
• implementation plan：spec 再拆成一组任务清单
• sub-agents：每个任务分发给一个独立 sub-agent，开新的 context window
• TDD 循环：强制先写测试再写实现
• inline code review：改完立刻做一次自审
• git worktree：每个任务一个工作树，互不污染主分支

视频里的演示是一个 AI 公司的落地页：作者给 Superpowers 喂了”未来感的 AI 美学网站 + tech stack + design goals”，剩下的事 Superpowers 自己跑完。中间它问了一次”是新建独立文件还是改造现有页面”，给出 A/B/C 三个方案让选，然后生成了一个 landing-page.md 当实现计划。落地页最后跑出一种 plasma shader 流动效果，加 3D 卡片和玻璃拟态，作者说”我从没见过模型自己造出这种 shader”。

对照组也录了：同样的需求扔到 Claude.ai 网页版的 extended thinking 里。结果不算难看，但跟 Claude Code + Superpowers 比起来明显糙一档，作者用的词是 “still a little laggy, still bugged out”。

跟 OpenSpec、SpecKit 不是同层的东西

视频里的暗示是：Superpowers 比 OpenSpec、SpecKit、BMAD 走得更远，所以可以替代它们。我不同意。

我之前在 wiki 里做过一次四框架横评（Superpowers / GSD / gstack / OpenSpec），那次的结论是 OpenSpec 跟其他三家根本不是同一层的东西。OpenSpec 是规格层——它定义 openspec/specs/ 和 openspec/changes/ 这两个目录，规定 proposal、design、tasks、implement 之间的工件关系，任何 agent 都能读这套规格去执行。它解决的是”跨工具一致性”和”可审计性”。

Superpowers 不是这个层。它是执行层的工作流引擎，把 brainstorm → spec → plan → TDD → review 这条线在 Claude Code 内部跑起来。它写出来的 spec 不是给别的 agent 复用的，是给自己当下这次跑批用的。

放在 spec-driven development（SDD）的六模式光谱里看更清楚：

确定性递增 →
Vibe Coding → Agentic → Harness → Ralph Wiggum → BMAD → SDD

Superpowers 同时占了 Harness 和 SDD 两段：用 sub-agents + worktree + TDD 做 harness 约束（运行时不让 agent 乱跑），用 spec + plan 做 SDD 约束（开发时不让 agent 乱想）。OpenSpec 只占 SDD 一段，但占得更深，它要的是规格本身能被 review、被 diff、被多人共识。

所以这两者其实是搭档关系。我之前在 wiki 里给的推荐组合就是 OpenSpec + Superpowers：OpenSpec 管规格沉淀，Superpowers 管执行纪律。视频把它俩当替代品比较，会让初学者误以为只能选一个。

它真正解决的是哪一个痛点

如果说视频里有什么是新信息，对我来说是这两条：

inline self-review 替代 subagent review loop。 旧版 Superpowers 用一个独立的 review subagent 跑 25 分钟去审代码，但抓不出什么真问题。新版换成 inline self-review，30 秒搞定，能抓 3-5 个真实 bug。这个改法很 Karpathy 味：把验证回路压短到能跑得动的尺寸，不去堆一个看起来很正经但没法用的长流程。

sub-agents 拿到 fresh context window。 主 agent 的 context 已经被 brainstorm、spec、plan 灌满了，让它自己去写代码会被记忆污染。Superpowers 的做法是每个 task 起一个独立 sub-agent，只看自己那一份 spec 和测试。这条本质上是在做 context engineering：把上下文压力分摊到多个轻量进程，而不是让一个进程扛全部。

GSD（最接近 agent workflow engine 那一家）也走类似路径，但它的 fresh 200k-token executor 用得更激进。Superpowers 的 sub-agent 隔离做得没那么彻底，但好处是工具链都在 Claude Code 里，不用换栈。

我会怎么用

视频说 “AI 模型加 Superpowers 等于 game changer”，这种话当营销听一听就行。放在团队场景里，我的判断是：

别单独用它当规格层。Superpowers 跑一次性的任务很顺手，但写出来的 spec 不是给团队复用的，跨人协作会重新乱掉。需要团队共识的项目，spec 还是得走 OpenSpec 这种能 review、能版本化的层。

个人探索倒是很顺。一个人在自己的电脑上跑一个 demo、做一个原型，brainstorm + sub-agents + TDD 这条链够用了，视频里那种落地页 demo 就是这种场景。

TDD 那段是免费午餐。Superpowers 强制 TDD 循环，这个习惯本身值得抄，跟用不用 Superpowers 无关。Matt Pocock 那个 Claude Code 真工程师的视频也讲过，测试先行才是 spec-driven 的真正棘轮，spec 只是个起手式。

往后看版本，重点看 release notes 里有没有像 inline review 这种”把长流程压短”的改动。这种小改动比大版本号有信息量。

视频的标题党不重要。Superpowers 的真正贡献是把”工程纪律”这件事用 plugin 的形式塞回 Claude Code，让一个人能跑出团队级别的开发流程。这个事 OpenSpec、SpecKit 也在做，只是切口不同：OpenSpec 切规格，Superpowers 切工作流。它们不互相替代。