我用 AI 写了十个月代码， 烧了几万块Token之后

从去年到现在，接近十个月的时间里，我几乎已经完全脱离了手写代码。

这段时间累计消耗的 Token，按价格估算应该已经超过 3 万元人民币。我使用过 Claude 4.x Opus 系列、GPT-5 系列、GLM-5 系列、DeepSeek 3.2、DeepSeek 4 等模型，也使用过 Claude Code、Codex、CodeBuddy 等编程 Agent。市面上比较主流的大模型和 Coding Agent，我基本都体验过。

单纯从效率来看，AI 辅助编程带来的提升非常明显。以代码产出量计算，AI 至少将我的开发效率提高了五倍。毫不夸张地说，我提交到项目仓库中的代码几乎全部由 AI 生成，我们团队中的大部分开发者也是如此。依靠这种开发方式，我们的项目在半年多时间里赶超了部门内另一个方向相似的项目，并获得了部门的里程碑奖。

从表面上看，这是一幅非常理想的图景：AI 像一台自动化机器一样源源不断地生成代码，功能快速上线，项目高速迭代。但经过近十个月的高强度使用，我逐渐意识到，AI 只是大幅降低了代码的生成成本，并没有自动解决软件工程中的问题。相反，当代码产出速度提高数倍后，项目原有的问题也可能被同步放大。

一、AI 辅助开发中暴露的问题

1. 代码越来越多，Bug 并没有减少

AI 全面参与开发后，代码量出现了几何倍数的增长，但 Bug 并没有因此减少。在实际项目中，用户每天仍然会反馈各种问题。更多代码带来了更多功能，同时也带来了更多可能出错的路径。我们的项目在半年多时间内经历了多次大版本迭代，每一次都涉及产品形态和已有模块的大范围重构。

AI 带来的高效率，也在一定程度上增强了产品和决策团队快速迭代的信心。过去需要谨慎评估的改动，现在可能会被更加激进地推进。团队很容易产生一种错觉：既然代码生成得很快，那么推翻、重构和重新实现的成本也很低。

但代码写得快，并不代表理解、验证和维护代码的成本也同样降低。频繁的大规模修改，反而会进一步提高问题出现的概率。

2. AI 生成的代码经常只有表面的可用性

如果只是从产品经理的角度描述需求，或者直接将 PRD 交给 AI，再根据运行现象不断反馈和微调，AI 确实可以生成一套看起来符合要求、也能够运行的代码。

但当我真正深入查看实现细节时，经常会发现里面存在很多问题。这些代码可能完成了表面的功能，却没有真正遵循项目原有的设计，也没有正确处理模块之间的关系。

我不止一次在深入 Review 某个功能的调用链路时，发现整条链路实际上都是死代码，没有任何真实作用。但当我询问 AI 时，它通常会非常自信地解释这段代码的“重要作用”。直到我反复确认，并指出其中一两个关键问题以后，它才会承认这条链路确实没有意义。

更严重的问题在于，一旦这些代码进入仓库，AI 几乎不会主动重新审视和整理它们。相反，这些代码会成为下一次生成代码时的上下文。错误的实现会成为新的基础，混乱的设计也会继续向后传播。当 AI 在基础模块中犯了错误，后续所有依赖该模块的开发，都可能继续继承这些错误。

如果功能没有立即出现明显 Bug，很少有人会主动质疑已有实现。AI 生成的代码和注释通常又写得非常完整，看起来很有道理，开发者反而不敢轻易修改。这些问题短期内可能不会产生影响，但当用户触发某些边界情况时，就可能突然暴露。

3. AI 容易产生冗余代码和扭曲的实现

AI 倾向于生成看起来“非常完整”和“非常安全”的代码。例如，它经常会为简单错误增加多层兜底，为很少发生的情况设计多套降级方案，或者在简单逻辑中加入大量 if-else，用于处理一些在真实业务中几乎不可能出现的路径。这些代码单独看似乎都有理由，但组合起来以后，会明显增加系统复杂度。

另一个常见问题是，当新需求与已有架构不兼容时，AI 通常不会主动停下来分析是否需要调整架构。它更倾向于在现有结构外增加适配层、包装层和特殊分支，通过绕路的方式完成表面功能。

