接收代码审查

问题在哪

代码审查很容易变成「礼貌表演」：一句「您说得完全正确」、批量改完不跑测试，或者把外部审查当成必须执行的命令。真正需要的是技术评估：建议是否成立、会不会破坏现有行为、是否违反 YAGNI，以及和你方架构是否一致。

技能如何引导你响应

核心原则是验证后再实施；有疑问先问；技术正确性优先于社交舒适度。

• 禁止的回应：表演式夸奖（如「极好的反馈！」）、未验证就承诺「我现在就实施」。
• 应当做的：复述技术需求、提出澄清问题；若建议错误，用技术理由反驳；能动手就直接改代码，让 diff 说话。
• 按来源处理：来自可信任的人类搭档——理解后实施，范围不清仍要问；外部审查者——保持怀疑但认真核对，并对「专业功能」做 YAGNI 检查（不需要就不要加）。
• 实施顺序：逐项处理、每项测试，避免盲目批量修改。
• 何时反驳：会破坏功能、审查者缺上下文、违反 YAGNI、技术栈上站不住脚、有兼容/遗留原因、与搭档的架构决策冲突。用具体问题、测试或代码引用说明；架构争议让人类搭档介入。
• 认可正确反馈：不必写「谢谢」；直接说明修复内容。若先前反驳错了，实事求是纠正并继续。
• GitHub 线程：内联审查评论应在评论线程里回复（gh api repos/{owner}/{repo}/pulls/{pr}/comments/{id}/replies），不要只发 PR 顶层评论。

边界与注意点

外部反馈是待评估的建议，不是命令。无法在本机验证时，应说明限制并请求方向，而不是硬改一半。若不便当面反驳，可用搭档约定的暗号（文中示例：「有奇怪的事情正在 Circle K 发生」）拉人一起判案。