AI 助手的代码审查能力，能替代 Code Review 吗

AI 助手的代码审查能力，能替代 Code Review 吗

从 GitHub Copilot Workspace 的翻车现场说起

今年 3 月，GitHub 把 Copilot Workspace 推到了公测阶段，宣传口径很响亮：自然语言描述需求，AI 自动规划、编码、测试、提交 PR。我盯着那个 demo 视频看了三遍，视频里演示者输入 "给这个 React 组件加上深色模式支持"，AI 噼里啪啦生成了一堆文件变更，包括测试用例。评论区一片 "CR 已死" 的欢呼。

两周后，我在一个私人 Telegram 频道里看到了真实的用户反馈。某个用了 Workspace 生成 PR 的团队，合并后线上崩溃，根因是 AI 把 useEffect 的依赖数组写漏了，而自动生成的 "测试" 根本没覆盖到组件挂载后的状态变更。这个 bug 不是复杂逻辑错误，是 React 新手都会犯的依赖缺失，但 AI 生成的代码审查环节——Copilot 自己的 review 功能——标记了 "LGTM"。

这个案例特别讽刺，因为它触及了 AI 代码审查的核心盲区：AI 能检测出明显的语法错误、未使用的 import、简单的空指针风险，但它对"这段代码在真实运行时的语义是否正确"几乎毫无感知。useEffect 依赖数组漏写，代码能编译，能跑通 AI 自己生成的单元测试（如果测试本身就不触发那个分支），静态分析工具也报不了错。只有人，在 review 时看到 useEffect(() => { ... }, []) 这个空数组，结合业务上下文，才能判断"这里是不是故意只在挂载时执行一次"。

GitHub 后来悄悄把 Workspace 的 beta 标签从 "ready for production" 改成了 "experimental"，没发公告，只是改了文档角落的一行字。这种小动作比任何技术白皮书都诚实。

Copilot Chat 的 review 功能，我实测了两个月

Copilot Chat 在 2023 年底上线了 /review 指令，宣称可以对整个 PR 做分析。我特意挑了两个项目做对比测试：一个是公司内部用了三年的 Kotlin 业务代码，另一个是开源的 Retrofit 仓库的某个历史 PR。

对 Kotlin 项目的测试，我选了一个真实的业务 PR，改动量 400 行，涉及协程作用域管理和 Room 数据库迁移。Copilot Chat 的 review 结果分三类：安全提示（检测到 GlobalScope 使用，建议改用 viewModelScope）、风格建议（某处可以用 ?.let 替代 if-null 检查）、以及完全错误的"优化建议"——它让我把 suspend fun 改成普通函数，理由是"没有调用其他 suspend 函数"，但实际上这个函数内部调用了 dao.insert()，而 Room 的 DAO 方法在 KSP 生成的代码里才是 suspend 的，Copilot 的静态分析没走到那层。

这个误报暴露了一个结构性问题：AI 代码审查工具的训练数据主要是公开代码，对使用了代码生成（KSP、KAPT、DataBinding、甚至 Jetpack Compose 的 Compiler Plugin）的项目，AI 看到的源码和实际编译后的语义之间存在断层。它审查的是"我看到的代码"，不是"编译器看到的代码"。

Retrofit 的测试更有意思。我选了 Square 官方仓库的一个旧 PR，改动是添加对 Kotlin Result 类型的适配器支持。Copilot Chat 的 review 给出了 12 条建议，其中 3 条是合理的（测试覆盖率可以更高、文档注释缺失），4 条是无关痛痒的格式问题，剩下 5 条是错的——包括建议"用 try-catch 替代 runCatching"，而 PR 的核心目的就是封装 Result 类型，避免异常抛出。这个建议如果采纳，会直接破坏 PR 的设计意图。

两个月测下来，我的体感是：Copilot Chat 的 review 对"明显违背社区共识的代码"有一定捕捉能力，比如 Java 里用 == 比较字符串、Kotlin 里混用 !! 和 ?. 的随意风格。但对"这段代码是否实现了 PR 描述里声称的目标"，对"这个设计选择和项目整体架构是否一致"，基本无能为力。它像是一个看过很多代码的实习生，能指出"这里别人一般不这么写"，但回答不了"这么写在这个场景下对不对"。

Google 的 Gemini Code Assist，企业级的幻觉

Google 在 2024 年 I/O 上大力推了 Gemini Code Assist，特别强调企业级场景，包括和内部代码库的集成、基于公司编码规范的审查。这个卖点很精准，因为 Copilot 的通用训练数据确实覆盖不到企业内部的框架和约定。

