---
name: receiving-code-review
description: 用于处理代码评审意见（receiving code review），尤其是意见含糊或可能不适用于当前代码时。
---

# 处理评审意见

评审意见是需要评估的技术判断，不是需要安抚的情绪。

**原则：** 先核实再修改，拿不准就先问，技术正确性优先于社交上的舒适感。

## 处理流程

```
收到评审意见时：

1. 读完：先读完全部意见，暂不修改
2. 理解：用自己的话复述每条要求（无法复述时就提问）
3. 核实：对照代码库的实际情况
4. 评估：对这个代码库而言，意见在技术上是否成立？
5. 回应：给出技术性确认，或有理有据地提出反对意见
6. 修改：一次处理一条，每条都测试
```

## 回应的写法

意见正确时，直接说明修复内容：

- “已修复：<改了什么>。”
- “确实存在 <具体问题>，已在 <位置> 修复。”
- 或者直接修改，用代码说明。

回应中只写技术内容：复述要求、提出澄清问题、给出反对理由，或者直接开始修改。“说得太对了！”“好建议！”这类表面附和不传递任何信息，还会让人误以为你未经核实就接受了意见。

## 含糊的意见

```
任何一条意见不清楚时：
  先不修改任何一条
  针对不清楚的条目请求澄清

原因：条目之间可能相关，只理解一部分就容易改错。
```

示例：

```
用户：“把 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（功能没有调用方）
- 对当前技术栈而言，技术上不正确
- 存在历史遗留或兼容性方面的原因
- 与用户的架构决策冲突

如何提出：给出技术理由，而不是防御性回应；提出具体问题；引用可以工作的测试或代码；涉及架构时请用户参与讨论。

直接提出反对意见让你感到犹豫时，说明这种犹豫，然后把你发现的问题告诉用户。

## 反对意见有误时

```
✅ “你是对的，我查了 <X>，它确实 <Y>。现在修改。”
✅ “核实过了，你说得对。我之前理解错了，原因是 <原因>。正在修改。”
```

直接说明更正，然后继续工作。无需长篇道歉，也无需为之前的反对意见辩护。

## GitHub 行内评论

回复 GitHub 上的行内评审评论时，回复到该评论所在的线程（`gh api repos/{owner}/{repo}/pulls/{pr}/comments/{id}/replies`），而不是发布为 PR 顶层评论。