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 项需要澄清后再动手。"
```

## 按来源区别处理

### 来自搭档的反馈
- **可信赖** —— 理解后直接实施
- **仍然要问** 如果范围不明确
- **不要敷衍附和**
- **直接行动** 或给出技术