最近在看 GitHub 周榜里的 alibaba/open-code-review 。它没有只靠一段 prompt 审 diff ，而是把文件筛选、关联文件分组、规则匹配、评论定位这些步骤做成确定性流程，再让 LLM agent 负责读上下文和判断问题。
更值得讨论的是它公开写出的取舍：项目方自己的 benchmark 里，precision 和 F1 高于通用 agent ，token 大约是后者的 1/9 ，但 recall 更低。这个结果目前仍是项目自测，不是独立评测，不过取舍本身很现实。
如果 precision 高，开发者收到的误报更少，评论才更可能被认真看；但 recall 低，意味着真实缺陷仍会漏掉。我的理解是，这类工具最合适的位置是 PR 的第一轮低噪声筛查，而不是替团队点“允许合并”。
我会把 CI 责任拆成三层：格式、类型、测试、安全规则等确定性检查负责硬阻断； AI review 给高置信提示；人工 reviewer 对业务语义和最终合并负责。
大家现在会让 AI review 阻断合并吗？如果会，你们用什么指标控制误报和漏报：按规则分类、置信度，还是只对少数高风险目录启用？
项目与 benchmark 说明： https://github.com/alibaba/open-code-review
更值得讨论的是它公开写出的取舍：项目方自己的 benchmark 里，precision 和 F1 高于通用 agent ，token 大约是后者的 1/9 ，但 recall 更低。这个结果目前仍是项目自测，不是独立评测，不过取舍本身很现实。
如果 precision 高，开发者收到的误报更少，评论才更可能被认真看；但 recall 低，意味着真实缺陷仍会漏掉。我的理解是，这类工具最合适的位置是 PR 的第一轮低噪声筛查，而不是替团队点“允许合并”。
我会把 CI 责任拆成三层：格式、类型、测试、安全规则等确定性检查负责硬阻断； AI review 给高置信提示；人工 reviewer 对业务语义和最终合并负责。
大家现在会让 AI review 阻断合并吗？如果会，你们用什么指标控制误报和漏报：按规则分类、置信度，还是只对少数高风险目录启用？
项目与 benchmark 说明： https://github.com/alibaba/open-code-review
Select Language