上周审查一个 AI 生成的 PR，工具扫完给了全绿：无空指针、并发安全、错误处理完整、命名规范。

但我越看越不对。

这段代码在给一个用户偏好配置项加缓存层。用户偏好这种东西，一个月改一次算频繁的，每次请求也只在会话开始时读一次。加缓存层的收益约等于零。而真正的性能瓶颈在写入路径——批量更新用户偏好时数据库压力大。AI 生成的代码完美地优化了一个不需要优化的地方，同时完美地忽略了真正的问题。

代码没有一行是错的。但整个方向错了。

AI 在代码层的审查能力已经很强——格式、安全漏洞、空值检查这类机械性问题，覆盖能力远超人类。但一旦涉及业务逻辑和架构合理性，AI 的表现断崖式下跌。“这段代码该不该存在"这种问题，AI 连问都不会问。

所以真正的问题不在 AI 会不会取代 Code Review。而是你的 Review 时间花在了哪一层。

一、AI 已经赢了——在代码层

Google 2025 年在 ICSE 发表的内部代码审查研究（Vijayvergiya et al., 2025）显示，AI 生成的审查评论被开发者接受的比例（42%）和人类评论（38%）已经非常接近。4 个百分点的差距算不上碾压——而且 AI 处理的主要是格式和常见缺陷类评论，难度本身就比人类处理的设计类评论低。但配合另一个数字看就清楚了：引入 AI 预审查后，人类审查者平均每次审查时间减少了 12%。机械性检查上，AI 已经在帮人省时间了。

多项学术研究也给出了一致的方向。其中一项覆盖了 1200 个 PR 和 40 个开源项目的研究数据比较有代表性：

单看 AI 独立审查的 62%，确实不如人类的 71%。AI 独立跑并不能替代人。但关键数字是最后一列：AI + 人类协作的 89%——比任何一方单独都高。这说明 AI 补上了人类审查的盲区，而不只是重复人类已经能做的事。更重要的是审查周期——从 26 小时压缩到 8 小时，AI 在代码层帮人类省下了大量机械性检查时间。

你大概也有体会：连续审查三四个 PR 之后，最后一个你基本是在"扫"而不是在"读”。审查质量随时间衰减，这是认知负荷的客观限制。AI 不会有这个问题——它审第一个 PR 和第一百个 PR 的质量一样。

有意思的是，截至 2025 年，Google 自己依然要求每行代码经过人类审查。但他们内部的数据显示，人类审查者的关注点已经在转移。AI 接手了格式、命名、常见缺陷这些机械性检查之后，人类留下的评论越来越集中在设计合理性和方案选择上。这不是 Google 刻意推动的变革，是 AI 能力到了那个水平之后自然发生的。

二、AI 看不见的大半

回到那个缓存层。

你的团队在做一个用户偏好服务。有人用 AI 生成了一段缓存逻辑——TTL 控制过期，读取时先查缓存再查数据库。代码写得很标准，是你在任何教程里都能看到的写法。

AI 审查工具扫了一遍，报告很漂亮：无空指针风险，并发安全，过期逻辑正确，数据库查询有错误处理，命名符合规范。如果你团队用了自动化审查流水线，这个 PR 大概率直接进入"待合并"队列。All Clear。

但一个有系统上下文的人会追问三个问题。

用户偏好多久变一次？几乎不变，一个月改一次算频繁的。一次请求读几次偏好？一次，会话开始时加载，整个会话复用。性能瓶颈在哪？在写入路径——批量更新偏好时的数据库压力，不在读取路径。

三个问题问完，结论就出来了：这个缓存层不该存在。读取频率低、数据几乎不变、瓶颈不在读——三个条件都不支持加缓存。AI 却往读取路径加了一层完全不需要的抽象，而真正该优化的写入路径没人碰。

这是 AI 审查的边界。

AI 擅长发现机械性缺陷——一个未关闭的资源、一个缺少的空值检查、一个有竞态风险的并发写入。这些问题有明确的模式，AI 可以通过模式匹配高效检出。但"这段逻辑在业务上说不说得通"，它几乎无能为力。

架构合理性更弱。AI 能检出一些有明确模式的架构问题（比如 N+1 查询、循环依赖），但它判断不了"在我们当前的阶段，引入消息队列是不是过度设计"。这个判断需要知道业务量的数量级、团队有没有运维消息队列的经验、产品未来半年的扩展计划——这些信息全在代码之外。

至于"这个 PR 解决的是不是对的问题"——AI 完全没有这个判断能力。它能判断代码"写得对不对"，但判断不了"该不该写"。

根源在上下文。AI 看到的是 diff，人看到的是 diff 背后的系统、团队、业务目标。虽然 AI 审查工具已经在尝试接入架构文档和 ADR，但效果还远不够。真正决定一个 PR 方向对不对的，往往是那些只存在于人脑中的隐性知识——为什么上次选了这个方案、某个模块为什么不能碰、产品下个季度要往哪走。这些知识有的可以文档化（比如 ADR），有的变化太快写下来的成本比口头同步高得多。

而恰恰是这些知识，决定了一个 PR 的方向对不对。

三、三层升维——你的 Review 在看哪一层？

代码审查保护的东西在变。我把它分成三层。

代码层——对不对。 语法、安全漏洞、空值、并发、性能反模式。前面说过了，这是 AI 的主场，不再展开。

