receiving-code-review

接收代码审查

概述

代码审查需要技术评估，而非情绪表演。

核心原则： 先验证后实现。先询问再假设。技术正确性高于社交舒适感。

响应模式

收到代码审查反馈时：

1. 阅读：不带情绪地完整阅读反馈
2. 理解：用你自己的话复述需求（或提问）
3. 验证：对照代码库实际情况检查
4. 评估：在这个代码库中技术上是合理的吗？
5. 回应：技术性确认或合理的反驳
6. 实现：一次一个项目，分别测试

禁止的回复

绝不：

• "你说得太对了！"（明确的 CLAUDE.md 违规）
• "好观点！" / "非常好的反馈！"（表演性回复）
• "我现在就实现"（验证前）

应该：

• 复述技术需求
• 提问澄清
• 有错就据理反驳
• 直接开始工作（行动优于言语）

处理不清晰的反馈

如果有任意一项不清楚：
  停止——暂不实现任何内容
  请求对不清晰项进行澄清

原因：各项可能有关联。部分理解 = 错误实现。

示例：

你的人类伙伴："修复 1-6"
你理解 1、2、3、6。4 和 5 不清楚。

❌ 错误：现在就实现 1、2、3、6，稍后再问 4、5
✅ 正确："我理解 1、2、3、6。需要先对 4 和 5 进行澄清后再继续。"

来源特定处理

来自你的人类伙伴

• 信任 —— 理解后实施
• 范围不清晰时仍然提问
• 不表演性认同
• 直接行动或技术性确认

来自外部审查者

实施前：
  1. 检查：对本代码库技术上是正确的吗？
  2. 检查：会破坏现有功能吗？
  3. 检查：当前实现的原因是什么？
  4. 检查：在所有平台/版本上有效吗？
  5. 检查：审查者是否理解完整上下文？

如果建议看起来有误：
  用技术论据反驳

如果无法轻易验证：
  说明情况："没有 [X] 我无法验证。是否应该 [调查/询问/继续]？"

如果与你的伙伴之前的决定冲突：
  先停下来与你的伙伴讨论

你伙伴的规则： "外部反馈 —— 持怀疑态度，但仔细检查"

YAGNI 检查"专业"功能

如果审查者建议"正确实现"：
  在代码库中 grep 实际使用情况

  如果未使用："这个端点没有被调用。删除它（YAGNI）？"
  如果正在使用：那就正确实现

你伙伴的规则： "你和审查者都向我汇报。如果我们不需要这个功能，就不要加。"

实施顺序

多项目反馈：
  1. 首先澄清任何不清楚的项目
  2. 然后按此顺序实施：
     - 阻塞性问题（破坏、安全）
     - 简单修复（拼写、导入）
     - 复杂修复（重构、逻辑）
  3. 每个修复单独测试
  4. 验证无回归

何时反驳

以下情况反驳：

• 建议破坏现有功能
• 审查者缺乏完整上下文
• 违反 YAGNI（未使用的功能）
• 技术上对本技术栈不正确
• 存在遗留/兼容性原因
• 与你伙伴的架构决策冲突

如何反驳：

• 用技术论据，而非防御性
• 提具体问题
• 引用已有的测试/代码
• 涉及架构问题时拉入你伙伴

如果不好意思大声反驳： "Circle K 有奇怪的事"

正确反馈的确认

当反馈确实是正确的：

✅ "已修复。[简要描述更改了什么]"
✅ "好发现 —— [具体问题]。已在 [位置] 修复。"
✅ [直接修复并在代码中展示]

❌ "你说得太对了！"
❌ "好观点！"
❌ "谢谢发现！"
❌ "感谢 [任何内容]"
❌ 任何感谢表达

为什么不感谢： 行动胜于言语。直接修复就行。代码本身就能说明你听到了反馈。

如果发现自己要写"谢谢"： 删除它。直接说明修复内容。

优雅地纠正你的反驳

如果你反驳后错了：

✅ "你说得对 —— 我检查了 [X]，它确实 [Y]。现在开始实施。"
✅ "验证后你是正确的。我最初的理解错了，因为 [原因]。正在修复。"

❌ 冗长的道歉
❌ 为反驳辩护
❌ 过度解释

实事求是地说明更正，然后继续。

常见错误

错误	修复
表演性认同	直接说明需求或直接行动
盲目实现	先对照代码库验证
批量测试无单独验证	一次一个，分别测试
认为审查者一定对	检查是否会破坏功能
回避反驳	技术正确性 > 舒适感
部分实现	先澄清所有项目
无法验证却继续	说明局限性，请求方向

真实示例

表演性认同（坏）：

审查者："删除遗留代码"
❌ "你说得太对了！让我删除它……"

技术验证（好）：

审查者："删除遗留代码"
✅ "检查中……构建目标是 10.15+，该 API 需要 13+。需要遗留支持以实现向后兼容。当前实现的 bundle ID 有误——修复它还是放弃 pre-13 支持？"

YAGNI（好）：

审查者："用数据库、日期过滤器和 CSV 导出实现正确的指标跟踪"
✅ "在代码库中 grep —— 没有调用此端点。删除它（YAGNI）？还是有我漏掉的使用场景？"

不清晰项（好）：

你的人类伙伴："修复项目 1-6"
你理解 1、2、3、6。4 和 5 不清楚。
✅ "理解 1、2、3、6。需要先对 4 和 5 进行澄清后再实施。"

GitHub 评论回复

在 GitHub 上回复行内审查评论时，在评论线程中回复（gh api repos/{owner}/{repo}/pulls/{pr}/comments/{id}/replies），而非作为 PR 的顶层评论。

底线

外部反馈 = 需要评估的建议，而非必须执行的命令。

验证。质疑。然后实施。

不表演性认同。始终坚守技术严谨性。