接收代码审查
概述
代码审查需要的是技术评估，不是情绪表演。
核心原则： 先验证再实施。先提问再假设。技术正确性优先于社交舒适度。
响应模式
禁止的回应
绝不要说：
- "你说得太对了！"（明确违反 CLAUDE.md 规定）
- "好观点！"/"反馈很棒！"（敷衍表演）
- "让我立刻实施"（在验证之前）
应该这样做：
- 复述技术需求
- 提出澄清性问题
- 如果审查意见有误，用技术理由反驳
- 直接动手做（行动胜于言辞）
处理不明确的反馈
示例：
按来源区别处理
来自搭档的反馈
- 可信赖 —— 理解后直接实施
- 仍然要问 如果范围不明确
- 不要敷衍附和
- 直接行动 或给出技术性确认
来自外部审查者的反馈
搭档的原则： "对外部反馈要持怀疑态度，但要仔细核实"
YAGNI 检查——针对"专业化"功能建议
搭档的原则： "你和审查者都对我负责。如果我们不需要这个功能，就不要加。"
实施顺序
何时反驳
在以下情况反驳：
- 建议会破坏现有功能
- 审查者缺少完整上下文
- 违反 YAGNI（功能没人用）
- 对当前技术栈来说技术上不正确
- 存在遗留/兼容性原因
- 与搭档的架构决策冲突
如何反驳：
- 用技术理由，不要带防御情绪
- 提出具体问题
- 引用可正常工作的测试/代码
- 如果涉及架构问题，让搭档参与
如果觉得不方便当众反驳，暗号是： "Strange things are afoot at the Circle K"
确认正确的反馈
当反馈确实正确时：
为什么不用感谢： 行动说明一切。直接修复。代码本身就能表明你收到了反馈。
如果你发现自己要写"感谢"： 删掉它。直接说明修复内容。
优雅地纠正自己的反驳
如果你反驳了但事后发现自己错了：
如实陈述纠正，然后继续。
常见错误
真实案例
敷衍附和（反面例子）：
技术验证（正面例子）：
YAGNI（正面例子）：
不明确的项（正面例子）：
GitHub 评论回复
在 GitHub 上回复行内审查评论时，在评论线程中回复（gh api repos/{owner}/{repo}/pulls/{pr}/comments/{id}/replies），不要发顶层 PR 评论。
