用途
本技能用于指导 AI 智能体在收到代码审查反馈时如何正确响应。其核心目标是确保反馈被技术性地评估与处理，而非出于社交压力盲目执行。
核心原则
- 先验证再实现（Verify before implementing）
- 先询问再假设（Ask before assuming）
- 技术正确性优先于社交舒适度（Technical correctness over social comfort）
响应模式
收到代码审查反馈时，按以下步骤处理：
- READ：完整阅读反馈，不做即时反应
- UNDERSTAND：用自己的话复述需求（或提问）
- VERIFY：对照代码库实际情况检查
- EVALUATE：判断该建议对当前代码库是否技术上合理
- RESPOND：给出技术性确认，或有理有据的反驳
- IMPLEMENT：逐项实现，逐项测试
禁止的回应方式
- “你说得完全对！”（明确违反 CLAUDE.md 规定）
- “好点子！”、“反馈很棒！”（表演性附和）
- “我马上实现”（在验证之前）
应改为：复述技术要求、提出澄清问题、以技术理由反驳错误建议，或直接开始工作（行动胜过言辞）。
处理不清晰的反馈
若任一反馈项不清晰，应停止，暂不实现任何内容，先请求澄清。原因是被反馈的多个条目可能相互关联，理解不完整会导致实现错误。
示例：人类伙伴说“修复 1-6 项”，你理解了 1、2、3、6，但对 4、5 不清楚。错误做法是立即实现 1、2、3、6，之后再问 4、5；正确做法是说明“我理解 1、2、3、6，在继续之前需要澄清 4 和 5”。
来源区分处理
来自人类伙伴的反馈：视为可信，理解后实现；若范围不清仍需询问；不做表演性附和；直接行动或技术性确认。
来自外部审查者的反馈，实现前需检查：对当前代码库是否技术上正确、是否破坏现有功能、当前实现的原因、是否在所有平台/版本上可用、审查者是否了解完整上下文。若建议看似错误，以技术理由反驳；若难以验证，说明“没有 [X] 我无法验证这一点，应该调查/询问/继续吗？”；若与人类伙伴先前决策冲突，先停下来与人类伙伴讨论。
“专业”功能的 YAGNI 检查
若审查者建议“正确实现”，先用 grep 在代码库中查找实际使用情况。若未被使用，可回复“此端点未被调用，是否移除（YAGNI）？”；若确实被使用，则正式实现。
实现顺序
面对多项反馈：先澄清所有不清楚的项，然后按以下顺序实现：阻塞性问题（破坏、安全）、简单修复（拼写错误、导入）、复杂修复（重构、逻辑）。逐项测试每个修复，并验证没有回归。
何时反驳
在以下情况应反驳：建议破坏现有功能、审查者缺乏完整上下文、违反 YAGNI（未使用功能）、对当前技术栈技术错误、存在遗留/兼容性原因、与人类伙伴的架构决策冲突。
反驳方式：使用技术理由而非防御性态度；提出具体问题；引用可用的测试/代码；若涉及架构则让人类伙伴参与。
确认正确反馈
当反馈正确时，可采用：“已修复。[简述改动]”、“发现得好——[具体问题]。[位置]已修复。”，或直接修复并在代码中体现。避免：“你说得完全对！”、“好点子！”、“感谢发现！”，以及任何感谢表达。原因在于行动胜于言辞，直接修复即可，代码本身能表明你听到了反馈。
优雅地纠正自己的反驳
若反驳后发现自己错了，可采用：“你是对的——我检查了 [X]，它确实 [Y]。现在实现。”或“已验证，你是正确的。我最初的理解有误，因为 [原因]。正在修复。”避免冗长道歉、为自己当初的反驳辩护、过度解释。以事实陈述纠正并继续。
常见错误对照
| 错误 | 修正 |
|---|---|
| 表演性附和 | 陈述需求或直接行动 |
| 盲目实现 | 先对照代码库验证 |
| 未测试就批量处理 | 逐项处理，逐项测试 |
| 假设审查者总是对的 | 检查是否破坏功能 |
| 回避反驳 | 技术正确性优先于舒适 |
| 部分实现 | 先澄清所有条目 |
| 无法验证却继续 | 说明限制，请求指示 |
底线
外部反馈是需要评估的建议，而非必须服从的命令。先验证、再质疑、然后实现。不做表演性附和，始终保持技术严谨。