审查计划、拉取请求（PR）、差异（diff）或代码变更时…

当用户要求审查、审计、快速检查、获取第二意见，或触发 /scrutinize 时，对计划、PR、diff、设计文档或提案代码变更做端到端审查。

适用场景

解决思路

1. 保持外部视角：忘掉作者是谁、为什么认为它对；冷读工件。
2. 端到端而非局限于差异（diff）：差异只是入口不是范围；沿调用图穿过真实代码路径。
3. 输出可执行、简洁、带理由：每条发现说明要改什么、为什么、什么证据；不要填充，不要把差异（diff）复述一遍。
4. 意图：用自己的一句话说明目标；若无法说明，指出工件描述不足并停止。
5. 意图：问是否存在更简单、更小或更优雅的方式达成同一目标。
6. 意图：考虑什么都不做（问题是否真实、是否关键）。
7. 意图：考虑使用代码库中已有实现，而不是新增接口或表面。
8. 意图：考虑更小改动，用 10% 风险解决 90% 目标。
9. 意图：考虑在不同层解决（配置 vs 代码、框架 vs 应用、构建期 vs 运行期）。
10. 意图：若存在更好替代方案，明确说出并给理由；这是最有价值的输出，在逐行审查前先提出。
11. 追踪：对变更声称的每个行为，沿真实代码端到端追踪，不只追踪差异（diff）中的行。
12. 追踪：入口点 → 调用点 → 走到的分支 → 被变更的状态 → 退出/返回/副作用。
13. 追踪：包含差异（diff）两侧未变更的代码；缺陷藏在接缝处。
14. 追踪：对计划或设计文档，把提议流程与现有系统对照追踪；它在哪里触碰现实？它假设了什么不真实的事？
15. 追踪：记录追踪中每一处令你意外的地方（意外分支、到达死代码、你不知道的状态）；意外是信号。
16. 验证：对每个声称，回答刚追踪的代码路径是否真的产生该行为；显式走一遍：“它声称 X。路径：A → B → C。在 C，[观察]。因此[成立/不成立]。”
17. 验证：哪些输入或状态会破坏它？边界情况、并发调用者、错误路径、部分失败、重试、空/null/unicode/巨大输入、顺序假设。
18. 验证：它静默改变了什么？性能、错误语义、可观测性、对其他调用者的契约、磁盘上或线路上格式。
19. 验证：如何测试的？测试是否真的覆盖所追踪路径，还是通过但跳过该路径（模拟隐藏缺陷、断言中间状态、仅正常路径）。
20. 报告：每个发现输出一个紧凑小节；按严重度排序（阻塞 blocker → 主要 major → 小问题 nit）。
21. 报告：每条发现包含 Finding：一句话，具体；适用时引用 file:line。
22. 报告：每条发现包含 Why it matters：后果，不是原则。
23. 报告：每条发现包含 Evidence：暴露它的追踪步骤或输入。
24. 报告：每条发现包含 Suggested change：具体、最小。
25. 报告：结尾给一行结论：发布 / 先修再发布 / 重做 / 拒绝，并给唯一最大原因。
26. 操作规则：不要橡皮图章式通过。“LGTM”（看起来没问题）不是输出。若确实没发现问题，说明你追踪了什么、检查了什么，让用户判断审查是否覆盖其关心的表面。
27. 操作规则：引用才作数。关于代码的每个声称都要引用具体路径、文件或行。不要模糊地说“负载下可能坏”。
28. 操作规则：区分声称与验证。“PR 说 X”和“我追踪 X 并确认/反驳”不同，在输出中分开。
29. 操作规则：必须做一次简化替代方案检查。即使小改动，也花一口气问整件事是否必要。只有当用户明确说“不要质疑范围”时才跳过。
30. 操作规则：存在结构问题时，不要用风格小问题填充。若步骤 1 或步骤 2 发现真实问题，先讲它；小问题推迟或删除。
31. 操作规则：不要奉承，不要含糊其辞。“这是一个很好的 PR，但是……”没有增加信息。直接陈述发现。

适用边界 · 注意事项

• 用户明确说“不要质疑范围”时，不要执行简化替代方案检查。
• 只有孤立差异（diff）、无法访问真实代码路径或系统上下文时，无法完成端到端追踪与验证。
• 纯格式或风格检查、仅需快速拼写检查时不适用；它针对意图、路径和验证。