"反正是 AI 写的，应该没问题吧？"

我听过不少人说这句话。他们觉得既然 AI 已经很"聪明"了，写出来的代码应该比人写的还好，还需要 Review 吗？

说实话，在某些方面 AI 确实写得比大多数人好——比如代码格式整齐、命名一致、不会犯拼写错误。但 AI 写代码有一个致命弱点：它不理解你的业务。

AI 知道怎么写一个"用户注册"功能的代码，但它不知道你的业务规则是"注册时必须验证企业邮箱后缀"。AI 知道怎么写一个购物车，但它不知道你的产品有"同一用户每天限购 3 件"的限制。AI 知道怎么写 SQL 查询，但它不知道你的数据库里有一张 500 万行的表，它写的全表扫描查询会把数据库打挂。

所以答案是：AI 时代，Code Review 不是变简单了，而是关注点变了。

传统 Code Review vs AI 时代 Code Review

以前做 Code Review，你的时间大概这样分配：

• 40% 检查语法和格式（缩进对不对、变量名规不规范）
• 30% 检查逻辑正确性（功能做对了没有）
• 20% 检查代码质量（有没有重复代码、结构合不合理）
• 10% 检查安全和性能

现在 AI 写的代码，语法和格式基本不用操心了。你的 Review 精力可以重新分配：

• 5% 语法格式（AI 基本不犯这种错）
• 35% 业务逻辑正确性（AI 最容易在这里犯错）
• 25% 安全性（AI 经常忽略安全问题）
• 20% 性能（AI 倾向于"能用就行"，不考虑规模）
• 15% 可维护性（AI 有时候会过度工程化或者写"聪明但难懂"的代码）

三个核心 Review 维度

维度一：安全性——"这段代码能被攻击吗？"

AI 最常犯的安全问题：

SQL 注入。AI 有时候会拼接字符串来构建 SQL 查询，而不是用参数化查询：

// ❌ AI 可能写出的代码
const query = `SELECT * FROM users WHERE email = '${email}'`;

// ✅ 应该用参数化查询
const user = await prisma.user.findUnique({ where: { email } });

硬编码密钥。前面"部署"那节讲过了，AI 会把 API Key 直接写在代码里。

XSS（跨站脚本攻击）。AI 在渲染用户输入的内容时，可能不做转义：

// ❌ 危险——如果 user.bio 包含 <script> 标签就会执行
<div dangerouslySetInnerHTML={{ __html: user.bio }} />

// ✅ 直接渲染文本，React 会自动转义
<div>{user.bio}</div>

缺少权限检查。AI 写 API 的时候经常忘记检查"这个用户有没有权限做这个操作"：

// ❌ 任何人都能删除任何用户——AI 写出来但可能没加权限检查
app.delete('/users/:id', async (req, res) => {
  await prisma.user.delete({ where: { id: req.params.id } });
});

// ✅ 需要验证身份和权限
app.delete('/users/:id', authenticate, authorize('admin'), async (req, res) => {
  await prisma.user.delete({ where: { id: req.params.id } });
});

维度二：性能——"这段代码在数据量大的时候还能用吗？"

AI 写代码的时候默认假设数据量很小。10 条数据时完全没问题的代码，1 万条时可能就卡了，100 万条时直接崩了。

常见的性能坑：

N+1 查询问题：

// ❌ AI 经常写出这种——每个 post 都要查一次数据库
const posts = await prisma.post.findMany();
for (const post of posts) {
  const author = await prisma.user.findUnique({ where: { id: post.authorId } });
  post.author = author;
}

// ✅ 用 include 一次查完
const posts = await prisma.post.findMany({
  include: { author: true },
});

没有分页。AI 可能会一次查出所有数据然后在前端做过滤/排序——数据少的时候没问题，数据多了浏览器直接卡死。

不必要的重渲染。在 React 中，AI 可能把函数定义放在组件里导致每次渲染都创建新引用。

维度三：可维护性——"三个月后你还看得懂这段代码吗？"

AI 有时候会写出"技术上正确但人类难以理解"的代码。比如把好几个操作 chain 在一起、用高度抽象的泛型、或者写一个 300 行的函数什么都往里塞。

Review 时问自己：如果一个新人加入团队，他看到这段代码，能在 5 分钟内理解它在做什么吗？如果不能，就需要重构或者加注释。