代码评审接收

# 代码评审接收 ## 概述 代码评审需要的是技术评估，而不是情感表演。 **核心原则：** 先验证，后实现。先询问，后假设。技术正确性高于社交舒适度。 ## 响应模式 当接收到代码评审反馈时： 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 检查 如果评审者建议“正确实现”： grep 代码库查找实际用法 如果未被使用: "此端点未被调用。删除它 (YAGNI)?" 如果被使用: 那么实现 p