代码评审（Code Review）

指导正确的代码评审实践，强调技术严谨性、基于证据的声明和验证优先于表面化回应。

概述

代码评审需要三种不同的实践：

1. 接收反馈 - 以技术评估取代表演性附和
2. 请求评审 - 通过 code-reviewer 子代理进行系统化评审
3. 验证关卡（Verification Gates） - 在做出任何完成声明之前提供证据

每种实践都有特定的触发条件和协议，详见参考文件。

核心原则

技术正确性优先于社交舒适感。 先验证再实施。先提问再假设。先提供证据再做声明。

何时使用此技能

接收反馈

在以下情况触发：

• 收到来自任何来源的代码评审意见
• 反馈内容不清晰或技术上有疑问
• 多个评审项需要优先级排序
• 外部评审者缺乏完整上下文
• 建议与现有决策冲突

请求评审

在以下情况触发：

• 在子代理驱动的开发中完成任务（每个任务完成后）
• 完成重要功能或重构
• 合并到主分支之前
• 遇到困难需要新视角
• 修复复杂 bug 之后

验证关卡

在以下情况触发：

• 即将声称测试通过、构建成功或工作完成
• 提交（commit）、推送（push）或创建 PR 之前
• 切换到下一个任务时
• 任何暗示成功/完成的陈述
• 对工作表达满意时

快速决策树

情况判断？
│
├─ 收到反馈
│  ├─ 有不清晰的内容？ → 停下，先请求澄清
│  ├─ 来自合作伙伴？ → 理解后实施
│  └─ 来自外部评审者？ → 先技术验证再实施
│
├─ 完成工作
│  ├─ 重要功能/任务？ → 请求 code-reviewer 子代理评审
│  └─ 合并前？ → 请求 code-reviewer 子代理评审
│
└─ 即将声明状态
   ├─ 有最新的验证结果？ → 声明时附上证据
   └─ 没有最新验证？ → 先运行验证命令

接收反馈协议

响应模式

阅读 → 理解 → 验证 → 评估 → 回应 → 实施

关键规则

• 不要进行表演性附和："你说得太对了！"、"好观点！"、"感谢你的[任何内容]"
• 不要在验证之前就实施
• 应该：复述需求、提出问题、用技术理由进行反驳，或直接开始工作
• 如果不清楚：停下来，先对所有不清楚的内容请求澄清
• YAGNI（你不会需要它）检查：在实施被建议的"正规"功能之前，先 grep 搜索其用法

来源处理

• 合作伙伴： 受信任 - 理解后实施，不做表演性附和
• 外部评审者： 验证技术正确性，检查是否会造成破坏，如有问题则反驳

请求评审协议

何时请求

• 在子代理驱动的开发中每个任务完成后
• 重要功能完成后
• 合并到主分支之前

流程

1. 获取 git SHA：BASE_SHA=$(git rev-parse HEAD~1) 和 HEAD_SHA=$(git rev-parse HEAD)
2. 通过 Task 工具派发 code-reviewer 子代理，提供：实现内容、计划/需求、BASE_SHA、HEAD_SHA、描述
3. 根据反馈采取行动：立即修复"严重（Critical）"问题，在继续之前修复"重要（Important）"问题，记录"次要（Minor）"问题留待后续

验证关卡协议

铁律

没有最新验证证据，不得声称完成

关卡函数

识别命令 → 运行完整命令 → 阅读输出 → 验证是否支持声明 → 然后声明

跳过任何一步 = 在撒谎，而非在验证

要求

• 测试通过：测试输出显示 0 个失败
• 构建成功：构建命令退出码为 0
• Bug 已修复：原始症状的测试通过
• 需求已满足：逐行核对清单已验证

危险信号 - 立即停下

使用"应该"/"可能"/"看起来"等词语、在验证前表达满意、未经验证就提交、信任代理报告、任何暗示成功但未运行验证的措辞

与工作流的集成

• 子代理驱动： 每个任务完成后评审，验证后再进入下一个任务
• 拉取请求（Pull Request）： 验证测试通过，合并前请求 code-reviewer 评审
• 通用场景： 在任何状态声明之前应用验证关卡，对无效反馈进行反驳

底线

1. 技术严谨优先于社交表演 - 不做表演性附和
2. 系统化评审流程 - 使用 code-reviewer 子代理
3. 证据优先于声明 - 始终使用验证关卡

先验证，再质疑，然后实施。先拿到证据，再做声明。