AI写代码三个月后：效率背后隐藏的工程挑战

先聊一个大家可能都经历过的场景：刚开始接触 AI 编程工具的时候，那种“按个 Tab 就能补全一整个函数、随口描述需求就生成一段完整代码”的体验，确实容易让人上头。用 AI 写代码的前三个月，效率提升是肉眼可见的——以前要查半天文档的 API 调用，现在几秒钟就能生成；不想写单元测试，AI 能一口气帮你补完；甚至重构遗留代码，AI 也能给出比搜索引擎更直接的答案。

但这种“爽感”能持续多久？我在用 AI 辅助开发三个月之后，逐渐意识到一个问题：AI 写代码最大的麻烦不是“写不出来”，而是“写出来之后看不懂、不敢改、出了问题不知道怎么排查”。如果一直停留在“生成代码—复制粘贴—跑通即结束”的阶段，代码库会在不知不觉中积累大量“看起来能运行、实际上没人真正理解”的模块。

这篇文章不打算唱衰 AI 编程，也不打算继续吹“AI 让程序员失业”的论调。我想从自己的使用体验出发，系统拆解 AI 写代码三个月之后会遇到的真实问题：代码质量怎么保证、技术债怎么处理、AI 幻觉怎么识别、团队协作怎么定规范、以及如何从一个“AI 代码生成器用户”进阶为“AI 驱动的软件工程师”。

1. AI 写代码到底在解决什么问题？

1.1 从“搜索引擎时代”到“生成式编程”

在 AI 编程工具普及之前，开发者遇到不熟悉的 API 或复杂算法时，通常的做法是打开搜索引擎，输入关键词，翻几页博客，再把找到的示例代码复制到 IDE 里修改。这个过程的问题在于：搜索结果鱼龙混杂，示例代码经常过时，而且需要花大量精力去筛选和自己项目环境匹配的内容。

AI 编程工具改变了这个流程。它不再只是“给你一段参考代码”，而是可以基于你的项目上下文、你当前的代码风格、你正在使用的框架版本，生成更贴合需求的代码。GitHub Copilot、Cursor、Codex、通义灵码、Qwen Code 这类工具，本质上都是把“搜索引擎 + 文档 + 社区示例”压缩成了一个对话式或补全式的交互界面。

这里要注意一个概念区分：

• 代码补全工具（如 GitHub Copilot）：在写代码时自动预测下一段代码，适合保持“心流状态”。
• 对话式编程工具（如 ChatGPT、Claude、Codex）：通过自然语言描述需求，生成整段代码或给出修改建议，适合探索性任务和大型重构。
• Agent 形态的编程工具（如 Cursor Agent、Codex Agent）：不仅能生成代码，还能自行执行命令、运行测试、修改多个文件，已经接近一个“自动编码员工”的雏形。

1.2 AI 编程真正擅长的场景

根据我三个月的实际使用体验，AI 写代码在以下场景中确实有显著优势：

从表格可以看出，AI 写代码最擅长的是“有明确范式、有大量历史样本、重复性高”的任务。它不擅长的是“需要深入业务理解、需要权衡多个约束条件、需要创新性设计”的模块。

这也是“爽三个月”的核心原因——前期的项目往往包含大量 CRUD、脚本、配置、接口对接这类工作，AI 在这些场景下效率极高。而当项目进入深水区，开始涉及复杂的业务逻辑、微服务调用链、性能优化、并发控制时，AI 的局限就开始显现。

1.3 “AI 写得快”与“项目推进快”不是一回事

这是我在实践中感受最深的一点。

AI 可以在一分钟内生成 100 行代码，但这段代码是否正确、是否符合项目规范、是否考虑到了边界条件、是否引入了隐藏的安全问题，这些都需要人来判断。如果把“AI 生成速度”等同于“项目开发速度”，就会陷入一种错觉——觉得自己的产出很高，但实际上去掉审查、调试、返工的时间，整体效率可能并没有想象中提升那么多。

更关键的是，AI 生成的代码越复杂，你需要花在理解它上面的时间就越多。你不可能保证每一段 AI 生成的代码都能直接运行，更不可能保证它和你既有的架构完全一致。三个月的“爽感”背后，往往隐藏着一笔正在累积的“理解债”。

