Open Code Review：少报错的代价是漏掉八成问题

它针对的问题

用通用智能体做代码评审，有三个常见的毛病：变更集一大就偷工减料，只审一部分文件；报告的问题和实际代码位置对不上，行号漂移；用自然语言写的评审技能难以调试，提示稍有变化，质量就跟着波动。项目给出的归因是：纯靠语言驱动的架构，对评审过程没有硬约束。

做法：不能出错的步骤不交给模型

由确定的程序完成的：

• 选文件：哪些要审、哪些过滤掉
• 打包：把相关文件归成一个评审单元，每个单元由一个上下文隔离的子智能体处理
• 规则匹配：按文件特征用模板引擎匹配评审规则
• 定位与反思：独立的模块负责把评论对到正确的行，并过滤评论内容

交给智能体的：动态决策和按需取上下文。工具集是从大规模生产数据的调用轨迹里筛出来的——调用频率、单个工具的重复率、新增工具对整条调用链的影响。

官方给出的数字

基准 AACR-Bench 取自 50 个开源仓库的 200 个真实合并请求，覆盖 10 种语言，由 80 多位资深工程师交叉标注出 1,505 个问题。在相同底层模型下，它的精确率和 F1 高于通用智能体，token 用量约为九分之一。

README 在同一段里写明：召回率低于通用智能体，这是有意的取舍，宁可少报也不要噪声。

外部的质疑

InfoQ 引用了两位评论者。

一位指出，到目前为止唯一一次独立基准测试的结果很难看：在 10 个合并请求上精确率约 12%。维护者对此提出异议，称是工具调用异常所致并已修复，但修复之后还没有独立的验证。

另一位算了召回率的上限：最优配置下是 20%，也就是专家标出的问题有 80% 它找不到。用来保证精确率的确定性分发，同时限制了它发现跨文件和架构层面问题的能力。

两位的评价并不是否定。前一位认为它公开基准并主动披露召回率劣势，比同类工具的做法更可信；后一位的结论是，它的贡献不在于用了更好的模型，而在于一个更好的外壳。

怎么读这条

先想清楚你要评审工具做什么。如果目的是减少人要看的噪声，让每条评论都值得读，高精确率是对的方向。如果目的是尽量不漏掉缺陷，20% 的召回率意味着它不能单独承担这件事。

它用 Apache 2.0 协议开源，兼容 OpenAI 与 Anthropic 的模型接口，可以评审差异、分支或整个文件，也可以作为插件接进几种编码智能体。

本条由 InfoQ 的报道带入，项目自述以其 GitHub 仓库的 README 为准。