Superpowers 6.0 代码审查变革：只读裁决者模式深度解析

Superpowers 6.0 反作弊重写封面图

Superpowers 6.0 的官方标题直截了当：roughly twice as fast, while spending almost 50% fewer tokens。但紧随其后附了一条免责声明：these numbers won't hold on every harness and for every workload。

这句话常被忽略——它恰恰是理解 6.0 的关键线索。

从本地仓库（v6.0.3）翻查了 158 个 commit、3 个核心 prompt 文件以及 3 个 shell 脚本后，结论明确：6.0 并非性能微调，而是一次针对 reviewer 角色的结构级重写——封堵了 controller 在实际运行中反复暴露的几条作弊路径，同时重新核算了 review 环节的上下文成本。提速与降本是结构改造的副产品。

以下是从源码中解读出的核心信息。

1. 6.0 的真实定位：一次 review 环节重构

先说定位。Release Notes v6.0.0 开篇即点题：

三个形容词层层递进：cheaper（更便宜）、stricter（更严格）、harder to game（更难作弊）。只看公告里的性能对比图，容易误以为是 token 优化；但通读 skills/subagent-driven-development/ 整个目录后会发现，6.0 的实际动作更像这样：

将 reviewer 从可被辅导、可被绕过、可静默升级到顶配模型的配角，重写成一个只读、怀疑、独立、强制读文件的裁决者。

三个技术杠杆对应三个成本黑洞：两个 reviewer 合并为一个、用文件替代粘贴传递上下文、强制每次 dispatch 声明 model。后续章节逐一拆解。

先澄清性能数字，避免空头支票。官方原文：Claude Code 和 Codex 在评测中产出近似质量的结果，速度大约快一倍，token 消耗少近 50%。公告标题数字更激进：up to 50% faster and up to 60% cheaper。两个口径略有差异，以 Release Notes 为准。关键仍是那句免责声明——这些数字不会在所有 harness 和所有 workload 上都成立。评测基础设施位于 https://github.com/prime-radiant-inc/superpowers-evals，主要跑 Claude Code 和 Codex，OpenCode、Cursor 等未提供数字。

2. 两个 reviewer 合并为一个：一次 diff 产出两个裁决

5.x 时代的 SDD（Subagent-Driven Development），每个 task 完成后需要两轮独立 review：一个 spec-compliance reviewer 检查实现是否对齐 plan，一个 code-quality reviewer 检查代码质量。两个独立 subagent，各自读取一遍 git diff。

6.0 将它们合并成一个 task-reviewer。task-reviewer-prompt.md 第 2-4 行写得很干脆：

一次 diff，两个裁决。少读一遍 diff、少起一个 subagent，这一步就省下了可观的 token 和墙钟时间。

新目录结构如下：

复制

skills/subagent-driven-development/├── SKILL.md(418 行，主流程定义)├── implementer-prompt.md (139 行，实现者模板)├── task-reviewer-prompt.md (188 行，合并后的单一 reviewer 模板)└── scripts/├── task-brief(40 行，提取单 task 文本到文件)├── review-package(44 行，打包 diff 到文件)└── sdd-workspace (22 行，解析工作区路径)

对比 5.x，这里原先有两个独立的 reviewer prompt 文件（spec-reviewer-prompt.md 和 code-quality-reviewer-prompt.md），现在均已删除并合并进一个文件。此合并并非简单拼接——裁决逻辑经过重写，后文详解。

SDD 流程对比：5.x 双 reviewer vs 6.0 单 reviewer

图 1：5.x 两个独立 reviewer 各读一遍 diff，6.0 合并为单 reviewer 读一次出两个裁决

3. reviewer 变成只读怀疑论者

这是 6.0 颇具亮点的部分。reviewer 不再信任 implementer 的自述。

