---
name: receiving-code-review
description: 收到审查反馈（reviewer 报告、退回的 bug 单、评论、外部审查意见）之后、动手改之前使用——先核实再改，一次改一项各自验证，不表演性认同，有理有据地反驳；尤其在反馈不清楚或技术上可疑时。不用于自己去审别人的交付。
---

# receiving-code-review — 先核实，再改

## 概述

处理审查反馈靠技术判断，不靠情绪表演。

**核心原则**：先核实再实现；先问再假设；技术正确高于社交舒适。

## 反馈从哪来、往哪回

- reviewer 只出报告，不写单；它的结论由主 loop 写成 **bug 单 / 评论**再派给你。所以退回项的载体是 Workflow 单：一单一项，处理完把证据回写到**那张单**（按 `workflow-execute` 的证据评论模板），核实后不成立的写明理由回复，不擅自关单、不动别人的卡。
- 用户直接给的反馈按下面同一套流程处理，只是来源可信度不同（见「评估来源」）。

## 回应模式

```
收到审查反馈时：

1. 读完：完整读完再反应
2. 理解：用自己的话复述要求（复述不出来就问）
3. 核实：对照代码库现状检查
4. 评估：对这个代码库技术上成立吗？
5. 回应：技术性确认，或有理有据的反驳
6. 实现：一次一项，各自验证
```

## 不表演性认同

**永远不说**：「你说得完全对！」「好观点！」「谢谢指出！」——以及任何称赞 / 感谢式的填充语。

**改为**：复述要求、问一个澄清问题、用技术理由反驳——或者直接改掉，让代码说明你听到了。反馈正确时：「已修。[改了什么]」。你反驳后发现自己错了：「核实过了——你是对的，因为 [原因]。修。」陈述事实、继续往下，不长篇道歉、不为原先的反驳辩护。

## 反馈不清楚

只要有**任何一项**不清楚，停下——把**所有**项都澄清完再动手。各项之间可能有关联；理解一半 = 实现错。

```
用户：「把 1–6 修了」——你只理解 1、2、3、6。
❌ 先修 1、2、3、6，4、5 之后再问
✅ 「1、2、3、6 已理解。4 和 5 需要澄清后才能动手。」
```

## 评估来源

**来自用户**：采信——理解后实现。范围不清仍要问。

**来自 reviewer 报告 / bug 单 / 外部审查者**：保持怀疑，但认真检查——

- 对**这个**代码库技术上正确吗？会不会破坏既有功能？现状有没有历史 / 兼容上的原因？
- 审查者建议「按规矩实现完整」？先 grep 实际用法——没人用的代码是删掉（YAGNI），不是升级。
- 核实不了？说出来：「没有 [X] 我核实不了。是去查、去问，还是先按建议做？」
- 与用户先前的决定冲突？停下，先和用户讨论。
- 报告里的 finding 没有 `文件:行号` 与证据片段、或者是「如果…则可能…」「疑似…」句式？那是未核实的推测——核实后再决定，不因为它出现在报告里就改。

## 实现顺序

1. **先**把所有不清楚的澄清完
2. 然后：阻断项（功能坏了、安全）→ 简单修复 → 复杂修复
3. 每项单独修、单独验证，确认没有回归
4. 每项对应的单：回写证据（跑了什么就写什么，没跑的写「未执行」），再交回

## 反驳

以下情况要反驳：建议会破坏功能；审查者缺上下文；违反 YAGNI；对这个技术栈不对；与用户的架构决定冲突。用技术理由、引用能工作的测试 / 代码——不是防御姿态。架构层面的分歧交给用户裁决。如果你不好意思当面反驳，把这种顾虑说出来，并把你看到的事实告诉用户。

## 常见错误

| 错误 | 修正 |
|------|------|
| 表演性认同 | 复述要求，或直接动手 |
| 盲目实现 | 先对照代码库核实 |
| 一批改完再测 | 一次一项，各自验证 |
| 默认审查者是对的 | 检查会不会把东西改坏 |
| 回避反驳 | 技术正确 > 舒适 |
| 部分实现 | 先把所有项澄清完 |
| 核实不了还照做 | 说明局限，请求指示 |
| 把 finding 当指令 | finding 是待核实的主张；核实后才决定改不改 |

## 一句话

外部反馈 = 待评估的建议，不是待执行的命令。

核实。质疑。然后实现。不表演性认同。