Appearance
收到代码审查意见时，最危险的反应不是拒绝，而是不假思索地同意。正确的处理流程是：先完整读完所有反馈，把每一条用自己的语言复述一遍，然后对照真实代码库验证，再判断技术上是否成立——只有在确认之后，才开始动手实现。不清楚的条目必须先问清楚，不能一边实现已经明白的部分一边搁置没懂的部分，因为各条意见之间往往存在关联。
receiving-code-review：如何用技术判断力处理 AI 审查反馈
代码审查是一个技术过程，不是一个社交表演。但很多人——包括 AI——在收到审查意见时，第一反应是找到表达认同的措辞，而不是先去验证意见是否正确。这是一种潜在的危险习惯。
为什么"你说得对"是个坏信号
"你绝对正确！""太好的建议了！"——这类回应看起来礼貌，实际上什么都没说。它们没有说明你理解了什么，也没有说明你会怎么做，更没有确认建议本身是否在这个代码库里成立。
表演性的赞同有两个常见后果：
- 盲目实现：在没有验证的情况下就开始改代码，结果引入新 bug，或者破坏了某个有意为之的设计决策
- 部分理解：只明白了六条意见里的四条，但怕显得"不专业"，先把四条做了，结果后两条方向完全不对
正确的心态是：外部反馈是待评估的建议，不是无条件执行的命令。
六步处理流程
收到代码审查意见后，按以下顺序处理：
第一步：完整读完所有反馈，不要中途反应 把每一条都读完再做任何回应，避免只看了前两条就开始讨论。
第二步：用自己的语言复述每一条要求 如果你无法用自己的话说清楚一条意见的意思，说明你还没真正理解它——需要先问清楚。
第三步：对照代码库现实进行验证 审查者的建议是否基于对这个项目的准确理解？当前实现是否真的有他所说的问题？有没有你知道但审查者不知道的背景？
第四步：在技术上评估建议是否成立 这条意见是否会破坏已有功能？是否违反了架构上的已有决策？是否涉及 YAGNI——代码库里根本没有地方会用到这个功能？
第五步：给出技术性回应或有理由的反驳 反馈正确就直接做，说明改了什么。反馈有问题就说明技术原因，不是防御性地解释自己，而是提出具体的技术论据。
第六步：逐条实现，每条单独测试 不要批量修改，每改一条就验证一次，防止问题相互掩盖。
有不明白的条目时，必须先停下来
假设你收到了六条意见，其中 1、2、3、6 条都清楚，但 4 和 5 你不确定是什么意思。
错误的做法：先把 1、2、3、6 都做了，然后再回头问 4 和 5。
正确的做法：在动手之前说清楚——"我理解了第 1、2、3、6 条，请帮我确认第 4 和第 5 条的具体含义。"
原因在于：各条意见之间可能有关联。如果 4 和 5 的意思和你理解的方向相反，那么你已经实现的 1、2、3 可能方向也错了。部分理解等于错误实现。
什么时候应该反驳
以下情况应该主动反驳，而不是沉默着照做：
- 建议会破坏现有功能或测试
- 审查者对这个代码库的背景了解不完整
- 建议违反了 YAGNI——在代码库里
grep一遍，那个接口根本没有被调用 - 技术上不适配当前的技术栈或平台要求
- 建议与项目负责人之前的架构决策冲突
反驳的方式是技术性的，而不是防御性的：引用具体代码、测试结果、平台版本要求，而不是说"我觉得你错了"。
如果反驳之后发现自己错了，不需要长篇道歉，一句话说清楚："验证之后你是对的，我当初的判断是因为 [具体原因] 产生了误解，现在改。"然后继续工作。
YAGNI 检查：警惕"规范化实现"的陷阱
审查者有时会建议"实现一套完整的指标追踪系统"或者"加一个带数据库、日期筛选和 CSV 导出的报告功能"。
在实现之前先问一个问题：这个东西现在真的有人用吗？
在代码库里搜索一下那个接口的调用点。如果没有任何地方调用它，就是 YAGNI。正确的回应是："搜了一下代码库，这个接口目前没有被调用，要直接删掉，还是你那边有我看不到的调用点？"
认可正确的反馈时，怎么回应
当反馈确实是对的，回应应该是：
- "已修复。[简单描述改了什么]"
- "好的发现——[具体问题]，已在 [位置] 修复。"
- 或者什么都不说，直接在代码里体现出来
不需要"感谢你的宝贵意见"，不需要"你说得非常有道理"。行动本身就是最好的确认。
FAQ
Q：反驳审查意见会不会显得不尊重对方？ A：不会。技术讨论的目的是让代码更好，而不是让对方感觉良好。有技术依据的反驳是负责任的表现，盲目同意才是不负责任的。明确你的技术论据，保持就事论事的态度，对方会理解的。
Q：如果真的无法判断一条建议对不对，怎么办？ A：直接说出来。"我没有足够的信息来验证这条建议，需要 [做什么] 才能确认。你希望我去调查还是先推进？"——这比假装理解然后瞎改要诚实得多。
Q：来自外部 reviewer 的建议和来自项目负责人的建议，处理方式有区别吗？ A：有区别。项目负责人对项目背景有直接了解，他的建议在"理解之后执行"的前提下可以信任度更高。外部 reviewer 有时缺乏具体上下文，技术正确性需要更主动地核实，有疑问应直接反馈。两者都不应该无条件盲从。