receiving-review

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

收到代码评审反馈时：

1. 阅读：完整读完反馈再做反应
2. 理解：用自己的话重述需求（或提问）
3. 验证：结合代码库实际情况核对
4. 评估：该建议是否适用于当前代码库的技术栈？
5. 回应：给出技术层面的确认或有理有据的反驳
6. 落实：逐项落实，每项都要测试

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:

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

若存在任何模糊的内容：
  停止行动——不要贸然落实任何内容
  针对模糊部分请求澄清

原因：各项内容可能相互关联。理解不全面会导致错误落实。

示例：

用户：“修复1-6项问题”
你理解1、2、3、6项，但对4、5项存疑。

错误做法：先落实1、2、3、6项，之后再询问4、5项
正确做法：“我理解1、2、3、6项的需求。在开始落实前，需要你澄清4和5项的具体内容。”

Source-Specific Handling

不同来源反馈的处理方式

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

user's rule: "External feedback - be skeptical, but check carefully"

落实之前：
  1. 核对：该建议是否适用于当前代码库的技术栈？
  2. 核对：是否会破坏现有功能？
  3. 核对：当前实现方式的原因是什么？
  4. 核对：是否在所有平台/版本上都能正常运行？
  5. 核对：评审者是否了解完整背景？

若建议存在问题：
  用技术理由反驳

若无法轻易验证：
  如实说明：“我无法在没有[X]的情况下验证这一点。我应该[调查/询问/继续]？”

若与用户之前的决策冲突：
  先停止并与用户讨论

用户规则：“外部反馈——保持怀疑，但要仔细核对”

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

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

若评审者建议“规范实现”：
  在代码库中搜索该功能的实际使用情况

  若未被使用：“该接口未被调用。是否移除它（YAGNI原则）？”
  若已被使用：再按规范实现

用户规则：“你和评审者都向我汇报。如果我们不需要这个功能，就不要添加。”

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

针对多项反馈：
  1. 首先澄清所有模糊内容
  2. 然后按以下顺序落实：
     - 阻塞性问题（功能崩溃、安全问题）
     - 简单修复（拼写错误、导入问题）
     - 复杂修复（重构、逻辑调整）
  3. 每项修复单独测试
  4. 验证是否存在回归问题

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 user's architectural decisions

How to push back:

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

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

在以下情况时可以反驳：

建议会破坏现有功能
评审者不了解完整背景
违反YAGNI原则（功能未被使用）
针对当前技术栈存在技术错误
存在遗留系统/兼容性需求
与用户的架构决策冲突

反驳方式：

基于技术理由，而非防御性态度
提出具体问题
参考可用的测试/代码
若涉及架构问题，邀请用户参与

若不便公开反驳的暗号：“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]

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

当反馈确实正确时：

“已修复。[简要说明修改内容]”
“发现问题——[具体问题]。已在[位置]修复。”
[直接修复并在代码中体现]

错误做法：
“你完全正确！”
“好观点！”
“感谢指出问题！”
“感谢[任何内容]”
任何表达感激的语句

为何不表达感谢： 行动胜于言语。直接修复问题，代码本身就能体现你已接收并处理了反馈。

若你下意识想写“谢谢”： 删除它，转而说明修复内容。

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

WRONG:
Long apology
Defending why you pushed back
Over-explaining

State the correction factually and move on.

若你之前反驳但实际是错误的：

“你是对的——我核对了[X]，确实存在[Y]问题。现在开始落实。”
“已验证，你是正确的。我最初理解有误是因为[原因]。正在修复。”

错误做法：
长篇道歉
为自己之前的反驳辩解
过度解释

如实说明纠正内容，然后继续推进。

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"
WRONG: "You're absolutely right! Let me remove that..."

Technical Verification (Good):

Reviewer: "Remove legacy code"
RIGHT: "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"
RIGHT: "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.
RIGHT: "Understand 1,2,3,6. Need clarification on 4 and 5 before implementing."

表面附和（错误）：

评审者：“移除遗留代码”
错误回应：“你完全正确！我这就去移除...”

技术验证（正确）：

评审者：“移除遗留代码”
正确回应：“正在核对...构建目标是10.15+，但该API需要13+版本支持。为了向后兼容需要保留遗留代码。当前实现的Bundle ID有误——是修复它还是放弃对13以下版本的支持？”

YAGNI原则应用（正确）：

评审者：“实现带数据库、日期筛选、CSV导出的标准指标追踪功能”
正确回应：“已在代码库中搜索——没有调用该接口的记录。是否移除它（YAGNI原则）？还是有我没发现的使用场景？”

模糊内容处理（正确）：

用户：“修复1-6项问题”
你理解1、2、3、6项，但对4、5项存疑。
正确回应：“我理解1、2、3、6项的需求。在开始落实前，需要你澄清4和5项的具体内容。”

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.

外部反馈是需要评估的建议，而非必须执行的命令。

先验证。再提问。然后落实。

禁止表面附和。始终坚持技术严谨性。