卷了一段时间的覆盖率，尝试用 LLM 对单个 PR 做完整的覆盖，结果越来越烧 token 。合规要求不能接 coderabbit 。现在在用 ocr： github.com/alibaba/open-code-review

这个工具用 go 写主要是做处理并发，核心是在 Prompt 模板（ MAIN_TASK / PLAN_TASK / RE_LOCATION_TASK / REVIEW_FILTER_TASK ），针对不同语言的规则文档，和 review 用的 agent 工具集定义。

放到 CI 里，跑了一个项目历史累积的 1400 个 PR ，连续跑了十多个小时，只改了 1 ～ 2 个文件几行代码的 PR 有时候都要跑几分钟。

参考 Meta 这套 RADAR (Risk Aware Diff Auto Review) 系统 arxiv.org/pdf/2605.30208v1

让 AI 评估风险，低风险不处理，高风险采用工具跑 Review 转人工审核。

• git diff 扔给大模型的方式消耗太大，先做特征工程，把开发者元数据（这个人的提交频次，回滚率等）、变更前后的 AST ，系统识别修改是改变了条件分支的判断逻辑（中风险），还是修改了锁的粒度（极高风险）
• 用 ML 的分类器，计算引发故障的概率
• 根据风险结果，动态调用测试集，使用更小的测试集，节省资源
• 如果处理失败，标记低风险但触发了故障，作为训练的负样本。和其他 ML 系统不同，PR 到实际故障的反馈可能滞后时间很长

AI 代码审查重点从 LLM 做具体的正确/安全/可维护/性能，转到 MLOps 的风险路由+局部强约束的 LLM 定向审查。