Superpowers 6

# Superpowers 6 来源：https://blog.fsck.com/2026/06/15/Superpowers-6/ 你也可以在我们的企业博客上阅读此文章：https://primeradiant.com/blog **太长不看**：Superpowers 6 快得多，且消耗的 token 数量大幅减少，却能获得同样高质量的结果。如果你在追求 token 最大化，或许可以跳过此版本；但如果你在乎你的构建速度提升高达 50%、成本降低高达 60%，你会爱上 Superpowers 6。 一周前，我们正准备发布 Superpowers 5.2。我们已经推迟了几次发布，只为加入“再多一个改进”。 我们增加了对 Pi、Antigravity 和 Kimi Code 的支持。 我们让 Superpowers 在 Codex、OpenCode 和 Cursor 上表现更好。 我们重写了 Superpowers 的大量技能，使其与模型和工具无关，从而让它们在各处都更可靠。我们还编写了一份新的贡献指南，指导如何为 Superpowers 添加新的编码代理工具支持。 我们做了大量工作，让视觉头脑风暴（Visual Brainstorming）更易用、更安全、更可靠。 我们还修复了一堆 bug，其中包括一个特别棘手的问题：代码审查子代理有时会审查整个分支，而不是单个任务。 这本该是一次伟大的发布。 然后 Anthropic 发布（并取消发布）了 Fable。在能访问 Fable 的那几天里，我尽最大努力利用了它。 我们最常听到的 Superpowers 用户抱怨是：token 昂贵，且 Superpowers 消耗大量 token。用 Superpowers 构建软件也比不用它更慢。“慢”这一点本身不该是问题——它发生在构建过程中自主的子代理驱动开发的编排阶段。 但问题确实存在。慢就不有趣。昂贵也不有趣。 Superpowers 构建耗时更长、成本更高的许多原因，恰恰也是它能为众多用户带来良好结果的原因。它做了大量前期规划工作，确保实现可以放手不管；在实现过程中强制使用严格的红绿 TDD（测试驱动开发）；然后 Superpowers 内部的编排器会从两个维度审查每一个变更： 1. 代理是否精确实现了要求的内容，不多也不少。 2. 工作质量是否达标。 就其本质而言，它当然会比直接跳过测试的实现方式更慢。 但这从未让我*高兴*过——因为慢且贵。 当 Fable 出现时，我决定看看它能在多大程度上优化子代理驱动开发。 我本希望 token 消耗能减少 15% 左右。 我确实得到了这个结果。而且还远远不止。 我们的第一个攻击点是研究协调器到评审器的交接过程。Fable 分析了数千次子代理驱动开发会话，发现代码和规范合规评审子代理在执行评审时，有时会运行*大量* git 命令。仅仅把查找待评审提交的书面指令切换为一个 shell 脚本（该脚本会预生成一个包含格式良好的 diff 和其他元数据的评审包），就将 token 消耗和运行时间减少了约 10%。 当天晚上临睡前，我告诉 Fable 在我睡觉期间，看看能否再削减 15% 的运行时间和 token 成本（针对我们的评估集）。 临睡前，我在内部 Slack 上发了一条消息，说我们应该评估一下如果合并代码评审器和规范合规评审器会发生什么。 我不太清楚自己预计晚上会发生什么，但绝对不是醒来发现 Fable 独立得出了相同结论、进行了测试，并发现整个评估集上额外节省了我要求的 15%。 pasted image 20260615 200048 (https://blog.fsck.com/assets/2026/06/pasted-image-20260615-200048.png) 第二天晚上，我更大胆了一些。 ``` /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 构建了一个完整的自动研究框架，并通宵运行。你可以看看它在 GitHub 上构建的内容：https://github.com/prime-radiant-inc/superpowers-autoresearch ``` **===自动研究==循环已完成：25个实验关闭**（另外4个记录为待办事项），全程使用 opus 作为协调器，每个假设都在日志中预注册了预测，现已持久化到评估文档 `docs/experiments/2026-06-11-build-loop-===autoresearch===.md` (a76ddc9)。循环花费约 $165。 该循环的发现 **候选发布版本 (E27):** opus 控制器 + 引发计划 + 条件性 haiku 实现者 + 简洁评审者契约 + 叙述配方 + 最终评审层级固定 → **分数 $6.24/$6.60**（手工计划上的组合配置是 $11.67–14.84）。植入缺陷的门槛 2/3，其中一次失败被法医归因于评审者方差加上评审官严格性——通过阅读评审者的报告明确排除了简洁契约的责任。N=5 的门槛电池测试在作为技能文本发布之前仍需完成。 **有数据的胜利：** 简洁评审者契约（评审输出减少 41%，裁决保持不变），叙述配方（减少 54%，零方差），条件性实现者层级化（每次运行约 $0.5–1，E22 证明它正确地_拒绝_对散文计划的 haiku），固定装置真实性在 svelte 上复制（范围匹配减少 24%）。 **现在已被证明无效的事情：** 限制控制器思考**适得其反**——轮次从 92 增加到 138，输出翻倍；思考换来了轮次效率。计划字数预算将测试内容削减了 62%，即使代码被豁免。Sonnet 计划生成保持保真度但破坏了任务结构。计划中的实现体作用很小——测试 + 接口 + 结构承担了全部负载 (E28)。 **值得记住的风险发现：** 只被给予 diff 包的评审者会产生_自信的_规范裁决，但默默地将“规范”重新定义为全局约束——0/5 标记了缺少简报。与 haiku 评审者倡导者属于同一失败家族。 **六个线索因已达到最优而被关闭**（报告阅读、缓存健康、评审者下限、haiku 修复者、待办事项账务、调度重新推导）——已记录以免有人重新购买。 我自己的三个测量错误在循环期间被人工检查纪律捕获并纠正（一个 grep 计数将模板回显视为自审捕获，一个框架从未内联 diff，一个评分器正则表达式缺少换行符）——一个被撤回的裁决被重新测量后变得干净（-74% 变成了诚实的 -41%）。 ``` 简而言之，在大约 36 小时的工作以及价值 $650 无补贴 token 消耗后，我们的 Anthropic 评估基准显示 Superpowers 构建的运行时间减少了 50%，token 消耗减少了 60%。 然后我们针对 Codex 运行了评估。结果不理想。我曾担心它们可能不会表现出同样程度的改进，但它们显示的是*没有任何*改进。 几分钟的排查后，我们找到了罪魁祸首。在 Codex 上，评估尚未与宿主机操作系统充分隔离……所以我们一直是在对 Superpowers 5.1.0 进行基准测试。 稍作调整后……是的，一切数据都吻合。 pasted image 20260615 195959 (https://blog.fsck.com/assets/2026/06/pasted-image-20260615-195959.png) 最大的改进来自：合并规范合规与代码质量评审代理；预先烘焙交付给评审者的评审“包”，使他们几乎不需要运行 git；以及更改我们给编排器关于特定任务需要何种代理的指导。 我们一直在努力改进 Superpowers 的评估套件，没有它，我们就无法衡量和测试我们所做的更改。该套件仍然相对年轻，但它使我们能够针对各种支持的框架制作和测试 Superpowers 的更改，并量化这些更改在不断增长的编码代理集合上的影响。你可以在 https://github.com/prime-radiant-inc/superpowers-evals 找到它。 我们为 Superpowers 6 所做的改进（以及我们的机器人伙伴所做的）感到非常自豪。我们相信你会喜欢这个新版本。 你现在就可以从 https://github.com/obra/superpowers 安装它。它将在未来几天内逐步渗透到第一方插件市场中。 附注：我们在招聘！如果你认识某个应该全职从事 Superpowers 工作的人，请将职位信息分享给他们：https://primeradiant.com/jobs/superpowers-community-engineer/