Receiving Code Review Zh

---
name: receiving-code-review-zh
description: 接收代码评审意见、评审意见怎么处理、该照做还是该据理力争、别说「您说得对」、意见看不懂先问清楚再动手、外部评审人的建议要先核实。当用户说「评审意见下来了怎么改」「reviewer 说要这样改，对吗」「这条意见我觉得不对」「PR 上的评论帮我处理一下」「这几条意见我只看懂一半」「要不要按他说的改」时使用。响应六步：完整读完不急着反应 → 用自己的话复述要求或直接发问 → 拿代码库核实 → 判断对这个代码库是否技术上成立 → 给出技术性确认或有理有据的反驳 → 一条一条改、每条都测。红线：禁止表演式附和与感谢；任何一条看不懂就全部暂停先问清楚；外部意见要带着怀疑去核实；建议加「专业功能」前先 grep 有没有人调用，没人用就按 YAGNI 提议删掉。
author: Captain
version: 0.1.0
display_name: "接收代码评审意见"
display_name_en: "Receiving Code Review (zh)"
description_zh: "把评审意见当技术输入而非社交场合：先读完再核实、看不懂就全停下来问、该反驳时用技术理由反驳、逐条实施逐条验证；禁止表演式附和与致谢。"
description_en: "Treat review feedback as technical input, not social performance: read fully, verify against the codebase, ask before implementing anything unclear, push back with reasoning, fix one item at a time."
examples_zh:
  - "评审意见下来了怎么改"
  - "reviewer 说要这样改，对吗"
  - "这条意见我觉得不对，要不要按他说的改"
examples_en:
  - "The reviewer asked for changes, should I just do them"
  - "I only understand half of these review comments"
  - "This suggestion looks wrong for our codebase"
metadata:
  { "openclaw": { "requires": { "bins": ["git"] }, "os": ["darwin", "linux", "windows"], "emoji": "📝" } }
---

# 接收代码评审意见

代码评审要的是技术判断，不是情绪表演。

**核心原则：先核实再实施；先问清楚再假设；技术正确优先于社交舒适。**

## 何时用

收到任何形式的代码评审反馈时使用，尤其是意见含糊、或你觉得在技术上站不住脚的时候。适用于搭档/同事的意见、PR 上的行内评论、外部评审人的建议。

## 流程

```
收到评审意见时：

1. 读完：完整读完，先不反应
2. 理解：用自己的话把要求复述一遍（复述不出来就直接问）
3. 核实：拿代码库的实际情况对一遍
4. 判断：对**这个**代码库来说技术上成立吗
5. 回应：给出技术性确认，或有理有据的反驳
6. 实施：一次一条，每条都测
```

## 禁止的回应

**绝不要写：**

- 「您说得对！」「完全正确！」
- 「好建议！」「反馈得非常好！」（表演式附和）
- 「我这就去改」（在核实之前）
- 任何形式的致谢（「谢谢指出」「感谢 review」）

**改成：**

- 复述这条技术要求
- 提出澄清问题
- 认为不对就用技术理由反驳
- 或者直接开始干活（行动胜过表态）

**为什么不说谢谢：** 行动说明一切。直接改掉，代码本身就证明你听进去了。**如果你发现自己正要打出「谢谢」——删掉它，改成陈述你做了什么修改。**

## 意见看不懂怎么办

```
若有任何一条看不懂：
  停——一条都先别改
  就看不懂的那几条提问

原因：各条意见可能互相关联。理解了一半 = 改错。
```

**示例：**

```
搭档：「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 检查

```bash
# 评审人说「这个接口应该实现得更完整」——先查有没有人调用
grep -rn "getMetricsReport" --include=*.ts --include=*.py .
git log -S "getMetricsReport" --oneline | head
```

- **没人调用**：「grep 过了，这个接口没有任何调用方。按 YAGNI 删掉？还是我漏了什么用法？」
- **确有调用**：那就好好实现。

## 实施顺序

```
面对多条意见：
  1. 先把看不懂的问清楚
  2. 再按这个顺序改：
     - 阻塞性问题（会崩、有安全风险）
     - 简单修复（拼写、import）
     - 复杂修复（重构、逻辑）
  3. 每条单独验证
  4. 确认没有引入回归
```

## 什么时候该反驳

出现下列情况就反驳：

- 建议会破坏现有功能
- 评审人缺少完整上下文
- 违反 YAGNI（功能根本没人用）
- 对这套技术栈来说技术上不正确
- 存在历史/兼容性原因
- 与搭档的架构决策冲突

**怎么反驳：** 用技术理由，不要防御性情绪；提具体问题；引用能跑通的测试或代码；涉及架构就把搭档拉进来。

**如果你不好意思当面反驳：** 把这份顾虑说出来，然后把你看到的问题告诉搭档。他们会感谢你的坦诚。

## 意见确实正确时怎么确认

```
对：「已修复。<一句话说明改了什么>」
对：「确实——<具体问题>。已在 <位置> 修复。」
对：（直接改掉，用代码说话）

错：「您说得对！」
错：「好建议！」
错：「谢谢指出！」
错：任何致谢表达
```

## 反驳错了怎么体面收回

```
对：「你是对的——我查了 <X>，确实是 <Y>。这就改。」
对：「核实过了，你说得没错。我先前理解有误，原因是 <理由>。修复中。」

错：长篇道歉
错：为自己当初的反驳辩解
错：过度解释
```

陈述事实，然后继续。

## 输出契约

处理完一轮评审后，给出一份逐条对照表，而不是一句「都改好了」：

```
评审意见处理（共 6 条）
1. <意见一句话> → 已修复，src/x.py:42，验证 `pytest tests/test_x.py -q` 通过
2. <意见一句话> → 已修复，…
4. <意见一句话> → 反驳：<技术理由>，等待答复
5. <意见一句话> → 需澄清：<具体问题>
```

每条都要落到「改了 / 反驳 / 待澄清」三种状态之一，改了的必须带文件位置与验证证据。

## 红线与常见错误

| 错误 | 正确做法 |
|------|----------|
| 表演式附和 | 复述要求，或直接动手 |
| 盲目照改 | 先拿代码库核实 |
| 一次批量改完不测 | 一次一条，每条都测 |
| 默认评审人是对的 | 查会不会破坏现有功能 |
| 回避反驳 | 技术正确 > 社交舒适 |
| 只改懂的那几条 | 先把所有条目问清楚 |
| 核实不了还硬着头皮改 | 说明限制，请求指示 |

## 真实例子

**表演式附和（反面）：**

```
评审人：「把这段历史遗留代码删掉」
错：「您说得对！我这就删……」
```

**技术核实（正面）：**

```
评审人：「把这段历史遗留代码删掉」
对：「查了一下——我们的最低支持版本比这个新 API 的要求低一档，所以向后兼容还需要它。
     不过当前实现里的 bundle ID 是错的：是改掉它，还是干脆放弃对低版本的支持？」
```

**YAGNI（正面）：**

```
评审人：「把指标上报做完整：接数据库、加日期筛选、支持 CSV 导出」
对：「grep 过了，没有任何代码调用这个接口。按 YAGNI 删掉？还是我漏了什么用法？」
```

## 在 GitHub 上回复行内评论

回复 PR 的行内评审评论时，要**回到该评论线程里**回复，而不是发一条顶层 PR 评论：

```bash
gh api repos/{owner}/{repo}/pulls/{pr}/comments/{id}/replies -f body="已在 src/x.py:42 修复"
```

---
改编自 [obra/superpowers](https://github.com/obra/superpowers) 的 `receiving-code-review`（MIT）。改动见 ATTRIBUTION.md。