---
name: receiving-code-review
description: 在接收代码审查反馈时、实施建议之前使用，尤其是在反馈看起来不明确或技术上存疑时——要求技术严谨性和验证，而不是表演式认同或盲目实施
---

# 接收代码审查

## 概述

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

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

## 响应模式

```
当接收到代码审查反馈时：

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]，我无法验证这一点。我应该 [investigate/ask/proceed] 吗？”

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

**你的人类伙伴的规则：**“外部反馈——保持怀疑，但要仔细核查”

## “专业”功能的 YAGNI 检查

```
如果审查者建议“正确实现”：
  在代码库中 grep 实际用法

  如果未使用：“此端点未被调用。是否删除它（YAGNI）？”
  如果已使用：那么就正确实现
```

**你的人类伙伴的规则：**“你和审查者都向我汇报。如果我们不需要此功能，就不要添加它。”

## 实施顺序

```
对于包含多项的反馈：
  1. 首先澄清任何不清楚的地方
  2. 然后按以下顺序实施：
     - 阻塞性问题（故障、安全问题）
     - 简单修复（拼写错误、导入）
     - 复杂修复（重构、逻辑）
  3. 单独测试每项修复
  4. 验证没有回归
```

## 何时提出异议

在以下情况下提出异议：
- 建议会破坏现有功能
- 审查者不了解完整上下文
- 违反 YAGNI（未使用的功能）
- 对此技术栈而言在技术上不正确
- 存在遗留/兼容性原因
- 与你的人类伙伴的架构决策冲突

**如何提出异议：**
- 运用技术推理，而不是采取防御态度
- 提出具体问题
- 引用可正常运行的测试/代码
- 如果涉及架构，让你的人类伙伴参与

**如果你不愿公开提出异议：** 点明这种不自在，然后告诉你的人类伙伴你发现的问题。他们会欣赏你的坦诚。

## 认可正确的反馈

当反馈确实正确时：
```
✅ "已修复。[Brief description of what changed]"
✅ "发现得好 - [specific issue]。已在 [location] 修复。"
✅ [直接修复，并在代码中展示]

❌ "你完全正确！"
❌ "说得好！"
❌ "谢谢你发现这个问题！"
❌ "感谢你的[anything]"
❌ 任何表达感谢的话
```

**为什么不说谢谢：** 行动胜于言辞。直接修复即可。代码本身就表明你听取了反馈。

**如果你发现自己正要写“谢谢”：** 删除它。改为说明修复内容。

## 得体地纠正你的异议
如果你提出了异议，但事实证明你错了：
```
✅ "你是对的——我检查了 [X]，它确实会 [Y]。现在开始实现。"
✅ "已核实，你是对的。我最初的理解是错误的，因为 [reason]。正在修正。"

❌ 长篇道歉
❌ 为自己为何提出异议进行辩解
❌ 过度解释
```

如实说明更正，然后继续推进。

## 常见错误

| 错误 | 修正方法 |
|---------|-----|
| 表演式认同 | 陈述要求，或直接行动 |
| 盲目实现 | 先对照代码库进行核实 |
| 未测试就批量处理 | 一次处理一个，逐一测试 |
| 假定审查者是对的 | 检查是否会破坏现有功能 |
| 避免提出异议 | 技术正确性 > 舒适感 |
| 部分实现 | 先澄清所有事项 |
| 无法核实，却仍继续推进 | 说明限制，请求指示 |

## 真实示例

**表演式认同（错误）：**
```
审查者："删除遗留代码"
❌ "你说得完全对！让我移除它..."
```

**技术验证（好的做法）：**
```
审查者: "移除旧版代码"
✅ "检查中... 构建目标版本为 10.15+，此 API 需要 13+。为了向后兼容，必须保留旧版代码。当前实现使用了错误的 bundle ID——是修复它，还是放弃对 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 评论回复。

## 底线

**外部反馈 = 需要评估的建议，而非必须遵从的命令。**
验证。质疑。然后实施。

不作表态式附和。始终保持技术严谨。
