AI 写得更快以后，为什么 Code Review 反而更累了？

越来越多团队开始把 Claude Code、Codex 等编码 Agent 引入日常开发。它们能够快速阅读代码、实现功能、补测试和修改多个文件，开发产量确实上去了。

但很多团队使用一段时间后，会遇到一个有些反直觉的问题：代码写得更快了，Code Review 却更累了。

问题不一定出在 AI 生成的代码完全不能用，而是同一个项目里的代码开始出现越来越多不一致。

同一个需求，为什么会生成两种风格？

假设需求只是“根据用户 ID 查询用户”。一位开发者让 AI 生成的代码可能是：

async function getUserById(id: string) {
  const user = await db.query(
    "SELECT * FROM users WHERE id = ?",
    [id]
  );
  console.log("User fetched:", user);
  return user;
}

另一位开发者得到的代码可能是：

async function get_user_by_id(userId: string) {
  try {
    const user = await db.findOne({ id: userId });
    logger.info("Fetched user", { userId });
    return user;
  } catch (error) {
    logger.error("Failed to fetch user", { error, userId });
    throw new ServiceError("User query failed", { cause: error });
  }
}

两段代码都在完成查询，但具体写法完全不同：

一个使用 camelCase，另一个使用 snake_case。
一个使用 console.log，另一个使用结构化 logger。
一个直接向上抛出异常，另一个在当前层捕获并转换。
一个使用手写 SQL 和 SELECT *，另一个使用 ORM。
两者对于日志、错误边界和数据访问层的理解不同。

这里先不判断哪一种一定更好。真正的问题是：同一个项目没有形成稳定、一致、可预测的工程约定。

AI 会放大团队已有的不确定性

AI 并不会天然知道团队内部那些没有写下来的约定。例如：

项目究竟使用哪个 logger？
哪一层负责异常转换？
Controller 是否可以直接调用 Repository？
API 使用哪种统一响应格式？
修改接口时要补单元测试还是集成测试？
数据库字段、语言变量和 JSON 字段分别使用什么命名方式？

如果这些信息只存在于组长的记忆、零散文档和历史 Review 评论里，AI 就只能根据当前代码、通用经验和开发者提示自行推断。

更麻烦的是，不同成员给 AI 的提示也不同。有的人只说“实现这个接口”，有的人会附上日志、异常和测试要求。最终生成结果自然参差不齐。

AI 的作用更像一个放大器：团队原来模糊的地方，会以更高速度、更大规模出现在代码里。

为什么只靠人工 Review 兜不住？

传统开发中，一名工程师一天可能只提交有限数量的改动。现在 Agent 可以一次修改几十个文件，甚至同时生成实现、测试、迁移和文档。

如果 Reviewer 仍然逐项检查下面这些内容：

有没有使用 console.log
命名是否符合约定
有没有 SELECT *
是否补了入参校验
是否遗漏错误处理
日志有没有必要上下文
是否更新测试
是否提交了本地配置或密钥

那么 Review 工作量会迅速失控。

当 Reviewer 一天要查看十几个 PR，每个 PR 又涉及数十个文件时，遗漏几乎无法避免。更危险的是，被遗漏的有时并非格式问题，而是异常未处理、权限判断缺失、事务边界错误或敏感信息泄露。

这说明一个关键事实：

能够由规则或工具稳定处理的问题，不应该长期依赖人的注意力。

新人问题也会被 AI 放大

团队加入新人时，经常会给他发送架构文档、编码规范、API 文档、数据库规范和发布手册。文档可能很多，新人很难迅速判断哪些是最关键的。

如果新人没有理解项目约定就开始使用 AI，结果可能更混乱：新人不知道规范，AI 同样不知道规范，而生成速度又很快。

理想状态应该是：新人拉取仓库后，项目本身就携带最重要的上下文和开发规范。无论是谁启动 Claude Code，AI 都能先看到同一套团队约定。

这正是把规则提交进 Git 的价值：

规则和代码一起版本化。
新人不需要先找到散落在多个系统里的文档。
规则变更可以通过 PR 评审。
全员拉取代码后获得同一版本的规范。
出现问题时可以追溯规则何时、为何发生变化。

从“人肉纠错”转向“分层治理”

解决办法不是再写一份更长的团队文档，也不是要求组长记住所有规则，而是把质量控制拆成不同层次：

在 AI 编码前提供项目事实和明确规则。
在 AI 操作过程中，对危险行为进行限制或反馈。
在代码完成后，用 lint、测试和 CI 做确定性验证。
最后由人判断业务逻辑、架构和风险。

其中：

CLAUDE.md 负责高频、全局的项目上下文。
.claude/rules/ 负责模块化、可按路径生效的编码规范。
Skills 负责按需执行的多步骤工作流。
Hooks 和权限负责工具层约束。
CI 负责真正不可绕过的合并门禁。

这套体系的目的不是让 AI 百分之百不犯错，而是让低级、重复问题尽量在进入人工 Review 之前被消化掉。

规则不是越多越好

看到这里，有人可能会想：那就把所有公司规范都写给 AI。

这同样会失败。规则太多会占用上下文、制造冲突、分散注意力，也会让真正重要的底线淹没在大量低价值说明中。

值得沉淀的通常是以下内容：

AI 无法从代码稳定推断的约定。
Code Review 中反复出现的问题。
违反后会造成明显维护成本或风险的问题。
需要告诉 AI“正确做法”而不只是“禁止做法”的内容。

能够由格式化工具、lint 或 CI 完全检查的规则，则应该尽量交给工具执行。

小结

团队采用 AI 编程后，真正的挑战不再只是“怎样让 AI 写出代码”，而是“怎样让不同的人和不同会话生成一致、可维护、可验证的代码”。

如果规范只存在于人的记忆里，AI 会放大不一致；如果规范进入仓库并形成分层体系，AI 才有机会成为团队工程能力的放大器。

下一篇我们讨论最容易混淆的问题：CLAUDE.md 和 .claude/rules/ 究竟应该分别写什么。