分支代码评审

要解决什么问题

同一段 diff，在不同项目里的风险完全不同。这个技能首先要解决的是：评审前先看项目自己的规范，而不是套一套通用规则。早期版本曾因为没读 README 和 .eslintrc，把项目明确允许的 console.log 报成违规，也漏掉过 README 里专门写明的内存泄漏热点。现在每次评审都强制跑一遍规范扫描。

第二个问题是评审深度一刀切：小改动不值得全量审查，大改动又需要沉淀长期架构记忆。所以 v2.6 引入了 lite / standard / deep 三档，默认 standard。

三档模型

• lite：快查风险，diff 看完直接说哪有坑、要测什么，产物收敛进单个 review.md（3 节）。
• standard：在 lite 基础上加一节影响分析，点名调用链和重组件，产物同样是单个 review.md（4 节），做完即走，不留长期资产。
• deep：唯一会写 AIReview/components/、project-overview.md 和 ADR 的档位。兼容性、性能、代码味道扫描、图谱输出全部归 deep 独占，避免浅做变成噪音。

关键步骤

1. Phase 0：解析 --tier（非法值直接报错停止），按需创建 AIReview/{日期}-{分支}-review报告/ 输出目录。
2. Phase 0.3 规范扫描（每次必跑）：按优先级读 README.md、AGENTS.md、CLAUDE.md、CONTRIBUTING.md、lint 配置等，提取 6 类结构化规范存进内存（不落盘，避免"两个真相"漂移）。之后每个 finding 都经这套规范过滤：该抑制的抑制，该升级的升级，finding 表格带"依据"列标明出处。
3. Phase 0.5：仅 deep 且提供 PRD 时执行，做 PRD 驱动的架构对齐。
4. Phase 1–3：知识图谱、需求问答、影响分析，深度随档位变化。
5. Phase 3.5–5：代码味道、兼容性、性能，仅 deep。
6. Phase 6–7：回归范围与最终文档。

diff 基线与产出约定

唯一有效的 diff 是 master 与当前分支 HEAD 的对比。"新增"只看分支上有而 master 上没有，不看分支内第几个 commit 引入；分支内 commit 历史仅用于理解意图。所有产物写入项目根的 AIReview/ 目录，lite/standard 收敛到单文件，deep 才产出多文件全套文档。

适用边界

• 规范文件全缺或过简时只告警不阻塞，后续 finding 依据统一标注 skill 默认规则。
• lite/standard 不生成 impact-report、回归清单、测试清单和任何图。
• deep 没给 PRD 会静默跳过 0.5，其余行为不变；给了 PRD 的 lite/standard 会提示升级。