code-review

代码审查

介绍规范的代码审查实践，强调技术严谨性、基于证据的判断，以及验证优先于表面应和。

概述

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

1. 接收反馈 - 注重技术评估，而非表面应和
2. 请求审查 - 通过 code-reviewer 子 Agent 系统地进行审查
3. 验证关卡 - 在声称完成任何工作之前提供证据

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

核心原则

技术正确性高于社交舒适感。 实施前先验证。先询问，再假设。提出主张前先提供证据。

何时使用此技能

接收反馈

在以下情况触发：

• 收到来自任何来源的代码审查意见
• 反馈不明确或在技术上值得质疑
• 需要确定多个审查事项的优先级
• 外部审查者缺乏完整背景信息
• 建议与现有决策冲突

参考： references/code-review-reception.md

请求审查

在以下情况触发：

• 在子 Agent 驱动的开发中完成任务后（每项任务之后）
• 完成重要功能或重构后
• 合并到 main 分支之前
• 陷入困境且需要新的视角
• 修复复杂 Bug 后

参考： references/requesting-code-review.md

验证关卡

在以下情况触发：

• 即将声称测试通过、构建成功或工作已完成
• 提交、推送或创建 PR 之前
• 转入下一项任务时
• 任何暗示成功或完成的陈述
• 对工作表示满意时

参考： references/verification-before-completion.md

快速决策树

SITUATION?
│
├─ Received feedback
│  ├─ Unclear items? → STOP, ask for clarification first
│  ├─ From human partner? → Understand, then implement
│  └─ From external reviewer? → Verify technically before implementing
│
├─ Completed work
│  ├─ Major feature/task? → Request code-reviewer subagent review
│  └─ Before merge? → Request code-reviewer subagent review
│
└─ About to claim status
   ├─ Have fresh verification? → State claim WITH evidence
   └─ No fresh verification? → RUN verification command first

接收反馈流程

响应模式

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

关键规则

• ❌ 不要表面应和：“你说得完全正确！”、“说得好！”、“感谢 [任何内容]”
• ❌ 未经验证，不要实施
• ✅ 重述需求、提出问题、基于技术理由反驳，或直接开始处理
• ✅ 如果不明确：停止，先询问所有不明确事项
• ✅ YAGNI 检查：实施建议的“完善”功能前，先用 grep 查找其用法

来源处理

• 人类协作者： 值得信任 - 理解后实施，不要表面应和
• 外部审查者： 验证技术正确性，检查是否会造成破坏；如有错误则提出异议

完整流程： references/code-review-reception.md

请求审查流程

何时请求

• 子 Agent 驱动的开发中，每项任务完成后
• 重要功能完成后
• 合并到 main 之前

流程

1. 获取 git SHA：BASE_SHA=$(git rev-parse HEAD~1) 和 HEAD_SHA=$(git rev-parse HEAD)
2. 使用 Task 工具分派 code-reviewer 子 Agent，并提供：WHAT_WAS_IMPLEMENTED、PLAN_OR_REQUIREMENTS、BASE_SHA、HEAD_SHA、DESCRIPTION
3. 根据反馈采取行动：立即修复 Critical 问题；继续之前修复 Important 问题；记录 Minor 问题以便稍后处理

完整流程： references/requesting-code-review.md

验证关卡流程

铁律

没有最新的验证证据，就不要声称已完成

关卡函数

确定命令 → 运行完整命令 → 阅读输出 → 验证输出是否证实主张 → 然后再提出主张

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

要求

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

危险信号 - 停止

使用“应该”“大概”“似乎”等措辞，在验证前表示满意，未经验证便提交，盲目信任 Agent 的报告，或使用任何未运行验证却暗示成功的措辞

完整流程： references/verification-before-completion.md

与工作流集成

• 子 Agent 驱动： 每项任务之后都进行审查，验证后再进入下一项
• Pull Request： 验证测试通过，并在合并前请求 code-reviewer 审查
• 通用： 发表任何状态声明前应用验证关卡；对无效反馈提出异议

核心要点

1. 技术严谨优先于社交表现——不做表面附和
2. 系统化审查流程——使用 code-reviewer 子 Agent
3. 先有证据再下结论——始终设置验证关卡

先验证，再质疑，然后实现。先有证据，再下结论。