但企业级审查有个致命前提：AI 需要理解企业的私有代码库。Google 的解决方案是"代码索引"，让 Gemini 先 ingestion 你的整个仓库，然后基于 RAG（检索增强生成）做审查。这个架构在理论上合理，实际落地时我听到了多个团队的吐槽。

某国内大厂的一个 Android 基础架构组试了 Gemini Code Assist 的 Enterprise 版本，他们的仓库有 200 万行 Kotlin/Java 混合代码，自定义了 17 个 Gradle Plugin，内部 RPC 框架和开源的 gRPC 接口相似但语义不同。Gemini 的审查结果里，频繁出现"建议使用 gRPC 的 ManagedChannel"来替代他们的内部 RpcChannel，因为训练数据里 gRPC 更常见。更麻烦的是，AI 会把内部某个类的命名和开源库里的同名类混淆，给出完全错误的类型安全建议。

这个团队最后把 Gemini 的审查功能降级为"仅对开源依赖库做安全漏洞扫描"，核心的业务逻辑 review 还是回到了人工。他们算过一笔账：AI 审查一条 PR 平均产生 8.3 条建议，其中 2.1 条有用，3.7 条是误报需要人逐一确认，2.5 条是危险的错误建议如果采纳会引入 bug。人工过滤这些建议的时间，比直接人工 review 还长。

Google 的文档里有个细节：Gemini Code Assist 的代码索引对单文件大小有限制，超过 2MB 的文件会被截断。这个阈值对普通业务代码够用，但遇到 Protobuf 生成的 Java 类、或者大型 R.java 风格的资源索引文件，AI 看到的是残缺的上下文。没人告诉用户"这段审查建议是基于不完整代码生成的"，界面上的置信度评分依然显示"高"。

静态分析工具的黄昏，还是 AI 的互补？

有人把 AI 代码审查和传统的静态分析工具（SonarQube、Detekt、Android Lint）对立起来，认为 AI 会取代后者。这个判断我不同意，至少在当前的技术代际里不成立。

去年 JetBrains 的 Qodana 团队发了一个技术博客，对比了他们的 AI 审查和规则引擎的互补性。数据很直白：在 Kotlin 代码库上，传统规则引擎对"空安全违规"的检出率是 94%，AI 是 67%；但对"这段异常处理是否覆盖了所有业务场景"这类需要语义理解的问题，规则引擎是 0%，AI 是 31%。31% 不算高，但确实是传统工具完全无法触及的维度。

这个互补关系意味着，AI 审查现在最好的定位是"静态分析的增量补充"，而不是替代。但市场上的产品叙事都在往"智能替代"走，因为"补充"卖不上价。Copilot 个人版 10 美元/月，企业版 39 美元/月，如果只说"帮你多检出 30% 的规则引擎漏报"，ROI 很难算；但说"替代你的 Code Review 人力"，CTO 的预算审批就松动了。

这个商业叙事和实际能力的落差，正在制造一批"AI 审查形式主义"的团队。我见过最极端的案例：某创业公司把 AI 审查的"通过"作为合并门禁，人工 review 变成可选流程。三个月后他们的 crash 率上升了 400%，根因是 AI 没识别出一个多线程竞态条件——代码里用了 volatile 变量做状态标志，AI 看到 volatile 就标记了"线程安全已处理"，但实际上 volatile 只保证可见性不保证原子性，复合操作 if (flag) { flag = false; } 仍然需要同步。

这个 bug 的讽刺之处在于，传统的 FindBugs/SpotBugs 规则里其实有 VO_VOLATILE_INCREMENT 这类检测器，虽然命名是针对增量操作，但规则引擎的抽象语义分析能覆盖类似的复合操作。AI 审查反而因为"理解"了 volatile 的字面含义，做出了错误的语义推断。

代码审查的本质，是知识传递还是缺陷拦截？

讨论 AI 能不能替代 Code Review，需要先澄清 Code Review 到底在干什么。很多人默认它的目标是"拦截 bug"，这个定义太窄了。

Google 的 Engineering Practices 文档里对 Code Review 的定义是："确保代码库的健康性和一致性，同时帮助开发者成长。" 健康性包括可维护性、可测试性、架构一致性；开发者成长指的是通过 review 反馈传递领域知识、编码技巧、项目历史上下文。这两件事里，AI 目前只能勉强触及第一层的一部分，第二层完全无法参与。

一个具体的场景：Android 开发里处理后台任务，新手可能写 AsyncTask（虽然已废弃但在老代码里常见），或者用 WorkManager 但选了错误的约束条件（要求网络连接却在 doze 模式下无法触发）。有经验的 reviewer 看到这段代码，会追问"这个任务如果用户切到后台、系统杀进程、然后网络恢复，预期行为是什么"，然后引导开发者去测 setExpedited 和 setConstraints 的组合。这个对话过程里，reviewer 传递的不是"这行代码错了"，而是"这个领域有哪些边界情况你需要考虑"。

