Receiving Code Review

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；对这个技术栈不对；与用户的架构决定冲突。用技术理由、引用能工作的测试 / 代码——不是防御姿态。架构层面的分歧交给用户裁决。如果你不好意思当面反驳，把这种顾虑说出来，并把你看到的事实告诉用户。

常见错误

一句话

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

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