2. 三个月后，代码库发生了什么？

2.1 AI 生成代码的“风格不统一”问题

我在复盘自己项目的时候发现，AI 生成的代码虽然在语法上通常没有问题，但在代码风格上存在明显的“跳跃感”。同一个 module 里，可能同时存在：

• 手写的回调函数风格代码，和 AI 生成的 async/await 风格代码混杂；
• 有的类用了 Lombok，有的类手写 getter/setter；
• 日志打印有的用 slf4j 占位符，有的用字符串拼接；
• 有的地方封装了统一返回体，有的地方直接返回裸实体类。

这些代码单独拿出来都能运行，但放在一个项目里，读起来就像拼接了多个不同团队的作品。当项目规模扩大、需要多人协作时，这种风格不统一会直接降低代码的可维护性。

AI 生成代码的风格问题，根源在于训练数据来自海量开源项目，而这些项目本身的风格就是多样的。如果不通过系统提示词（System Prompt）或者项目级配置约束 AI 的输出风格，它就会“随机挑选”一种风格来生成代码。

2.2 重复代码和“过度生成”

AI 编程工具倾向于生成“完整性”更高的代码，这是好事，但也会带来一个问题：它经常生成冗余代码。

举个例子，我让 AI 写一个从 Kafka 消费消息并写入数据库的 Service 类，它生成的代码不仅包含了消费逻辑，还额外生成了：

• 一个单独的配置类；
• 一个消息体 DTO；
• 一个简单的事件监听器框架；
• 几段实际上不会被调用的辅助方法。

这在 Demo 阶段看上去很完善，但在实际项目中，这些额外代码往往是为了“凑完整性”而生成的，并不是业务真正需要的。它们增加了代码量，却没有增加对应的价值，反而让后续维护变得更加吃力。

另一个常见问题是重复代码。AI 生成的代码中经常出现“同一个工具方法在多个类里各有一份”的情况，因为它是根据当前文件上下文推测的，并不会检查整个项目里是否已经存在类似实现。这种重复在代码审查时不容易发现，但一旦需要修改公共逻辑，就要在多个地方同步修改，极易遗漏。

2.3 测试呢？—— AI 写代码最常见的盲区

很多人在享受 AI 写代码的便利时，会下意识地跳过测试。理由很直接：连业务代码都是 AI 生成的，再让它写测试，不是“AI 自问自答”吗？

但问题恰恰在这里。如果 AI 生成了业务代码，而你又不写测试（无论是 AI 帮你写还是手写），那么这段代码的正确性就没有任何保障。这三个月里，我见过太多 AI 生成的代码“看起来逻辑没问题”，实际上因为一个边界条件没处理，在特定输入下直接抛异常。

哪怕让 AI 写测试，也需要注意：AI 倾向于根据你给它看的实现代码来生成测试用例，也就是说，它写出来的测试往往只能覆盖代码“已经实现的路径”，很难发现代码逻辑本身的漏洞。这种测试在提升覆盖率指标上有效，但在发现隐藏缺陷上效力有限。

所以一个比较务实的做法是：AI 生成的代码，测试至少由人来补充关键边界场景，或者用 AI 生成测试后，人工 Review 覆盖路径是否足够。直接把生成的测试代码和业务代码一起贴进 PR 里，风险很大。

3. AI 幻觉与“看似正确”的陷阱

3.1 AI 幻觉是如何产生的

AI 编程工具的底层是大型语言模型，它的本质是“根据上下文预测最可能的下一段文本”，而不是“从数据库里精确查询答案”。因此，它有时会一本正经地生成一段完全虚构的 API、一个不存在的类名、或者一个错误的方法签名。

这类问题被称为“AI 幻觉”。在对话式 AI 里，幻觉相对容易被发现，因为你可以追问和验证；但在代码补全和 Agent 工具中，幻觉产生的代码如果刚好能通过编译，就很容易混入项目。

举几个我实际遇到的例子：

