AI 生成代码审查指南

概述

AI 生成的代码看起来漂亮、语法正确、格式规范，但往往存在系统性问题。AI 代码通过了视觉检查，但在生产环境中可能失败。

本文介绍如何有效审查 AI 生成的代码，包括常见问题模式、审查框架、工具和最佳实践。

一、AI 代码的六大失败模式

1.1 乐观路径幻觉

AI 生成代码时默认一切顺利，省略错误处理、边界情况和优雅降级。

检查清单：

  • null/undefined 输入是否显式处理？
  • 空数组、空字符串是否考虑？
  • 边界条件是否测试？
  • 网络失败是否有处理？
  • 并发访问是否考虑？

1.2 同义反复测试

当 AI 同时生成实现和测试时，测试验证的是 AI 写的代码，而不是业务需求。

测试红旗：

  • expect(result).toBeDefined() 而非具体值检查
  • 测试逻辑完全复制实现逻辑
  • Mock 过度，不锻炼真实逻辑
  • 只有正常路径覆盖

1.3 依赖漂移

AI 引用的库可能是 2+ 个主要版本前的，或为简单任务引入重型依赖。

检查清单：

  • 验证 import 的包是否真实存在于依赖列表
  • 检查方法在已安装版本中是否存在
  • 验证方法签名是否匹配用法
  • 是否引入了不必要的新依赖

1.4 重复工具逻辑

AI 不知道代码库中已存在工具函数，每次任务都会生成新的。

现象： 在一个代码库中发现 11 个不同的邮箱验证实现，每个略有不同。

1.5 过时 API 引用

AI 可能虚构不存在的 API，使用过时的 SDK 模式，或调用已重命名的内部 API。

1.6 缺少架构上下文

AI 不知道系统为什么这样设计，会生成违反服务边界、绕过模式、引入耦合的代码。

二、AI 代码质量问题数据

安全漏洞

指标 发现
AI 代码未通过 OWASP Top 10 测试 45%
比人类代码有更多漏洞 2.74 倍
包含设计缺陷或漏洞 62%
XSS 防护失败 86% 的样本
Java 代码安全失败 72% 的样本

代码质量

指标 发现
AI 代码每 PR 问题数 vs 人类 1.7 倍
正确性问题 1.75 倍
可维护性问题 1.64 倍
安全问题 1.57 倍
代码流失增加 +115%（翻倍）
静默失败 60% 的 AI 代码缺陷

开发者信任

指标 发现
不完全信任 AI 代码的开发者 96%
实际验证后才提交的开发者 48%
信任 AI 工具准确性（2025） 29%（从 2024 年的 40% 下降）

关键发现： 知道 AI 代码不可靠和实际检查它之间的差距，是大多数问题的根源。

三、REVIEW 审查法（6 步框架）

专门针对 AI 生成代码的结构化审查方法。

R - 需求检查（3 分钟）

看代码之前，先读需求。写下代码必须做的 3 件最重要的事。

AI 代码经常解决的是略微不同的问题。

E - 检查边界情况（5 分钟）

对于每个函数，问：

  • null 或 undefined 输入会怎样？
  • 空数组或空字符串会怎样？
  • 并发请求会怎样？
  • 网络失败会怎样？

V - 验证现有模式（5 分钟）

打开 2-3 个类似文件。AI 代码是否遵循相同模式？

  • 错误处理方式
  • Import 风格和依赖选择
  • 命名规范
  • 文件/文件夹结构

I - 检查安全边界（3 分钟）

AI 经常生成有安全漏洞的代码：

  • SQL 注入（字符串拼接）
  • XSS（未转义的用户输入）
  • 命令注入（用户输入到 exec()）
  • 硬编码密钥
  • 新端点缺少 auth 检查

E - 评估测试质量（5 分钟）

不要只看测试是否存在，检查：

  • 测试验证的是行为而非实现？
  • 边界情况有覆盖？
  • 错误路径有测试？
  • 断言具体，不只是 toBeDefined()？

W - 警惕不必要的复杂（4 分钟）

AI 喜欢过度工程——工厂模式、依赖注入、抽象基类，而简单函数就够了。

复杂嗅探测试： 能用一句话向队友解释代码做什么吗？如果不能，可能过度复杂了。

四、AI 代码审查清单

关键项（必须检查）

  • Auth + 授权检查存在且正确
  • 输入验证存在（不只是类型检查）
  • 遵循现有代码库模式
  • 没有与现有工具重复的逻辑
  • 边界情况处理（null、空值、边界）
  • 错误传播，不吞掉
  • 没有 N+1 查询模式
  • 测试验证行为，不是实现

