AI时代的代码审查能力：工程师的新护城河

📰 科技要闻

• 美银喊出白银百元目标价但同时警示，光伏"去银化"成为银价持续上涨的最大阻力。

• AI 内容共创平台 FunloomAI 完成数千万元 Pre-A 融资，估值达 2 亿元。

• 微信小游戏月活跃用户超 5 亿，小游戏成为内容消费新增长点。

上周给团队新人 review 一段 Cursor 生成的代码。功能跑通了、单测过了、自测也没问题。代码风格甚至比他平时手写的还工整。我看了大概 5 分钟，问了他一个问题："你这里为什么 catch 了异常之后只打了 log 就吃掉了？"

他愣了一下："AI 给的就是这么写的，我以为是标准做法。"

这就是问题。那段代码里的 try-catch 把一个本来应该让上层感知的业务异常给静默吞了，下游链路如果出错，监控不会告警、用户不会重试、数据可能就这么悄悄丢了。Cursor 没错，它生成的是"语法上能跑通"的代码；新人也没错，他确实没经验判断这个 catch 该不该写。错的是这个 review 链路——AI 输出的代码进到主干之前，没有人真正"看懂"它在做什么。

这事儿之后我琢磨了挺久，越想越觉得：AI 时代工程师最值钱的能力，不再是写代码的速度，而是看懂代码、判断代码、否决代码的能力。换句话说，code review 从一个团队协作环节，正在变成工程师的核心壁垒。

一、AI 写代码的速度，重构了"工程师的产出曲线"

先聊一个我自己的体感对比。

过去我做一个中等复杂度的功能（比如一个带缓存、带重试、带指标上报的 HTTP Client 封装），从设计到写完大概要 1-2 天。现在用 Cursor + Claude，我能在 30 分钟内拿到一个 80% 可用的初稿。但接下来的事儿才是关键——剩下的 20% 我要花的时间，跟以前手写后期调试的时间几乎一样长。

这 20% 包括：

• 检查它的异常处理是不是符合我们业务的容错策略 • 看它的日志埋点是不是覆盖了关键路径 • 验证它的并发控制（线程池、协程作用域）有没有竞态 • 确认它的接口设计跟我现有架构是不是兼容 • 排查它"看起来对但其实有 bug"的边界情况

说白了，AI 把"写出能运行的代码"这件事的成本压到了接近 0，但"写出能上生产的代码"这件事，门槛反而升高了。因为以前你写代码是 1 行 1 行写的，每写一行你都在思考；现在 AI 一次给你 100 行，你要在 100 行里找出那 5 行隐藏的雷。

"看懂"比"写出"难得多

我之前一直觉得 review 别人的代码比自己写要轻松，因为你只是在评审，不需要从零构造。AI 时代这个直觉彻底反了。

当代码是你自己写的，每一行的意图、每一个变量的来源你都清楚，bug 一般出在你没考虑到的边界。但当代码是 AI 写的，整段逻辑对你来说都是"陌生输入"——你得反向推理：它为什么这么设计？这个变量从哪来？这个分支保护的是什么场景？

这是个完全不同的认知负担。我现在 review AI 代码的标准动作是：

// 第 1 步：通读全文，
// 不看细节，先建心智模型
// 这段代码大概在做什么？
// 输入是什么？输出是什么？// 第 2 步：找异常路径
// 所有 try-catch、null 判断、
// 返回 null/默认值的地方
// 都问一遍：被吞的异常
// 上层怎么知道？// 第 3 步：找资源管理
// 文件、连接、线程池、
// 锁、订阅，
// 都问一遍：谁来释放？// 第 4 步：找并发点
// 所有共享变量、
// 异步回调、
// 协程作用域，
// 都问一遍：竞态可能吗？// 第 5 步：对照业务上下文
// 这个 catch 吃掉异常
// 在我们业务里合理吗？
// 这个默认值会不会
// 误导下游？

这五步走下来，30 分钟 review 出来的问题，往往比我自己写 2 小时碰到的坑还多。AI 不会跳过任何"看起来该写"的代码，但它也不会判断"这段代码不该写"。

二、AI 代码的典型陷阱地图

review 多了，你会发现 AI 生成代码的"坑"其实是有规律的，而且这些规律和它的训练机制高度相关。我整理了几类最高频的坑，列出来给你做个 checklist：

最阴的坑：单测和实现一起错

这个我必须单独说一下。AI 写代码的时候，如果你让它"顺便写一下单测"，它经常会犯一个非常隐蔽的错误：单测和实现的预期是同时按照它的（错误）理解来写的。

举个真实例子。一段处理订单状态流转的代码，业务规则是"已退款的订单不能再发货"。AI 写完之后单测全部通过，但 PR review 的时候我发现：

// 实现（错的）
fun canShip(
order: Order
): Boolean {
// 应该是 != REFUNDED
return order.status
== Status.REFUNDED
}// 单测（也错的）
@Test
fun refundedCanShip() {
val order = Order(
status = Status.REFUNDED
)
// 单测也按错的预期写
assertTrue(
canShip(order)
)
}

这种 bug 在传统人工开发里几乎不会发生，因为程序员写实现和写单测会经过两次独立的思考。但 AI 是同一次推理出的两份代码，它们共享同一个错误前提。

