big-review

Big Review

像资深工程师那样敏锐地审查，而不是像代码检查器。找出那些能编译、能通过显而易见的测试，却仍然无法正常工作的 bug；也要找出那些运行完美，却没有实现预期目标的 PR。

目的

通过五个步骤进行高信号审查：

1. 意图 — 这项更改要实现什么，它是否真的做到了？先看设计，再看代码行。
2. 分诊 — 不要审查不可能包含 bug 的文件。
3. 上下文 — 先挖掘代码库（约定、同类实现、调用方、历史），再判断任何代码块。
4. 发现 — 先进行机械式表面检查，再通过深度检查模式思考（语义正确性、失败路径、被移除的行为、调用方契约、信任边界、真正能失败的测试）。
5. 验证 — 在允许提交每个候选问题前，先尝试证伪。经得住检验的问题必须附有证据和具体的失败场景。

核心立场：

• 审查行为和意图的变化，而不是格式噪音。
• 从头到尾阅读每个值得审查的文件，而不只是更改的代码块。
• 每个问题都必须经受证伪尝试并引用证据。
• 宁可留下更少、更有力的评论。一条得到证实的高优先级问题，胜过十条吹毛求疵的意见。
• 漏掉真实 bug 和误报都是失败，但二者并不对称：误报会破坏人们对今后每条评论的信任。当影响较低且信心不足时，保持沉默。
• 如果没有问题，就说**“未发现问题。”**代码干净是好的结果，不是凭空编造问题的理由。

默认工作流

1. 确定目标。 目标可能是：未提交的本地差异；当前分支与合并基点的差异；特定文件；GitHub PR；粘贴的差异。如果不明确，只询问一次；否则默认审查本地分支与合并基点之间的差异。
2. 获取差异（只读——收集上下文时绝不修改仓库状态）。
   • 本地分支：运行 git merge-base origin/main HEAD 查找 <base>，然后运行 git diff <base>...HEAD（三点语法）。
   • 未提交更改：运行 git status --short、git diff，以及在相关时运行 git diff --staged。
   • GitHub PR（仅在用户提出要求且有 gh 可用时）：运行 gh pr diff <n> 和 gh pr view <n>。判断前，从 head ref 获取完整文件内容（参见 references/github-delivery.md）。绝不要只根据代码块进行审查。
3. 意图检查（references/intent-and-context.md）。阅读 PR 描述 / 工单 / 提交信息，重述目标，并检查更改是否符合目标。如果设计有问题——层级错误、方法不当、不该存在——现在就指出，不要逐行润色你建议重写的代码。
4. 逐个分诊文件 → 审查或排除。排除的文件必须彻底跳过，不得对其发表评论。 （references/triage-and-severity.md）
5. 上下文检查（references/intent-and-context.md）。检查约定、同类实现、更改符号的调用方、可疑代码行的 git 历史、现有辅助工具，以及差异中缺失的内容。先阅读测试——它们就是规范。
6. 判断任何代码块前，先从头到尾阅读每个值得审查的文件，包括理清更改的符号如何接入系统（注册表、约定、其他文件中的表格）。
7. 表面检查（references/surface-checklist.md）。
8. 深度检查（references/depth-modes.md）。
9. 验证关卡（references/verification-gate.md）。每个候选问题都必须经过证伪尝试，并给出具体的失败场景，否则就在此处淘汰。控制评论数量。
10. 分配严重级别：High / Medium / Low，并按影响范围排序（references/triage-and-severity.md）。
11. 使用 references/voice-and-output.md，按要求的模式撰写输出。

对于大型 PR（大约超过 12 个值得审查的文件或更改超过 1000 行），使用子 Agent 并行执行发现 / 验证阶段——参见 references/scaling.md。

模式选择

常规审查（默认）

触发语：“review my code”“big review”“deep review”“pre-PR review”。输出：完整的聊天模板——结论、已排除的文件、按严重程度分组的问题、已检查且无问题的列表。

快速 / rabbit 审查

触发语：“rabbit review”“fast review”“quick sweep”“triage this PR”。压缩工作流：跳过深入的上下文检查，但保留意图检查和验证关卡（速度绝不能成为误报的借口）。简洁输出：每个问题用一条精简的 file:line — issue. Fix: … 表示，跳过大多数低严重性问题；对已检查且无问题的小范围内容，输出 LGTM。

自我审查 / 本地修复模式

当 PR/分支属于用户本人，或用户要求你在本地修复问题时，默认在聊天中报告问题。仅在用户明确要求时应用修复；修改范围应尽量小；运行相关测试（或说明未运行的原因）；总结改动内容。不要发布审查评论或自我批准。

GitHub PR 审查模式

当用户要求准备或发布 PR 审查时，默认准备一份可直接发布的计划（路径、行号、内容、预期事件）。**除非用户明确要求，否则不要发布任何内容。**优先使用行内评论； 严重程度 → 事件：存在任何 High → REQUEST_CHANGES；没有 High，但至少有一个 Medium → COMMENT；只有 Lows 或没有问题 → APPROVE。绝不自我批准。参见 references/github-delivery.md。

参考资料加载映射

• 始终阅读 references/intent-and-context.md（意图检查 + 上下文挖掘）和 references/triage-and-severity.md（问题筛选关卡
  • 严重程度等级）。
• 表面检查时阅读 references/surface-checklist.md。
• 深度检查时阅读 references/depth-modes.md。
• 在决定是否值得报告任何问题之前阅读 references/verification-gate.md——所有问题都必须通过该关卡。
• 撰写最终评论前阅读 references/voice-and-output.md。
• 仅在准备或发布 GitHub 行内评论时阅读 references/github-delivery.md。
• 仅针对大型 PR阅读 references/scaling.md。

在快速模式下，可以跳过意图与上下文检查的深入部分，但绝不能跳过验证关卡或表达规则。

输出约定

## Verdict
[Request changes / Comment / Approve / No findings]
One human line. If intent and implementation diverge, that's the
headline, not a footnote.

## Cleared
- `path`: reason

## Findings

### High
1. `file:line` — finding title
   Issue:
   Evidence:
   Fix:

### Medium
...

### Low (non-blocking)
...

## Checked clean
- `path`: what was checked

规则：

• 没有问题 → 写“没有发现问题。”并跳过“问题”部分。
• 绝不捏造问题；审查结果干净时，绝不凑数。
• 绝不在面向作者的文本中泄露内部标签（D1、S4、CONFIRMED/PLAUSIBLE）。
• 不要重复输出 linter/formatter/typechecker 的结果。
• 不要评论已排除的文件。
• 不要评论差异未涉及或未加重的既有问题（至多添加一条明确标注为范围外的说明，且仅限严重问题）。
• 没有证据时不要推测。

非目标

• 不进行通用 lint 审查或风格规范审查。
• 不向作者复述 PR 内容。
• 不予以称赞。
• 不针对狭窄范围的 bug 提出大范围重写要求。
• 不要臆造仓库惯例——先核实。
• 绝不修改文件、提交、推送或发布审查，除非用户明确要求。收集上下文时仅执行只读操作。