receiving-code-review

1# 接收代码审查
2 
3## 概述
4 
5代码审查需要的是技术评估，不是情绪表演。
6 
7**核心原则：** 先验证再实施。先提问再假设。技术正确性优先于社交舒适度。
8 
9## 响应模式
10 
11```
12收到代码审查反馈时：
13 
141. 阅读：完整阅读反馈，不急于反应
152. 理解：用自己的话复述需求（或提问）
163. 验证：对照代码库的实际情况检查
174. 评估：对这个代码库来说技术上合理吗？
185. 回应：技术性确认或有理有据的反驳
196. 实施：一次一项，逐个测试
20```
21 
22## 禁止的回应
23 
24**绝不要说：**
25- "你说得太对了！"（明确违反 CLAUDE.md 规定）
26- "好观点！"/"反馈很棒！"（敷衍表演）
27- "让我立刻实施"（在验证之前）
28 
29**应该这样做：**
30- 复述技术需求
31- 提出澄清性问题
32- 如果审查意见有误，用技术理由反驳
33- 直接动手做（行动胜于言辞）
34 
35## 处理不明确的反馈
36 
37```
38如果有任何一项不明确：
39  停下来——先不要实施任何内容
40  就不明确的项目提出澄清
41 
42为什么：各项之间可能有关联。部分理解 = 错误实施。
43```
44 
45**示例：**
46```
47搭档："修复第 1-6 项"
48你理解 1、2、3、6。对 4、5 不确定。
49 
50❌ 错误做法：先实施 1、2、3、6，稍后再问 4、5
51✅ 正确做法："第 1、2、3、6 项我理解了。第 4 和第 5 项需要澄清后再动手。"
52```
53 
54## 按来源区别处理
55 
56### 来自搭档的反馈
57- **可信赖** —— 理解后直接实施
58- **仍然要问** 如果范围不明确
59- **不要敷衍附和**
60- **直接行动** 或给出技术性确认
61 
62### 来自外部审查者的反馈
63```
64实施之前：
65  1. 检查：对这个代码库来说技术上正确吗？
66  2. 检查：是否会破坏现有功能？
67  3. 检查：当前实现这样写是否有原因？
68  4. 检查：在所有平台/版本上都适用吗？
69  5. 检查：审查者了解完整上下文吗？
70 
71如果建议似乎有误：
72  用技术理由反驳
73 
74如果无法轻易验证：
75  说明情况："没有 [X] 我无法验证这一点。我应该 [调查/提问/先做]？"
76 
77如果与搭档之前的决策冲突：
78  先停下来和搭档讨论
79```
80 
81**搭档的原则：** "对外部反馈要持怀疑态度，但要仔细核实"
82 
83## YAGNI 检查——针对"专业化"功能建议
84 
85```
86如果审查者建议"正规地实现"：
87  在代码库中 grep 实际使用情况
88 
89  如果没人用："这个接口没有被调用。删掉它（YAGNI）？"
90  如果有人用：那就正规实现
91```
92 
93**搭档的原则：** "你和审查者都对我负责。如果我们不需要这个功能，就不要加。"
94 
95## 实施顺序
96 
97```
98对于包含多项的反馈：
99  1. 先澄清所有不明确的项
100  2. 然后按以下顺序实施：
101     - 阻塞性问题（崩溃、安全）
102     - 简单修复（拼写、导入）
103     - 复杂修复（重构、逻辑）
104  3. 逐个测试每项修复
105  4. 验证没有回归
106```
107 
108## 何时反驳
109 
110在以下情况反驳：
111- 建议会破坏现有功能
112- 审查者缺少完整上下文
113- 违反 YAGNI（功能没人用）
114- 对当前技术栈来说技术上不正确
115- 存在遗留/兼容性原因
116- 与搭档的架构决策冲突
117 
118**如何反驳：**
119- 用技术理由，不要带防御情绪
120- 提出具体问题
121- 引用可正常工作的测试/代码
122- 如果涉及架构问题，让搭档参与
123…