这样做可以减少当前的修改范围，也更容易快速交付，但最终的实现往往比较扭曲。随着需求不断叠加，这些绕路方案会形成越来越多的兼容逻辑和特殊处理，最终变成难以维护的冗余代码。AI 更擅长解决局部问题，但不总能判断什么时候应该继续增加逻辑，什么时候应该停下来重构整体设计。

4. AI 无法解决项目中的信息差

即使 AI 是一个能力很强的代码专家，它也无法在缺少信息的情况下作出正确判断。

真实项目中存在大量只属于项目内部的知识，例如：

• 某个接口为什么要保留一个看起来多余的字段；

• 某段逻辑为什么暂时不能删除；

• 某个数值在不同开发版本中代表什么；

• 某个模块为什么采用了特殊的实现方式；

• 某次线上问题留下了哪些兼容约束；

• 哪些历史逻辑虽然已经废弃，但当前仍然需要保留。

这些信息可能只存在于部分长期维护项目的开发者脑海中，也可能只在口头沟通、聊天记录或者历史会议中出现过。

如果 AI 没有获得这些信息，就只能根据代码表象进行猜测，因此非常容易出错。我曾经为了一个奇怪的 Bug 排查了几个小时，最后发现，原因只是接口传值时有一个与开发版本有关的数值传错了。从代码本身来看，很难理解这个数值的真正意义。只有了解项目历史背景的人，才能迅速定位问题。

这类问题并不能单纯依靠更强的模型解决。只要信息没有被记录，AI 就不可能自动知道。

二、如何降低 AI 辅助开发的风险

1. 持续记录文档和项目知识

前段时间，我听了一次微信支付相关负责人的分享，其中提到了两个对 AI 辅助开发长期实践非常重要的关键点。

第一个关键点是文档积累。

任何长期维护的项目，都会形成大量历史债务、业务规则和特殊约束。

这些知识不是通用的软件工程知识，也不是模型通过训练就能掌握的内容。它们只属于某个项目、某个团队或者某个历史阶段。

如果这些信息只存在于开发者脑海中，那么当 AI 修改相关模块时，就很容易踩坑。因此，在 AI 辅助开发环境下，项目留痕会变得比过去更加重要。

团队至少应该持续记录以下内容：

• 架构设计以及这样设计的原因；

• 关键技术决策；

• 重要业务规则；

• 历史兼容逻辑；

• 已知限制和常见问题；

• 线上问题复盘；

• 不允许随意修改的模块边界；

• 不同版本之间的差异。

文档是 AI 理解项目私域知识的重要渠道。

没有这些信息，AI 再强，也只能基于不完整的上下文作出判断。

2. 建立完善的自动化测试

第二个关键点是测试。

AI 辅助开发后，代码产出量可能增长数倍。很多产品迭代不仅涉及新增功能，还会涉及对已有模块的重大调整。

这会引出一个核心问题：

我们如何确定 AI 的修改没有破坏已有功能？

只依赖开发者经验进行人工 Review，很难真正保证。

我所在团队负责的是一个启动半年左右的新项目，目前仍处于快速迭代阶段。项目已经经历了不下三个大版本，每一次都涉及产品形态的大范围重构。

由于项目还比较新，测试体系没有完全建立。即使是在我长期负责、非常熟悉的模块中，迭代时也偶尔会出现一些疏漏。

修改代码时，开发者可能已经尽量考虑已有的历史问题和业务边界，但仅靠个人记忆和人工检查，仍然很难完全避免问题。

完善的测试用例不仅用于检查 AI 是否完成了新需求，更重要的是验证它有没有破坏旧功能。

当 AI 可以在短时间内修改大量文件时，自动化测试实际上是在为这种高速度提供安全边界。如果缺少测试体系，那么 AI 提升的只是改代码的速度，而不是稳定交付的速度。

3. 控制任务范围，让 AI 小步修改

一个项目开发伊始，慢就是快。

新项目刚开始时，需求边界通常并不清晰，架构也没有稳定下来。如果开发者此时直接要求 AI 从零生成完整系统，AI 往往会一次性生成数百行甚至数千行代码。巨大的代码量会给开发者带来很高的 Review 成本。

