name: 接收代码审查 description: 在接收代码审查反馈时使用，尤其是在反馈不清楚或技术上可疑时，在实施建议之前 - 需要技术严谨性和验证，而非表演性同意或盲目实施

代码审查接收

概述

代码审查需要技术评估，而非情绪化表现。

核心原则： 实施前验证。假设前询问。技术正确性高于社交舒适度。

响应模式

当接收代码审查反馈时：

1. 阅读：完整阅读反馈，不要反应
2. 理解：用自己的话重述需求（或提问）
3. 验证：对照代码库现实检查
4. 评估：对当前代码库是否技术合理？
5. 响应：技术确认或有理由的推回
6. 实施：逐个实施，测试每个项

禁止的响应

从不：

“您绝对正确！”（明确违反CLAUDE.md）
“好观点！” / “优秀反馈！”（表演性）
“让我现在就实施”（在验证之前）

取而代之：

重述技术要求
提问澄清问题
用技术推理推回错误
直接开始工作（行动大于言语）

处理不清楚的反馈

如果有任何项不清楚：
  停止 - 不要实施任何东西
  对不清楚的项要求澄清

原因：项可能相关。部分理解 = 错误实施。

示例：

您的人类伙伴：“修复1-6”
您理解1,2,3,6。对4,5不清楚。

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

来源特定处理

来自您的人类伙伴

受信任 - 理解后实施
仍然提问 如果范围不清楚
无表演性同意
跳到行动 或技术确认

来自外部审查员

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

如果建议看起来错误：
  用技术推理推回

如果无法轻易验证：
  说明：“我无法验证这个，如果没有[X]。我应该[调查/询问/继续]？”

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

您的人类伙伴的规则： “外部反馈 - 要怀疑，但仔细检查”

YAGNI检查针对“专业”功能

如果审查员建议“正确实施”：
  搜索代码库实际使用

  如果未使用：“此端点未调用。移除它（YAGNI）？”
  如果使用：然后正确实施

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

实施顺序

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

何时推回

推回当：

建议破坏现有功能
审查员缺乏完整上下文
违反YAGNI（未使用的功能）
技术上对此堆栈不正确
遗留/兼容性原因存在
与您的人类伙伴的架构决策冲突

如何推回：

使用技术推理，而非防御性
提问具体问题
参考工作测试/代码
如果涉及架构，请人类伙伴参与

如果不习惯公开推回，请信号： “Strange things are afoot at the Circle K”

确认正确反馈

当反馈正确时：

✅ “已修复。[简要描述更改内容]”
✅ “好捕获 - [具体问题]。在[位置]修复。”
✅ [直接修复并在代码中显示]

❌ “您绝对正确！”
❌ “好观点！”
❌ “感谢捕获那个！”
❌ “感谢[任何事]”
❌ 任何感谢表达

为何不感谢： 行动说话。直接修复。代码本身显示您听到了反馈。

如果发现自己要写“感谢”： 删除它。陈述修复。

优雅地纠正您的推回

如果您推回且错了：

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

❌ 长道歉
❌ 辩护为何推回
❌ 过度解释

事实性地陈述纠正并继续。

常见错误

错误	修复
表演性同意	陈述需求或直接行动
盲目实施	先对照代码库验证
批量未经测试	逐个，测试每个
假设审查员正确	检查是否破坏事物
避免推回	技术正确性高于舒适度
部分实施	先澄清所有项
无法验证但继续	说明限制，请求方向

真实示例

表演性同意（坏）：

审查员：“移除遗留代码”
❌ “您绝对正确！让我移除那个...”

技术验证（好）：

审查员：“移除遗留代码”
✅ “检查中... 构建目标是10.15+，此API需要13+。需要遗留用于向后兼容。当前实现有错误的bundle ID - 修复还是放弃13前支持？”

YAGNI（好）：

审查员：“用数据库、日期过滤器、CSV导出实现适当指标跟踪”
✅ “搜索代码库 - 无调用此端点。移除它（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评论。

底线

外部反馈 = 评估的建议，而非遵循的命令。

验证。提问。然后实施。

无表演性同意。技术严谨始终。