• 虚构的 Docker 镜像名：AI 推荐了一个看起来很像官方镜像的名字，实际查询后发现镜像不存在。
• 过时的 API 用法：AI 生成了旧版本的 SDK 调用方式，在当前版本中已经废弃或签名不同。
• 编造的配置项：AI 在生成配置文件时，加入了官方文档中根本不存在的新配置，生成后项目启动报错，排查了很久才发现是多余配置导致的。
• 不存在的开源项目：AI 在回答中引用了某个声称“很流行的库”，但搜索后发现完全不存在，或者名字相似但实际功能完全不同。

3.2 如何识别和防范 AI 幻觉

要完全消除 AI 幻觉目前不太现实，但可以通过以下方式降低它进入生产代码的概率：

1. 代码审查不能省：这是最基础也最有效的一道防线。即使 AI 生成的代码能运行，也该问一句：它用的 API 是不是当前项目依赖的版本里的？有没有用到废弃方法？
2. 运行前查看官方文档：当 AI 生成涉及不熟悉的框架或 SDK 代码时，不要直接复制，先去官方文档确认关键 API 是否真实存在。
3. 让 AI 给出参考来源：部分工具支持 AI 返回时引用文档链接，可以要求 AI 在生成代码时附带官方文档地址，再人工核对。
4. 从报错反推：验证 AI 生成代码是否靠谱的终极手段是让它跑起来。如果遇到网络上的报错信息，直接把报错贴回给 AI 工具，通常能够快速定位问题。

3.3 “像人写的代码”不等于“正确的代码”

在长期使用 AI 编程工具后，我还会遇到一种隐蔽的问题：AI 生成的代码读起来非常“自然”——变量命名合理，函数拆分明细，注释也写得规范，但逻辑本身是错误的。

这种错误不像“API 不存在”那样容易被编译器发现，它发生在业务逻辑层面。比如：

• 分页查询的分页参数写反了；
• 金额计算时出现了浮点精度问题；
• 并发情况下没有加锁，导致数据覆盖；
• 状态机的迁移条件漏掉了某个分支。

这些问题的出现，是因为 AI 并不理解你的业务，它只是在模仿“看起来合理的代码”的样子。越流畅、越自然的 AI 生成代码，越容易让人放松警惕，从而跳过深入阅读。真正的风险往往就藏在这种“看起来没什么问题”的代码里。

4. 从“AI 生成代码”到“AI 驱动开发”的进阶之路

4.1 第一阶段：把 AI 当作高级搜索引擎

这是大多数人使用 AI 编程的初始阶段。遇到不懂的知识点、不熟悉的 API、想找一个现成的代码示例，直接用 AI 提问。这个阶段的核心价值是“节省检索和筛选的时间”，类似用一个更聪明的搜索引擎。

在这个阶段，不太需要关注“AI 工程实践”的复杂问题，但需要留意的是：AI 的回答不一定全对，基本语法检查仍然依赖编译器。建议在这个阶段养成“看完文档再让 AI 写”的习惯，而不是完全让 AI 替你“猜”。

4.2 第二阶段：把 AI 当作结对编程搭档

进入这个阶段后，不再只是让 AI “给一段代码”，而是开始给它更完整的上下文。你会在 prompt 里写清楚：

• 项目使用的技术栈和版本；
• 要实现的接口定义；
• 现有的代码风格约束；
• 已知的边界条件和异常处理方式。

这个阶段特别适合让 AI 参与代码重构、编写单元测试、生成接口文档、分析复杂调用链。你会开始意识到，AI 的输出质量很大程度上取决于输入的上下文质量。Prompt 写得越清晰，AI 生成结果的可用率就越高。

这也是“AI 编程提示词”开始变重要的阶段。好的编程提示词不是“帮我写一个登录功能”，而是：

项目使用 Spring Boot 3.2 + MyBatis-Plus + MySQL 8.0。 现有用户表 user，包含 id、username、password_hash、status 字段。 请生成一个登录接口，要求： 1. 账号密码校验； 2. 登录成功后返回 JWT token； 3. 密码使用 BCrypt 加密验证； 4. 同一账号连续失败 5 次后锁定 10 分钟； 5. 使用统一的 Result 返回体封装。

这样的 prompt 提供的信息密度高，AI 生成的代码才可能贴合真实业务需求。

4.3 第三阶段：让 AI 参与软件工程设计

