Back to Details

scrutinize

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Scrutinize

深度审查

Stand outside the change and ask whether it should exist at all, then verify it actually does what it claims end-to-end.
站在变更之外，首先质疑该变更是否有存在的必要，然后端到端验证其是否真正实现了宣称的功能。

Operating stance

操作立场

  • Outsider. Forget who wrote it and why they think it's right. Read the artifact cold.
  • End-to-end, not diff-local. The diff is the entry point, not the scope. Follow the call graph through real code paths.
  • Actionable, concise, with rationale. Every finding states what to change, why, and what evidence led you there. No filler, no restating the diff back.
  • 旁观者视角：忘记代码的作者及其认为正确的理由，以全新视角审视审查对象。
  • 端到端审查，而非仅聚焦diff：diff是切入点，而非审查范围。需沿着真实代码路径追踪call graph。
  • 可执行、简洁且附带依据：每一项发现都需说明修改内容、原因以及得出结论的依据。无冗余内容，不重复diff内容。

Workflow

工作流程

Run these in order. Do not skip ahead.
按以下顺序执行，不可跳过任何步骤。

1. Intent — what is this actually trying to do?

1. 意图确认——该变更实际想要实现什么？

  • State the goal in one sentence, in your own words. If you cannot, the artifact is underspecified — say so and stop.
  • Ask: is there a simpler, smaller, or more elegant way to achieve the same goal? Consider:
    • Doing nothing (is the problem real / load-bearing?).
    • Using something that already exists in the codebase instead of adding new surface.
    • A smaller change that solves 90% of the goal with 10% of the risk.
    • Solving it at a different layer (config vs code, framework vs app, build vs runtime).
  • If a better alternative exists, name it explicitly with rationale. This is the most valuable thing you can output — surface it before the line-by-line review.
  • 用自己的话一句话阐述目标。若无法做到，说明审查对象描述不明确，并停止审查。
  • 提问：是否存在更简洁、更轻量化或更优雅的方法来实现相同目标？ 可从以下方面考量：
    • 不做任何变更（问题是否真实存在/是否影响核心功能？）。
    • 使用代码库中已有的功能，而非新增代码。
    • 用更小的变更实现90%的目标，同时将风险降低至10%。
    • 在不同层面解决问题（配置层面 vs 代码层面、框架层面 vs 应用层面、构建阶段 vs 运行阶段）。
  • 若存在更优方案，需明确指出并说明依据。这是最有价值的输出内容——应在逐行审查前优先呈现。

2. Trace — walk the actual code path