AI 审查能指出 "AsyncTask is deprecated, use WorkManager instead"，但它不会追问那个后续的设计问题。更关键的是，它不会知道你们团队上个月刚踩过 setExpedited 在 Android 12+ 上的行为变更坑，这个知识只存在于人的记忆里，或者某个没写进文档的 Slack 线程里。

我在一个 Kotlin 技术群里看到过一段真实的 review 对话，关于 Flow 的收集时机：

Reviewer: "这个 flow.collect 写在 onResume 里，但 lifecycleScope 的取消是在 onDestroy。如果用户快速切换页面，上一个页面的收集可能还没取消，新页面又开始收集，内存里会有两个相同的数据流。"

>

Author: "但 lifecycleScope 不是绑定到 DESTROYED 吗？"

>

Reviewer: "是，但 collect 是挂起函数，它不会自动在 onPause 取消。你需要用 repeatOnLifecycle(Lifecycle.State.STARTED)，这个我们去年在订单列表页踩过坑，当时导致了内存泄漏，见 #4723。"

这段对话里的知识密度，包括 lifecycleScope 的具体生命周期绑定点、collect 的挂起特性、repeatOnLifecycle 的存在、以及团队历史踩坑记录和关联 issue，没有任何 AI 审查工具能在当前技术条件下还原。Copilot 可能会建议 "use lifecycleScope"，但给不出 #4723 的上下文；Gemini 如果索引了全仓库，可能能关联到那个 issue，但前提是 issue 的描述足够清晰、且 AI 能正确理解"订单列表页的内存泄漏"和"当前这个 PR 的数据流收集"是同类问题。

那些 AI 审查确实做得好的角落

我不想把 AI 代码审查说成一无是处，那不符合我实际使用的体验。有几个特定场景，AI 确实比人更可靠。

第一是安全漏洞的模式匹配。GitHub 的 CodeQL 和 Copilot 的 security feature 对 SQL 注入、XSS、硬编码密钥的检测，基于的是大量 CVE 和漏洞模式的训练。人 review 时容易看漏的 String.format("SELECT * FROM users WHERE id = %s", userId)，AI 能稳定标记，因为它不需要理解业务语义，只需要匹配"字符串拼接进 SQL"这个危险模式。这个场景下，AI 的零漏报率（相对人的注意力波动）是真实价值。

第二是跨语言/跨框架的 boilerplate 检查。比如 Android 项目里 Kotlin 调用 C++ 的 JNI 代码，人的 review 通常只关注自己熟悉的那一侧，AI 可以同时看 Kotlin 的 external fun 声明和 C++ 的 JNIEXPORT 实现，检查签名是否匹配。这个工作枯燥、容易出错、且需要跨文件跳转，AI 的耐心优势很明显。

第三是历史代码的增量审查。大型仓库里，某个 PR 改了 5 行代码，但触发了一个 10 年前写死的假设。人 review 时往往只看 diff 的 5 行，AI 如果做了全仓库索引，能追溯这个假设的依赖链。Google 的 internal study（Mondrian 系统相关论文里提到过）显示，这种"跨时间维度的关联"是 AI 相对人的显著优势，虽然准确率还不高，但能提示人去看那些本来不会注意到的文件。

但这些优势场景有个共同点：它们都是"已知模式的应用"，不是"未知问题的发现"。AI 擅长的是"我见过这种 bug，这段代码像它"，不是"这段代码引入了一种新的、我们团队没见过的风险模式"。而 Code Review 最有价值的部分，恰恰是后者——尤其是系统架构演进时，新的设计模式带来的隐性约束。

为什么 "AI 替代 CR" 的叙事能持续升温

技术能力的局限是一回事，市场叙事是另一回事。2023-2024 年的融资环境和裁员潮，共同推动了"用 AI 降本增效"的迫切需求。Code Review 作为工程流程里"明显消耗人天"的环节，自然成为 AI 替代叙事的目标。

这个叙事有个隐含的假设：Code Review 的成本主要是" reviewer 的时间"，而 AI 的时间近似免费。但实际成本结构更复杂。一个需要人工逐条确认 AI 建议的 review 流程，消耗的是 author 和 reviewer 的双重时间；一个采纳了 AI 错误建议导致线上事故的修复成本，可能远超省下来的人力。这些隐性成本在采购决策时很难量化，而"减少 50% review 时间"的 KPI 很容易量化。

我观察到一个现象：鼓吹"AI 替代 CR" 最积极的，往往是没经历过大型项目维护的决策者。真正维护过 5 年以上代码库、处理过历史技术债务的工程师，对 AI 审查的态度普遍保守。这个分化不是技术理解力的差异，是成本核算的维度不同——前者算的是"这个季度的 engineering efficiency metric"，后者算的是"这段代码三年后我还能不能看懂、能不能安全修改"。