到了第三个阶段，AI 不再只是一个“编码工具”，而是可以参与设计讨论的“技术顾问”。这个阶段可以做的事情包括：

• 让 AI 对比不同技术方案的优缺点，辅助做技术选型；
• 让 AI 分析现有代码的坏味道，给出重构建议；
• 让 AI 生成多个备选的数据模型，人工判断后再细化；
• 让 AI 输出接口设计的草稿，再由团队评审。

这个阶段的挑战在于：AI 的建议依然可能流于表面，它无法理解你们的业务背景、团队结构、运维能力、交付压力。因此，在任何 AI 给出的“最佳实践”面前，都需要加上一层“人肉判断”：这个方案适合我们团队的现状吗？

AI 驱动开发的本质不是“让 AI 多干活，人少干活”，而是“把人的注意力从低价值的编码细节中释放出来，投入到更高层的设计、决策和代码审查中”。

5. 一套可以落地的 AI 写代码团队规范

5.1 哪些代码允许 AI 生成

根据实际项目的风险等级，可以给团队制定一个简单的 AI 代码适用矩阵：

强烈建议团队内部至少达成一个共识：AI 生成的代码，和手写代码一样需要走代码评审流程，不能因为“AI 生成的”就跳过 Review。

5.2 在 Prompt 层面约束代码风格

如果团队用了支持自定义指令的 AI 编程工具（如 Cursor 的 rules、GitHub Copilot 的 custom instructions），建议把项目的代码规范写进这些配置里。否则 AI 每次生成的代码都会存在随机风格差异。

例如，可以在 Cursor rules 里配置：

项目代码规范： - Java 版本：17，禁止使用已废弃 API； - 使用 Lombok 处理 getter/setter/构造器； - 所有接口返回 Result<T> 统一结构； - 日志使用 slf4j + logback，禁止 System.out.println； - Service 层必须处理事务边界，禁止在 Controller 中写业务逻辑； - 所有外部 API 调用必须设置超时时间和异常处理； - 数据库操作必须使用 @Mapper 注解和 MyBatis-Plus； - 禁止生成不存在的 pom 依赖； - 单元测试必须包含：正常流程、边界条件、异常分支。

这类规则越具体，AI 生成代码的风格就越可控。这比写一堆“请写出高质量的代码”之类无法衡量的提示词有效得多。

5.3 代码审查清单：AI 生成的代码重点看什么

针对 AI 生成代码的审查，建议额外关注以下内容：

1. 依赖版本是否与项目一致：AI 可能引入当前项目中没有的库，甚至是不存在的版本号。
2. 是否存在重复代码：检查当前项目中是否已经有类似的工具类、常量类。
3. 异常处理是否真实有效：AI 有时会生成空的 catch 块，或只打印日志不处理。
4. 并发安全：AI 生成的静态变量、单例 Bean 是否线程安全。
5. 资源释放：IO 流、数据库连接、HTTP 客户端是否都能正确关闭。
6. 业务逻辑完整性：不要被“代码写得很完整”迷惑，对照产品需求逐条核对。
7. 安全弱点：AI 生成的代码是否有 SQL 注入、XSS、越权等常见安全风险。

推荐把这条清单放在代码评审模板里，每次提交含 AI 生成代码的 MR/PR 时都要求 reviewer 对照检查。

6. 如何避免“三个月后吃老本”

6.1 不要只当 AI 的“复制粘贴员”

如果长期停留在“AI 写 → 我复制 → 修一下报错 → 提交”的循环里，三个月后你会发现自己的核心能力并没有提升：复杂问题定位能力、代码抽象能力、性能调优能力、架构设计能力，这些都是 AI 暂时无法替代的。而一旦项目遇到 AI 无法解决的问题，就会束手无策。

真正值得花时间锻炼的能力包括：

• 阅读和审查代码的能力：能快速判断 AI 生成的代码是好是坏。
• 系统设计能力：知道如何拆分模块、设计接口、选择合适的技术方案。
• 异常排查能力：能在复杂调用链路中快速定位问题根因。
• 业务理解能力：能把业务需求翻译成技术方案，这是 AI 目前最欠缺的。

6.2 把 AI 生成的代码当成“初稿”，而不是“成品”

