receiving-code-review

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Code Review Reception

代码审查反馈处理

Quick Start

快速开始

Before implementing any review feedback:

Verify the suggestion is technically correct for this codebase
Ask clarifying questions if anything is unclear
Push back with reasoning if the suggestion is wrong
Implement and test one item at a time

No performative agreement. Just verify, then act.

在实施任何审查反馈前：

验证该建议针对此代码库在技术上是否正确
询问：如有任何不清楚的地方，提出澄清问题
反驳：如果建议有误，给出合理依据进行反驳
实施：逐一实施并测试每个项

不要做表面认同。只需验证，然后行动。

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)

NEVER:

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

INSTEAD:

重述技术要求
提出澄清问题
如果建议有误，给出技术依据进行反驳
直接开始行动（行动胜于言语）

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:

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

示例：

User: "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 the User

来自用户的反馈

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 the user's prior decisions:
  Stop and discuss with the user first

Guiding principle: 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 the user's prior decisions:
  Stop and discuss with the user 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

Guiding principle: If the feature isn't needed, don't add it - regardless of who suggested 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 the user's architectural decisions

How to push back:

Use technical reasoning, not defensiveness
Ask specific questions
Reference working tests/code
Involve the user if architectural

当出现以下情况时进行反驳：

建议会破坏现有功能
审查者缺乏完整上下文
违反YAGNI原则（功能未被使用）
针对此技术栈在技术上不正确
存在遗留/兼容性原因
与用户的架构决策冲突

如何反驳：

使用技术依据，而非防御性态度
提出具体问题
参考有效的测试/代码
如果涉及架构问题，让用户参与进来

Handling Conflicting Feedback

处理相互矛盾的反馈

When multiple reviewers suggest contradictory approaches:

Don't pick sides - Present the conflict to the user
Summarize both positions - State each approach and its tradeoffs
Ask for direction - Let the user decide

Example:

Reviewer A suggests extracting to a helper function.
Reviewer B prefers keeping it inline for readability.

"Two conflicting suggestions: extract vs inline. Extraction adds reusability
but increases indirection. Inline keeps it readable but duplicates logic
if used elsewhere. Which approach do you prefer?"

Never: Implement one reviewer's suggestion while ignoring the other without discussing.

当多个审查者提出相互矛盾的方案时：

不要选边站——将冲突呈现给用户
总结两种立场——说明每种方案及其利弊
请求指导——让用户做决定

示例：

Reviewer A suggests extracting to a helper function.
Reviewer B prefers keeping it inline for readability.

"Two conflicting suggestions: extract vs inline. Extraction adds reusability
but increases indirection. Inline keeps it readable but duplicates logic
if used elsewhere. Which approach do you prefer?"

**绝对不要：**在未讨论的情况下，实施其中一位审查者的建议而忽略另一位。

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!"
❌ Excessive gratitude or validation

Why avoid gratitude: Actions speak louder. The fix itself demonstrates you understood the feedback. Focus on what changed, not on thanking.

当反馈正确时：

✅ "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!"
❌ Excessive gratitude or validation

**为何避免感谢：**行动胜于言语。修复本身就表明你理解了反馈。专注于所做的更改，而非致谢。

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

❌ Long apology
❌ Defending why you pushed back
❌ Over-explaining

实事求是地说明修正，然后继续行动。

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

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

模糊项（正确示例）：

User: "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 Thread Replies

GitHub线程回复

When replying to inline review comments on GitHub, reply in the comment thread (

gh api repos/{owner}/{repo}/pulls/{pr}/comments/{id}/replies

), not as a top-level PR comment.

在GitHub上回复内联审查评论时，应在评论线程中回复（

gh api repos/{owner}/{repo}/pulls/{pr}/comments/{id}/replies

），而不是作为PR的顶级评论。

The Bottom Line

核心要点

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

Verify. Question. Then implement.

No performative agreement. Technical rigor always.

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

验证。质疑。然后实施。

不要表面认同。始终保持技术严谨性。