先说结论

直接点：Superpowers 6 相较上一代实现了显著提速，并且在达到同等高质量结果时，Token 消耗大幅降低。

如果你追求的是 Token 用量最大化（Tokenmaxxing），那这一版可能并非最佳选择；但如果你关注构建速度提升 50%、成本降低 60%，那这一版会让你感到满意。

一、原本只是个 5.2

一周前，Prime Radiant 团队正准备发布 Superpowers 5.2。该版本已多次跳票，每次都是“再加一项改进就发布”。

5.2 中积累的内容其实不少：

• 新增了对 Pi、Antigra vity、Kimi Code 的支持
• 优化了 Superpowers 在 Codex、OpenCode、Cursor 上的运行流畅度
• 将一批 Superpowers skill 重写为与模型和 harness 无关的形式，使其在各处更可靠；同时撰写了一份新的贡献指南，讲解如何为新的编程 agent harness 添加支持
• 提升了 Visual Brainstorming 的易用性、安全性和稳定性
• 修复了多个 bug，其中有一个尤为棘手——code review 子 agent 有时会审查整条分支，而非单个任务

原本这会是一个出色的发布版本。

然后 Anthropic 发布了（又撤下了）Fable。在能用到 Fable 的那几天里，团队将其用在了刀刃上。

二、慢和贵，是 Superpowers 的老问题

Superpowers 用户最常抱怨的一点，从来不是什么秘密：Token 价格昂贵，而 Superpowers 的使用量很大。用 Superpowers 构建软件，也比不用它要慢。这个“慢”按理说不该重要——它发生在构建过程中由子 agent 驱动的自治编排阶段。

但它确实重要。慢，影响体验；贵，同样影响体验。

Superpowers 构建之所以既慢又贵，很多原因恰恰就是它能给大量用户带来好结果的原因：

• 它做大量前置规划，确保实现可以放心交给 agent
• 实现阶段强制遵循严格的红绿 TDD
• 完成后，编排器会从两个维度审查每一处改动：1. agent 是否恰好实现了要求——不多也不少；2. 工作质量是否达标

它做的事情本身，就注定比“随便写一版不做测试就提交”要慢。

但它又慢又贵，从未让团队满意过。

三、把 Fable 拿来优化 SDD

Fable 一出现，团队就想看看它能把 Subagent Driven Development（SDD，子 agent 驱动开发）优化到什么程度。

原本期望的 Token 开销降幅大约是 15%。

结果拿到了这个数字，以及远超于此的成果。

第一刀：coordinator → reviewer 的交接

第一个突破口，是 coordinator 到 reviewer 的交接环节。Fable 分析了数千个 SDD 会话，发现 code review 和 spec-compliance review 这两个子 agent 在审查时经常执行大量 git 命令。

将“如何找到要审查的 commit”这段文字说明，替换为一个 shell 脚本——由它预先组装好一份格式规范的 diff 和一些元数据，作为“审查包”交给 reviewer——单这一项调整，Token 和耗时各降低了约 10%。

第二刀：合并两个 reviewer

当晚临睡前，团队在内部 Slack 留了一张便条：可以尝试把 code reviewer 和 spec compliance reviewer 合并成一个。

没指望那一夜能发生什么。结果醒来发现 Fable 自己得出了相同的结论，跑通了验证，并且发现这套合并方案在整个 eval 套件上，正好节省了预期中额外的 15%。

四、放手让它跑 25 个实验

第二天晚上，团队胆子大了一些，给了它一个更激进的目标：

/goal once this is done, run an autoresearch loop to improve cost-efficiency of the superpowers build loop. test with opus as the coordinator. make an hypothesis log. run experiments. run at least 25 experiments.

Fable 搭建了一整套 autoresearch 框架，跑了一整夜。它在 GitHub 上：https://github.com/prime-radiant-inc/superpowers-autoresearch

下面是它最终汇报的内容（关键数字已加粗）：

The autoresearch loop is complete: 25 experiments closed (plus 4 logged as backlog), opus as coordinator throughout, every hypothesis pre-registered with a prediction in the log. Loop spend ≈ $165.

What the loop found
The ship candidate (E27): opus controller → elicited plan → conditional haiku implementers → terse reviewer contract → narration recipe → final-review tier pin → fractals 6.24/6.60 (the combo config on hand plans was $11.67–14.84). Planted-defect gates 2/3, with the one fail forensically attributed to reviewer variance plus judge strictness — the terse contract was explicitly exonerated by reading the reviewer's reports.