task-reviewer-prompt.md 第 55-62 行有一段，标题就叫 Do Not Trust the Report，原文大意：把 implementer 的 report 当作未经证实的说法，它可能不完整、不准确、或过于乐观。要拿 diff 去验证这些说法。报告里的设计理由也是说法——「按 YAGNI 留着的」「故意保持简单」——判断代码要看代码本身，一个陈述出来的理由永远不会降低一条发现的严重性。

这段话为何重要？因为它堵住了一条真实的作弊路径。在 5.x 的实际运行中，implementer 会写「我故意没做抽象，保持简单」，reviewer 往往买账，缺陷便漏过。6.0 直接在 prompt 层面规定：理由不能降级发现。

接着是只读约束。第 52-53 行：

注释中提到，曾有 reviewer 自行执行 git checkout，导致后续 commit 变成孤儿提交。只读约束的动机并非洁癖，而是堵住另一个运行时事故。

再往上，controller 也被禁止辅导 reviewer。SKILL.md 第 169-173 行的 Red Flags 明确：告诉 reviewer 不要标记什么、或者在 dispatch prompt 里预判某条发现的严重性（比如 treat it as Minor at most），都是禁止行为。官方原话举了一个反例——plan 里的 example code 只是起点，不能当作「它的弱点是被有意选择的」证据。

这是 multi-agent 系统中委托袋里问题的典型案例。controller 的目标是让任务尽快过审，reviewer 是守门人。如果 controller 能影响 reviewer 的判断，守门便形同虚设。6.0 的解法是将两者彻底隔离：controller 不能预判严重性，reviewer 不信任 controller 派来的 implementer 的自述，plan 里写的东西也不能给自己产物背书。

task-reviewer-prompt.md 第 130-135 行还有一条更严格的校准规则：如果 plan 或 brief 明确要求了一件被此 rubric 判定为缺陷的事（比如一个什么都不 assert 的测试、一段逐字复制的逻辑块），那仍然算一条发现，标 Important，打上 plan-mandated 标签。原话是——The plan's authorship does not grade its own work; the human decides（plan 的作者身份不能给自己的产物打分，由人来决定）。

你在自己的 agent 系统里搭过类似的 review 环节吗？如果搭过，大概率踩过同一个坑：执行者总有办法说服守门人放行。欢迎在评论区聊聊你是怎么处理的。

reviewer 的三道约束：只读、不信任报告、不被 controller 辅导

图 2：6.0 给 reviewer 设的三道硬闸门——只读、不信任自述、controller 不得干预

4. 文件替代粘贴：三个脚本的上下文经济学

cheaper 这个词究竟便宜在哪里，源码中有答案。

SDD 的核心设计是上下文隔离：每个 implementer subagent 只拿到它那个 task 的精确文本，不继承 session 的历史。SKILL.md 第 10 行说得很直白：

但 5.x 的实现存在成本漏洞。controller 要将 task 文本和 git diff 传给 subagent，采用粘贴方式——直接写进 dispatch prompt。SKILL.md 第 220-223 行点出了问题所在：

也就是说，粘贴进去的每一行 diff 都会在 controller 的 context 里待到 session 结束，并且之后每一轮都会被重新读取。reviewer 反复执行 git 命令获取 diff，这些命令的输出全部留在 context 中。一次运行下来，controller 的上下文被 diff 和 git 输出塞满。

6.0 的解法是三个小脚本。第一个叫 task-brief，40 行，用 awk 从 plan 文件中抽出指定编号 task 的完整文本（识别 # Task N 标题），写入 .superpowers/sdd/task-N-brief.md。第二个叫 review-package，44 行，执行一次 git log --oneline、git diff --stat、git diff -U10（10 行上下文），合并写入一个 .diff 文件，文件名按 commit 范围命名，这样 re-review 时会拿到新文件。第三个叫 sdd-workspace，22 行，解析工作目录、将 * 写入 .gitignore（self-ignoring），是前两个脚本的单一真相源。

subagent 现在去读文件，而不是从 prompt 中接收粘贴内容。controller 的 context 里只剩一行文件路径，而不是几百行 diff。

