Superpowers 6 —— 更快、更省、更强
原文：Superpowers 6 作者：Jesse 日期：2026-06-15
TL;DR
Superpowers 6 大幅加快了构建速度，同时大幅减少了 Token 消耗，且输出质量不打折。如果你专注于 Token 最大化（tokenmaxxing），也许可以跳过这个版本；但如果你希望构建速度提升高达 50%、成本降低高达 60%，那你会爱上 Superpowers 6。
从 5.2 到 6 的飞跃
一周前，我们正准备发布 Superpowers 5.2。为了加「再改进一个」，我们已经推迟了好几次。
我们增加了对 Pi、Antigravity 和 Kimi Code 的支持。
我们让 Superpowers 在 Codex、OpenCode 和 Cursor 上运行得更好。
我们重写了大量 Superpowers 技能，使其与模型和编码框架无关，这让它们在各个平台上都更可靠。我们还撰写了一份新的贡献指南，说明如何为 Superpowers 添加对新编码智能体框架的支持。
我们做了大量工作，让可视化头脑风暴更易用、更安全、更可靠。
我们还修复了一整批 bug，其中一个特别讨厌的 bug 导致代码审查子智能体有时会审查整个分支，而不是单个任务。
这本该是一次很棒的发布。
Fable 带来的转折
然后 Anthropic 发布了（然后撤回了）Fable。在能使用 Fable 的那几天里，我把它用在了最有价值的地方。
Superpowers 用户最常见的抱怨不是什么秘密：Token 太贵了，而 Superpowers 消耗的 Token 又太多了。用 Superpowers 构建软件也比不用时更慢。「慢」这个部分其实不应该是个问题——它发生在自主子智能体驱动开发编排的构建过程中。
但它确实是个问题。慢并不好玩。贵也不好玩。
Superpowers 构建耗时更长、成本更高的很多原因，也正是它能为大量用户带来良好结果的原因。它做大量的前期规划工作，确保实现过程可以完全放手；在实现过程中强制严格的红绿 TDD；然后 Superpowers 内部的编排器会从两个维度审查每一个变更：
- 智能体是否精确地实现了要求，不多也不少。
- 工作质量是否达标。
就其本质而言，它必然比直接裸写一个未经测试的实现然后收工更慢。
但速度慢、成本高这件事从未让我开心过。
第一夜：15% 的惊喜
当 Fable 出现时，我决定看看它能在多大程度上优化子智能体驱动开发。
我想我当时期望的是 Token 消耗能减少 15% 左右。
我得到了那个数。而且远不止。
我们的第一个攻击角度是审查协调器到审查器的交接。Fable 分析了数千个子智能体驱动开发会话，发现代码审查和规格合规审查子智能体有时在审查过程中运行了大量 git 命令。仅仅是改变书面指令——用一段预生成审查包的 shell 脚本来替代查找待审查提交的方式，审查包包含格式化良好的 diff 和一些其他元数据——就将 Token 消耗和实际时间减少了约 10%。
那天晚上睡觉前，我让 Fable 在我睡着的时候再削减 15% 的实际时间和 Token 成本。
同时，我在内部 Slack 上发了一条消息，说我们应该评估一下合并代码审查器和规格合规审查器的效果。
我其实不太确定过夜会发生什么，但我绝没料到醒来时发现 Fable 已经独立得出了同样的结论，测试了它，并发现我们的评测套件显示——它节省了我要求的那额外 15%。
第二夜：25 个实验的自动研究
第二天晚上，我更有野心了。
/goal 完成后，运行一个自动研究循环来提高 superpowers 构建循环的成本效率。使用 opus 作为协调器进行测试。建立假设日志。运行实验。至少运行 25 个实验。
Fable 构建了一个完整的自动研究框架并运行了一整夜。你可以在 GitHub 上查看它构建的内容。
自动研究循环完成：25 个实验已关闭（另有 4 个记录为积压），全程使用 opus 作为协调器，每个假设都在日志中预先注册了预测，现已持久化在评测
docs/experiments/2026-06-11-build-loop-autoresearch.md（a76ddc9）。循环花费约 $165。循环发现
候选发布配置（E27）： opus 控制器 + 引导式计划 + 条件式 haiku 实现器 + 精简审查合约 + 叙述配方 + 最终审查层级锁定 → fractals 6.60（之前的组合配置为 $11.67–14.84）。植入缺陷关卡 2/3 通过，唯一的失败被归因于审查器方差加评判严格度——精简合约通过阅读审查器的报告被明确免责。在发布前还需要 N=5 的关卡测试。
数据亮眼的改进： 精简审查合约（审查器输出减少 −41%，判定完整）、叙述配方（−54%，零方差）、条件式实现器分层（每次运行节省约 $0.5–1，E22 证明它在文本计划上正确拒绝了 haiku）、fixture 真实度在 svelte 上复现（−24% 范围匹配）。
已被证伪的方向： 限制控制器思考时间适得其反——轮次从 92 升至 138，输出翻倍；思考能换取轮次效率。计划字数预算削减了 −62% 的测试内容，即便代码被豁免。Sonnet 生成计划质量尚可但任务结构崩溃。实现体放在计划中是边际收益——测试 + 接口 + 结构才是全部核心（E28）。
值得记住的风险发现： 只拿到 diff 包的审查器会产生自信的规格判定，却悄悄将「规格」重新定义为全局约束——0/5 标记了缺失的 brief。与 haiku 审查器偏见的失败模式相同。
六个方向已确认最优（报告读取、缓存健康、审查器下限、haiku 修复器、todo 记录、调度重新推导）——记录在案，防止别人再次尝试。
我自己的三个测量错误在循环中被发现并修正（一个 grep 计数将模板回显当作自查捕获、一个框架从未内联 diff、一个评分正则缺少换行符）——一个被撤回的判定重新测量后修正（−74% 变成了诚实的 −41%）。
结果：50% 更快，60% 更省
长话短说，经过约 36 小时的工作和本来需要 $650 的 Token 消耗（无补贴情况下），我们的 Anthropic 评测基准显示 Superpowers 构建的实际运行时间减少了 50%，Token 消耗减少了 60%。
然后我们在 Codex 上跑了评测。结果并不好。我担心过它们可能不会显示出同样的改进幅度，但事实是它们完全没有任何改进。
几分钟的排查后我们找到了原因。在 Codex 上，评测环境还没有充分与宿主机 OS 隔离……所以我们一直在评测 Superpowers 5.1.0。
稍作调整后……是的。一切数据都对上了。
核心改进
最大的改进来自三个方面：
- 合并规格合规审查和代码质量审查智能体
- **预生成审查「包」**交给审查器，让它们几乎不需要运行 git
- 调整编排器对不同任务所需智能体类型的指导
我们一直在努力打磨 Superpowers 的评测套件，没有它，我们无法测量和测试这些变更。评测套件仍然相对年轻，但它意味着我们能在多种支持的编码框架上对 Superpowers 做出变更并测试，同时量化这些变更在日益增长的编码智能体集合上的效果。你可以在 GitHub 上找到它。
结语
我们为我们（以及我们的机器人伙伴）在 Superpowers 6 中取得的改进感到非常自豪。相信你会喜欢这个新版本。
你现在就可以从 GitHub 安装。它将在接下来几天内逐步进入第一方插件市场。
PS：我们在招人！如果你认识适合全职投入 Superpowers 的人，请分享招聘信息：Superpowers 社区工程师
译者注：这篇文章是 Superpowers（一个 AI 编码智能体框架）创始人 Jesse 的个人博客。文章最有趣的地方在于他展示了如何用 Anthropic 的 Fable（一个实验性的自主编程智能体）来优化自身的 AI 工具——形成了一种「用 AI 优化 AI 工具」的递归。Fable 在无人干预的情况下独立完成了 25 个实验，发现了合并审查智能体、预生成审查包、精简审查合约等关键优化策略，最终实现了 50% 的速度提升和 60% 的成本降低。这种将自主 AI 研究直接应用于生产系统优化的方法，展示了下一代软件工程的雏形。