卷了一段时间的覆盖率,尝试用 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 定向审查。