架构层——合不合理。 关注的是技术方案内部的合理性：设计模式选择、模块耦合度、职责划分、是否引入了不必要的复杂度。AI 能发现一些有明确模式的问题，但对"这个设计选择在我们的上下文中合不合理"几乎无能为力。

为什么架构层这么难？因为"合理"没有绝对标准。同样是引入一个中间层，在一个 3 人团队的早期项目里是过度工程，在一个 20 人团队的成熟服务里是合理解耦。AI 看不到团队规模，看不到项目阶段，看不到上下游依赖关系。它能告诉你这个抽象层的接口设计有没有问题，但告诉不了你这个抽象层该不该存在。

意图层是最容易被忽视的一层——该不该做。 关注的不再是技术方案本身，而是整个 PR 的存在价值：这个 PR 解决的是不是对的问题？值不值得这个复杂度？有没有更简单的替代方案？

AI 审查代码是否存在，人审查代码是否应该存在——这两个问题之间隔着一整个认知维度。

用一个简化的场景来感受差异。

有人提了一个 PR：重构订单服务，引入事件驱动架构。代码层审查（无论人还是 AI）发现了几个空值遗漏和竞态条件，结论是修复后可合并。

但如果你往上看一层。当前业务量不大，团队也没有消息队列的运维经验。事件驱动在这个阶段属于过度设计——你在为一个还没到来的规模问题预支复杂度。更重要的是，引入消息队列意味着团队要学习一整套新的运维技能：消息积压怎么处理、消费者挂了怎么办、消息顺序如何保证。这些隐性成本，代码层审查一个也看不到。

再往上看一层。这个重构要解决什么？“提升订单处理速度”。瓶颈真的在架构吗？查了一下——瓶颈在一个内部服务的同步调用链路上。把那个同步调用改成异步回调，处理时间从秒级降到毫秒级。

结论翻转了：不应该合并。方向错了。真正的修复是调整调用方式，不是重构整个架构。几百行的重构白写了，几个月的运维债也不用背了。

当然，意图层审查不保证每次都对——你可能判断错瓶颈所在。但它确保你至少问了对的问题：“这件事该不该做？“不问这个问题的 Review，默认方向是对的——而方向错误恰恰是代价最大的那类错误。

有人可能会说，好的工程师一直在做架构和意图层的审查，这不是什么新鲜事。没错。区别在于：以前人类审查者要同时兼顾三层，认知带宽被代码层大量消耗。当 AI 接管了代码层，人类第一次有了把全部注意力放在架构层和意图层的条件。三层升维不是发明了新东西，是 AI 让人类第一次有机会把该做的事做到位。

四、怎么升维

说了三层模型，落到实操上怎么做？

代码层交给 AI。配置好审查工具的规则——安全策略、代码风格、性能反模式。定期抽查它的输出，校准而非逐行复查。先让 AI 跑一遍生成报告，人只看它标记为"需要人类确认"的项目。

这一步最大的心理障碍是"万一 AI 漏了怎么办”。AI 会漏，人也会漏。前面的数据说得很清楚：AI 独立 62%，人类独立 71%，但 AI+人协作 89%。协作模式下两边互补盲区，比任何一方单独都强。你不需要 100% 信任 AI，你只需要把它当成一个不会疲劳的第一轮筛查员。

架构层的关键是问对问题。举个例子：有人在 PR 里把一个内部调用改成了 gRPC 微服务。架构层审查不是看 proto 文件定义对不对——那是代码层的事。架构层要问的是：这两个模块之间的交互频率是多少？拆成独立服务后部署复杂度增加了多少？团队有没有运维微服务的经验和基础设施？如果答案是"交互频率高、团队没有服务网格、当前单体完全扛得住”，那拆分就是过度设计。

架构审查不需要你是架构大师，但需要你有系统上下文——知道这个模块和其他模块怎么交互，知道团队的技术栈边界在哪，知道当前阶段的约束条件是什么。很多团队的架构问题不是某个人设计得差，而是没人在 Review 时问"我们真的需要这个复杂度吗"。

意图层只需要三个问题：这个 PR 解决的是不是对的问题？有没有更简单的方案？投入和产出匹配吗？

听起来简单，难的是跳出代码的视角。怎么训练这种意识？一个实操习惯：每次打开 PR 页面，强迫自己先读标题和描述，而不是直接滚到 diff。标题和描述是 PR 的"意图声明"——如果标题都说不清楚这个 PR 要解决什么问题，代码写得再好也该打回去。

三层不是每个 PR 都要走一遍。小改动（修 typo、更新依赖版本）代码层 AI 扫完就够了。但凡涉及业务逻辑变更、架构调整、新模块引入的 PR，架构层和意图层就不能省。判断标准：这个 PR 如果方向错了，返工成本有多大？返工成本越高，越值得在意图层多花时间。

升维不只是个人意识转变，它需要团队文化支持——允许你在 Review 时说"这件事该不该做"而不会被认为越权。在很多团队里，质疑 PR 的存在意义比质疑代码的实现方式困难得多。一个可行的起步方式：在 PR 模板里加一个必填字段——“这个 PR 要解决什么问题？有没有考虑过更简单的方案？“把意图层审查从依赖个人意识变成流程保障。

意识是第一步，文化是土壤。

PR 没有死，但你的 Review 可能该升级了。

下次审查 PR 的时候，先滚动到最上面，看一眼标题和描述。问自己：这件事该不该做？

这个问题，AI 回答不了。