Wins with numbers:
- terse reviewer contract (−41% reviewer output, verdicts intact)
- narration recipe (−54%, zero variance)
- conditional implementer tiering (~$0.5–1/run, and E22 proved it correctly refuses haiku on prose plans)
- fixture-realism replicated on svelte (−24% scope-matched)

Things now provably dead:
- capping controller thinking backfires — turns rose 92→138 and output doubled; thinking buys turn efficiency
- plan word budgets slash test content −62% even when code is exempted
- Sonnet plan generation keeps fidelity but collapses task structure
- implementation bodies in plans are marginal — tests + interfaces + structure carry the whole load (E28)

Risk finding worth remembering: reviewers given only the diff package produce confident spec verdicts that silently redefine "spec" as the global constraints — 0/5 flagged the missing brief. Same failure family as the haiku-reviewer advocacy.

Six leads closed as already-optimal (report reads, cache health, reviewer floor, haiku fixers, todo bookkeeping, dispatch re-derivation) — recorded so nobody re-buys them.

Three of my own measurement bugs were caught and corrected mid-loop by the manual-inspection discipline (a grep counting template echoes as self-review catches, a harness that never inlined the diff, a scorer regex missing newlines) — one retracted verdict was re-measured clean (−74% became the honest −41%).

这份报告里值得划重点的地方

• 候选发布配置（E27）：opus 做控制器 → 诱导式 plan → 按条件切换 haiku 实现 → 精简 reviewer 契约 → narration recipe → final-review 锁定层级 → 在 fractal（分形）基准任务上跑出 6.24 / 6.60，而对照组的手写 plan 配置要 $11.67–14.84。
• 有数字撑腰的胜利：精简 reviewer 契约（reviewer 输出 −41%，判定不变）；narration recipe（−54%，方差归零）；条件式实现分层（每轮省 ~$0.5–1，且 E22 证明它正确拒绝了对散文式 plan 用 haiku）。
• 被证伪的死路：限制控制器思考适得其反——轮数从 92 涨到 138，输出翻倍；思考换来了轮次效率。plan 字数预算会把测试内容砍掉 −62%；Sonnet 生成 plan 保住了保真度却压塌了任务结构；plan 里的实现正文其实可有可无，测试 + 接口 + 结构才是承重墙。
• 一条值得记住的风险：只给 reviewer 看 diff 包，它会给出自信的 spec 判定，却悄悄把"spec"重定义成全局约束——5 次里有 0 次报出漏掉的 brief。这和"让 haiku 当 reviewer"的失败是同一个家族。
• 六条被判定为已是最优、记档以防再踩：report reads、cache health、reviewer floor、haiku fixers、todo bookkeeping、dispatch re-derivation。
• 自查纪律抓出了三个测量 bug：一个 grep 把模板回声当成自审命中、一个 harness 从不内联 diff、一个 scorer 正则漏了换行；一条被撤回的结论（−74%）重新干净地测成了诚实的 −41%。

五、50% 更快，60% 更省——然后团队差点自欺欺人

合计约 36 小时的工作、按未补贴价格本该花掉约 $650 的 Token，团队的 Anthropic eval 基准显示：Superpowers 构建的端到端耗时降低了 50%，Token 开销降低了 60%。

然后团队把 eval 跑到了 Codex 上。结果不理想。原本就担心 Codex 上的提升没那么大，但实际是完全没有提升。

挖了几分钟，找到元凶：在 Codex 上，eval 还没有与宿主 OS 充分隔离……所以一直在测的其实是 Superpowers 5.1.0。

稍微调整了隔离……成功了，一切成立。

六、最大的三项改进

将上述内容归结起来，Superpowers 6 最大的几项改进来自：

1. 合并 spec compliance 与 code quality 两个 review agent
2. 预先打包给 reviewer 的"审查包"，让它们几乎无需再运行 git
3. 重写编排器指南：针对特定任务类型，给出该使用哪种 agent 的更明确指引

七、没有 eval 套件，这一切都做不到

团队一直在 Superpowers 的 eval 套件上投入了大量精力。没有它，这次的各种改动根本无法度量和测试。

这套套件虽然还比较新，但它已经让团队能够在多种受支持的 harness 上改进 Superpowers，并量化改动在越来越多编程 agent 上的效果。地址在：https://github.com/prime-radiant-inc/superpowers-evals

八、现在就能装

Prime Radiant 团队（连同那套自动化的 agent）对 Superpowers 6 的改进感到非常自豪。他们相信你会喜欢这一版。

现在就可以从这里安装：https://github.com/obra/superpowers

接下来几天，它会逐步进入第一方插件市场。