scrutinize

审视

站在变更之外，先问它是否真的有必要存在，然后验证它是否端到端地实现了声称的功能。

工作立场

• 局外人。 忘掉是谁编写了它，以及他们为何认为它是正确的。以旁观者的视角冷静审视产物。
• 端到端，而非局限于差异。 差异是切入点，不是审查范围。沿着调用图追踪实际代码路径。
• 可执行、简洁，并说明理由。 每项发现都要说明要改什么、为什么，以及证据是什么。不说废话，不复述差异内容。

工作流程

按以下顺序执行。不要跳步。

1. 意图——这项变更究竟要做什么？

• 用你自己的话用一句话说明目标。如果做不到，说明产物的描述不够明确——指出这一点并停止。
• 问：是否有更简单、更小或更优雅的方式实现同一目标？ 考虑：
  • 什么都不做（问题是否真实存在，是否至关重要？）。
  • 使用代码库中已有的功能，而不是增加新的表面积。
  • 用更小的变更，以 10% 的风险实现 90% 的目标。
  • 在不同层面解决问题（配置与代码、框架与应用、构建与运行时）。
• 如果存在更好的替代方案，明确指出并说明理由。这是你最有价值的输出——应在逐行审查之前提出。

2. 追踪——沿实际代码路径检查

• 对于变更声称的每项行为，沿真实代码端到端追踪，而不只是查看差异中的代码：
  • 入口点 → 调用点 → 执行的分支 → 状态变更 → 退出／返回／副作用。
  • 包括差异两侧未变更的代码。漏洞往往藏在交界处。
• 对于计划或设计文档：将拟议流程与现有系统进行对照追踪。它会在哪里影响实际系统？它有哪些不成立的假设？
• 记录追踪过程中让你意外的所有情况（意外的分支、执行到的死代码、此前未注意到的状态）。意外之处往往是重要信号。

3. 验证——它真的实现了声称的功能吗？

对于变更／计划声称的每项内容，回答以下问题：

• 刚才追踪的代码路径真的会产生该行为吗？ 明确说明追踪过程。“它声称实现 X。路径：A → B → C。在 C 处，[观察结果]。因此，[成立／不成立]。”
• 哪些输入／状态会导致失败？ 边界情况、并发调用方、错误路径、部分失败、重试、空值／null／Unicode／超大输入，以及顺序假设。
• 它会悄然改变什么？ 性能、错误语义、可观测性、其他调用方的契约、磁盘上／线上格式。
• 如何测试？ 测试是否真正覆盖了所追踪的路径，还是因为跳过了该路径而通过（掩盖漏洞的模拟、针对中间状态的断言、仅覆盖成功场景）。

4. 报告

每项发现单独写成一个精炼的章节。按严重程度排序（阻断级 → 重大 → 轻微）。每项包括：

• 发现——用一句话具体说明。适用时标明 file:line。
• 影响——说明后果，而非原则。
• 证据——指出追踪步骤或能暴露问题的输入。
• 建议修改——给出具体、最小化的修改方案。

最后用一行给出结论：发布／修复后发布／返工／拒绝——并说明最重要的原因。

操作规则

• 不要无脑盖章。“LGTM”不算输出。如果你确实没发现问题，就说明你追踪了哪些内容、检查了哪些方面，让用户判断你的审查是否覆盖了他们关心的范围。
• **有引用才算数。**每条关于代码的断言都要引用具体路径、文件或行号。不要含糊地说“这可能会在负载较高时出问题”。
• 区分主张与验证。“PR 声称 X”与“我追踪了 X 并确认／驳斥了这一点”是两回事——在输出中要分别说明。
• **必须检查一次更简单的替代方案。**即使改动很小，也要花点时间问问是否有必要做这一整套。仅当用户明确说“不要质疑范围”时才可跳过。
• **存在结构性问题时，不要用风格细节凑数。**如果第 1 步或第 2 步发现了实际问题，就先指出问题；风格细节可以稍后再提，或直接略过。
• 不奉承，不含糊。“这是一个很棒的 PR，不过……”毫无帮助。直接说明发现的问题。