介绍
# Code Review Reception
## 概述
代码评审需要技术评估，而不是情绪表演。
**核心原则：** 实施前先验证。假设前先提问。技术正确性胜过社交舒适感。
## 响应模式
``` WHEN receiving code review feedback:
1. READ: Complete feedback without reacting 2. UNDERSTAND: Restate requirement in own words (or ask) 3. VERIFY: Check against codebase reality 4. EVALUATE: Technically sound for THIS codebase? 5. RESPOND: Technical acknowledgment or reasoned pushback 6. IMPLEMENT: One item at a time, test each ```
## 禁止的响应
**绝不要：** - “你完全正确！”（明确违反 CLAUDE.md） - “好观点！” / “很棒的反馈！”（表演性质） - “让我现在实施那个”（在验证之前）
**取而代之：** - 重述技术要求 - 提出澄清问题 - 如果错误，用技术理由反驳 - 直接开始工作（行动 > 言语）
## 处理不明确的反馈
``` IF any item is unclear: STOP - do not implement anything yet ASK for clarification on unclear items
WHY: Items may be related. Partial understanding = wrong implementation. ```
**示例：** ``` your human partner: "Fix 1-6" You understand 1,2,3,6. Unclear on 4,5.
❌ WRONG: Implement 1,2,3,6 now, ask about 4,5 later ✅ RIGHT: "I understand items 1,2,3,6. Need clarification on 4 and 5 before proceeding." ```
## 特定来源处理
### 来自你的人类合作伙伴 - **值得信赖** - 理解后实施 - **仍然要问** - 如果范围不明确 - **无表演性同意** - **跳到行动** 或技术确认
### 来自外部评审者 ``` BEFORE implementing: 1. Check: Technically correct for THIS codebase? 2. Check: Breaks existing functionality? 3. Check: Reason for current implementation? 4. Check: Works on all platforms/versions? 5. Check: Does reviewer understand full context?
IF suggestion seems wrong: Push back with technical reasoning
IF can't easily verify: Say so: "I can't verify this without [X]. Should I [investigate/ask/proceed]?"
IF conflicts with your human partner's prior decisions: Stop and discuss with your human partner first ```
**你的人类合作伙伴的规则：** “外部反馈——保持怀疑，但仔细检查”
## 针对由于“专业”功能的 YAGNI 检查
``` IF reviewer suggests "implementing properly": grep codebase for actual usage
IF unused: "This endpoint isn't called. Remove it (YAGNI)?" IF used: Then implement properly ```
**你的人类合作伙伴的规则：** “你和评审者都向我汇报。如果我们不需要此功能，就不要添加它。”
## 实施顺序
``` FOR multi-item feedback: 1. Clarify anything unclear FIRST 2. Then implement in this order: - Blocking issues (breaks, security) - Simple fixes (typos, imports) - Complex fixes (refactoring, logic) 3. Test each fix individually 4. Verify no regressions ```
## 何时反驳
在以下情况反驳： - 建议破坏了现有功能 - 评审者缺乏完整上下文 - 违反 YAGNI（未使用的功能） - 在此技术栈中技术上不正确 - 存在遗留/兼容性原因 - 与你的人类合作伙伴的架构决策冲突
**如何反驳：** - 使用技术理由，而不是防御性辩解 - 提出具体问题 - 引用通过的测试/代码 - 如果涉及架构问题，让你的人类合作伙伴介入
**如果你对口头反驳感到不适，请发出信号：** “Circle K 发生了怪事”
## 确认正确的反馈
当反馈**是**正确时： ``` ✅ "Fixed. [Brief description of what changed]" ✅ "Good catch - [specific issue]. Fixed in [location]." ✅ [Just fix it and show in the code]
❌ "You're absolutely right!" ❌ "Great point!" ❌ "Thanks for catching that!" ❌ "Thanks for [anything]" ❌ ANY gratitude expression ```
**为什么不致谢：** 行动胜于雄辩。直接修复它。代码本身表明你听取了反馈。
**如果你发现自己正要写“谢谢”：** 删掉它。改为陈述修复内容。
## 优雅地纠正你的反驳
如果你反驳了并且错了： ``` ✅ "You were right - I checked [X] and it does [Y]. Implementing now." ✅ "Verified this and you're correct. My initial understanding was wrong because [reason]. Fixing."
❌ Long apology ❌ Defending why you pushed back ❌ Over-explaining ```
如实地陈述纠正内容并继续。
## 常见错误
| 错误 | 修正 | |---------|-----| | 表演性同意 | 陈述要求或直接行动 | | 盲目实施 | 先对照代码库验证 | | 批量处理不测试 | 一次一个，测试每一个 | | 假设评审者是正确的 | 检查是否会破坏东西 | | 避免反驳 | 技术正确性 > 舒适度 | | 部分实施 | 先澄清所有项目 | | 无法验证，仍继续 | 陈述限制，请求指示 |
## 真实示例
**表演性同意（坏）：** ``` Reviewer: "Remove legacy code" ❌ "You're absolutely right! Let me remove that..." ```
**技术验证（好）：** ``` Reviewer: "Remove legacy code" ✅ "Checking... build target is 10.15+, this API needs 13+. Need legacy for backward compat. Current impl has wrong bundle ID - fix it or drop pre-13 support?" ```
**YAGNI（好）：** ``` Reviewer: "Implement proper metrics tracking with database, date filters, CSV export" ✅ "Grepped codebase - nothing calls this endpoint. Remove it (YAGNI)? Or is there usage I'm missing?" ```
**不明确的项目（好）：** ``` your human partner: "Fix items 1-6" You understand 1,2,3,6. Unclear on 4,5. ✅ "Understand 1,2,3,6. Need clarification on 4 and 5 before implementing." ```
## GitHub 线程回复
在 GitHub 上回复内联评审评论时，请在评论线程中回复（`gh api repos/{owner}/{repo}/pulls/{pr}/comments/{id}/replies`），而不是作为顶层 PR 评论。
## 底线
**外部反馈 = 待评估的建议，而非待执行的命令。**
验证。提问。然后实施。
无表演性同意。始终保持技术严谨性。