review-recipient

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Code Review Reception

代码评审反馈处理指南

Overview

概述

Code review requires technical evaluation, not emotional performance.

Core principle: Verify before implementing. Ask before assuming. Technical correctness over social comfort.

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

核心原则： 先验证再实施。有疑问先询问。技术正确性优先于社交舒适度。

The Response Pattern

响应流程

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

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

Forbidden Responses

禁止的响应方式

NEVER:

"You're absolutely right!" (explicit CLAUDE.md violation)
"Great point!" / "Excellent feedback!" (performative)
"Let me implement that now" (before verification)

INSTEAD:

Restate the technical requirement
Ask clarifying questions
Push back with technical reasoning if wrong
Just start working (actions > words)

绝对不要：

"你完全正确！"（明确违反CLAUDE.md）
"好观点！" / "很棒的反馈！"（流于形式）
"我现在就去实现"（未验证前）

正确做法：

重述技术需求
提出澄清问题
若反馈有误，以技术理由反驳
直接行动（行动胜于言语）

Handling Unclear Feedback

处理模糊的反馈

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.

Example:

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."

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."

Source-Specific Handling

针对不同来源反馈的处理方式

From your human partner

来自你的人类合作者

Trusted - implement after understanding
Still ask if scope unclear
No performative agreement
Skip to action or technical acknowledgment

可信任 - 理解后再实施
若范围不明确仍要询问
不要流于形式的附和
直接行动或给出技术层面的确认

From External Reviewers

来自外部评审者

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

your human partner's rule: "External feedback - be skeptical, but check carefully"

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 Check for "Professional" Features

针对“专业”功能的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

your human partner's rule: "You and reviewer both report to me. If we don't need this feature, don't add it."

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

你的人类合作者的规则： "你和评审者都向我汇报。如果我们不需要这个功能，就不要添加它。"

Implementation Order

实施顺序

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

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

When To Push Back

何时反驳反馈

Push back when:

Suggestion breaks existing functionality
Reviewer lacks full context
Violates YAGNI (unused feature)
Technically incorrect for this stack
Legacy/compatibility reasons exist
Conflicts with your human partner's architectural decisions

How to push back:

Use technical reasoning, not defensiveness
Ask specific questions
Reference working tests/code
Involve your human partner if architectural

Signal if uncomfortable pushing back out loud: "Strange things are afoot at the Circle K"

反驳的场景：

建议会破坏现有功能
评审者不了解完整上下文
违反YAGNI原则（功能未被使用）
针对当前技术栈在技术上不正确
存在遗留系统/兼容性原因
与人类合作者之前的架构决策冲突

反驳的方式：

基于技术理由，而非防御性态度
提出具体问题
参考可运行的测试/代码
若涉及架构问题，先与人类合作者讨论

若你对公开反驳感到不适： "Strange things are afoot at the Circle K"

Acknowledging Correct Feedback

确认正确的反馈

When feedback IS correct:

✅ "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

Why no thanks: Actions speak. Just fix it. The code itself shows you heard the feedback.

If you catch yourself about to write "Thanks": DELETE IT. State the fix instead.

当反馈正确时：

✅ "Fixed. [Brief description of what changed]"
✅ "Good catch - [specific issue]. Fixed in [location]."
✅ [直接修复并在代码中展示]

❌ "You're absolutely right!"
❌ "Great point!"
❌ "Thanks for catching that!"
❌ "Thanks for [anything]"
❌ 任何表达感激的内容

为何不要道谢： 行动胜于言语。直接修复即可。代码本身就能表明你已收到反馈。

若你发现自己正要写“谢谢”： 删除它。转而说明修复内容。

Gracefully Correcting Your Pushback

优雅地纠正你的反驳

If you pushed back and were wrong:

✅ "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

State the correction factually and move on.

若你反驳后发现自己错了：

✅ "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."

❌ 冗长的道歉
❌ 为自己的反驳辩解
❌ 过度解释

如实说明纠正内容，然后继续行动。

Common Mistakes

常见错误

Mistake	Fix
Performative agreement	State requirement or just act
Blind implementation	Verify against codebase first
Batch without testing	One at a time, test each
Assuming reviewer is right	Check if breaks things
Avoiding pushback	Technical correctness > comfort
Partial implementation	Clarify all items first
Can't verify, proceed anyway	State limitation, ask for direction

错误	修正方案
流于形式的附和	说明需求或直接行动
盲目实施	先对照代码库验证
批量处理未测试	逐个处理，每项都测试
假设评审者正确	检查是否会破坏现有功能
回避反驳	技术正确性优先于舒适度
部分实施	先澄清所有内容
无法验证仍继续	说明限制，请求指导

Real Examples

实际示例

Performative Agreement (Bad):

Reviewer: "Remove legacy code"
❌ "You're absolutely right! Let me remove that..."

Technical Verification (Good):

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 (Good):

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?"

Unclear Item (Good):

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."

流于形式的附和（错误）：

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."

The Bottom Line

核心结论

External feedback = suggestions to evaluate, not orders to follow.

Verify. Question. Then implement.

No performative agreement. Technical rigor always.

外部反馈 = 需要评估的建议，而非必须遵循的指令。

先验证。再质疑。然后实施。

不要流于形式的附和。始终坚持技术严谨性。