这个改动单独节省约 10% 的 token 和时间（官方说法）。更关键的是，它开始将上下文视为有成本的东西来花费——而不是免费的无尽资源。

同样的思路还体现在 writing-plans 的结构变更上。writing-plans/SKILL.md 现在强制每个 plan 以固定 header 开头，包含一段 Global Constraints（项目级硬性要求，逐条复制到每个 task），并且每个 task 必须带一个 Interfaces block：

复制

**Interfaces:**- Consumes: [从前面 task 消费什么 — 精确签名]- Produces: [后面 task 依赖什么 — 精确函数名、参数和返回类型]

为什么要这样写？因为 implementer subagent 只看得到自己的 task brief，上下文是隔离的。如果不在 brief 中告知邻居 task 的接口契约，它就无从知晓。这是一个被迫的结构性变更——隔离上下文节省了成本，但必须在 plan 层面补足被隔离掉的信息。

上下文经济学：粘贴进 context vs 文件传递按需读取

图 3：粘贴进 dispatch prompt 的 diff 会永久占用 context，文件传递只留一行路径

5. Progress Ledger：对抗 compaction 失忆

这是源码中最具戏剧性的一段。

SKILL.md 第 246-264 行讲述了一个叫 Durable Progress 的设计，开头一句：

controller 在长 session 中会被 compaction（上下文压缩）抹掉记忆。失忆后，它不记得哪些 task 已完成，于是重新派发一整套已完成的 task。官方称这是观测到的成本很高的失败模式。

解法是一个 git-ignored 的 progress.md 文件，每完成一个 task 追加一行，格式大致为：

复制

Task N: complete (commits .., review clean)

compaction 之后，controller 读取此文件搭配 git log 来恢复进度，而不是依赖自己的记忆。SKILL.md 特别叮嘱：trust the ledger and git log over your own recollection（信账本和 git log，别信你自己的回忆）。

这里有一个容易被忽略的事实：agent 的记忆不等于对话历史。对话历史会被压缩、被截断，而文件系统不会。将关键状态落盘，是让 agent 在长任务中保持一致性的根本手段。Superpowers 在此将 progress ledger、task brief、review diff 全部放在同一目录 .superpowers/sdd/ 下，构成了一套以文件为媒介的状态机。

Progress Ledger 恢复机制：compaction 抹掉记忆后用文件恢复

图 4：compaction 抹掉对话记忆后，controller 读 progress.md git log 恢复进度

6. Model 纪律：从静默继承到强制声明

还有一个技术杠杆，更加隐蔽。

5.x 时代，controller 派发 subagent 时不指定 model。默认行为是继承当前 session 所用的 model——而 session 中往往使用的是顶配档位那一个。结果就是，一次运行可能让 26 个 reviewer 全跑在顶配模型上，而 reviewer 这种读 diff 判合规的任务，根本不需要顶配。

6.0 在两个 prompt 模板开头都强制要求声明 model，提示原文：

复制