所以现在我看 AI 写的单测，第一件事不是"过没过"，而是把单测的断言对照需求文档逐个核对一遍——这听起来很傻，但救过我好几次。

三、构建你的"AI 代码 review 决策树"

review 多了我发现，每次面对一段 AI 代码，我大脑里其实跑的是一个相对固定的决策树。把它显式化出来，效率高很多：

收到一段 AI 代码

↓

这段代码进生产环境吗？

↓

❌ 是 → 走完整 review 流程，禁止跳过

✅ 否 → 脚本/工具类可以快速过

↓

涉及外部依赖吗？

↓

⚠️ 是 → 重点查 API 是否真实存在、版本是否匹配

✅ 否 → 重点看业务逻辑映射

↓

有异常处理吗？

↓

⚠️ 有 → 每个 catch 都要追问"被吞的异常上层怎么知道"

↓

通过 → 合并

这个流程看起来繁琐，但跑过几次就会内化成肌肉记忆。关键是不能省"涉及外部依赖时验证 API 真实存在"这一步——AI 的幻觉 API 是最阴的，它的方法名会非常符合命名习惯，不点开文档你根本看不出来是编的。

用 AI review AI：双 Agent 模式

说实话，我最开始也不信"用一个 AI 去 review 另一个 AI 写的代码"这种玩法能 work。但试了几次发现——只要 prompt 设计得好，效果意外地不错。

核心是你要把 review 的 AI 放在对抗性视角。我现在常用的 prompt 模板大概长这样：

# Review Prompt 模板你是一个有 10 年经验的
// 高级工程师
你的任务不是夸赞这段
代码，而是找出它的问题// 强制对抗性视角
请按以下顺序审视：1. 异常处理是否完整
2. 边界条件是否覆盖
3. 并发安全是否成立
4. 资源是否正确释放
5. API 调用是否真实
6. 单测断言是否对齐
需求// 关键约束
对每一处问题，必须给出
具体行号 + 修复方案
不要给 "看起来还行" 这种
模糊评价代码：
[贴代码]

这个模式不是用来取代你 review 的，而是当成"第一遍粗筛"。AI 反馈出来的问题你再人工判断哪些真、哪些假。我大概有 60% 的有效问题是这样筛出来的，比纯人工 review 快不少。

四、新手工程师怎么补这块能力？

这个问题其实最让我担心。新人现在的成长路径已经被 AI 显著扭曲了。以前你写 5 年代码，自然就把那些坑都踩过一遍——异常该不该吞、资源什么时候释放、并发怎么处理，这些是手感。现在新人一上来就用 AI 出代码，他根本没机会"自己撞墙"。

我带新人现在的做法是这样：

• 禁止 AI 写第一版。新功能的第一版必须自己手写，写完再让 AI 帮忙优化。逻辑是你想出来的，bug 才是你的；AI 写完你 review，发现的 bug 大多变成"AI 的锅"，对成长帮助有限。

• 故意写错一段代码让新人 review。每周一次，我会拿一段我写的"看起来对但有坑"的代码（或者直接用 AI 生成的有问题代码）让团队新人 review，看他们能不能找出来。这是培养嗅觉最快的方式。

• 建立团队的 review checklist。把团队踩过的所有坑沉淀成一份 checklist，每次 review 强制对照。这个 list 要持续维护，每发现新坑就往上加。

• 读高质量的开源代码。AI 的代码风格平均水位偏低（毕竟训练数据里平庸代码占多数），想培养品味只能靠读真正的好代码——OkHttp、Coroutines、Compose 这些库的实现读一遍，比看 100 段 AI 代码有用。

一个反直觉的判断：越是 AI 能力强的时代，工程师越要保持"手写代码"的频率。不是说要拒绝 AI，而是不能让"判断力"萎缩。代码品味是磨出来的，不是看出来的。

五、Review 能力的"复利"在哪里

最后聊点更长期的判断。我现在越来越相信，未来 3-5 年，工程师会显著分化成两类：

第一类是"AI 操作员"——能熟练用 AI 出代码，但对代码本身缺乏判断力。这类人产出速度很快，但质量上限被 AI 顶住了，遇到 AI 解决不了的问题就卡死。

第二类是"AI 编辑"——能驾驭 AI 大量产出，同时能精准识别和修正 AI 的错误。这类人的产出是 AI × 自身判断力的乘积，复利效应非常明显。

代码不再值钱，但"判断什么代码该上线"非常值钱。

review 能力之所以是壁垒，是因为它是无法被 AI 替代的——AI 自己写的代码，它没有动机也没有上下文去 review；只有人类工程师，带着具体业务理解、团队约定、线上故障史，才能做出"这段代码到底能不能上"的判断。

而且 review 能力的复利是真复利：你 review 1000 段 AI 代码积累的判断力，会反过来让你的 prompt 写得更精准，让你的架构设计更鲁棒，让你 debug 线上问题的速度更快。这个飞轮一旦转起来，跟那些只把 AI 当代码生成器的人差距会越拉越大。

说回开头那个新人。我后来花了半小时陪他重新看了一遍那段代码，把 catch 的处理方式改对，把单测补上断言。最后跟他说：以后 AI 给你代码，你就当成是某个素未谋面的同事写的——你会替这个同事的 PR 直接合并到主干吗？

他想了想说："不会，我得 review 一下。"

这就对了。