Anthropic 的 Claude 团队在 2024 年初发过一个内部使用 AI 辅助 code review 的反思，没发正式博客，是 CEO Dario Amodei 在某个播客里提到的。他说 Claude 生成的 review 建议，他们团队采纳率大约 15%，但"这 15% 里有 1/3 是采纳后需要二次修正的"。这个坦诚的数字和市场上"AI review 准确率 90%+" 的宣传形成对照。注意，Claude 是公认代码能力最强的模型之一，如果连 Anthropic 自己的使用体验都这样，其他产品的实际数字只会更难看。

一个被忽视的维度：审查的社交契约

Code Review 不只是技术活动，是团队内的社交契约。这个维度几乎被所有 AI 审查产品忽略。

当一个 junior developer 提交 PR，senior reviewer 花 20 分钟写详细的反馈，指出设计模式的选择、解释为什么这里要用 sealed class 而不是 enum，这个交互在传递技术判断标准。即使 AI 能生成同样内容的文本建议，它无法替代"一个具体的人认可/质疑你的技术决策"这个社交确认过程。人对 AI 建议的心理接受度，和对同事建议的接受度，机制完全不同——前者是"一个工具在挑错"，后者是"社区在帮我成长"。

这个差异在开源社区更明显。Linux Kernel 的 review 文化、Android Open Source Project 的 Gerrit 流程，核心不是缺陷拦截效率，是社区成员通过 review 建立技术信任、形成共识。Linus Torvalds 的骂人邮件（虽然风格争议很大）本质上是一种强社交信号：某些设计选择在这个社区里是不可接受的。AI 审查的温和建议，无法替代这种边界划定。

有些团队试图用"AI 初筛 + 人做终审"来兼顾效率和社交，但实际操作中往往变形。我见过一个团队的流程：AI 审查通过后，人的 review 变成"快速扫一眼"，因为"AI 已经看过了"。这个心理替代效应，让终审的质量大幅下降。更隐蔽的是，AI 的误报让人产生"审查疲劳"，对真正重要的建议也习惯性忽略。

回到问题本身：能替代吗？

我的明确观点：不能，至少在可见的未来不能。AI 代码审查是工具箱里的新工具，不是 Code Review 的替代品。

具体说，替代不了的核心原因有三层：

第一层是技术能力的天花板。当前大语言模型对代码的理解，停留在"统计关联"层面，不是"因果推理"和"运行时语义模拟"。它能说"这段代码像有 bug 的代码"，不能说"这段代码在用户的具体设备、具体网络条件下会出什么问题"。而 Code Review 的终极价值，正是对"代码在真实世界运行时的行为"做预判。

第二层是知识形态的错配。团队的历史经验、隐性约束、架构演进中的临时妥协，这些知识大量以非结构化形式存在（Slack 讨论、会议记录、甚至某个老员工的大脑皮层）。AI 的 RAG 索引能覆盖文档化的部分，但文档化的知识永远是子集。Code Review 是人把未文档化的知识注入决策过程的最后防线。

第三层是工程伦理的责任归属。如果 AI 审查通过了一个导致数据泄露的 PR，责任算谁的？工具厂商的条款里全是免责。Code Review 作为工程流程，背后是明确的责任链条：reviewer 签字，意味着"我用我的专业判断担保这段代码可接受"。这个担保不能转嫁给概率模型。

我最后的建议是：把 AI 审查当作"一个永不疲倦的初级 reviewer"，它能帮你扫一眼 obvious issues，但别指望它做 architectural review、别让它成为合并门禁的单一依赖、更别因为用了 AI 就压缩人工 review 的时间预算。省下来的时间，应该花在更深度的设计讨论上，而不是开更多会。

那些宣称"AI 替代 Code Review" 的产品，你去看它们的客户案例，找得到哪个团队公开说"我们完全取消了人工 review、且质量指标提升"的吗？找不到的。能找到的，都是"review 效率提升 X%"——而效率提升的算法，通常是 "(AI 建议数 + 人工建议数) / 人工 review 时间"，这个分母变小、分子变大，指标自然好看，但和实际代码质量的关系，没人敢拍胸脯。

所以，下次有人再跟你说"我们上了 AI 审查，可以减两个 reviewer HC"，你可以反问：你们 AI 审查的采纳率多少？采纳后的回滚率多少？同一个 PR，AI 和人工 review 的重叠建议占比多少？这些数字，比任何产品 demo 都诚实。

真正的好代码，是人对人的责任传递。AI 可以辅助这个传递，但替代不了传递本身。