技术 · 熟练
同一个审查档位套所有仓库，贵和漏你都会遇到
深度是参数，不是开关
把 AI 代码审查当成一个开 / 关的按钮，是这类工具最常见的一次误配。深档套到十几个小仓上，账单先到；快档套到动钱动数据的那两个仓上，漏检先到。现在主流工具已经把「深度」做成了可按仓库设的参数（快 / 标准 / 深），组织级定默认、仓库级覆盖。这一页给四步：把深度当参数 · 按风险而不是按习惯分工 · 开启成功不等于已被覆盖 · 新仓默认纳入。关键动作只有一个：先给「覆盖」做一次对账 —— 没被审过和审过没问题，在结果上长得一模一样。
方法 · 一图看懂
1
把深度当成一个按仓库设的参数 — 组织级给一个默认档，再对少数仓库逐个覆盖；⛔ 不要用一个全局档位配完就结束
2
按风险分工，不按习惯分工 — 动钱、动数据、动发布流程的仓上深档；试验仓、文档仓、一次性脚本仓上快档。判据是「它出事时影响谁」，不是「谁的代码更难看」
3
「开启成功」不等于「已被覆盖」 — 官方修过一个静默窗口：审查开启后一两分钟内开的 PR 会被悄悄排除、从不被审。⇒ 每周拉一份「本周期开过的 PR」与「被审过的 PR」对照，差集就是要补的那几条
4
新仓库默认纳入，别靠手工加 — 整组织注册一次、新建仓自动进来；手工维护的列表必然漏，而漏掉的仓库不会报错
原理 · 为什么有效
审查的成本与保障是两条曲线：成本随「深度 × 变动量 × 仓库数」线性涨，漏检风险随「没被覆盖的仓库数」跳变。于是最贵的配置不是全深，也不是全快，而是「用同一个档位对待所有仓库」—— 它同时买到两头的坏处。把深度做成参数，等于把这两条曲线分开管：宽的一层用快档兜住「有没有明显问题」，窄的一层用深档兜住「会不会出事」。而覆盖缺口之所以危险，是因为它不产生任何信号：一个从未被审过的仓库，在流水线上和「审过且没问题」的仓库显示得一样绿。所以这套方法里唯一必须周期性做的动作，是对账而不是调档。
适用场景
适用：一个人管多个仓、或给团队统一配 AI 审查的人；正在把审查从「谁想开就开」收拢到「统一治理」的团队。不适用：只有一个仓库的个人项目（直接一档到底，对账也只盯一个）；把「开了审查」当验收终点的团队 —— 那正是这一页要纠的读法。
自测 · 5 问
我说得出哪些仓库用了深档、哪些用了快档，以及各自的理由吗
我上一次把「开过的 PR」和「被审过的 PR」对过账，是什么时候
有没有哪个仓库是「以为在审、其实从没审过」的（开启时间点附近的那批 PR 最可疑）
新仓库是自动纳入的，还是要有人手工去加
我调档的判断依据是「出事时影响谁」，还是「这个仓最近改动多」
怎么上手 · 验证步骤
第一件事不是调档，是拉一张覆盖表。① 列出全部仓库，逐个标：当前档位 · 最近 30 天有没有 PR · 这些 PR 有没有被审过。② 把「有 PR 但没有审查记录」的挑出来，逐个查是不是落在开启前后的静默窗口里。③ 按「出事时影响谁」重排档位：动钱/动数据/动发布的升深档，其余降快档。④ 定一个每周十分钟的动作：只对账，不调档 —— 对账发现的缺口才去补。
问自己一句：如果明天有个仓库出了事，我说得出它上一次被审是什么时候吗？答不出 ⇒ 覆盖对账没做，这时候讨论档位深浅没有意义。再补一句：我现在的档位分布，是「两个仓深、其余快」，还是「全都一样」—— 全都一样，就还没开始按风险分工。