code-review
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
ChineseCode Review
代码评审
Both sides of the code review process: requesting and receiving feedback.
代码评审流程的双视角：请求评审与接收反馈。
When to Request Review
何时请求评审
Mandatory
强制场景
| Situation | Why |
|---|---|
| After completing major feature | Catch issues before they spread |
| Before merge to main | Gate quality |
| After each task in subagent workflow | Fix issues before compounding |
| 场景 | 原因 |
|---|---|
| 完成主要功能后 | 在问题扩散前发现它们 |
| 合并至主分支前 | 把控质量关卡 |
| 完成子代理工作流中的每个任务后 | 在问题复杂化前修复 |
Valuable
建议场景
| Situation | Why |
|---|---|
| When stuck | Fresh perspective |
| Before refactoring | Baseline check |
| After fixing complex bug | Verify fix doesn't introduce new issues |
| 场景 | 原因 |
|---|---|
| 陷入瓶颈时 | 获取全新视角 |
| 重构前 | 进行基线检查 |
| 修复复杂漏洞后 | 验证修复未引入新问题 |
Requesting Review
请求评审
What to Provide
需提供的内容
| Element | Purpose |
|---|---|
| What was implemented | Context for reviewer |
| Requirements/plan reference | What it should do |
| Base SHA | Starting point |
| Head SHA | Ending point |
| Brief summary | Quick orientation |
| 要素 | 目的 |
|---|---|
| 实现内容 | 为评审者提供上下文 |
| 需求/方案参考 | 明确预期功能 |
| Base SHA | 起始版本节点 |
| Head SHA | 结束版本节点 |
| 简要概述 | 帮助快速了解内容 |
Acting on Feedback
处理反馈的行动
| Severity | Action |
|---|---|
| Critical | Fix immediately |
| Important | Fix before proceeding |
| Minor | Note for later |
| Disagree | Push back with reasoning |
| 严重程度 | 行动 |
|---|---|
| 严重 | 立即修复 |
| 重要 | 推进前完成修复 |
| 次要 | 记录后续处理 |
| 不认同 | 给出理由后提出异议 |
Receiving Review
接收评审
Core Principle
核心原则
Verify before implementing. Ask before assuming. Technical correctness over social comfort.
先验证再实施。先询问再假设。技术正确性优先于社交舒适度。
The Response Pattern
响应流程
- Read - Complete feedback without reacting
- Understand - Restate requirement (or ask)
- Verify - Check against codebase reality
- Evaluate - Technically sound for THIS codebase?
- Respond - Technical acknowledgment or reasoned pushback
- Implement - One item at a time, test each
- 阅读 - 完整查看反馈，不急于反应
- 理解 - 重述需求（或提出疑问）
- 验证 - 对照代码库实际情况检查
- 评估 - 对当前代码库而言技术上是否合理？
- 回应 - 技术层面确认或给出有依据的异议
- 实施 - 逐项处理，每项都测试
Handling Unclear Feedback
处理模糊的反馈
| Situation | Action |
|---|---|
| Some items unclear | STOP - ask before implementing any |
| Partially understood | Don't implement partial - items may be related |
| Scope unclear | Ask for clarification |
Key concept: Partial understanding leads to wrong implementation. Clarify everything first.
| 场景 | 行动 |
|---|---|
| 部分内容不清晰 | 暂停 - 先询问清楚再实施任何内容 |
| 部分理解 | 不要部分实施 - 各项内容可能相互关联 |
| 范围不明确 | 请求澄清 |
核心概念：部分理解会导致错误实现。先澄清所有内容。
When to Push Back
何时提出异议
| Situation | Push Back |
|---|---|
| Suggestion breaks existing functionality | Yes |
| Reviewer lacks full context | Yes |
| Unused feature (YAGNI violation) | Yes |
| Technically incorrect for this stack | Yes |
| Legacy/compatibility reasons exist | Yes |
| Conflicts with architectural decisions | Yes |
| 场景 | 是否提出异议 |
|---|---|
| 建议会破坏现有功能 | 是 |
| 评审者缺乏完整上下文 | 是 |
| 建议的功能未被使用（违反YAGNI原则） | 是 |
| 对当前技术栈而言技术上不正确 | 是 |
| 存在遗留系统/兼容性考量 | 是 |
| 与架构决策冲突 | 是 |
How to Push Back
如何提出异议
| Do | Don't |
|---|---|
| Use technical reasoning | Be defensive |
| Ask specific questions | Argue emotionally |
| Reference working tests/code | Ignore valid feedback |
| Show evidence | Just say "no" |
| 应做 | 不应做 |
|---|---|
| 基于技术理由 | 带有防御性 |
| 提出具体问题 | 情绪化争论 |
| 参考可用的测试/代码 | 忽略有效反馈 |
| 提供证据 | 只说“不行” |
Implementation Order
实施顺序
When fixing multiple items:
- Clarify anything unclear FIRST
- Then implement in order:
- Blocking issues (breaks, security)
- Simple fixes (typos, imports)
- Complex fixes (refactoring, logic)
- Test each fix individually
- Verify no regressions
修复多个问题时：
- 首先澄清所有不明确的内容
- 然后按以下顺序实施：
- 阻塞性问题（功能中断、安全问题）
- 简单修复（拼写错误、导入问题）
- 复杂修复（重构、逻辑调整）
- 单独测试每项修复
- 验证无回归问题
Response Patterns
回应规范
Forbidden (Performative)
禁用（流于形式）
| Don't Say | Why |
|---|---|
| "You're absolutely right!" | Performative, not technical |
| "Great point!" | Empty agreement |
| "Let me implement that now" | Before verification |
| 不应说 | 原因 |
|---|---|
| “你完全正确！” | 流于形式，非技术层面回应 |
| “好观点！” | 空洞的认同 |
| “我现在就去实现” | 未验证就行动 |
Correct Responses
正确回应
| Situation | Response |
|---|---|
| Feedback is correct | "Fixed. [Brief description]" |
| Need clarification | "Need clarification on X before proceeding" |
| Disagree | "[Technical reasoning why current approach is better]" |
| Can't verify | "Can't verify without [X]. Should I investigate?" |
Key concept: Actions speak. Just fix it. The code shows you heard the feedback.
| 场景 | 回应 |
|---|---|
| 反馈正确 | “已修复。[简要说明]” |
| 需要澄清 | “在推进前需对X进行澄清” |
| 不认同 | “[说明当前方案更优的技术理由]” |
| 无法验证 | “没有[X]无法验证。是否需要我先调研？” |
核心概念：行动胜于言语。直接修复即可。代码会证明你已听取反馈。
Red Flags
注意事项（红牌警示）
| Never Do | Why |
|---|---|
| Skip review because "it's simple" | Simple changes cause bugs too |
| Ignore Critical issues | They're critical for a reason |
| Proceed with unfixed Important issues | They'll compound |
| Argue with valid technical feedback | Ego over quality |
| Implement without understanding | Wrong fixes waste time |
| 绝对禁止 | 原因 |
|---|---|
| 因“内容简单”跳过评审 | 简单改动也会引发漏洞 |
| 忽略严重问题 | 它们被标记为严重是有原因的 |
| 带着未修复的重要问题推进 | 问题会复杂化 |
| 反驳有效的技术反馈 | 把自我置于质量之上 |
| 未理解就实施 | 错误的修复会浪费时间 |
Source-Specific Handling
按反馈来源处理
| Source | Approach |
|---|---|
| User | Trusted - implement after understanding, skip to action |
| External reviewer | Evaluate technically before implementing |
| Automated tool | Verify relevance to your context |
| 来源 | 处理方式 |
|---|---|
| 用户 | 可信 - 理解后直接实施，跳过评估步骤 |
| 外部评审者 | 先从技术层面评估再实施 |
| 自动化工具 | 验证其与当前场景的相关性 |