把代码评审交给大模型，最难的不是让模型看懂代码，而是让整套流程稳定、可控、可负担。阿里开源的 Open Code Review（内部使用两年后对外发布，Apache-2.0）给了一个很有参考价值的架构答案：确定性流水线兜底流程，Agent 只做判断。

AI 代码评审的核心矛盾

最直觉的做法是把 Git diff 整个丢给大模型，加一句”请评审这段代码”。做过的人都知道这条路走不远，问题出在四个地方：

  1. 漏报不可控：一次 diff 可能涉及几十个文件，塞不进上下文就得截断，模型评审了哪部分、漏了哪部分，你无从知晓
  2. 噪音淹没价值：模型自由发挥时倾向于”多报以示勤奋”，十条评论里九条是风格建议，真正的 NPE 风险被淹掉
  3. 定位漂移：模型说”这个变量可能为空”，但评论落在错误的行号上，开发者还得自己找
  4. 成本失控：全量上下文 × 每次提交 × 全部仓库，token 账单会迫使项目下线

这四个问题的共同根源是：把流程正确性也交给了概率模型。而流程恰恰是确定性工程最擅长的事。

混合架构：确定性兜底 + Agent 判断

Open Code Review 的设计哲学是”确定性工程 × Agent 混合”，各司其职：

确定性工程负责”不能出错”的环节

  • 文件筛选：直接解析 Git diff，精确圈定变更文件。选哪些文件是流程问题，不需要模型参与
  • 智能打包：相关联的文件组成 bundle，每个 bundle 作为独立上下文交给子代理并行评审。这一步同时解决了上下文长度限制和注意力稀释问题——模型每次只看一个高内聚的变更单元
  • 模板化规则匹配：NPE、SQL 注入、线程安全这类有固定模式的缺陷走模板引擎。确定性匹配零 token 消耗，且结果可复现
  • 评论定位与反思的独立校验：评论必须锚定到具体行号，由确定性逻辑校验，不允许模型”指错位置”

Agent 负责”需要语义理解”的环节

  • 场景化的 prompt 模板：针对不同缺陷类型深度优化，而不是一个通用 prompt 打天下
  • 专用工具集：从生产环境的工具调用数据中提炼，模型评审时可以主动查被调函数实现、追踪变量来源——判断建立在证据上，而不是猜测上

这个分工值得记住一句话：先想清楚流程里哪些环节绝不能出错，那些环节就不该交给概率模型。

基准数据背后的取舍

官方在自建的 AACR-Bench 上对比了”直接用通用 Agent（Claude Code）评审”：相同模型下，Open Code Review 的 Precision 和 F1 显著更高，token 消耗约为其 1/9，但 Recall 更低。

Recall 偏低是刻意的设计选择。评审工具的产品现实是：漏报一条的代价，远低于每天刷屏一百条误报——开发者对噪音的容忍度极低，评审结果一旦被视为”狼来了”，工具就死了。在评审、安全审计、告警这类”宁缺毋滥”的场景，指标目标应该定在 Precision 上，然后用确定性工程去换 Precision，这通常比拼命调 prompt 有效得多。

上手实践

工具是 CLI 形态，前置要求只有 Git ≥ 2.41：

npm install -g @alibaba-group/open-code-review
ocr config provider   # 交互式配置模型提供方，自动测试连通性
ocr config model

常用命令覆盖典型场景：

ocr review                              # 评审当前工作区改动
ocr review --from main --to feature-x   # 评审分支区间
ocr review --commit abc123              # 评审单个提交
ocr scan                                # 不依赖 diff，整目录扫描
ocr review --resume <session-id>        # 恢复中断的会话
ocr review --format json --output result.json  # 结构化输出供其他工具消费

模型侧兼容 OpenAI 与 Anthropic 接口。比较有意思的是 ocr delegate 委托模式：在 Claude Code、Codex、Cursor 这类宿主编码 Agent 中运行时，直接用宿主自带的模型完成评审，OCR 只提供流程与规则——评审变成了编码 Agent 的一项即插即用的技能，不用再单独维护一套模型配置。

对 AI 工程实践的启示

这个工具本身的用法很简单，更值得带走的是它的架构方法论：

  1. 拆解流程，按容错能力分类：把任务拆成环节，问每个环节”错了会怎样”。文件筛错了评审就白做——确定性实现；缺陷判断错了一条只是少条评论——可以交给模型
  2. 把领域知识固化进工程，而不是 prompt：模板规则、专用工具集、场景化模板，都是把生产经验沉淀为确定性资产
  3. 成本结构决定可持续性：1/9 的 token 消耗不是靠更便宜的模型，而是靠”不需要模型的环节就不调模型”
  4. 明确指标偏好：Precision 优先还是 Recall 优先是产品决策，架构要围绕它设计，而不是两头都想要最后两头都平庸

如果你在做评审、审计、监控告警类的 AI 应用，这套思路基本可以直接搬。

小结

  1. AI 代码评审的难点在流程可控性，不在模型能力；把 diff 丢给大模型自由发挥，必然漏报、噪音、漂移、超支
  2. Open Code Review 的解法是混合架构：筛选、打包、规则匹配、定位校验走确定性工程，语义判断交给 Agent
  3. 基准上同模型 Precision/F1 更高、token 约 1/9、Recall 偏低——后者是面向”少打扰”的刻意取舍
  4. 通用启示：按容错能力拆解流程，确定性环节绝不交给概率模型