2. 路径追踪——遍历实际代码路径

  • For each behavior the change claims, trace the path end-to-end through the real code, not just the lines in the diff:
    • Entry point → call sites → branches taken → state mutated → exit / return / side effect.
    • Include the unchanged code on either side of the diff. Bugs hide at the seams.
  • For a plan or design doc: trace the proposed flow against the existing system. Where does it touch reality? What does it assume that isn't true?
  • Note every place the trace surprises you (unexpected branch, dead code reached, state you didn't know existed). Surprises are signal.
  • 针对变更宣称的每一项功能，端到端追踪真实代码路径，而非仅查看diff中的代码行：
    • 入口点 → call sites → 分支走向 → 状态变更 → 退出/返回/副作用。
    • 需包含diff两侧未变更的代码。漏洞往往隐藏在衔接处。
  • 针对方案或设计文档：将拟议流程与现有系统进行对比。它与现有系统的哪些部分交互？它做出了哪些不符合实际的假设？
  • 记录所有追踪过程中出现的意外情况（意外分支、执行到死代码、发现未知状态）。意外情况是重要信号。

3. Verify — does it actually do what it claims?

3. 验证确认——变更是否真正实现了宣称的功能？

For each claim the change/plan makes, answer:
  • Does the code path you just traced actually produce that behavior? Walk it explicitly. "It claims X. Path: A → B → C. At C, [observation]. Therefore [holds / doesn't hold]."
  • What inputs / states would break it? Edge cases, concurrent callers, error paths, partial failures, retries, empty/null/unicode/huge inputs, ordering assumptions.
  • What does it silently change? Performance, error semantics, observability, contract for other callers, on-disk / on-wire format.
  • How is it tested? Do the tests actually exercise the traced path, or do they pass while skipping it (mocks that hide the bug, asserts on intermediate state, happy path only)?
针对变更/方案的每一项宣称，回答以下问题：
  • 你刚才追踪的代码路径是否真的产生了该行为？ 需明确遍历路径。例如：“宣称实现X。路径：A → B → C。在C点，[观察结果]。因此[符合/不符合]宣称。”
  • 哪些输入/状态会导致其失效？ 边缘情况、并发调用、错误路径、部分失败、重试、空值/Null/Unicode/超大输入、顺序假设。
  • 它会悄然改变哪些内容？ 性能、错误语义、可观测性、对其他调用者的契约、磁盘/网络传输格式。
  • 它是如何被测试的？ 测试是否真正覆盖了追踪的路径，还是通过跳过路径来通过测试（隐藏漏洞的Mock、对中间状态的断言、仅覆盖正常流程）？

4. Report

4. 报告输出

Output one tight section per finding. Order by severity (blocker → major → nit). For each:
  • Finding — one sentence, specific. Cite 
    file:line
    when applicable.
  • Why it matters — the consequence, not the principle.
  • Evidence — the trace step or input that exposes it.
  • Suggested change — concrete, minimal.
Close with a one-line verdict: ship / fix-then-ship / rework / reject — with the single biggest reason.
针对每一项发现输出一个紧凑的章节。按严重程度排序（阻塞问题 → 主要问题 → 细微问题）。每个章节包含：
  • 发现：一句话描述，具体明确。适用时标注
    文件:行号
    。
  • 影响：说明后果，而非原则。
  • 依据：指出暴露问题的追踪步骤或输入。
  • 建议修改方案：具体、最小化的修改建议。
最后用一句话给出结论：合并/修复后合并/重新设计/拒绝——并说明最主要的原因。

Operating rules

操作规则

  • No rubber-stamps. "LGTM" is not an output. If you genuinely find nothing, say what you traced and what you checked, so the user can judge whether your review covered the surface they cared about.
  • Cite or it didn't happen. Every claim about the code references a specific path, file, or line. No vague "this might break under load."
  • Distinguish claim from verification. "The PR says X" and "I traced X and confirmed / refuted it" are different — keep them separate in the output.
  • One simpler-alternative pass is mandatory. Even on small changes, spend one breath asking if the whole thing is necessary. Skip only if the user explicitly says "don't question scope."
  • Don't pad with style nits when there's a structural problem. If step 1 or step 2 surfaces a real issue, lead with it; defer nits or drop them.
  • No flattery, no hedging. "This is a great PR but..." adds nothing. State the finding.
  • 不做形式上的认可：“LGTM”不是有效输出。若确实未发现问题，需说明你追踪了哪些内容、检查了哪些方面，以便用户判断审查是否覆盖了他们关心的范围。
  • 有依据才算数：每一项关于代码的结论都需引用具体路径、文件或行号。禁止模糊表述，如“这可能在高负载下失效”。
  • 区分宣称与验证：“PR宣称实现X”和“我追踪了X并确认/否定了该宣称”是不同的——需在输出中明确区分。
  • 必须执行一次更优方案评估：即使是小变更，也需花时间思考该变更是否有必要。仅当用户明确说明“不要质疑范围”时才可跳过此步骤。
  • 存在结构性问题时，不纠结于风格细节：若步骤1或步骤2发现了真实问题，需优先呈现；可推迟或忽略细微的风格问题。
  • 不奉承，不模棱两可：“这是一个很棒的PR，但……”毫无意义。直接陈述发现。