Superpowers 把 vibe coding 推回 TDD

最近几个月，社区里出来一批”反 vibe coding”的 Claude Code 插件。它们的共同形态都差不多：把一段写代码的过程拆成 brainstorm、spec、plan、worktree、subagent 这几道工序，让模型必须按顺序走。Superpowers 是这一类里社区体量最大的一个。Eric 这期视频 Claude Code + SUPERPOWERS = The End of Vibe Coding? 用一个真实的 Next.js 项目把整条线跑了一遍，刚好可以拿来回答一个问题：这套东西到底解决了什么，又值不值得装在你的工作流里。

真正的卖点是 TDD，不是 subagent

视频里 Eric 自己也先问了一句：现在已经有 GSD、SpecKit、BDD 一堆 spec-driven 框架了，为什么还要 Superpowers？

他给的答案是 TDD：先写测试，再写实现，跑通后再 refactor，循环到没东西可以重构为止。

这句话听起来很普通，但它把 Superpowers 在 Agent 框架谱系里的位置说清楚了。GSD 强在长任务编排和上下文隔离，gstack 强在浏览器 QA，OpenSpec 强在规格标准化，Superpowers 的差异点不在调度也不在规格，而在”过程纪律”——它逼着模型在写实现之前先把验收口径写成可执行的测试。

对照我之前整理的四框架评分，Superpowers 在长任务可扩展、互操作、安全/隐私上都排不到第一，但在”工程纪律”这一项上几乎没对手。这也解释了为什么它的 token 消耗会比 GSD 之外的执行层框架稍高：测试代码本身就是额外产出，模型没法像 vibe coding 那样省掉这一步。

一次完整跑通是什么样

Eric 在视频里演示了一遍真实流程。他自己的项目叫 Bookworm.ai，做的是把收据图片用 OCR 解析进系统的 SaaS。他要加的新功能是：用户在 Google Drive 文件夹里放新文件后，应用能一键同步过来。

Superpowers 的执行链是这样的：

第一步 brainstorm。他把一张写好的 Jira ticket 贴进 Claude Code，调 brainstorm skill。模型没有直接给方案，先去读项目里现有的 cloud import 架构，然后反问”sync 按钮在 UI 上要怎么放”，顺手生成一个本地 HTML mockup，开浏览器让 Eric 在三个 UI 方案里挑一个。

第二步生成 spec。brainstorm 跑完，模型在 docs/ 下落了一份完整 spec：上下文、设计决策、架构、用户路径、新加的 API 路由、新增组件、边界情况、验收标准全都在里面。

第三步规划。Eric 让模型把 spec 转成 implementation plan，模型调 writing-plan skill，把整个功能拆成 11 个 task。每个 task 都写明了要改的文件、要新加的测试、对应的实现步骤，每一步都是带 checkbox 的清单。

第四步选执行模式。这里有个分叉：subagent driven 还是 inline。Eric 选了官方推荐的 subagent driven，每个 task 起一个新的 subagent，带 fresh context window 跑完再回主线，避免长上下文里的 context rot。

第五步 worktree。模型问他要在项目目录下建 worktree 还是放在全局位置，Eric 选项目级。后续 11 个 task 全在这个 worktree 里执行，主分支不受影响。

第六步是 TDD 循环本身。每个 task 都按”写测试→跑测试看到红→写实现→跑测试看到绿→commit”的节奏走。

第七步 code review。所有 task 完成后，模型自己调 code-review skill，对照 spec 和 test plan 把整个 worktree 扫一遍，找出关键 bug（视频里抓到了 stale credentials、confirmed selections、metadata 错位三类问题），然后再 dispatch 一个 fix agent 去修。

最后 merge PR。worktree 合回 main，整个功能可以做手工 smoke test 了。

Eric 在浏览器里实测：上 Google Drive 加 6 个文件，回应用里点 sync，6 个文件全部识别并导入。功能验证完成。

几个值得记的小细节

视频里有几个一笔带过但很值钱的点。

老的 slash command 已经废弃。在 Claude Code 里输入 /superpowers: 仍然能看到 plan brainstorm execute-plan 这些命令，但 Eric 明确说它们已经 deprecated，正确路径是直接调对应的 skill。这是一个典型的”补全列表落后于实际能力”的坑，新手很容易踩。

code review 在 inline 而不是 subagent 里跑。任务执行阶段是 fan-out subagent，但 review 阶段反而合回 inline。我之前看官方资料时记下来过这一点：旧版 Superpowers 的 review loop 走 subagent 时一次要 25 分钟，改成 inline self-review 后压到 30 秒，照样能抓出 3-5 个真 bug。视频里 Eric 没解释为什么，但这个分层在我看是有道理的：task 之间需要隔离，review 需要的是横向视野，两件事的诉求正好相反。

worktree 必须本地选位置。这个交互体验上有点冒昧，但其实暗含一个设计判断：Superpowers 默认你想要 isolation，不想要 isolation 你自己说。这跟 GSD 的”原子提交 + 主上下文 30-40%”是同一种洁癖。

我会怎么用它

如果只是写小脚本，Superpowers 是杀鸡用牛刀，token 成本会让你心疼，每个功能拆 11 个 task 也没必要。

但如果在写底层核心库、或者改一段你自己都不太敢动的老业务代码，它的 TDD 强制循环加 subagent 隔离会变得有用：你被逼着先把验收写下来，每个修改都被关在自己的小盒子里，最后还会被一道独立 review 扫过。对真实生产代码，这就是把”凭感觉写、凭运气过”换成了”先立规矩、再上手”。

我的位置感是这样的：Superpowers 更像团队里那种话不多但很认真的同事，他不会帮你想清楚要做什么——那是 OpenSpec 或者你自己的事；他只保证你说要做的东西被认真做出来。”做什么”和”做对没”是两件事，Superpowers 只接后半句。

这期视频真正值钱的部分，是 Eric 把整条工程纪律的工作流完整摊开给你看的那段流程。Superpowers 值不值得装看人，但下次再让 Claude Code “随便先跑跑”之前，可以先问自己一句：这次有没有先写测试。