AI 时代的代码 Review——标准变了吗

适读人群：有团队协作经验的工程师、技术 Leader | 阅读时长：约12分钟 | 核心价值：重新定义 AI 辅助开发时代的 Code Review 重点，给出可落地的 Checklist 变化对比

上个月我们团队来了个新人，工作两年，代码写得很流畅，PR 提得很勤。我第一次 Review 他的代码，花了将近一个小时——不是因为代码质量差，恰恰相反，代码格式非常整齐，命名规范，注释也到位。但 Review 完我整个人都不对劲。

我发现自己在 Review 一堆根本不需要人来盯的东西。

他用 Cursor 写代码，AI 给他格式化好了，变量名也 AI 帮他想的，连方法注释都是 AI 生成的。我在那儿一行一行看"这个变量名是不是语义化""这里有没有遵守项目规范"……完全是在验收 AI 的工作，不是在 Review 人的判断。

那一刻我意识到：我们的 Code Review 标准，还停留在五年前。

Review 的本质是什么

在说标准怎么变之前，得先把这个问题想清楚。

Code Review 的本质，从来不是找错别字，不是检查括号有没有空格。Review 的本质是：在代码合并进主干之前，让另一个有经验的大脑过一遍这个决策。

这里有两个关键词——"有经验的大脑"和"决策"。

语法对不对、格式规不规范，这些不是决策，是规则的执行。规则的执行，机器比人准确得多，也快得多。

但"这个模块为什么要这么设计""这个异常为什么在这里吞掉而不是向上抛""这个接口设计三个月后扩展会不会很麻烦"——这些是决策，是判断，是只有理解业务背景、理解系统全貌的人才能真正检验的东西。

AI 辅助开发之前，我们的 Review 标准里混杂了大量规则执行类的检查，因为那时候没有别的办法。现在有了，就得分开。

原来我们 Review 什么

我把自己过去几年的 Review 记录翻了翻，大概分成这几类：

格式和风格（占 Review 时间约 30%）

• 缩进对不对
• 命名是否遵守团队规范（驼峰、下划线）
• 注释是否充分
• 代码有没有多余空行

基础错误（占约 25%）

• 空指针可能性
• 资源有没有关闭
• 异常处理是否正确
• SQL 有没有明显的性能问题

逻辑确认（占约 20%）

• 实现的逻辑和需求文档对不对
• 边界条件有没有处理
• 有没有明显的逻辑 bug

设计和架构（占约 15%）

• 有没有重复造轮子
• 模块划分合不合理
• 接口设计是否稳定

测试（占约 10%）

• 有没有单测
• 单测覆盖了关键路径吗

你看，前两类加起来占了一半时间，而这两类恰恰是 AI 最擅长的地方。

现在 AI 替我们做了什么

我们团队现在标配的工具链是这样的：

代码提交前:
  - Cursor / Copilot 写代码时实时建议
  - ESLint / Checkstyle 自动格式检查
  - SonarQube 静态分析（含空指针、资源泄漏等）
  - GitHub Actions 跑 CI，包含单测覆盖率报告

代码提交后:
  - PR 描述由 AI 辅助生成（至少是草稿）
  - 部分团队用 CodeRabbit 做第一轮 AI Review

坦白说，在这套工具链下，一个工程师提的 PR，在人工 Review 之前就已经经历了至少三道自动化检查。格式问题、基础空指针、没有测试——这些大概率已经被拦截或者标注出来了。

那人工 Review 还剩什么价值？剩的是最重要的那部分。

新标准：Review 什么

我在团队里推行的新标准，核心思路是"把时间花在机器判断不了的地方"。

一、逻辑正确性——真正的业务逻辑，不是语法

不是"这个 if 语句语法对不对"，而是"这个条件判断反映的业务规则是正确的吗"。

举个例子。有个同事写了一段订单状态流转的代码：

public boolean canRefund(Order order) {
    return order.getStatus() == OrderStatus.PAID 
        && order.getCreateTime().plusDays(7).isAfter(LocalDateTime.now());
}

语法完全没问题，AI 也不会报错。但问题是：业务上退款窗口是7天，还是7个自然日？订单创建时间还是支付时间？如果用户在第6天23:59下单，明天才算第7天还是今天已经算到期？

这些问题机器不知道，只有理解业务的人才能 Review。

二、设计合理性——面向三个月后的自己

我在团队里提了一个问题模板，Review 接口设计时要问：三个月后，如果这个接口要增加一个字段，代价是多少？

如果回答是"很麻烦，要改很多地方"，那这个设计值得在 Review 阶段就提出来。

AI 生成的代码在局部很漂亮，但 AI 没有你的系统全局观，也没有你对业务演进方向的判断。它不知道这个服务三个月后要支持多租户，不知道这个接口以后要对外暴露。

三、测试覆盖的质量，不是数量

覆盖率 80% 这个数字，现在 AI 很轻松就能帮你达到——它会生成一堆 happy path 的测试。

但 Review 时要问：边界条件测了吗？异常路径测了吗？那个最可能出 bug 的地方，测试是不是真的覆盖了，还是只是执行到了？

