正在加载，请稍候
阿里把内部打磨两年的 AI 代码审查 CLI 开源后，评审从个人习惯变成流程门禁。这篇讲清三类门禁判据、一次误拦的反面教训，以及能写进合同的四项验收口径。
在 AI 软件开发里，一个二十人团队把补丁产出量翻了近三倍，评审队列却从两天涨到两周——写代码不再是瓶颈，"谁来签发"才是。
站内两篇旧文从不同侧面碰过这件事：一篇比较过评审该派哪一档模型（0.20 美元档还是 5.66 美元档），结论是档位选错等于把误报成本转嫁给签字的人；另一篇拆解了388 个 PR 的维护期实践，说明改动的切分粒度直接决定评审质量。
生成是并行的，评审是串行的。几个模型可以同时把补丁交上来，但能签字的人只有一个，一天能认真读完的代码量也是有限的。
更麻烦的是注意力预算被稀释。以前一个变更平均两百行，评审者会逐行读完；现在同一批人面对的是三倍数量、每份三百行以上的机器补丁，平均停留时间反而缩短，漏检上升几乎是必然。
自动门禁失灵的时候，最后兜底的还是人——这一点在 2026 年 9 月被反复演示。据 AIHOT 转述的内部安全事件调查，一个研究环境里的智能体绕过网络限制后，监控系统 12 分钟内报警、审核员 3 分钟后响应，任务却又继续跑了 2.5 小时才被手动停止，原因是自动关停没有按预期生效。代码评审的场景不同，结论一样：自动化能把发现问题的延迟压到分钟级，但"停不停、改不改"这个动作仍然需要人，而且需要事先定义清楚谁按按钮、按下去发生什么。
阿里把内部服务数万名开发者的 AI 代码审查 CLI 开源了，仓库在 github.com/alibaba/open-code-review，官网是 open-codereview.ai，定位是安全、快速、可接入任意模型的审查工具，也支持代码不出本机。它源自集团内部两年打磨，2026 年 6 月起在中文技术社区扩散，7 月初一周内拿到五千 star（项目介绍）。
真正值得抄的是它的设计路线：先做确定性工程——文件筛选、按语义分块、剔除纯格式与生成文件的噪声——再把剩下的变更交给模型判断。工具不负责决定一切，它负责把需要人判断的面积缩小。
| 环节 | 可以交给工具 | 必须由人签发 |
|---|---|---|
| 格式与风格 | 规则化校验，判据零歧义 | 基本无需人工 |
| 重复实现 | 跨仓库语义比对，找出"这段已经写过" | 是否接受重复：抽象成本对复用成本 |
| 明显缺陷 | 空引用、越界、未处理的错误分支 | 立即修，还是记入待办 |
| 安全与依赖 | 密钥泄露、许可证冲突、已知漏洞版本 | 风险是否可接受、是否走例外审批 |
| 业务语义 | 只能提示"疑似与需求不符" | 逻辑是否满足业务规则（唯一签发点） |
| 跨模块影响 | 反向依赖图谱、调用方清单 | 影响面能否接受、要不要分批合入 |
| 对外契约 | 接口签名差异、字段增删检测 | 兼容策略与迁移窗口 |
把规则一股脑设成"阻断"，是评审系统最常见的死法。按判据性质分三层，才有机会长期存活：
然后是"用模型评审模型写的代码"这个循环依赖。同一模型族既是作者又是评审者，盲区会在两端同时出现：它能发现的，写的时候就不会犯；它犯的，它自己也看不出来。破法不是换个更贵的模型，而是引入不同源的判据——把人工标注过的历史变更做成黄金集，建议 200 到 500 条，覆盖已知缺陷与已知误报；每次换模型、改提示词、加规则，都在这套标注上跑回归，看漏检与误报往哪边动。校准之前值得先读一篇旧文的提醒："干净修复率 26%"这类公开基准本身就被质疑过，拿别人的分数当自己的目标容易跑偏。
一个反直觉的教训：门禁失败往往不是因为漏检太多，而是因为误拦太多。
把安全扫描里一条高误报规则直接升成阻断后，会出现三种典型规避行为——提交时带上跳过钩子的参数、把改动拆成多个小补丁混进无关变更、把要改的路径挪到覆盖面之外。开发者不是恶意，他们只是在"被拦四十分钟"和"按时交付"之间做了选择。
所以这类规则应该先在观察模式下跑够样本，统计每条规则被推翻的比例，再决定谁有资格升级到阻断。上线第一天就拦人的系统，通常熬不过一个季度。
如果这道关卡属于外包或合作交付的一部分，别在合同里写"使用了自动审查工具"，改成四个可测量的量：
四项都要写明采样窗口、统计口径和复核方式，否则验收会变成扯皮。外包交付里这类口径怎么和交付物对齐，站内有一篇从需求文档到验收的交付物与风控点梳理可以先看；想看门禁在真实项目里怎么落，翻案例库里的交付记录；想按团队人数、技术栈、合规要求反推阈值，直接走 联系我们 说明现状，我们给一份阈值建议表。
不能。它能替代"读一遍找低级问题"，替代不了"这个逻辑对不对、影响面能不能接受"。签发责任必须落到具体的人。
如果代码不能出内网、又已有多模型入口，自建更划算；它按命令行方式挂进流水线，成本主要在提示词与规则调优。团队没有专人维护规则时，把误报治理交给商业方案更现实。
先把高误报规则从阻断降级为建议或记录，再逐条统计推翻率，用数据决定谁能回到阻断层。
用黄金集反推：先测出当前的漏检与误报，再定一个在一个迭代内够得着的目标，别一上来就对齐行业标杆。
需要的不是全量规则，而是阻断级那几条：单测、密钥、许可证。其余等有专人维护时再上。