Back to Details

review

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Review

代码审查

When to use

使用场景

  • Reviewing a spec before execution
  • Reviewing current changes before commit or merge
  • Reviewing a specific file or focus area
  • Checking whether a change is safe to ship
  • 执行前审查spec
  • 提交或合并前审查当前变更
  • 审查特定文件或重点区域
  • 检查变更是否可安全发布

Process

流程

  1. Choose the target from 
    $ARGUMENTS
    , the working tree, staged changes, or the latest commit.
  2. If the target is a spec, check whether decisions, invariants, requirements, error behavior, and tests are reviewable before code exists.
  3. If the target is code, read the actual changes and any available context that explains intent, such as the spec, plan, commit message, or PR title and description.
  4. Apply any repo-specific concerns from 
    REVIEW.md
    if it exists.
  5. Prioritize concrete bugs, regressions, contract breaks, failure-path gaps, missing decisions, broken invariants, and unnecessary complexity.
  6. Report findings as 
    Must fix
    , 
    Should fix
    , or 
    Observations
    , ordered highest risk first. A clean review is a valid outcome.
  1. 从
    $ARGUMENTS
    、工作树、暂存变更或最新提交中选择审查目标。
  2. 如果目标是spec，在代码编写前检查决策、不变量、需求、错误行为和测试是否可审查。
  3. 如果目标是代码，阅读实际变更以及任何解释意图的可用上下文，例如spec、计划、提交信息或PR标题和描述。
  4. 如果存在
    REVIEW.md
    ，应用其中针对特定仓库的注意事项。
  5. 优先处理具体漏洞、回归问题、契约破坏、故障路径缺口、缺失的决策、被破坏的不变量和不必要的复杂性。
  6. 按照风险从高到低的顺序，将发现的问题归类为“必须修复”、“应该修复”或“观察项”。无问题的审查结果也是有效的。

Verification

验证标准

  • Every finding is tied to concrete evidence in the target
  • Every finding explains why it matters
  • Findings are limited to the changes under review
  • Highest-risk findings come first
  • Pre-existing issues are not mixed in
  • No finding is just a style preference
  • 每个发现的问题都与审查目标中的具体证据相关联
  • 每个发现的问题都解释了其影响
  • 发现的问题仅限于所审查的变更
  • 高风险问题优先列出
  • 不混入预先存在的问题
  • 不包含仅涉及风格偏好的问题

Rules

规则

  • Prioritize real bugs and regressions over style commentary.
  • Flag changes that add unnecessary surface area.
  • Flag silent contract changes.
  • Flag decisions made in code that were not surfaced in the spec when they affect behavior or maintenance.
  • Flag invariants that were omitted from a spec or quietly broken by an implementation.
  • Flag missing or weak failure-path handling when it matters.
  • Flag reviewer-facing context that is missing or misleading when it would make the change hard to review, such as a PR title or description that does not explain what changed and why.
  • If there is no concrete diff, file, or commit to review, say so.
  • Findings only. Do not fix the code.
  • Be direct and specific.
  • Tie each finding to evidence in the diff.
  • Do not speculate without evidence.
  • If you are unsure a problem is real, say so honestly.
  • 优先处理真实漏洞和回归问题，而非风格评论。
  • 标记增加不必要复杂度的变更。
  • 标记无提示的契约变更。
  • 当代码中的决策影响行为或维护但未在spec中体现时，标记此类决策。
  • 标记spec中遗漏的不变量或被实现悄悄破坏的不变量。
  • 当故障路径处理缺失或薄弱且造成影响时，标记此类问题。
  • 当PR标题或描述未解释变更内容及原因，导致变更难以审查时，标记此类缺失或误导性的审查上下文。
  • 如果没有具体的差异文件、文件或提交可供审查，需明确说明。
  • 仅报告发现的问题，不修复代码。
  • 表述直接且具体。
  • 每个发现的问题都关联差异中的证据。
  • 无证据不猜测。
  • 如果不确定问题是否真实，需如实说明。