AI coding 爆火之后，我学到的 5 个工程教训

第一次撞上 AI 生成代码的真实场景

去年接手一个遗留 Spring Boot 微服务，需要将内部用户认证模块迁移到 OAuth 2.1。团队只有三个人，时间窗口三周。我自然想到用 AI 编程工具（Cursor + GPT-4）加速。一开始很顺利：AI 生成了新的认证过滤器、Token 存储层和配置类，大概 800 行代码，覆盖了 routes、异常处理和部分测试。

但问题在集成测试时爆发：AI 生成的 SecurityFilterChain 配置中有两个 @Order 注解冲突，导致部分 API 端点绕过了认证。更隐蔽的是一个 JwtAuthenticationConverter 中的 null 指针，AI 没有处理 claims 字段缺失的场景。修复这 5 个问题花了比手动写更长的时间，因为要先理解 AI 自己的“思维”——它习惯用 Optional 但又不完全一致。

这个场景让我意识到：AI coding 的最大陷阱不是它写不出代码，而是你误以为它写的代码可以直接信任。

真正改变判断方式的 4 个结论

第一，代码审查不可跳过，但审查对象变了。 以前 review 同事代码，重点在逻辑和风格。现在 review AI 代码，重点在边界条件、异常路径和与现有系统的隐式耦合。AI 非常擅长生成“看起来对”的代码，但经常漏掉 null、越界、超时这些角落。我后来的做法是：每次 merge AI 代码前，专门检查三类问题：1）所有输入输出参数的非空假设；2）所有分支条件的默认行为；3）所有异步操作的超时和重试。

第二，迁移类任务要用“分阶段替换”，而不是全量重写。 那次 OAuth 迁移我犯的最大错是让 AI 一次性生成整个模块的替换代码。更好的做法是：先让 AI 生成一个兼容新旧两套认证的“代理过滤器”，逐步切流量；每步保留旧代码作为回滚点。这个教训花了我两天加班时间才学会。

第三，prompt 结构直接影响输出质量。 不是简单写“生成 OAuth 2.1 配置”就行。我后来固定了一个三段式 prompt：1）明确问题上下文（框架版本、现有结构、约束条件）；2）具体输出格式（类名、方法签名、注释风格）；3）需要避免的陷阱（如不要用已废弃 API、不要引入新依赖）。效果提升明显，错误率降低至少 40%。

第四，AI 更适合“从 0 到 1”而不是“从 1 到 0.9”。 原型、脚手架、演示代码是 AI 的强项；但当你需要对现有系统做精细修改时，AI 容易破坏已有逻辑。现在我会隔离使用场景：新功能原型用 AI，存量修改坚持手动。

踩过的坑和修正路径

最大的一个坑：没有为 AI 生成的代码建立独立测试层。 我直接让 AI 生成代码，然后扔进现有的测试套件运行。但 AI 生成的代码往往需要特殊的 mock 数据或配置，而现有测试没有覆盖。结果测试通过，集成失败。修正方法是：建立一个 ai-generated/ 目录，所有 AI 代码先放入该目录，并为其编写独立的单元测试和集成契约测试，通过后再合并到主代码库。

另一个坑：过度信任 AI 的“解释”。 当我问“为什么这样做”时，AI 会给出一个听起来很合理的理由，但有时是幻觉。一次 AI 解释某个 @Transactional 传播行为时，它的理由基于 Spring 5 的旧行为，而项目用的是 Spring 6 的 Jakarta 命名空间。现在我需要问之前先验证一次官方文档，或让 AI 同时给出引用。

如果你也在做类似工作，最值得先照抄的一步

设置一个“AI 代码准入清单”，每次从 AI 获取代码后，手动检查以下项：

1. 所有外部输入（参数、环境变量、配置文件）的默认值是否合理？
2. 所有异常路径有没有被吞掉（空 catch 块或仅 log 不恢复）？
3. 所有异步调用是否有超时设置（尤其是网络请求）？
4. 生成的代码是否引入了项目没有的新依赖（检查 import 和 build 文件）？
5. 代码风格是否符合团队现有规范（缩进、命名、注释模式）？

这个清单我给团队每个成员都贴在了显示器旁边。使用两周后，线上故障率降低了约 35%。

什么时候继续投入，什么时候该换路线

继续投入的条件：当你看到 AI 生成的代码在通过准入清单后，修改量低于手写量的 30%。 如果你的场景是创建新模块、写样板代码、写测试用例、生成 SQL 或脚本——这些是 AI 的舒适区，可以持续用。

该换路线的信号：修改 AI 代码的时间超过手写时间的两倍，或者修复一个 bug 引出了三个新 bug。 例如那次 OAuth 迁移，我花了 4 小时 debug AI 生成的配置，最后放弃，自己花 1.5 小时重写。这种场景表明当前任务超出了 AI 的能力边界——通常是涉及遗留系统、复杂上下文依赖、或非标准配置。

还有两个明确应该停止的情况：1）你无法理解 AI 生成的代码逻辑（复杂 lambda 链或抽象桥接模式）；2）AI 生成的代码包含你无法完整测试的外部依赖（比如直接调用第三方 API 而不做 mock）。这时手动实现更安全。