// AI 生成的测试，看起来覆盖率很好
@Test
void testCanRefund() {
    Order order = new Order();
    order.setStatus(OrderStatus.PAID);
    order.setCreateTime(LocalDateTime.now().minusDays(3));
    assertTrue(orderService.canRefund(order));
}

// 但这些场景测了吗？
// 1. createTime 正好是7天前的情况
// 2. status 是 PARTIALLY_PAID 的情况
// 3. order 本身是 null 的情况
// 4. 时区问题

四、上下文一致性——这段代码和系统其他部分说的是同一种语言吗

AI 在单个文件里的一致性很强，但跨文件就可能出现"方言"问题。

比如错误处理，项目里原来统一用 Result<T> 包装返回值，AI 生成的代码可能直接抛异常。比如日志，原来约定 INFO 级别只记录关键节点，AI 可能给你加了一堆 DEBUG 日志但忘了改级别。

这种一致性问题，在 Review 时需要特别关注，因为它会慢慢侵蚀系统的整体风格。

五、安全和权限——不要相信 AI 生成代码的安全敏感度

这是我踩过坑的一个点。

AI 在功能实现上很强，但在安全意识上往往不足——因为大部分训练数据里的代码也没有很好的安全实践。

Review 时要专门看：接口有没有鉴权？用户输入有没有过滤？敏感数据有没有脱敏？日志里会不会打印出密码或 token？

新旧 Checklist 对比

给大家一个直观的对比：

旧 Checklist（人工 Review 时代）

[ ] 代码格式是否符合规范
[ ] 命名是否语义化
[ ] 注释是否充分
[ ] 有没有空指针风险
[ ] 资源是否正确关闭
[ ] 异常处理是否完整
[ ] 是否有单元测试
[ ] 测试覆盖率是否达标
[ ] 逻辑是否与需求一致
[ ] 有没有明显性能问题
[ ] 是否有重复代码
[ ] 接口设计是否合理

新 Checklist（AI 辅助开发时代）

【自动化工具负责的（不在人工 Review 范围内）】
- 格式和风格
- 基础静态分析（空指针、资源泄漏）
- 测试覆盖率数字
- 代码重复检测

【人工 Review 重点】
[ ] 业务逻辑正确性：条件判断、状态流转反映的业务规则是否准确
[ ] 边界条件覆盖：极值、空值、并发场景是否有对应处理
[ ] 测试质量：测试是否覆盖了关键的异常路径和边界条件（而非只是 happy path）
[ ] 设计扩展性：当前设计面对可预见的需求变化，代价是否可接受
[ ] 系统一致性：与现有代码风格、错误处理、日志规范是否一致
[ ] 安全敏感点：鉴权、输入验证、敏感数据处理
[ ] 依赖合理性：新引入的依赖是否必要，是否有安全风险
[ ] AI 生成代码的"幻觉"：特别是涉及外部 API 调用、框架特性的代码，是否真实有效

最后一条值得专门说一下。AI 生成代码有时候会"幻觉"——它会自信地写出一个并不存在的方法调用，或者使用一个 API 的旧版本签名。这种错误在 Review 时如果只看语法，完全看不出来，必须真正理解这段代码在运行时会发生什么。

推行过程中遇到的阻力

说句实话，这套标准推行起来并不顺利。

最大的阻力来自两个方向。

一是老工程师。他们 Review 习惯了，Review 格式和规范是有成就感的，因为能抓到东西，看着 PR 上一条条 comment 很有存在感。改成新标准，有些东西他们不知道该怎么评价，反而觉得"没什么好 Review 的"。

二是新工程师。他们觉得 AI 帮他们检查过了，Review 是走形式。有一次我在 Review 一个新人的 PR，指出他的业务逻辑有问题，他的第一反应是"我问过 AI 了，AI 说没问题"。这个反应让我意识到，除了 Review 标准，还有一个更重要的东西需要重建：工程师对自己判断的责任感。

AI 说没问题，不等于没问题。AI 的判断是基于普遍规律，你的业务逻辑是特定上下文。这两者之间的 gap，就是人工 Review 存在的价值。

一个实际的 Review 流程

我们现在团队的 Review 流程大概是这样：

1. 提 PR 之前，作者自己用 AI 工具做一遍检查
   （格式、潜在 bug、测试覆盖）

2. CI 自动跑：lint + 静态分析 + 单测

3. PR 描述里，作者必须写：
   - 这个改动解决了什么问题
   - 涉及哪些业务逻辑变化
   - 测试了哪些场景（包括异常场景）

4. 人工 Review 按新 Checklist 进行
   重点看：业务逻辑、设计、安全、一致性

5. Review 通过后合并

这套流程下来，Review 的时间反而比以前短了——因为低价值的检查都卸载出去了，人工 Review 的信噪比更高，能更快抓到真正重要的问题。

---

Code Review 这件事，本质上是在问：如果这段代码出了问题，你作为 Reviewer 是否尽到了该尽的职责？

AI 帮你把低层次的检查做完了，但这同时也意味着你没有借口再停留在低层次了。

你的 Review，得真正值回那个时间。