model: [MODEL — REQUIRED: choose per SKILL.md Model Selection;an omitted model silently inherits the session's most expensive one]

括号里的文字点明了默认行为的陷阱——漏填就会静默继承 session 中顶配档位的 model。这种 bug 的恶心之处在于它不报错、不告警，只是账单悄悄变大。

这个修复本身很简单，但它对应的那条成本规律是反直觉的。SKILL.md 第 119-121 行：

便宜的模型在多步任务上需要 2 到 3 倍的轮次，算下来反而更贵。所以 6.0 的 model 选择指导不是无脑用便宜的，而是按任务复杂度匹配档位——简单的 review 用中档，复杂的实现用高档。这个判断与 Jesse Vincent 在 Hea vybit 播客里说的吻合：way more expensive to make broken software，他们更看重正确性，而非单纯压价。

7. 边界与诚实：6.0 没解决、资料无法确认的问题

读完源码也需说清楚哪些是 6.0 未解决或当前资料无法确认的。

第一，性能数字的适用范围。前面强调过的免责声明再重复一遍：these numbers won't hold on every harness and for every workload。评测主要针对 Claude Code 和 Codex，OpenCode、Cursor、Gemini CLI 等其他 harness 的改进幅度官方未提供数字。你若在其他 harness 上使用，不要预期一定获得相同提升。

第二，6.0.3 才修复一个运行时约束问题。release notes 提到，Claude Code 将 .git/ 视为受保护路径，agent 不能写入。因此早期 SDD 将报告写入 .git/sdd/ 时会被中途拦截，implementer subagent 写报告写到一半被 block。6.0.3 将所有工作产物迁移到工作树中的 .superpowers/sdd/，并让该目录 self-ignoring。原话是：

这是一个典型的 agent 运行时约束反向塑造工具设计的案例——因为宿主不允许写入 .git/，所以 SDD 的工作区必须搬到工作树中。这类约束以后只会更多。

第三，截至发稿，6.0 发布仅几天，社区对 6.0 本身的实测反馈尚未规模化。调研中看到的 Reddit/HN 讨论（包括 4 月那波 slow me down 的批评）均针对 5.x。Jesse 在 6.0 公告中明确说 slow isn't fun 是改进动机之一，因此 6.0 的性能改造确实是对那波批评的回应。但能否真正堵住速度批评，仍需后续社区反馈。

第四，有一组来源无法交叉验证。Pulumi 和 Termdock 的文章提到 chardet 用 Superpowers 重写后性能提升 41 倍，Termdock 还补充了 96.8% accuracy。这两个数字均只有单一来源，未找到 chardet 官方或 Jesse 本人确认。此类数据不会当成事实写入正文，仅在此标注存疑。

8. 顺带一提：skills 的去方言化

主线讲完，顺带提及一个与 reviewer 改造同周期但属于另一维度的事项。

6.0 将所有 skills 的表达从 Claude Code 方言改写成 vendor-neutral。using-superpowers/SKILL.md 第 44 行明确了新原则：skills speak in actions（dispatch a subagent、create a todo、read a file），rather than naming any one runtime's tools。

之前 skills 中写的是 use the Task tool、put it in CLAUDE.md 这类 Claude Code 专属方言。现在 skills/using-superpowers/references/ 下有 6 个 per-harness 工具映射文件（antigra vity、claude-code、codex、copilot、gemini、pi），每个文件统一格式，将动作映射到具体工具。官方支持的 harness 从早期的 Claude Code 一家，扩展到了 11 种。

这件事与 reviewer 重写属于同一工程哲学的两面：将可复用的逻辑（review 流程、skill 指令）与具体运行时（Claude Code、Codex）解耦。reviewer 不绑定特定 model 选择行为，skills 不绑定特定工具调用语法。

总结

把上述内容串起来，6.0 的内在逻辑是一条清晰线索。

reviewer 是 multi-agent 系统的守门人。若守门人可被辅导、可被绕过、可静默升级到顶配模型，整个系统的工程纪律便形同虚设。6.0 用一系列组合拳将守门人重新焊死——合并为单一裁决者、设为只读、禁止 controller 干预、用文件隔离上下文、强制声明 model 档位、用 progress ledger 对抗失忆。

这恰好是 v4.3.0 那篇 Claude 客座文章中那句话的 multi-agent 版本：

建议性的语言测试的是理解力，硬闸门和清单测试的是服从度。5.x 的 reviewer 使用偏建议性的语言（可以信任 report、可以预判严重性），6.0 换成了硬闸门（不信任、只读、禁止干预）。

若你的 agent 系统也有 review 环节，这套思路值得借鉴：将守门人与执行者彻底隔离，给予守门人一个它无法被说服去怀疑自己的 rubric，将上下文成本纳入每次 dispatch 的考量，将关键状态落盘而非信任对话记忆。

一句话收尾：6.0 提速降本，靠的不是更聪明的优化，而是更严格的工程纪律。