Superpowers 6.0 深度解读：AI 写代码的评审链路被重写了 - 今日头条 摘要

文档概览

• 文章主线判断非常明确：Superpowers 6.0 表面上像一次包含平台扩展、prompt 调整、安全补强与路径策略修改的“大扫除”，但真正值得关注的核心变化，是 AI 写代码后那段“任务级评审链路”被重写。
• 文章把这次更新的目标概括为四个工程问题：
• 1. 当 Agent 开始实现较大的功能时，如何持续做对事。
• 2. 如何让 review 的边界更清晰，不在低价值上下文里发散。
• 3. 如何让长任务能够恢复，而不是会话一断就失忆。
• 4. 如何让同一套方法论能运行在不同 Agent 容器与 harness 之上。
• 因此，这篇文章并不把“新增平台支持”当成主角，而是把 AI 工程纪律、AI编程Agent工程纪律文本分发机制 与任务评审机制的重构，视为 6.0 真正的结构性变化。

关键事实

旧版 SDD 的任务后评审是双 reviewer

• 旧版 subagent-driven-development 在每个任务完成后，会运行两个 reviewer：
• 一个是 spec compliance reviewer，用来检查需求或 spec 是否被满足。
• 一个是 code quality reviewer，用来检查代码质量是否过关。
• 文章认为，这种设计表面上很严谨，但实际代价很高：
• 两个 reviewer 都要重新理解同一个 diff。
• 同一段上下文被重复消耗。
• controller 需要把大量 diff 与任务信息塞进主会话。
• 随着上下文变长，评审容易从“只检查当前任务”滑向“顺手检查整个仓库”，造成边界失控。

新版改为单一 Task Reviewer 输出两个 verdict

• Superpowers 6.0 的核心改动，是把每个任务后的双 reviewer 模式改成单 reviewer 模式。
• 新版只派一个 Task Reviewer。
• 这个 reviewer 只读一次 task diff。
• 然后一次性给出两个独立结论：
• 1. spec verdict：当前任务是否满足需求与边界。
• 2. quality verdict：当前实现的质量是否过关。
• 文章强调，这不是减少检查项，而是把两次重复阅读 diff 的成本合并成一次。
• 因而它重写的不是“有没有 review”，而是“任务级 review 如何组织、如何消耗上下文、如何限制边界”。

新版仍保留最终 whole-branch broad review

• 文章特别强调：6.0 并没有降低质量门槛。
• 新版只是把评审层次拆得更清楚：
• 任务阶段做的是“窄审”，聚焦当前 task diff。
• 分支完成阶段仍保留 whole-branch broad review，即面向整个分支的最终宽审。
• 所以它形成的是一种分层评审结构：
• 任务窄审 + 最终宽审。
• 文章把这一点作为反驳“合并 reviewer 就是偷工减料”的关键论据。

重要细节

关键文件与主流程

• 文章指出，这次 SDD 评审重写的核心文件主要在以下位置：
• skills/subagent-driven-development/SKILL.md
• task-reviewer-prompt.md
• scripts/task-brief
• scripts/review-package
• 新版主流程被写成一种更明确的流水线：
• 1. 每个 task 派一个新的 implementer。
• 2. implementer 完成任务实现。
• 3. 生成 review package。
• 4. 派 task reviewer 做评审。
• 5. 只有 spec 与 quality 两个 verdict 都通过，才把任务写入 progress ledger。
• 这个 progress ledger 位于 .superpowers/sdd/progress.md。
• 它的用途不是装饰性记录，而是长任务恢复时的账本。

Task Reviewer 的边界约束

• 文章认为 task-reviewer-prompt.md 最关键的价值，在于它把 reviewer 的活动范围明确收窄了。
• 其中几条重要约束包括：
• diff file 是 reviewer 的主视图。
• reviewer 不应默认把注意力扩展到 diff 之外的整个代码库。
• 只有当 reviewer 能明确指出某个具体风险时，才允许去查看 diff 外代码。
• prompt 不鼓励 reviewer 重跑整个测试套件。
• 只有在代码阅读已经产生了具体疑问时，才允许做 focused test，也就是有针对性的局部验证。
• 文章对这套约束的解释是：
• 评审真正有价值的地方，在于识别具体缺陷与具体风险。
• 它不在于制造“我又完整检查了一遍”的仪式感。
• 对 Agent 而言，越开放的评审 prompt，越容易把上下文与 token 烧在低价值搜索上。
• 因此 Superpowers 6.0 不是让 reviewer 更自由，而是让 reviewer 更受边界约束，从而提高信号密度。