面对一套已经可以运行、功能看起来也比较完整的代码，开发者很容易被动地选择接受。但这些代码中可能隐藏着大量冗余逻辑、不合理抽象和错误的架构判断。等到代码积累到一定规模后，再想重新整理，往往需要付出更大的时间和精力。

更合理的方式是，先由开发者建立基本框架，明确模块边界，然后采用小步推进的方式，让 AI 每次只完成一个小任务或者一个局部模块。每次生成几十行代码，可能看起来不如一次生成几千行代码那么高效，但开发者可以持续理解代码，及时纠正方向，并保证后续实现遵循已有结构。

一个合理的初始框架，也会成为 AI 后续生成代码时的重要约束。

4. 用工程规则约束 AI，而不是完全依赖提示词

现在关于 Loop Engineer 和无人值守开发的讨论越来越多。

理想情况下，AI 可以自动读取需求、编写代码、执行测试、发现问题并修复问题，持续循环直到完成任务。但从我的实际使用体验来看，要实现完全无人监控的项目开发，仍然存在很大阻力。

AI 在函数级、局部模块级的编程任务中通常表现较好。只要输入输出明确、影响范围有限、验收标准清楚，它可以较稳定地完成任务。

但当任务涉及多个模块、复杂业务状态和历史兼容逻辑时，AI 很容易因为上下文不足而作出错误判断。

同时，AI 经常倾向于走捷径。如果一个需求无法直接在现有架构下实现，它可能不会暂停并询问用户，而是通过某种不符合项目架构的方式完成表面功能。

因此，不能只依靠提示词告诉 AI“代码要写得好一点”，而应该通过工程手段进行约束，例如：

• 明确目录和模块边界；

• 维护代码规范和架构文档；

• 使用静态检查和类型检查；

• 限制单次修改的文件数量；

• 要求修改前先输出方案；

• 要求新增功能同时补充测试；

• 使用单元测试、集成测试和端到端测试进行验收；

• 对核心模块保留人工 Review。

我们的团队在 AI 应用方面比较激进，甚至将仓库开放给产品经理，让产品经理可以通过 Vibe Coding 直接修改并提交代码。

这种方式确实缩短了从需求提出到功能实现的链路，但也带来了风险。

产品经理通常更加关注功能是否实现、页面是否符合预期，而不一定能够判断代码是否符合架构、是否影响已有模块、是否引入了技术债务。AI 降低了修改代码的门槛，但降低门槛并不等于取消工程约束。

越多角色能够直接修改代码，团队越需要建立严格的合并流程、测试要求和质量标准。

三、总结

近十个月的使用让我确认，AI 辅助编程确实是一种巨大的效率提升。

它可以快速生成代码、补充实现、修改功能和分析问题，也能够显著降低大量常规开发工作的成本。但 AI 并没有让软件工程中的基本规律失效。架构仍然重要，测试仍然重要，文档仍然重要，代码 Review 仍然重要，开发者的判断仍然重要。

AI 可以把代码产出速度提高五倍，但如果项目的工程能力没有同步提高，那么技术债务、Bug 和维护成本也可能以更快的速度增长。

过去，开发者的大量时间花在如何把代码写出来。

未来，开发者更重要的工作可能会变成：

• 定义问题和验收标准；

• 划分合理的任务边界；

• 设计和维护系统架构；

• 为 AI 补充项目上下文；

• 判断 AI 的实现是否合理；

• 建立测试和质量保障体系；

• 控制技术债务。

至少在现阶段，AI 还不是一台可以完全替代开发团队的自动代码机器。

它更像是一个速度极快、知识丰富，但缺少项目记忆、容易过度实现，也不会主动承担长期维护责任的开发者。

如何使用和约束 AI，决定了它最终是项目的加速器，还是技术债务的放大器。在我的实际使用过程中，AI 第一次生成的代码中，大约有 40% 会被我拒绝。我需要修改指令、补充上下文、调整实现方向，然后要求它重新生成。

这说明 AI 辅助开发并不是简单地描述需求，然后接受代码。开发者仍然需要判断实现是否符合架构、是否引入了不必要的复杂度，以及是否会影响已有功能。AI 降低了代码编写成本，但没有消除判断成本。