任务级双结论代码评审

定义

任务级双结论代码评审，是指在 Superpowers 6.0 的 subagent-driven-development（SDD）流程里，每个 task 完成后只派出一个 Task Reviewer，由它对同一份任务 diff 进行一次主阅读，并同时产出两个彼此独立的结论：

• spec verdict：当前任务是否满足任务 brief 与需求边界；
• quality verdict：当前实现的代码质量是否达到可接受标准。

它明确替代了旧版 SDD 的“双 reviewer”模式。旧模式下，一个 reviewer 专门看 spec compliance，另一个 reviewer 专门看 code quality；6.0 则把两类判断合并到同一个任务级 reviewer 中完成。

在本文档语境中的含义

在本文语境里，这不是一个泛泛的“代码评审优化”说法，而是 Superpowers 6.0 对 Agent 软件工程评审链路的重新切分。

它要解决的核心问题是：当 AI Agent 在较大功能上连续执行多个 task 时，任务后的评审既昂贵、又容易失焦。旧版每个 task 后运行两个 reviewer，两个 reviewer 都要重新理解同一个 diff 和同一段任务上下文，导致：

• 同一份变更被重复阅读；
• 主会话需要反复承载大量 diff 与任务信息；
• 上下文越长，评审越容易从“检查当前任务”滑向“顺手检查整个仓库”；
• 评审成本被堆在低价值的重复理解上，而不是具体缺陷发现上。

因此，任务级双结论代码评审的重点不是“减少 reviewer 数量”这么简单，而是把任务级评审重新定义为一种窄边界、高信号、低重复的检查动作。

替代的旧机制

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

• spec reviewer：检查实现是否符合任务需求与 spec；
• code quality reviewer：检查实现是否存在质量问题。

这个设计表面上更严谨，但在 Agent 场景里代价很高。因为两位 reviewer 实际都必须阅读同一个 task diff，理解同一任务背景，再分别得出结论。结果是上下文被重复消耗，controller 也需要把同样的信息多次塞进评审链路。

6.0 明确废除了这一点：不再对同一任务分别调用 spec reviewer 和 code quality reviewer，而是统一改为 Task Reviewer 一次阅读、双结论输出。

关键机制

单一 reviewer，一次阅读，两个 verdict

新机制要求单一 Task Reviewer 以任务 diff 为主视图，只读一次当前 task 的变更，然后输出两项独立判断，而不是一个笼统的“通过/不通过”。

这两个 verdict 必须区分：

• 需求是否满足；
• 质量是否过关。

也就是说，某个任务可能在功能上满足 brief，但质量不过关；也可能代码风格尚可，却没有真正实现任务要求。双结论机制保留了这两类判断的独立性，但不再用两个 reviewer 来重复完成。

任务通过条件

在新版 SDD 主流程中，一个 task 完成后会先形成评审材料，再交给 task reviewer。只有当 spec 与 quality 两个 verdict 都通过时，该任务才会被记入进度账本。

这意味着：

• 合并 reviewer 不等于合并标准；
• 通过门槛并没有降低；
• 只是把原先分散在两次阅读中的判断，合并为一次受约束的评审动作。

任务级窄审与最终宽审分层

这一机制最容易被误解成“取消了更严格的审查”，但原文强调并非如此。

6.0 保留了最终的 whole-branch broad review。它并没有把任务级 reviewer 扩展成全局 reviewer，而是反过来把职责拆得更清楚：

• 任务级评审：只看当前 task diff，判断当前任务是否按 brief 完成、是否引入明显质量风险；
• 分支级最终评审：保留 whole-branch broad review，用来检查跨任务耦合、全局一致性、集成风险以及任务之间交互产生的问题。

因此，任务级双结论代码评审不是取消最终审查，而是把“任务窄审”和“最终宽审”明确分层。

reviewer prompt 的关键约束

diff file 是主视图

Task Reviewer 的 prompt 明确规定：评审应以 diff file 作为主视图。

这意味着 reviewer 的首要工作不是在仓库里到处浏览，也不是先运行一轮全面测试，而是先基于当前任务的变更包进行代码阅读，理解本 task 实际改了什么、为什么改、改动是否覆盖任务目标。

只有能指出具体风险时，才查看 diff 外代码

prompt 的一个关键边界是：只有在 reviewer 已经能够指出某个具体风险、并且需要额外上下文来验证时，才应查看 diff 之外的代码。

换句话说，查看 diff 外代码不是默认动作，而是有条件的扩展动作。条件不是“我想更保险一点”，而是“我已经有明确怀疑，需要外部上下文来证实或排除这个具体问题”。

这条规则的目的，是防止任务评审滑成全仓库 review。

不鼓励重跑整套测试，只允许 focused test

Task Reviewer prompt 也不鼓励 reviewer 在任务评审时重跑整个测试套件。只有在代码阅读产生了具体疑问时，才允许做 focused test。

这里的重点在于“具体疑问”和“focused”。

也就是说，测试不是为了完成一种形式上的“我也跑过了”，而是为了验证阅读过程中发现的某个明确风险点。例如 reviewer 在 diff 中看到边界条件处理可能不完整，才有理由围绕该点做针对性验证。

价值判断：评审的意义是发现具体缺陷

这一机制背后的核心判断非常工程化：reviewer 的价值主要来自发现具体缺陷，而不是执行“我完整检查过”的仪式化搜索。

原文强调，对 Agent 而言，评审 prompt 越开放，越容易把上下文和 token 花在低价值搜索上。让 reviewer 漫无边界地扩展阅读、全面巡检，未必能提高发现率，反而会：

• 消耗更多上下文；
• 让任务边界模糊；
• 稀释对当前 diff 中真实问题的注意力；
• 让评审变成一种覆盖姿态，而不是缺陷发现机制。

因此，任务级双结论代码评审通过收窄 reviewer 的活动范围，来提升问题信号的纯度。它不追求 reviewer 宣称“我把一切都看过了”，而追求 reviewer 能指出具体缺陷、具体风险、具体不满足之处。

与文件化交接的关系

任务级双结论代码评审并不是孤立出现的，它与 SDD 6.0 的文件化交接机制配套。

在新版流程中：

• controller 会为单个任务生成 task brief；
• 实现完成后会生成 review package；
• review package 中包含 commit list、files changed 和带上下文的 net diff；
• Task Reviewer 直接读取这一评审包开展双结论评审。

这样做的效果是，reviewer 不需要临场自己拼凑发生了什么，也不需要 controller 把大量 diff 粘贴进对话。对于长任务、多任务分支尤其重要，因为主会话不会被每个 task 的 diff 反复挤占。

如果评审失败，后续修复也可以继续围绕同一份任务 brief 和同一份 diff package 迭代，而不是在对话中不断追加解释，导致 prompt 越补越乱。