一位前辈跟我聊过一个观点：AI 写代码就像请了一个经验丰富但没做过你们项目的实习生。它能快速给出一个“大多数人会这么写”的版本，但你必须亲自检查边界条件、异常处理、性能表现和是否符合团队架构。

这个心态转变很重要。当你把 AI 生成的代码当作“初稿”看待时，你就不会因为“它已经写得很完整了”而跳过审查。你会有意识地去修改、去完善，而不是被动接受。

6.3 善用 AI 做“学习伙伴”，而不是“答案机器”

AI 编程工具也是很好的学习工具。遇到不理解的报错，可以问“这个报错的根本原因是什么？”；看到一段复杂的算法，可以问“这段代码的每个步骤是做什么的？”；想了解一个框架的设计思想，可以问“为什么 Spring 要用三级缓存？”。

这样使用 AI，既能解决当下的问题，也能逐步加深对技术原理的理解。把 AI 当作“答案机器”只是获得暂时的答案，把 AI 当作“学习伙伴”才能获得长期的能力提升。

6.4 建立自己的“AI 工程实践”沉淀

最后，建议维护一份属于自己的 AI 编程笔记，记录：

• 哪些类型的 prompt 生成质量最高；
• 哪些项目的代码不适合让 AI 生成；
• 遇到 AI 幻觉时的识别特征；
• 团队里总结的代码审查清单；
• 各 AI 工具在不同场景下的表现对比。

这些经验会随着时间积累成为一种“工程判断力”。它不仅能帮助你更高效地使用 AI 编程工具，也能在团队内部形成可复用的知识资产。

7. 一个可参考的 AI 辅助开发流程

分享一个我在后端项目中较常使用的 AI 辅助开发流程，不一定适合所有团队，但可以作为参考。

7.1 需求分析与技术方案阶段

• 人工主导：梳理需求、确认边界条件、识别风险点。
• AI 辅助场景：让 AI 帮忙列出不同技术方案的优劣，生成接口定义草稿。

7.2 编码阶段

• 人工主导：编写核心业务逻辑、安全敏感代码、复杂算法。
• AI 辅助场景：生成 CRUD 代码、单元测试、数据格式转换、DTO/VO 转换、配置文件、脚本。

7.3 自测阶段

• 人工主导：设计关键测试用例，尤其是异常边界。
• AI 辅助场景：让 AI 生成基础单元测试、构造 Mock 数据、生成压测脚本。

7.4 代码评审阶段

• 人工主导：执行代码评审清单，重点检查业务逻辑和安全隐患。
• AI 辅助场景：让 AI 做一次“静态代码扫描”，帮忙找出可能的空指针、资源泄漏、重复代码。

7.5 发布与线上监控阶段

• 人工主导：确认发布方案、回滚方案、监控告警规则。
• AI 辅助场景：让 AI 帮忙分析日志、排查报错、生成告警联动方案。

这套流程的核心逻辑是：AI 负责高重复、高确定性、低风险的工作，人负责高不确定性、高风险、需要业务理解的工作。

8. 三个月后，我的真实建议

如果现在有人问我“用 AI 写代码三个月后是什么感受”，我会说：前期效率确实提升明显，但三个月才是真正开始考验工程素养的时候。

AI 可以帮你写代码，但不会帮你理解代码；AI 可以帮你生成测试，但不会帮你思考测试覆盖是否合理；AI 可以帮你快速完成功能，但不会帮你保证系统的长期可维护性。

如果你能在这三个月的“爽感”里，同步建立起代码审查意识、Prompt 工程习惯、AI 幻觉防范机制、团队协作规范——那 AI 写代码就是真正的效率加速器。如果只是单纯享受“生成速度”带来的快感，那三个月后，你大概率会面对一个自己也不敢随便改动的代码库。

最后分享一个很实用的小技巧：在每天的工作结束前，花十分钟快速回顾一下当天 AI 帮你生成的代码，问自己三个问题：

1. 这段代码我彻底理解了吗？
2. 如果它出了问题，我能快速定位并修复吗？
3. 换了一个需求，这段代码还能直接复用吗？

这三个问题的答案，决定了你是“AI 编程工具的使用者”，还是“被 AI 编程工具使用的复制粘贴员”。