AI 评审能替代人工评审吗：分层看，别问要不要，要问哪一层

2026-07-28

数据截至 2026-07，各项目能力以官方文档当前版本为准。

“AI 评审能不能替代人工评审”这个问题本身问错了。代码评审不是一件事，而是四件性质完全不同的事叠在一个 PR 页面上：查机器能查的错、找经验型缺陷、判断设计意图对不对、以及由谁为这段代码负责。前两层 AI 现在确实能接走相当一部分工作量，第三层只能给提示，第四层压根不是技术问题。把这四层拆开，选型和流程设计就都清楚了。

常见的误解是把评审当成一个整体来押注：要么觉得”AI 都能看代码了，人工评审可以砍掉”，要么试用两天觉得”净是废话，还是得人看”。这两种判断都来自同一个错误——用某一层的体验去否定或肯定全部四层。AI 工具在第一层可能不如一个配好的 linter 划算，在第二层却能捞出人眼在深夜扫过去不会注意的空指针，在第三层大概率给不出有价值的意见。混在一起看，结论必然摇摆。

下面按这四层逐一说，最后落到一套可以直接搭的流程上。

一、第一层：机器规则层，AI 未必是首选

这一层指的是格式、命名、import 顺序、未使用变量、圈复杂度阈值这类有确定答案的检查。判断标准很简单：同一段代码跑十次，结果必须完全一样。

这一层的关键认知是：能用确定性工具解决的，就别交给模型。ESLint、Ruff、gofmt、Checkstyle 这类工具跑得快、结果稳定、不消耗任何调用额度，而且报错位置绝对准确。把这些交给 LLM，你付出的是等待时间和 token，换回来的是一个可能措辞更好听但偶尔飘忽的答案。

值得注意的是，现在做得比较认真的 AI 评审工具自己也承认这一点。阿里开源的 open-code-review 在仓库自述里把架构描述为**“确定性流水线 + LLM Agent 动态决策”两段结合**：文件筛选、规则匹配这些能写死的部分走确定性流水线，只有需要理解语义的部分才交给 agent。这个设计思路本身就说明，一个负责任的工具不会把机械检查也塞进模型里。

所以第一层的正确做法是：先把 linter 和格式化配齐并接进 CI，再考虑上 AI 评审。顺序反了，你会花钱让模型去做一件免费工具做得更好的事，还会让 AI 的评审意见被大量格式噪音淹没。

二、第二层：缺陷模式层，AI 的真正主场

这一层是有经验的人看得出、但需要注意力和上下文才能发现的问题：空指针风险、并发访问共享状态、未转义的用户输入、字符串拼接出来的 SQL、资源没关、异常吞掉。

这类问题的特点是”模式化但不机械”：它有典型形态，可静态规则很难覆盖全部变体，需要读懂这段代码在做什么。人能查出来，但人的检出率随疲劳程度大幅波动——PR 排到第七个的时候，谁都会开始只看 diff 的红绿。

open-code-review 在仓库自述中提到它有一套经过微调的内置规则集，覆盖空指针、线程安全、XSS、SQL 注入这几类。这个方向是对的：不追求”什么都能评”，而是把高频高危的几类做深。需要提醒的是，这套规则的实际检出效果是仓库自己的描述，目前没有可交叉验证的公开基准，你只能在自己的代码库上试跑之后判断。

同样来自项目仓库自述的还有一点值得留意：它称有独立的评论定位模块，用来解决通用 agent 常见的”位置漂移”和”覆盖不全”问题。这一条如果在你的项目上成立，价值其实不小——评审意见挂错行号是这类工具最劝退的体验之一，一条挂错位置的意见比没有意见更浪费时间，因为你得先花力气确认它到底在说哪。

这一层是我认为 AI 评审最值得投入的地方。它不替代人，但它能把人从”逐行扫 diff 找低级错误”里解放出来，让人的注意力留给下面两层。

三、第三层：设计意图层，AI 只能给提示

到了这一层，问题变成：这个抽象拆得对不对？这个新增的依赖有没有必要？这段逻辑是不是应该放在另一个模块？三个月后要改需求，这个结构是帮忙还是添乱？

这些问题没有唯一答案，取决于团队约定、历史包袱、产品路线图，甚至取决于某个模块下季度要不要重写。模型看到的只是 diff 和有限的上下文，它不知道你们上个月刚决定把这块下线，也不知道这个”重复代码”是团队故意保留的、因为两处的演化方向不同。

这一层 AI 能做的是提问而不是判断：指出”这段逻辑与另一处高度相似”、“这个函数承担了三类职责”这类观察。观察本身有价值，但把观察当成结论去执行，就会出现”为了消除重复而做出错误抽象”这种典型返工。

实操上的建议是：把 AI 在这一层的输出降级为参考项，不作为合并卡点。如果你的流程里 AI 意见能阻塞 PR，那阻塞规则只应该覆盖第二层里那些确定性较高的类别，设计类意见让人来定夺。

四、第四层：责任层，这不是技术问题

