第 22 章 · Reviewer、Judge 与共识

本章目标：设计一个独立但不迷信多数票的审查层，让发现能够定位、复现并与验收标准关联。

1. 为什么需要独立审查

实现 Agent 带着自己的过程历史，容易沿用原假设。Reviewer 使用新的上下文，只读取需求、项目规则、最终 diff 和测试结果，可以减少自我合理化。它的任务不是重做实现，而是寻找回归、遗漏边界和缺失验证。

独立上下文也意味着 Reviewer 不知道实现过程中的所有困难。必要背景应通过设计决定和证据提供，而不是让它读取全部聊天。

2. 高质量 Finding

一个可行动发现包含严重度、具体位置、触发路径、行为影响和修复方向。只说“这里可能有问题”会增加噪声。

P1 · 过期 token 仍可能通过缓存路径
位置：src/cache_auth.py:88
触发：token 首次验证后过期，再次命中缓存
影响：绕过 expires_at 检查
证据：新增测试可在当前分支复现

严重度按用户影响和发生概率，而不是按代码风格偏好。

3. Judge 能做什么

当多个 Reviewer 产生候选问题，Judge 可以去重、检查证据、打分并过滤低置信度项。Judge 仍是模型，不应成为真理裁判。确定性测试和源码证据优先于投票结果。

用两个 Agent 重复说同一错误并不会让它成为事实，因为它们可能共享同一模型偏见。多样性来自不同证据、工具、提示和模型，而不只是多运行几次。

4. 共识与分歧

共识适合降低遗漏，但会增加成本。对高风险安全问题，可以让两个独立 Reviewer 检查，再由主 Agent 验证。对普通小改，一个严格 Reviewer 和测试通常足够。

分歧不应被平均掉。报告应保留“Reviewer A 认为接口会破坏兼容，Reviewer B 认为有迁移层”，并指向双方证据。最终决策可能需要人类产品判断。

5. 防止审查噪声

Reviewer 要限制在本次 diff 和可证明问题，不要借机重构整个仓库。可以设置置信阈值，但更重要的是要求每个 finding 有文件位置和失败场景。

误报率需要评测。团队如果长期忽略 80% 的发现，真正严重问题也会被淹没。记录被接受、拒绝和后来证实的结果，可以改进 rubric。

6. 审查闭环

发现进入实现 Agent 修复后，应由原验证器或新 Reviewer 确认问题消失，不能仅听实现 Agent 说“已处理”。最终交付列出解决的发现、拒绝理由和残余风险。