Peer Review 是一种质量门禁模式，通过引入第二个 AI 智能体或模型来审查并挑战主构建智能体的工作。其核心原则是：审查者的职责是找出构建者遗漏的问题，而不是表示赞同。一个只说“看起来不错”的审查是浪费的审查。审查模型应被明确指示要批判、挑战假设，并关注缺失的内容而非已有的内容。
为什么有效：LLM 存在盲点，每个模型都有过度依赖的模式、遗漏的边界情况和隐式做出的架构假设。第二个模型（或同一模型使用不同提示和角色）能捕获不同类别的问题。自动化测试遗漏而同行评审能捕获的问题包括：架构过度设计或设计不足、缺失的错误处理模式、构建者未考虑的安全漏洞、技术上满足但实现不佳的需求、死代码与无用导入、仅在规模下显现的性能陷阱、以及未覆盖的边界情况。
六种审查模式：
- Diff Critique（差异评审）：在实现完成后，由第二个模型以找错提示检查变更集，构建者采纳有效修复。
- Design Challenge（设计挑战）：在规划阶段，由第二个模型提出替代设计，构建者根据规格要求评估两者并选择更优方案。
- Threaded Debate（线程化辩论）：在探索复杂权衡时，在持久对话线程上进行多轮交流，使上下文跨轮次累积。
- Delegated Scrutiny（委托审查）：对于大型审查任务，由专门的队友智能体管理完整的同行评审交互，并向负责人提交整合后的发现报告。
- Deciding Vote（决定性投票）：当两种方案冲突时，负责人将两个选项提交给同行评审模型，由其分析权衡并推荐前进路径。
- Coverage Audit（覆盖率审计）：在验证阶段，将测试覆盖率数据和差距分析提交给同行评审模型，独立评估测试的彻底性。
选择合适模式：审查已完成代码时，小变更集（少于500行）用 Diff Critique，大变更集或完整功能用 Delegated Scrutiny；设计架构时，单一决策点用 Deciding Vote，完整系统设计用 Design Challenge；辩论权衡时，需要扩展来回讨论用 Threaded Debate，需要决定性答案用 Deciding Vote；验证测试质量时用 Coverage Audit。
通过 MCP 服务器设置：任何暴露 MCP 服务器接口的 AI 模型都可作为同行评审者。设置与模型无关。在项目的 .mcp.json 中添加同行评审模型作为 MCP 服务器： { "mcpServers": { "peer reviewer": { "command": "{ADVERSARY_CLI}", "args": ["mcp-server"], "env": { "API_KEY": "{ADVERSARY_API_KEY}" } } } } 将 {ADVERSARY_CLI} 替换为所选模型的 CLI 命令，{ADVERSARY_API_KEY} 替换为相应凭据。
两个核心 MCP 工具：
- Start session（启动会话）：开始与同行评审模型的新对话。参数包括 prompt、审批策略、沙箱模式、模型选择；返回线程/会话标识符。
- Reply to session（回复会话）：继续现有对话。参数包括线程/会话 ID、后续消息；返回模型响应。 线程/会话标识符至关重要，它允许多轮对话，使同行评审者基于先前上下文构建。
策略细节：
- Diff Critique：构建者实现功能并提交后，生成变更差异 git diff {BASE_BRANCH}...HEAD，发送给同行评审模型并附代码审查提示，解析发现为可操作项，构建者应用有效修复，可选将修复发回重新审查。审查提示模板要求寻找 bug、逻辑错误、安全漏洞、缺失错误处理、性能问题、需求合规性和代码质量，并明确不要只说“看起来不错”，不要重写代码，输出格式包含严重性、文件、问题、原因和建议。
- Design Challenge：在规划阶段，构建者起草架构或计划，发送计划与需求给同行评审模型，评审者提出替代方案或批评，构建者根据需求验证两者，如有真正权衡由人类做最终决定。
- Threaded Debate：复杂设计讨论需要扩展来回时，启动会话呈现问题，使用 reply-to-session 跨多轮继续，保持线程 ID，讨论收敛时总结结论。关键考虑：基于线程的对话会累积上下文，保持对话聚焦单一主题以避免上下文稀释。
- Delegated Scrutiny：大型任务中同行评审本身很繁重时，团队负责人生成专门队友协调同行评审，队友拥有同行评审 MCP 交互，管理多轮审查会话，总结发现并报告给团队负责人，负责人分配修复给相应构建者队友。委托的原因：同行评审来回可能消耗大量上下文窗口，委托给专门队友可保留负责人的上下文用于协调。
- Deciding Vote：当构建者与人类（或两个智能体）对方案有分歧时，将两种观点提交给同行评审模型，要求评估权衡并推荐一个，附明确推理，用推荐来辅助决策（人类有最终决定权）。
- Coverage Audit：在验证阶段，测试生成并运行后，运行测试覆盖率分析，生成覆盖率报告，发送报告与需求给同行评审模型，评审者识别未测试的边界情况、缺失的集成测试、无对应测试的需求，构建者添加缺失测试。
同行评审迭代（带审查的收敛循环）：不是简单的先构建后审查，而是运行交替收敛循环，每次迭代在构建和审查之间交替。迭代1：构建者根据规格运行产生代码；迭代2：审查者根据代码和规格运行产生发现；迭代3：构建者根据规格和发现运行修复代码；迭代4：审查者根据更新代码和规格运行产生新发现；重复直到发现收敛为零或微不足道。实现时创建两个提示文件：prompts/build.md 和 prompts/review.md。构建者和审查者共享同一 git 仓库，审查者读取构建者最新提交的代码，构建者读取审查者最新的 review-findings.md，通过 git 自然收敛。收敛信号：审查者发现降至零或仅剩低严重性项，构建者迭代间差异极小，所有需求已审查并确认满足。
反模式：
- 同行评审者当好好先生：模型只说“看起来不错”而不发现真实问题。修复：明确指示寻找问题，添加“如果发现零问题，解释检查了哪些区域以及为何认为正确。空审查可疑。”
- 同行评审者重写一切：提供完整重写而非识别问题。修复：指示描述问题和位置，不写代码。“你的输出是发现列表，不是拉取请求。”
- 构建者忽略发现：构建者无视评审发现而不处理。修复：要求构建者明确回应每个发现：“对每个审查发现，要么修复并解释修复，要么解释为何发现无效。不得跳过任何发现。”
- 无限分歧循环：构建者和审查者来回不停不收敛。修复：设置最大迭代次数，N 次后升级给人类。如果分歧持续，可能表明规格模糊需要人类澄清。
- 同一模型审查自己：构建和审查使用相同模型相同提示。修复：至少使用不同角色不同提示，理想情况使用不同模型或不同模型版本。同行评审的价值来自多样视角。
提示模板快速参考：Diff Critique 要求“找 bug、安全问题、缺失边界情况。不要说‘看起来不错’。”；Design Challenge 要求“找弱点和更简单的替代方案。评估失败模式。”；Threaded Debate 要求“继续讨论。基于先前上下文构建。”；Delegated Scrutiny 要求“拥有同行评审交互。为负责人总结发现。”；Deciding Vote 要求“评估两种方案。推荐一个并附明确推理。”；Coverage Audit 要求“识别未测试的边界情况和无测试的规格需求。”
与 Cavekit 生命周期集成：同行评审在 Hunt 生命周期的多个点适用。Draft 阶段审查需求完整性、模糊性、缺失边界情况；Architect 阶段进行架构审查，在实现前挑战计划；Build 阶段进行代码审查，每个功能后根据需求审查实现；Inspect 阶段进行同行评审迭代循环，交替构建/审查收敛；Monitor 阶段进行测试覆盖率审查，验证监控覆盖所有失败模式。最有影响的点是在 Inspect 阶段，同行评审迭代能捕获自动化测试和单智能体收敛循环都找不到的问题。
交叉引用：convergence-monitoring（如何检测同行评审迭代已收敛）、validation-first（同行评审是验证管道中的第6道门）、prompt-pipeline（如何在 Hunt 管道中构建构建者和审查者提示）、revision（当同行评审者发现需求缺口时，将修复修订到需求中）、impl-tracking（在实现跟踪文档中记录同行评审发现）。
Codex Loop Mode：最严格的自动化质量流程，通过 Ralph Loop 运行 Cavekit，其中 Claude 构建，Codex 每隔几次迭代进行对抗性审查。完全不同的模型（不同训练数据、不同偏见、不同盲点）挑战你的实现。为什么有效：单模型循环中盲点每次迭代相同，而双模型能捕获不同类别问题；构建者可能静默偏离需求，同行评审者明确检查需求合规性；质量下限从“对一个模型足够好”收敛到“经得起交叉检验”；死胡同方面，同行评审者标记重复模式。