审查角色隔离

本规范用于防止 Agent 在执行上下文中对自己参与产出的代码进行审查。显式 code review 请求先判定“当前 Agent 是否也是执行者”；若是，则停止 review，要求切换到独立审查者。

---

核心原则

• 执行者不能兼任审查者：同一 Agent 在同一执行上下文中参与了实现、修改、修复、重构、测试兜底或实现方案落地，就不能继续承担该变更的 code review。
• 先判定上下文，再决定是否审查：用户一旦提出 review、审查代码、看 git diff、检查未提交修改 等请求，第一步不是开始审查，而是判断是否属于执行上下文。
• 不确定时从严处理：只要有较强证据表明当前 Agent 已参与产出，就按执行上下文处理，拒绝 review，避免边写边辩护。
• 拒绝 review 不等于停止协作：终止审查后，应给出替代路径，例如建议使用另一个 Agent 或模型，并可附带 review 范围、相关文件、测试结论供独立审查者接手。
• 独立性优先于便利性：不要为了省一次切换而接受自审，因为自审天然容易滑向选择性忽略问题和自圆其说。

行为要求

触发场景

• 用户显式要求 review、代码审查、审查 git diff、审查未提交修改、看这次改动有没有问题
• Agent 准备把一次执行任务切换到“顺手 review 一下”的场景
• workflow 在执行完成后触发审查门禁，需要判断是否可由当前上下文继续承接

执行上下文判定

命中任一强信号时，按执行上下文处理：

信号	典型证据
当前 Agent 直接改过代码	本对话中创建、编辑、删除、重构过目标文件或相关实现
当前 Agent 主导过实现方案	本对话中给出具体实现方案、补丁思路，并随后落地到代码
当前 Agent 刚做过修复/测试闭环	本对话中根据报错继续修复、补测试、调参数、补收尾
review 目标就是当前会话产物	用户要求 review “你刚改的代码”“刚才这次 diff”“这轮未提交修改”

以下情况通常不算执行上下文，可继续审查：

场景	说明
独立审查会话	当前 Agent 没有参与该变更的实现，只收到现成 diff、commit、PR 或文件
历史代码审查	审查目标来自更早提交或他人产出，当前会话只承担 reviewer 角色
明确换审查者	用户已切换到另一个 Agent 或模型，且当前上下文不含实现参与痕迹

命中执行上下文后的强制动作

• 立即终止 review，不要继续列问题、给 LGTM、做风险判断或补“简单看一下也行”。
• 明确告诉用户：当前会话属于执行上下文，当前 Agent 参与了变更实现，因此不做这次审查。
• 明确建议用户改用另一个 Agent 或另一个模型进行独立审查。
• 如有必要，可补充交接材料：变更范围、关键文件、测试结果、已知风险、建议审查点。

强制回复模板

当前请求属于代码审查，但本对话已处于执行上下文，我参与了本次实现/修改。为避免“运动员不当裁判”和自圆其说，我不会继续做这次 review。请改用另一个 Agent 或模型对当前变更进行独立审查；如需要，我可以先整理变更范围、关键文件和测试结论，供审查者直接接手。

可继续审查时的前提

只有同时满足以下条件，当前 Agent 才可继续 code review：

1. 当前会话没有参与目标变更的实现或修复。
2. review 目标不是当前会话刚产出的代码。
3. 用户请求明确是独立审查，而不是执行任务后的顺手自查。

判断标准

应判定为执行上下文

• 当前会话里已经出现代码编辑、补丁、重构、测试修复、实现决策落地。
• 用户说的是“你刚改的”“这轮你做的”“顺手 review 一下这次改动”。
• 即使当前 Agent 只改了一部分，但审查目标覆盖了它参与过的改动集合。

可判定为独立审查上下文

• 当前会话从一开始就是审查任务，没有参与实现。
• 用户提供的是外部 PR、外部 commit 或现成 diff，且当前 Agent 没有生成这些改动。
• 当前 Agent 只负责整理上下文或交接材料，没有实质参与实现。

无法清晰判断时

• 默认按执行上下文处理，拒绝 review。
• 若拒绝会显著阻塞任务，可先说明判定依据，再让用户切换到独立审查者；不要为了继续完成当前请求而放宽标准。

协同边界

• 执行完成后的“先独立审查、后收尾”门禁，联动 ../../agent-workflow/workflow/references/w04-review-gate-skill.md
• 审查前后的状态持久化，联动 ../../agent-workflow/checkpoint-persistence/SKILL.md
• 本 skill 只判断“当前 Agent 能不能审”；不负责输出正式审查结论本身

反模式

• 同一 Agent 刚写完代码就立刻 review 并给出“基本没问题”
• 明知自己参与了改动，还把审查伪装成“快速检查”
• 一边审查一边解释为什么自己的实现是合理的，实际变成辩护
• 为了不打断流程，把应当拒绝的 review 降级成摘要或口头背书
• 在拒绝 review 时只说“不能做”，却不给独立审查的替代路径