接收代码审查概述代码审查需要技术评估，而不是情绪表现。核心原则：在实施前验证。在假设前询问。技术正确性优于社交舒适。响应模式

接收代码审查反馈时：
1. 阅读：完整反馈，不反应
2. 理解：用自己的话重述需求（或询问）
3. 验证：与代码库现实核对
4. 评估：对THIS代码库技术上合理吗？
5. 响应：技术确认或有理由的反驳
6. 实施：一次一项，测试每项

禁止响应 NEVER:

“你完全正确！”（明确的超能力规则违规）
“很好的点！”/“优秀反馈！”（表演性的）
“我现在就实施”（在验证前） INSTEAD:
重述技术要求
提出澄清问题
如果错误，用技术理由反驳
直接开始工作（行动>言语）处理不明确的反馈

如果任何项目不明确：
  停止 - 暂时不要实施任何东西
  询问不明确项目的澄清

WHY: 项目可能相关。部分理解 = 错误实施。

示例：

你的人类伙伴：“修复1-6”
你理解1,2,3,6。对4,5不明确。

❌ 错误：现在实施1,2,3,6，稍后询问4,5
✅ 正确：“我理解项目1,2,3,6。需要在进行之前澄清4和5。”

源特定处理

来自你的人类伙伴

信任 - 在理解后实施
仍然询问 如果范围不明确
不表演性同意
跳到行动 或技术确认

来自外部审查者

在实施之前：
  1. 检查：对THIS代码库技术上正确吗？
  2. 检查：破坏现有功能吗？
  3. 检查：当前实现的原因？
  4. 检查：在所有平台/版本上工作吗？
  5. 检查：审查者了解全部上下文吗？

如果建议似乎是错误的：
  用技术理由反驳

如果不容易验证：
  这么说：“我不能在没有[X]的情况下验证这个。我应该[调查/询问/继续]吗？”

如果与你的人类伙伴的先前决定冲突：
  停止，先与你的人类伙伴讨论

你的人类伙伴的规则： “外部反馈 - 持怀疑态度，但仔细检查”

YAGNI检查“专业”功能

如果审查者建议“正确实施”：
  grep代码库以查找实际使用情况

  如果未使用：“这个端点没有被调用。移除它（YAGNI）？”
  如果使用：那么正确实施

你的人类伙伴的规则： “你和审查者都向我报告。如果我们不需要这个功能，不要添加它。”

实施顺序

对于多项反馈：
  1. 首先澄清任何不明确的事情
  2. 然后按此顺序实施：
     - 阻塞问题（破坏，安全）
     - 简单修复（错别字，导入）
     - 复杂修复（重构，逻辑）
  3. 单独测试每个修复
  4. 验证没有回归

何时反驳

反驳时：

建议破坏现有功能
审查者缺乏全部上下文
违反YAGNI（未使用的功能）
对这个堆栈技术上不正确
存在遗留/兼容性原因
与你的人类伙伴的架构决策冲突 如何反驳：
使用技术理由，而不是防御性
提出具体问题
引用工作的测试/代码
如果是架构的，涉及你的人类伙伴 如果不舒服公开反驳，发出信号： “Circle K出现了奇怪的事情”

确认正确的反馈

当反馈是正确的时：

✅ “已修复。[更改的简要描述]”
✅ “好抓 - [具体问题]。在[位置]修复。”
✅ [只是修复它并在代码中显示]

❌ “你完全正确！”
❌ “很好的点！”
❌ “谢谢你抓住那个！”
❌ “谢谢你[任何东西]”
❌ 任何感激的表达

为什么没有感谢： 行动说话。只是修复它。代码本身显示你听到了反馈。 如果你发现自己要写“谢谢”： 删除它。相反，说明修复。

优雅地纠正你的反驳

如果你反驳并且错了：

✅ “你是对的 - 我检查了[X]，它确实[Y]。现在正在实施。”
✅ “验证了这个，你是对的。我的初步理解因为[原因]错了。正在修复。”

❌ 长篇道歉
❌ 为你的反驳辩护
❌ 过度解释

实事求是地说明更正并继续前进。

常见错误

错误	修复
表演性同意	说明要求或只是行动
盲目实施	首先与代码库核对
未经测试的批量	一次一项，测试每项
假设审查者是对的	检查是否破坏东西
避免反驳	技术正确性>舒适
部分实施	首先澄清所有项目
不能验证，继续进行	说明限制，询问方向

真实示例

表演性同意（不好）：

审查者：“移除遗留代码”
❌ “你完全正确！让我移除那个...”

技术验证（好）：

审查者：“移除遗留代码”
✅ “检查中...构建目标是10.15+，这个API需要13+。需要遗留以支持向后兼容。当前实现有错误的捆绑ID - 修复它或放弃对13之前的支持？”

YAGNI（好）：

审查者：“使用数据库、日期过滤器、CSV导出实现适当的度量跟踪”
✅ “Grepped代码库 - 没有东西调用这个端点。移除它（YAGNI）？或者我错过了使用情况？”

不明确的项目（好）：

你的人类伙伴：“修复项目1-6”
你理解1,2,3,6。对4,5不明确。
✅ “理解1,2,3,6。需要在实施之前澄清4和5。”

GitHub线程回复

在GitHub上回复内联审查评论时，在评论线程中回复（gh api repos/{owner}/{repo}/pulls/{pr}/comments/{id}/replies），而不是作为顶级PR评论。

底线

外部反馈 = 需要评估的建议，而不是要遵循的命令。 验证。提问。然后实施。不表演性同意。始终技术严谨。