你也可以在我们的公司博客阅读这篇文章：https://primeradiant.com/blog
TL;DR：Superpowers 6 快了非常非常多，并且能用少得多的 token 得到同样高质量的结果。如果你追求的是 token 用量最大化，也许可以跳过这个版本；但如果你关心构建最多快 50%、成本最多降 60%，你会喜欢 Superpowers 6。
一周前，我们正准备发布 Superpowers 5.2。为了加入“最后一个改进”，这个版本已经延期过几次。
我们增加了对 Pi、Antigravity 和 Kimi Code 的支持。
我们让 Superpowers 在 Codex、OpenCode 和 Cursor 上表现得更好。
我们重写了一批 Superpowers skills，使它们与模型和 harness 解耦，从而在各处都更可靠。我们还写了一份新的贡献指南，说明如何为 Superpowers 增加新的 coding agent harness 支持。
我们做了大量工作，让 Visual Brainstorming 更易用、更安全、更可靠。
我们还修了一大堆 bug，包括一个特别糟糕的问题：代码审查 subagent 有时会审查整个分支，而不是只审查单个任务。
这本来会是一次很棒的发布。
然后 Anthropic 发布了（又撤下了）Fable。在我能使用 Fable 的那几天里，我尽可能把它用在最有价值的地方。
众所周知，我们从 Superpowers 用户那里听到最多的抱怨是：token 很贵，而 Superpowers 会用掉大量 token。用 Superpowers 构建软件也比不用它更慢。“慢”这件事理论上不该那么重要——它发生在构建流程中由自治 subagent 驱动的开发编排阶段。
但它确实重要。慢并不好玩。贵也不好玩。
Superpowers 构建耗时更长、成本更高的很多原因，和它能为这么多用户交付良好结果的原因其实是同一批原因。它会做大量前置规划，确保实现过程可以放手让 agent 处理；它在实现时强制严格的红绿 TDD；然后 Superpowers 内部的 orchestrator 会从两个维度审查每一个变更：
- agent 是否准确实现了被要求的内容，不多也不少。
- 工作质量是否达标。
就它正在做的事情本身而言，它必然会比 YOLO 式写一个未经测试的实现然后收工更慢。
但它慢、它贵，从来没有让我觉得开心过。
Fable 出来后，我决定看看它能把 Subagent Driven Development 优化到什么程度。
我想我当时期待的是 token 开销能降低大约 15%。
结果它做到了。而且远不止如此。
我们的第一个切入点是 coordinator 到 reviewer 的交接。Fable 分析了数千个 Subagent Driven Development session，发现代码审查和规格符合性审查 subagent 在做审查时，有时会运行非常多的 git 命令。我们只是把“如何找到需要审查的 commit”的书面说明，换成了一个预先生成 review package 的 shell 脚本，里面包含格式良好的 diff 和一些其他元数据，就把 token 开销和墙钟时间降低了大约 10%。
那天晚上我准备睡觉时，告诉 Fable 在我睡觉期间，看看能不能再从 eval 的墙钟时间和 token 成本里削掉 15%。
也是在准备睡觉时，我在内部 Slack 发了一条消息，说我们应该评估一下：如果把代码 reviewer 和规格符合性 reviewer 合并，会发生什么。
我并不真的知道自己期待隔夜会发生什么，但我觉得自己没想到的是：醒来后发现 Fable 独立得出了同样的结论，测试了它，并发现它在我们的 eval suite 上确实省下了我要求的额外 15%。
第二天晚上，我变得更有野心了一点。
/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 harness，并让它跑了一整夜。你可以在 GitHub 上看看它构建出来的东西。
**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, now durable at evals `docs/experiments/2026-06-11-build-loop-==autoresearch==.md` (a76ddc9). 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. The N=5 gate battery is still owed before any of it ships as skill text.
**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%).
简而言之，经过大约 36 小时的工作，以及如果没有补贴原本会达到 650 美元的 token 花费，我们的 Anthropic eval benchmark 显示：Superpowers 构建的墙钟运行时间降低了 50%，token 开销降低了 60%。
然后我们用 Codex 跑了 eval。结果并不好。我原本担心改进幅度可能没那么大，但结果是完全没有改进。
挖了几分钟之后，我们找到了罪魁祸首。在 Codex 上，eval 当时还没有和宿主 OS 充分隔离……所以我们一直在 benchmark Superpowers 5.1.0。
稍微调整了一下之后……没错，所有结果都站得住。
最大的改进来自三件事：合并规格符合性审查 agent 和代码质量审查 agent；预先烘焙交给 reviewer 的 review “packet”，让它们很少需要运行 git；以及改变我们给 orchestrator 的指导，说明某类任务需要什么样的 agent。
我们一直在努力完善 Superpowers 的 eval suite。没有它，我们不可能衡量和测试这些改动。这个 suite 还相对年轻，但它已经让我们能够在多种受支持的 harness 上修改和测试 Superpowers，并量化这些变化在越来越多 coding agent 上产生的影响。你可以在这里找到它：https://github.com/prime-radiant-inc/superpowers-evals
我们为自己（以及我们的机器人伙伴们）在 Superpowers 6 中做出的改进感到非常自豪。我们认为你会喜欢这个新版本。
你现在就可以从 https://github.com/obra/superpowers 安装它。接下来几天，它会逐步进入各个第一方插件市场。
PS：我们正在招聘！如果你认识应该全职参与 Superpowers 工作的人，请把这个招聘信息分享给他们：https://primeradiant.com/jobs/superpowers-community-engineer/