安全清单

  • 无 SQL 注入（只用参数化查询）
  • 用户输入在渲染/存储前清理
  • 所有受保护路由有 auth 检查
  • 无硬编码密钥/API 密钥
  • 错误消息不泄露敏感数据
  • auth/支付端点有速率限制

性能清单

  • 无 N+1 查询模式
  • 数据库查询使用适当索引
  • 大数据集分页
  • 独立 async 操作用 Promise.all
  • 请求处理器中无阻塞操作
  • 响应负载大小合理

架构清单

  • 符合现有代码库结构
  • 使用已建立的抽象
  • 没有团队认可的新依赖
  • 正确的层级（业务逻辑不在 UI 组件中）

五、基于风险的分类审查

不是所有 AI 代码都需要同等程度的审查：

绿色（5 分钟审查）

  • UI 调整、copy 修改、配置更新
  • AI 这些做得很好

黄色（15 分钟审查）

  • 无外部集成的新功能
  • 使用标准 REVIEW 方法

红色（25+ 分钟审查）

  • 任何涉及 auth、支付、数据迁移、外部 API 的
  • 完整 REVIEW 方法 + 与资深工程师配对审查

六、审查工具

自动化扫描工具

工具 用途 价格
SonarQube SAST、质量门禁 免费（社区版）/ 企业版定制
Semgrep 自定义规则、代码匹配 免费（开源）/ Semgrep App（免费/付费）
Snyk Code 安全漏洞检测 免费（开源）/ $1,260/年/人
CodeQL GitHub 原生分析 免费开源
DeepSource 开发者友好 SAST 免费（开源）/ $24/月
Gitleaks 密钥扫描 免费开源
npm audit 依赖安全 免费

AI 辅助审查

工具 特点 价格
Cursor BugBot PR 审查，70%+ 问题在合并前解决 含在 Cursor 付费计划
Claude Code /review 结构化 diff 审查 $20/月 或 API 计费
CodeRabbit PR 总结、内联评论、一键修复 $24-30/月
Qodo 多仓库上下文，57% bug 检测率 $30/月
GitHub Copilot Review 原生 GitHub 集成 含在 Copilot Business ($19/月)
/ultrareview 多智能体并行验证 $5-20/次
Cubic 实时 PR 审核 + 夜间扫描 $30-79/月

本地 CI Pipeline

// scripts/ci-local.mjs
try {
  run("npm ci");
  run("npm run lint");
  run("npm run typecheck");
  run("npm test");
  run("gitleaks detect --source . --no-git --redact");
  console.log("✅ local CI passed");
} catch (e) {
  console.error("❌ local CI failed");
  process.exit(1);
}

七、AI vs 人类审查

方面 AI 审查 人类审查
速度 快（分钟级） 慢（小时/天）
语法/风格 优秀 优秀
安全漏洞 良好（SAST 工具） 需要专项检查
业务逻辑 差 优秀
架构判断 差 优秀
上下文理解 有限 深度
边界情况 需要明确提示 依靠经验

结论：AI 审查 + 人类复核是最佳组合。

八、关键要点

  1. 表面质量具有欺骗性。 AI 代码看起来精致，但失败方式与人类代码不同。

  2. 审查聚焦边界。 AI 生成的内部逻辑通常没问题。Bug 存在于接口处：函数签名、API 契约、错误处理。

  3. 测试行为，不是实现。 运行代码，点击 UI，发送真实 API 请求。

  4. 自动化能做的就自动化。 Linter、类型检查器、SAST 工具捕获机械错误。人类审查留给逻辑和架构。

  5. 检查 AI 没改的部分。 最严重的 bug 来自应该更新但没更新的现有代码。

  6. 理解是真正的门槛。 如果不读代码就无法解释代码如何处理失败，审查就不完整。

  7. 使用清单。 80% 完整度的清单，比被跳过的完美清单好。

九、总结

AI 生成代码审查的核心：

AI 生成代码 → AI 审查工具扫描 → 人类复核关键项 → 通过合并

REVIEW 框架：

  • R - 需求检查
  • E - 边界情况
  • V - 验证模式
  • I - 安全边界
  • E - 测试质量
  • W - 警惕过度复杂

关键认知：

  • AI 代码有 1.7 倍更多问题
  • 60% 是"静默失败"
  • 人类审核仍然不可替代

最佳实践：

  • 用工具做自动化检查
  • 用 AI 发现常见问题
  • 人类做架构和业务逻辑判断

参考来源