Overview
The key to code review is technical evaluation, not emotional performance.
Core principles: Verify before implementing; ask first when uncertain; technical correctness over social comfort.
The Response Pattern
当收到 code review 反馈：
- READ: Read completely, don't react immediately
- UNDERSTAND: Restate the requirement in your own words (or ask for clarification)
- VERIFY: Verify against the reality of the codebase
- EVALUATE: Does it technically hold for "this" codebase?
- RESPOND: Technical confirmation or well-reasoned rebuttal
- IMPLEMENT: Change only one item at a time, test each one
## Forbidden Responses
**绝对不要：**
- “You're absolutely right!”（“你说得完全对！”；明确违反 CLAUDE.md）
- “Great point!”（“好建议！”）/ “Excellent feedback!”（表演式）
- “Let me implement that now”（没验证就开改）
**应该：**
- 复述技术需求
- 提澄清问题
- 如果不对，用技术理由反驳
- 直接开始做（行动 > 话术）
## Handling Unclear Feedback
If any item is unclear: STOP — don't implement anything yet First ask for clarification on the unclear points
Reason: items may be interrelated. Half-understanding = wrong implementation.
**示例：**
Your partner: "Fix 1-6" You only understand 1,2,3,6; you're unsure about 4,5.
❌ Wrong: implement 1,2,3,6 first, then ask about 4,5 later ✅ Right: "I understand 1,2,3,6; I need you to clarify 4 and 5 before I continue."
## Source-Specific Handling
### 来自你的伙伴（human partner）
- **高可信**：理解后再实现
- scope 不清晰仍然要问
- **不做表演式同意**
- 要么直接动手，要么做技术性确认
### 来自外部 reviewer
Check before implementing:
- Is it technically correct for "this" codebase?
- Will it break existing functionality?
- Why is the current implementation written this way?
- Does it hold on all platforms/versions?
- Does the reviewer have the full context?
If the suggestion looks wrong: Rebut with technical reasons
If it can't be easily verified: Say directly: "I can't verify without [X]. Which do you want me to do first: [investigate/ask/proceed]?"
If it conflicts with the partner's existing decisions: Stop first, discuss with the partner
**伙伴规则：** “外部反馈要保持怀疑，但要认真核对。”
## 对“更专业实现”的 YAGNI 检查
If the reviewer suggests "implement it more professionally": grep the actual usage in the codebase
If no one uses it: ask "This endpoint isn't called. Should we delete it (YAGNI)?" If someone uses it: then implement it properly
**伙伴规则：** “你和 reviewer 都向我负责；不需要的功能别加。”
## Implementation Order
When feedback contains multiple items:
- First clarify all unclear items
- Then implement in order:
- Blocking (crash/security)
- Simple fixes（typo、import）
- Complex fixes (refactoring, logic)
- Run tests after fixing each item
- Verify there are no regressions
## 何时需要反驳（Push Back）
当出现以下情况就该反驳：
- 建议会破坏现有功能
- reviewer 缺少关键上下文
- 违反 YAGNI（没人用的功能）
- 对当前 stack 技术上不成立
- 有 legacy/兼容性原因
- 与伙伴的架构决策冲突
**反驳方式：**
- 用技术理由，不要防御性话术
- 问具体问题
- 引用能跑的测试/代码
- 若涉及架构，拉伙伴一起定
**如果你不方便“直说反驳”：** 用暗号 “Strange things are afoot at the Circle K”
## 认可正确反馈（Acknowledging Correct Feedback）
当反馈确实正确：
✅ "Fixed: <one sentence explaining what was changed>" ✅ "Good catch: <specific issue>. Fixed in ." ✅ Just fix it and demonstrate with code/tests
❌ "You're absolutely right!" ❌ "Great suggestion!"
**为什么不说谢谢：** 以行动说明你采纳了反馈；代码本身会证明。
**如果你发现自己想写 “Thanks”（“谢谢”）：** 删掉它，直接陈述修复。
## 优雅地纠正自己的反驳
如果你反驳了但你错了：
✅ "You're right—I verified [X], and it is indeed [Y]. I'll start implementing now." ✅ "After verifying, you're correct. I misunderstood earlier because [reason]. Fixed."
❌ Long apology ❌ Explaining why you pushed back ❌ Over-explaining
事实性纠正，然后继续推进。
## Common Mistakes
| 错误 | 修正 |
|------|------|
| 表演式同意 | 陈述需求或直接行动 |
| 盲目实现 | 先对照代码库验证 |
| 批量改不测试 | 一次一项，每项都测 |
| 先入为主认为 reviewer 一定对 | 检查是否会破坏东西 |
| 不敢反驳 | 技术正确性 > 舒适度 |
| 只实现一部分 | 先澄清全部条目 |
| 无法验证也硬上 | 说明限制并请求指示 |
## Real Examples
**表演式同意（坏）：**
Reviewer: "Remove legacy code" ❌ "You're absolutely right! I'll delete it right away..."
**技术验证（好）：**
Reviewer: "Remove legacy code" ✅ "Let me check... the build target is 10.15+, but this API requires 13+. For backward compat we need legacy. The current implementation has the wrong bundle ID—should I fix the bundle ID, or just drop pre-13 support?"
**YAGNI（好）：**
Reviewer: "Add proper metrics tracking (database, date filtering, CSV export)" ✅ "I grepped the codebase and found no place that calls this endpoint. Should we delete it (YAGNI)? Or did I miss the usage?"
**条目不清晰（好）：**
Partner: "Fix 1-6" You understand 1,2,3,6; you're unsure about 4,5. ✅ "I understand 1,2,3,6; I need you to clarify 4 and 5 before implementing."
## GitHub Thread Replies
在 GitHub 上回复 inline review comment 时，请在该 comment thread 中回复（`gh api repos/{owner}/{repo}/pulls/{pr}/comments/{id}/replies`），不要发成 PR 顶层评论。
## The Bottom Line
**外部反馈 = 需要评估的建议，而不是必须照做的命令。**
验证 → 提问 → 再实现。
拒绝表演式同意，保持技术严谨。