Superpowers v6 深度拆解：Fable 驱动 36 小时自治研发，提速 50% 降本 60%

> 作者：Jesse Vincent（Prime Radiant） > 发布时间：2026-06-15 > 项目地址：https://github.com/obra/superpowers > Evals：https://github.com/prime-radiant-inc/superpowers-evals > 原文：https://primeradiant.com/blog/2026/superpowers-6.html > 一句话：Superpowers 从 5.2 直接跳到 6，不是因为功能堆砌，而是因为 Fable 用 36 小时跑完 25 个量化实验，彻底重构了 Subagent Driven Development 的成本结构。

---

一、引言：从 5.2 到 6 —— 一个被 Fable 改写的发布计划

Superpowers 本准备发布 5.2。版本已经 delay 了两次，团队加了 Pi/Antigravity/Kimi Code 支持、改写了 model-agnostic 的 skills、优化了 Visual Brainstorming、修了一堆 bug。

然后 Anthropic 发布了 Fable。

创始人 Jesse Vincent 在拿到 Fable 的几天里，做了一件极具代表性的事：他没有让 Fable 去写新功能，而是让 Fable 优化 Superpowers 自己的构建循环。结果远超预期——不是 15% 的 token 节省，而是 wall-clock 提速 50%、token 成本降低 60%。

这足够让版本号从 5.2 变成 6。

---

二、Superpowers 的核心工作流回顾

在拆解 v6 之前，先理解 Superpowers 的"标准动作"：

1. Brainstorming：视觉化脑暴，输出设计文档 2. 隔离工作区：为每个任务创建独立分支/环境 3. 计划编写：生成详细的实现计划（spec） 4. TDD 驱动实现：严格的红绿测试驱动开发 5. 代码审查：两道关卡——代码质量审查 + Spec 合规审查 6. 完成合并：审查通过后合并分支

这个流程保证了高质量，但也带来了两个代价：慢和贵。慢是因为层层审查，贵是因为每一步都要消耗大量 token。

Jesse 的原话："It's never made me happy that it's slow and expensive."

---

三、v6 三大核心突破

突破一：Coordinator-Reviewer 交接优化 —— Pre-baked Review Packet

问题：审查子代理经常运行大量 git 命令来获取要审查的 diff。

解法：把"如何找到要审查的 commit"从文字指令改成 shell 脚本，预生成一个 review packet——包含格式良好的 diff 和元数据。

效果：token 消耗和 wall-clock 时间各降 ~10%。

这个优化的精妙之处在于：它不是让 reviewer "变聪明"，而是把 reviewer 本来要做的工作（查 git、格式化 diff）提前做完，让 reviewer 专注在"判断"而不是"准备"。

突破二：审查器架构合并 —— 从两道关卡到一道

问题：Superpowers 原本有两个独立的审查代理：

Code Quality Reviewer：代码质量是否达标
Spec Compliance Reviewer：实现是否严格符合 spec

Jesse 的直觉：把两个 reviewer 合并成一个，能不能省 15%？

Fable 的行动：Jesse 睡前在内部 Slack 发了这个思路，Fable 在夜间独立得出了同样结论，测试验证，第二天早上 Jesse 醒来时结果已经在 evals 里了。

效果：额外节省 ~15% wall-clock 和 token。

关键技术细节：

统一的两阶段审查提示词重构
引入了极具启发性的 "无法从 diff 验证"（unverifiable from diff） 状态
审查更严格、更难被绕过

突破三：Fable 自治研发循环 —— 36 小时 25 个实验

这是 v6 的灵魂。Jesse 给 Fable 的指令：

> /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
25 个关闭的实验 + 4 个 backlog
每个假设都有预注册预测
完整实验日志：docs/experiments/2026-06-11-build-loop-autoresearch.md
循环花费：~$165（未补贴 token 成本约 $650）

---

四、25 个实验的关键发现

🏆 ship candidate（E27）—— 最优配置

组合：opus controller + elicited plan + conditional haiku implementers + terse reviewer contract + narration recipe + final-review tier pin

成本：fractals ＄6.24/＄6.60（对比基准 combo config ＄11.67–14.84）

质量：planted-defect gates 2/3，唯一失败归因于 reviewer variance + judge strictness，terse contract 被明确排除责任

📈 有数字的胜利

优化项	效果
Terse reviewer contract	-41% reviewer 输出，verdict 完整性保持
Narration recipe	-54% 输出，零 variance
Conditional implementer tiering	~＄0.5-1/运行节省，且正确拒绝 haiku 处理 prose plans
Fixture-realism on svelte	-24% scope-matched

💀 被证明"彻底死亡"的直觉

这些发现极其宝贵——它们是被实验证明无效的方向，帮团队避免了未来在这些路上的投入：

1. Capping controller thinking（限制 controller 思考） → 反效果

turns 从 92 升到 138，输出翻倍
结论：thinking 买的是 turn 效率，限制它不划算

2. Plan word budgets（限制计划字数） → 破坏测试内容

即使代码部分豁免，测试内容被削减 -62%

