修炼AI技能
AI 教程 / AI 编程实战 / 用 AI 做代码审查与测试

用 AI 做代码审查与测试

代码审查（Code Review）和测试是质量的两条主干防线，却也最耗人力。AI 恰好擅长”按标准逐项检查”和”按函数批量造用例”这类结构化工作。本文给出可落地的工作流、可复制的提示词，以及必须正视的局限。

让 AI review PR

把一次 PR 审查拆成四个维度，分别交给 AI 检查，比笼统说”帮我 review”更有效：

维度看什么常见发现问题
风格命名、格式、约定一致性与既有代码风格冲突、冗余导入
安全注入、鉴权、密钥、数据处理SQL/命令注入、硬编码密码、越权
逻辑边界、竞态、空值、异常路径漏处理 null、off-by-one、并发问题
性能复杂度、N+1 查询、不必要的拷贝循环内查库、大对象深拷贝

Anthropic 在 Claude Code 里提供了内置的 /code-review 技能：它在独立 subagent 上下文里只审当前 diff，不受”刚写这段代码”的立场影响，把发现返回主会话。你也可以让一个会话写代码、另一个会话审代码（Writer/Reviewer 模式），因为” fresh context 对代码审查更有利”。

可复制的审查提示词

你是资深 reviewer。请审查以下 diff（@path/to/diff 或粘贴内容）。
只报告影响正确性、安全性、与既有约定一致性的问题，忽略纯风格偏好。
逐条给出：文件:行号、问题类型、为什么是问题、建议修改。
不要改动代码，只输出审查报告。

针对安全的专用提示词：

你是有 15 年经验的资深安全工程师。审查这段代码是否存在：
- SQL 注入 / 命令注入 / XSS
- 鉴权与授权缺陷
- 密钥或凭据硬编码
- 不安全的反序列化或数据处理
请给出具体行号与修复建议。

自动生成单元测试与用例

AI 最稳的产出之一，就是给函数补测试。有效做法是”先定验收、再让 AI 补用例”：

  1. 选中目标函数/模块，告诉 AI 输入空间与边界（正常值、空值、超界、异常）。
  2. 要求它覆盖” happy path + 边界 + 异常路径”三类。
  3. 让它先写失败测试复现某个 bug，再写实现修复（red-green 节奏）。
  4. 跑测试，把输出作为证据回贴到 PR。

示例提示词：

为 src/validate.py 的 validate_email 写 pytest 用例。
覆盖：标准邮箱为真、缺少 @ 为假、域名后加点(.com 缺后缀)为假、
超长输入、含空格。不要使用 mock。实现后运行 pytest 并贴出结果。

注意：生成的测试要能真实失败才能证明价值。如果 AI 写的测试”永远通过”，它只是在表演覆盖，没有守住行为。

用 mutation testing 思维看测试质量

很多团队测了很多，却没测对。mutation testing（变异测试）的思路很适合用来审视 AI 生成的测试是否”有用”：

  • 核心思想：故意在代码里做微小改动（把 > 改成 >=、把 + 改成 -、删掉一个判断），看测试会不会失败。
  • 如果改动后测试仍全绿，说明这条测试没捕捉到那一行行为——它是”弱测试”。
  • 对 AI 生成的测试尤其要做这一步，因为模型倾向于写”看起来齐全但断言很松”的用例。

你不必真去跑 mutation 框架，关键是建立这种反向检验的习惯：AI 补的测试，能不能在代码真的出错时抓到错？抓不到，就要求它加强断言。

在 CI 中集成 AI 审查

把 AI 审查接进持续集成，能让它在每次 PR 自动跑，而不是等人力：

  • 非交互模式：Claude Code 的 claude -p "review this diff" 可放在 CI、pre-commit、或脚本里，输出 JSON/文本供解析。
  • 确定性门槛：用 Stop hook 在每次文件改动后自动跑 lint/测试，未通过则阻断该轮结束；或用 /goal 让独立评估器每轮复查目标是否达成。
  • 分层：轻量检查（lint、单测）全自动；安全与架构类检查产出报告供人决策，不直接合并。
claude -p "Review the git diff of this PR for bugs, security and style.
Output a concise report." --output-format text

上面这条命令演示了在 CI 中对当前 diff 做 AI 审查（示意）。

集成原则：让 AI 当”第一道滤网”和”证据收集者”，把人从重复筛查里解放出来；但最终合并决策与安全责任，留在人手里。

局限与风险

AI 审查/测试不是免费的质量保险，要清楚它的边界：

  • 缺仓库上下文：AI 只看到你给的 diff，不了解系统全貌、历史坑与业务约束，可能放过跨模块问题。
  • 误报与漏报并存：它会报一些不是问题的问题（误报，耗费人力），也会自信地漏掉真实缺陷（漏报，更危险）。
  • 测试可造假象：AI 可能写出”高覆盖率、低有效性”的测试，制造”已测过”的错觉。
  • 安全责任仍在人：审查结论不能替代人类判断，尤其安全敏感与合规相关代码。
  • 质量随 prompt 与上下文波动：给的样例、标准、范围越清晰，结果越稳；含糊则参差。

这也呼应了 METR 2025 年研究的提醒：在复杂成熟代码库上，AI 工具若缺乏深度上下文，反而增加返工与审查负担（Becker 等，arXiv:2507.09089）。把 AI 当”放大人类判断”的工具，而不是”替代判断”的裁判。

小结

  1. 把 PR 审查拆成风格/安全/逻辑/性能四维度分别检查，比笼统”帮我 review”更准。
  2. 可用内置 /code-review 技能或 Writer/Reviewer 双会话模式，让独立上下文做对抗式复查。
  3. 生成测试时坚持”先定验收、再补用例、先写失败测试”，并要求贴出测试证据。
  4. 用 mutation testing 思维反向检验：AI 的测试要在代码真出错时能抓到，否则是弱测试。
  5. 在 CI 中以非交互模式接入 AI 审查，轻量检查自动跑、关键检查出报告供人决断。
  6. 局限在于缺上下文、有误报漏报、测试可造假象，安全责任始终在人。

参考来源

  1. Anthropic，Claude Code 官方最佳实践（验证、subagent、/code-review、hooks、CI 非交互模式）：https://code.claude.com/docs/en/best-practices
  2. Anthropic，《Building effective agents》（evaluator-optimizer 等工作流模式，可用于”生成—评估”迭代）：https://www.anthropic.com/engineering/building-effective-agents
  3. Becker, Rush, Barnes, Rein，《Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity》（复杂代码库上 AI 的上下文与返工问题）：https://arxiv.org/abs/2507.09089
  4. OpenAI，《A practical guide to building agents》（护栏与人在回路，适用于把 AI 审查纳入流程时的风险控制）：https://cdn.openai.com/business-guides-and-resources/a-practical-guide-to-building-agents.pdf
  5. SWE-bench 官方站（理解”可被客观验证”的编码能力评测口径，类比 AI 审查的验收标准）：https://www.swebench.com/
  6. METR，《Measuring AI Ability to Complete Long Software Tasks》（自主编码能力快速上升，印证把审查/测试交给 Agent 的可行性）：https://metr.org/blog/2025-03-19-measuring-ai-ability-to-complete-long-tasks/
本文累计阅读 — 次