respond-review

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Responding to Code Review

回应代码审查

Iron Law

铁律

EVERY REVIEW COMMENT DESERVES A RESPONSE

EVERY REVIEW COMMENT DESERVES A RESPONSE

Steps

步骤

1. Read All Comments First

1. 先阅读所有评论

Before responding to anything, read every comment on the PR.

Understand the full scope of feedback before reacting
Look for patterns — multiple reviewers raising the same concern is a strong signal
Note the severity: is this a blocker, a suggestion, or a style preference?
Do not start fixing anything until you have read everything

在做出任何回应之前，阅读PR上的每一条评论。

先理解反馈的全部范围再做出反应
寻找规律——多位审查者提出相同问题是强烈信号
注意问题严重程度：这是阻塞问题、建议还是风格偏好？
在读完所有评论前不要开始修复任何内容

2. Categorize

2. 分类

Sort every comment into one of four categories:

Category	Description	Action
Must-fix	Bugs, security issues, correctness problems, failing tests	Fix immediately, no discussion needed
Should-fix	Design improvements, better patterns, readability gains	Fix unless you have a strong reason not to, then explain
Discussion	Architectural questions, alternative approaches, trade-offs	Respond with your reasoning, be open to changing your mind
Nit	Style preferences, minor naming suggestions, formatting	Fix if easy, acknowledge if not, never argue

将每条评论归入以下四个类别之一：

类别	描述	行动
必须修复	漏洞、安全问题、正确性问题、测试失败	立即修复，无需讨论
应该修复	设计改进、更优模式、可读性提升	除非有充分理由不修复，否则进行修复，若不修复则需解释原因
讨论类	架构问题、替代方案、权衡取舍	清晰阐述你的理由，保持开放心态接受改变
细节优化	风格偏好、轻微命名建议、格式调整	容易修复就处理，若不修复则需告知原因，绝不争论

3. Address Must-Fix Items

3. 处理必须修复项

Fix all must-fix items first.

These are non-negotiable — do not push back on correctness issues
Commit each fix with a clear message referencing the review comment
If a must-fix requires a significant change, explain what you changed and why
Re-run quality checks after fixes

优先修复所有必须修复的内容。

这些内容没有商量余地——对于正确性问题不要反驳
每次修复都提交清晰的提交信息，并关联对应的审查评论
如果必须修复的内容需要重大改动，解释你做了什么更改以及原因
修复后重新运行质量检查

4. Respond to Each Comment

4. 回应每条评论

Leave a response on every single comment.

Must-fix: "Fixed in [commit hash]" or "Fixed — [brief explanation of the change]"
Should-fix: "Good catch, fixed" or "I considered this but chose X because [reason] — open to changing if you still disagree"
Discussion: Share your reasoning clearly. Ask clarifying questions if the comment is ambiguous. Be willing to be wrong.
Nit: "Fixed" or "Acknowledged — keeping as-is because [reason]"

Never leave a comment without a response. Silence reads as dismissal.

对每一条评论都留下回应。

必须修复：“已在[提交哈希值]中修复”或“已修复——[对更改的简要说明]”
应该修复：“提得好，已修复”或“我考虑过这个方案，但选择了X，原因是[理由]——如果你仍有异议，我可以调整”
讨论类：清晰分享你的理由。如果评论表述模糊，提出澄清问题。愿意承认自己可能有误。
细节优化：“已修复”或“已了解——保持原样，原因是[理由]”

绝对不要对评论置之不理。沉默会被视为无视。

5. Re-Request Review

5. 重新请求审查

After addressing all comments:

Push the updated branch
Leave a summary comment listing what was addressed
Re-request review from the original reviewers
If significant changes were made, highlight them explicitly

在处理完所有评论后：

推送更新后的分支
留下总结评论，列出已处理的内容
向原审查者重新请求审查
如果做出了重大改动，明确突出这些变更

Red Flags — If You Catch Yourself Thinking:

危险信号——如果你有以下想法：

Thought	Reality
"The reviewer doesn't understand my code"	If the reviewer doesn't understand it, the code isn't clear enough. Improve it.
"This nit isn't worth fixing"	Nits take 30 seconds to fix and build goodwill. Just fix it.
"I'll address these comments in a follow-up PR"	Address them now. Follow-up PRs for review feedback rarely happen.
"The reviewer is wrong about this"	Assume good intent. Explain your reasoning, but be genuinely open to being wrong.

想法	实际情况
“审查者不懂我的代码”	如果审查者看不懂，说明代码不够清晰。需要改进。
“这个细节优化不值得修复”	细节优化只需30秒就能完成，还能建立良好协作关系。直接修复即可。
“我会在后续PR中处理这些评论”	现在就处理。针对审查反馈的后续PR很少能真正落地。
“审查者在这个问题上错了”	假设对方是出于善意。解释你的理由，但真正开放地接受自己可能有误。

Rules

规则

Respond to every comment — no exceptions
Assume good intent from reviewers
Fix before defending — if the fix is easy, just do it regardless of whether you agree
Never dismiss feedback without explanation
Re-run all quality checks after incorporating changes
Push fixes as new commits (not amended) so reviewers can see what changed

回应每一条评论——没有例外
假设审查者是出于善意
先修复再辩解——如果修复很简单，不管你是否认同都直接做
不要在不解释原因的情况下无视反馈
采纳变更后重新运行所有质量检查
将修复作为新提交推送（不要修改原有提交），以便审查者看到具体变更内容