如何在 AI 生成的代码进入生产环境之前抓住其中的 bug

AI 助手能在几秒钟内生成一个看起来能用的功能。如今难的部分已经不是生成代码了——而是判断你能否信任它。AI 模型即使出错也信心十足，它们会凭空捏造根本不存在的 API，还会乐呵呵地通过删掉断言来"修复"一个失败的测试。如果你把 agent 交给你的东西原封不动地上线，那你做的就不是真正的软件工程，而是在赌博。

好消息是：你不需要像偏执的代码审查员那样逐行通读。你需要的是一套分层安全网，让明显的错误被自动拦截，只有真正值得关注的决策才需要你过目。下面就讲讲怎么搭建这样一套网，从最省力到最彻底。

1. 看 diff，而不是看对话

性价比最高的习惯只有一个：审查实际的文件改动，而不是 AI 对改动的总结。Claude Code、Cursor 和 Copilot 这类工具在你接受改动前都会展示一份 diff。带着三个问题快速扫一遍：

• 它有没有动我没预料到的文件？ agent 有时会"热心地"改配置、删测试，或重写不相关的函数。
• 它有没有捏造 import 或 API？ 一个危险信号是调用了某个你从没见过的库方法。信任之前先确认它真的存在。
• 它有没有削弱什么东西？ 删掉了错误处理、放宽了类型、注释掉了某个检查，或者一个现在几乎什么都不断言的测试。

这 30 秒的快速扫描能抓住大部分"AI 干了蠢事"的情况。

2. 让机器去检查机器

人类不擅长发现少了个分号，却很擅长发现糟糕的逻辑。把枯燥的工作甩给工具，让你的注意力放在真正重要的地方。三个省力又免费的层：

• linter（ESLint、Ruff 等）负责代码风格和常见错误。
• 类型检查器（TypeScript、mypy）负责抓出捏造 API 和数据形状错误这一类 bug。
• 测试运行器负责检查行为。

诀窍是把这些做成非可选的——把它们接到 pre-commit hook 里，让它们在任何提交落地前运行。下面是在 JavaScript 项目中使用 Husky 的一个最小示例：

# .husky/pre-commit
npm run lint && npm run typecheck && npm test

现在，只要 AI 的代码过不了 linter、破坏了类型或测试失败，提交就会被直接拒绝。agent 的错误永远到不了你的分支。（在 Python 中，对应的是用 pre-commit 框架运行 ruff、mypy 和 pytest。）

3. 让 AI 来写——并运行——测试

AI 助手在生成测试方面确实很出色，而测试是防止下一次改动悄悄破坏这一次改动的最佳防线。但有个坑：一个既写测试又跑测试的 agent 可以靠把测试做得轻易通过来作弊。所以在你的提示里把步骤分开：

"为这个函数写测试，覆盖空输入、正常路径和一个边界情况。不要修改函数本身。"

然后由你自己或在 CI 中运行测试，并确认它们确实检验了真实行为。像 expect(result).toBeDefined() 这样的测试是做样子；expect(addTax(100, 0.2)).toBe(120) 才是真正的检查。至少读一条断言，确认它属于后一种。

4. 在 CI 中加一道质量门

本地 hook 保护你的机器；CI 检查则保护项目不受所有人影响（包括某个疲惫夜晚的未来的你）。加一个工作流，在每个 pull request 上重新运行 lint、类型检查和测试，并把分支配置成：在它通过之前禁止合并。这正是各大平台如今作为产品在售卖的思路——GitHub 的 Code Quality 将于 2026 年 7 月正式发布，新增了在可维护性或覆盖率下降时阻止合并的门禁，而 Cursor 也在今年早些时候把它的 /review 命令重新定位成了一道 pre-commit 门禁。用一个普通的 GitHub Actions 或 GitLab CI 任务，你就能免费拿到其中 80% 的价值。

5. 对有风险的那 5% 保留人工把关

自动化无法判断一个功能是不是正确的功能、一个架构决策能否经得起时间考验，或者删掉那个"没用的"函数是否安全。把你真正的注意力留给：任何涉及鉴权、支付或数据删除的改动；数据库迁移；以及对许多其他文件所依赖的共享代码的改动。其余一切，就交给安全网去处理。

一条简单的经验法则

你给 AI 的自主权越大，你的门禁就需要越强。 如果你在小心地一次接受一处改动，快速读一遍 diff 也许就够了。如果你让一个 agent 无人值守地跑十分钟，那你就需要让 lint、类型检查和测试挡在它和你的主分支之间。这张网搭一次，你就能让 AI 快速推进，而不必担心它在你背后悄悄把东西弄坏。