实现者报告不被默认采信

• 文章还提到新版 reviewer prompt 的一个重要态度：implementer report 只能被当作“未验证声明”。
• 也就是说，实现者自己声称：
• “我保持了简单”
• “这是 YAGNI”
• “测试已经覆盖”
• 这些说法都不能直接被 reviewer 采信。
• reviewer 必须回到 diff 本身，核实当前改动是否真的满足任务目标，以及是否引入新的质量风险。
• 这实际上是把评审从“听实现者解释”改成“以代码证据为准”。

交接材料文件化，降低主会话上下文成本

• 文章认为，这次 SDD 重写里另一个“小但关键”的动作，是把交接材料文件化。
• scripts/task-brief 会从计划中抽出单个任务，写成 .superpowers/sdd/task-N-brief.md。
• 这样 implementer 不必在主会话里接收整份长计划全文，而只需读取当前任务对应的 brief。
• scripts/review-package 会基于 base 和 head 生成一个 diff 包。
• 这个 review package 包含：
• commit list
• files changed
• 带上下文的 net diff
• reviewer 直接读取这个文件，不需要自己临时跑一串 git 命令，也不需要 controller 把大段 diff 粘贴到对话里。
• 文章认为，这种 文件化任务交接 直接带来三类收益：
• 1. 长任务中的主会话不再被每个 task 的 diff 反复挤占。
• 2. reviewer 不必临场重新还原“刚才到底发生了什么”。
• 3. 如果评审失败，修复回路可以围绕同一个 brief 与同一个 diff package 继续转，而不是不断在 prompt 里补丁式追加说明。

进度账本与恢复机制

• 新版把 .superpowers/sdd/progress.md 作为 progress ledger。
• 文章把它称为长任务恢复时的账本。
• 在上下文被压缩、会话中断或分支暂停后，controller 可以读取这个 progress ledger，并结合 git log，定位第一个未完成任务后继续推进。
• 文章特别指出，这对多小时甚至多天的 Agent 开发尤为重要。
• 它解决的是“做了一半如何续上”的工程问题，而不是单纯的“记笔记”。

v6.0.3 的修补：scratch 目录从 .git/sdd 迁到 .superpowers/sdd

• 文章说明，早期 6.0 把 scratch 文件放在 .git/sdd/ 下。
• 这个决定引出了兼容问题：
• Claude Code 会保护 .git/ 目录。
• 当子代理尝试写 report 时，可能被该保护机制阻挡。
• 同时，把这类 scratch 内容放在 .git/ 附近也容易引出状态管理问题。
• 因此 v6.0.3 的修补是：
• 把 SDD workspace 固定到工作树中的 .superpowers/sdd。
• 并写入“自忽略”的 .gitignore。
• 这样做的结果有两个：
• 1. 避开 Claude Code 对 .git/ 的保护。
• 2. 避免 scratch 文件污染 git status。
• 这是一个看似细小、实际很关键的兼容修补。

对业务流程的影响

计划阶段边界必须更清晰

• 文章指出，新版 SDD 会在计划中更强调：
• Global Constraints
• Interfaces
• Non-negotiables
• 原因是：task reviewer 是按照当前任务 brief 做评审的。
• 如果计划阶段没有把边界、接口与不可违背条件写清楚，后续就不能指望 reviewer 自动脑补。
• 这体现出 任务颗粒化计划 与任务级评审之间的耦合：计划越清楚，任务窄审越可靠。

任务派发更像文件驱动流水线

• 文章把新版流程概括为一种带明确交接物的流水线：
• controller 生成 brief
• implementer 写 report
• review-package 生成 diff 包
• task reviewer 给出双 verdict
• 每一步都留下文件化交接物。
• 文章承认，这会让流程“慢一点点”。
• 但换来的是：
• 可恢复
• 可审计
• 可复跑

评审阶段更聚焦，不再默认扩展成全仓审查

• 旧版两个 reviewer 可能分别再扫一遍同一份 diff。
• 新版则要求一个 reviewer 在单次阅读中做双重判断。
• 它不应该顺手扩展成全仓 review。
• 跨任务、跨模块的集成风险，原则上留给最终 broad review 处理。
• 文章认为，这样的分工更符合风险分层。

多平台支持的真实意义

• 6.0 新增了 Kimi Code、Pi、Antigravity 三个 harness。
• 但文章明确认为，这件事真正重要的，不是“支持的平台数多了三个”，而是 skill 层与 harness 层的语义分离更清晰了。