3. Sonnet plan generation → 任务结构崩溃

保持 fidelity 但 task structure 坍塌

4. Implementation bodies in plans → 边际效用极低

tests + interfaces + structure 已经 carry 了全部负载

⚠️ 值得记住的风险发现

Reviewer 只给 diff package 时的问题：

reviewer 会产生 confident 的 spec verdicts
但静默地将 "spec" 重新定义为 "global constraints"
0/5 标记了缺失的 brief
Jesse 评价："Same failure family as the haiku-reviewer advocacy"

这个发现对任何做代码审查自动化的团队都是警钟：给 reviewer 的上下文边界必须精确定义，否则 reviewer 会自信地给出错误结论。

✅ 六项已最优，无需再投入

以下方向被证明已经是当前最优，记录以防未来重复购买：

report reads
cache health
reviewer floor
haiku fixers
todo bookkeeping
dispatch re-derivation

🔧 方法论层面的收获

Fable 在循环中抓到了 3 个测量 bug： 1. grep 把 template echoes 计为 self-review catches 2. harness 从未 inline diff 3. scorer regex 漏了 newline

其中一个 verdict 被撤回重新测量：-74% 修正为诚实的 -41%。

这展示了 autoresearch 的关键纪律：manual-inspection 不是可选项，是必需项。

---

五、Eval 体系：从"感觉快了"到"可量化"

v6 的发布如果没有 eval 体系，就是一笔糊涂账。

Superpowers evals 的价值：

跨多种 harness（Claude、Codex、OpenCode、Cursor）验证改进
量化每个改动对构建速度和 token 成本的影响
发现 Codex 上的"假阴性"——最初 Codex eval 没有与 host OS 充分隔离，一直在测 5.1.0

GitHub：https://github.com/prime-radiant-inc/superpowers-evals

这个发现过程本身就有教育意义：如果你的 eval 环境没有正确隔离，你优化的可能是旧版本。

---

六、Superpowers v6 的通用设计范式

从 v6 的演进中，可以提炼出几条超越 Superpowers 本身的工程原则：

1. 交接即成本

Coordinator→Reviewer 的 handoff 是天然的成本点。Superpowers v6 的做法不是"让交接更快"，而是"减少交接的信息准备负担"——pre-baked packet 让 reviewer 到手即用。

2. 合并审查关卡的前提是提示词工程

把两个 reviewer 合并成一个不是简单做减法。v6 的关键是统一的两阶段审查提示词重构，以及引入 "unverifiable from diff" 状态来处理边界情况。

3. Autoresearch 是成本优化的正确姿势

36 小时、$165、25 个实验——这不是"让 AI 随便试试"，而是假设预注册 + 系统测量 + 失败记录的科学方法。

4. 证明什么"不 work"和证明什么"work"同等重要

v6 的 autoresearch 日志里，"dead ideas" 和 "wins" 被同等重视。团队不需要再为 capping controller thinking 或 plan word budgets 浪费一天。

---

七、局限与风险

N=5 gate battery 仍待完成：E27 的最优配置还需要更大样本验证
Reviewer variance 是质量风险：terse contract 的效果依赖于 reviewer 的一致性
Diff-only review 的上下文缺失风险：已发现 reviewer 会静默重定义 spec
Codex 隔离问题：eval 环境的正确配置是前提，否则优化成果可能是幻觉

---

八、结语：AI 编程工作流的下一个标杆

Superpowers v6 不是又一个"支持更多模型"的功能更新。它是第一个被 Fable 级别的自治研究循环系统性优化过的 AI 编程工作流框架。

50% 提速、60% 降本，不是通过牺牲质量换来的——planted-defect gates 仍然 2/3 通过，唯一失败归因于 reviewer variance 而非提示词本身。

Jesse Vincent 在博客结尾说："We're very proud of the improvements that we (and our robot buddies) have made."

"Robot buddies" 这个词用得精准。Superpowers v6 是人类工程师和 AI 自治研究循环协作的产物。36 小时的 autoresearch 不是替代人类判断，而是把人类从"试错 25 次"中解放出来，让人类专注于判断"哪些发现值得 ship"。

对于所有正在构建 AI 编程工作流的团队，Superpowers v6 的实验日志（docs/experiments/2026-06-11-build-loop-autoresearch.md）是一份免费的经验包——里面记录了什么 work、什么不 work、以及为什么。

---

参考信息

项目地址：https://github.com/obra/superpowers
Evals 仓库：https://github.com/prime-radiant-inc/superpowers-evals
官方博客：https://primeradiant.com/blog/2026/superpowers-6.html
核心人物：Jesse Vincent（Prime Radiant 创始人，Superpowers 作者）
关键工具：Anthropic Fable（用于 autoresearch 循环）
实验日志：docs/experiments/2026-06-11-build-loop-autoresearch.md
发布时间：2026-06-15

#Superpowers #AI编程 #工作流优化 #Fable #SubagentDrivenDevelopment #Token成本 #自治研发 #代码审查 #Evals框架 #小凯