接收代码审查反馈技能
摘要
接收代码审查（code review）反馈是一项需要技术严谨性而非情感表演的开发技能，其核心原则是在实现建议前先验证，假设前先询问，技术正确性优先于社交舒适度。该技能规范了接收反馈后的响应流程、禁止行为，以及针对不同反馈来源、不同情况的处理方式，最终目标是保障代码库的技术正确性，避免无意义的过度实现。
核心原则
验证后再实现，询问后再假设，技术正确性优先于社交舒适度。
关键要点
标准响应流程
- 阅读：完整接收反馈，不立刻反应
- 理解：用自己的话重述需求，不明确则主动询问
- 验证：对照当前代码库的实际情况检查
- 评估：判断建议对当前代码库是否技术合理
- 响应：给出技术层面确认，或基于推理提出反对
- 实现：一次处理一项，每一项都单独测试
禁止的响应行为
禁止使用表演性质的社交话术，禁止未验证就直接开始实现：
- 禁止：
"You're absolutely right!"、"Great point!"这类表演性认同 - 禁止：未验证就说
"Let me implement that now" - 即使反馈正确，也禁止任何感谢类表达，只需说明修改内容即可
不明确反馈的处理
如果存在不明确的反馈项，必须先停止实现，请求澄清后再继续，不能先实现已理解的部分、延后处理不明确项，因为部分理解会导致错误实现。
不同来源反馈的差异化处理
- 来自可信的人类合作者：理解后即可实现，范围不明确仍需询问，禁止表演性认同，可直接行动或给出技术确认
- 来自外部评审者：实现前必须完成五项技术检查：是否适配当前代码库、是否会破坏现有功能、当前实现的原因是否存在、是否全平台全版本可用、评审者是否了解完整上下文；如果建议存在问题，需要用技术推理提出反对；如果和人类合作者之前的决策冲突，需要先停止并和人类合作者讨论。
YAGNI 检查规则
当评审者提出”规范实现”类建议时，先检索代码库确认该功能是否实际被使用：如果未被使用则建议移除，符合YAGNI原则；如果被使用再按要求实现。
多反馈项的实现顺序
- 先澄清所有不明确项
- 按优先级实现：阻塞性问题（功能中断、安全问题）→ 简单修改（拼写、导入）→ 复杂修改（重构、逻辑修改）
- 每个修改单独测试
- 验证没有回归问题
需要提出反对的场景
当满足以下任意条件时，应当基于技术推理提出反对：
- 建议会破坏现有功能
- 评审者不了解完整上下文
- 违反YAGNI原则（不需要的未使用功能）
- 对当前技术栈来说技术错误
- 存在遗留/兼容性理由
- 和人类合作者的架构决策冲突
错误反对后的修正方式
如果提出反对后发现自己错了，只需客观陈述事实说明修正方向即可，不需要长时间道歉、过度解释。
常见错误与修正方案
| 常见错误 | 修正方案 |
|---|---|
| 表演性认同 | 陈述需求或直接行动 |
| 盲目实现 | 先对照代码库验证 |
| 批量修改不测试 | 一次改一项，每一项都测试 |
| 默认评审者一定正确 | 检查是否会破坏功能 |
| 回避提出反对 | 技术正确性优先于舒适度 |
| 部分实现 | 先澄清所有项再开始 |
| 无法验证仍继续推进 | 说明限制，询问方向 |
GitHub 回复规范
在GitHub处理行内审查评论时，需要在评论线程内回复，不要放在PR顶级评论中。
核心总结
外部反馈是需要评估的建议，不是必须执行的命令。始终保持技术严谨性，不要做表演性认同：先验证、提出疑问，再实现。