最后一层最容易被忽略：评审的一个核心功能是责任转移与知识扩散。批准合并的人对这段代码有了共同责任，看过这个 PR 的人知道了系统里多了什么。出事故的时候，“谁批的”是一个必须有答案的问题。

AI 无法承担这个角色，不是因为能力不够，而是因为责任这个概念不适用于它。哪怕某天它在第二层的检出率远超人类，“这段代码由 AI 批准合并”在事故复盘里依然不构成一个有效答复。

所以无论工具做到什么程度，PR 上的 approve 必须是人点的。AI 的产物是意见列表，人的产物是决定。把这条守住，前面三层怎么自动化都不会出结构性问题。

五、落地：一条分层的评审流水线

把上面四层翻译成流程，大致是这样一条链路：

提交前：本地跑格式化和 linter，机器规则层就地解决，不带进 PR。
推送后 / PR 打开时：CI 里跑 AI 评审，输出行级意见，聚焦缺陷模式层。
人工评审：人不再逐行找空指针，而是集中看设计意图、边界条件、这个改动值不值得做。
合并：由人 approve，AI 意见作为参考记录留在 PR 里。

如果用 open-code-review 来占第 2 步，仓库给出的上手路径是全局安装后做交互式配置：

npm install -g @alibaba-group/open-code-review

ocr config provider          # 选 LLM 供应商
ocr config model             # 选模型
cd your-project
ocr review                   # 评审已暂存/未暂存的改动

配置流程会引导你选供应商、填 API key，并自动做一次连通性测试。模型侧，仓库自述兼容 OpenAI 与 Anthropic 两种接口格式，具体可用的模型名以你所选供应商的官方文档当前版本为准。

除了默认的 diff 评审，仓库还列了几种模式，对应不同场景：

ocr review --from main --to feature-branch    # 分支对比
ocr scan --path internal/agent                # 整文件审计
ocr delegate preview                          # 由 AI agent 执行评审

分支对比适合在 PR 层面一次性看完整改动；scan 是整文件审计，适合接手一个陌生模块时先摸一遍底，这和评审 diff 是两种不同用法，别混着用——整文件扫描的输出量会大得多。

CI 集成方面，仓库列出的是 GitHub Actions、GitLab CI、GitFlic CI、Gerrit 这四个。如果你的团队用的是其他平台，需要自己按 CLI 的方式接，官方列表里目前就这四项。

六、关于厂商自述数字，怎么读才不会被带偏

这类工具的宣传里总会有几个亮眼的数字，open-code-review 也不例外。项目仓库自述称它在阿里内部被”数万开发者”使用、发现过”数百万个代码缺陷”，并称在保持更高精度的同时，token 消耗约为 Claude Code 的 1/9。

这几个数字应该怎么看？

第一，它们都是项目自己的口径，不是第三方复现的结果。规模数字无从核对，1/9 这个比值也是仓库自己设定的基准条件下测出来的——用什么代码库、评审什么规模的 diff、对比时两边的配置是否对等，这些都会大幅改变结果。

第二，不要用它做”比某某工具强”的结论。AI 评审这个赛道目前没有一个各家都认的公开基准，Copilot 的 code review、CodeRabbit 这类工具同样只有各自的说法。跨工具比效果，现阶段只能比机制差异（架构怎么设计、定位怎么做、支持哪些 CI），比不了效果数字。

第三，成本这件事你可以自己测。跑十个真实 PR，记录调用消耗和你实际采纳的意见条数，算出”每条有效意见的成本”。这个数比任何厂商基准都更贴近你的实际情况，做起来也就半天。

七、诚实说局限

需要提前知道的几件事：

AI 评审对大 PR 的效果衰减明显。一个改了四十个文件的 PR，无论人还是模型都很难给出有质量的意见。想让工具发挥作用，先把 PR 拆小，这个前提比选哪个工具重要得多。
误报是必然的，要提前想好怎么处理。如果每个 PR 都挂着五条模型提出但实际不成立的意见，团队很快会养成整体忽略的习惯，工具就等于白装。可行的做法是初期只开启信噪比最高的几类规则，跑顺了再逐步放开。
上下文边界决定上限。工具看到的通常是 diff 加有限的关联文件，跨服务、跨仓库的隐含约定它看不到。凡是需要”知道另一个系统怎么用这个接口”才能判断的问题，都别指望它。
私有代码送给外部模型这件事要走合规流程。开源的是 CLI 工具本身，模型调用仍然发往你配置的那家供应商。企业环境下这一步该怎么审批、能不能用，要按你们自己的规定来，不是技术选型能绕开的。

小结

代码评审拆开是四层：机器规则、缺陷模式、设计意图、责任归属。第一层交给 linter 更划算，第二层是 AI 评审工具当前最有价值的位置，第三层它只能提问、不能定论，第四层与它无关。open-code-review 这类工具值得试，但要按第二层的定位去用，先拆小 PR、先收窄规则、先在自己的代码库上跑十个真实案例。厂商自述的规模和成本数字可以当作了解项目的背景，不适合当作选型依据——真正能说服团队的，是你自己测出来的那条”每条有效意见成本”。最后一条不会变：approve 按钮由人来点。