首页科技快讯 AI生成代码速度像“开挂”，一上线却疯狂“踩雷”！

AI生成代码速度像“开挂”，一上线却疯狂“踩雷”！

来源：晰数塔互联网快讯时间：2025年11月22日 08:09

AI 写代码的速度已经快到离谱了，一句话就能生成一堆“看起来能跑”的函数。但问题是：这些代码真正上生产环境后，往往不是崩就是漏，维护成本甚至比人类敲的还高。我们现在遇到的，不是“代码不够多”，而是“代码不靠谱”。那么，既然生产力爆炸了，为什么可靠性没跟上？又该怎么补上这块短板？这成了所有工程团队必须面对的新问题。

原文：https://thenewstack.io/ai-code-doesnt-survive-in-production-heres-why/

作者 | Animesh Koratana责编 | 苏宓

出品 | CSDN（ID：CSDNnews）

我几乎每天都能看到类似的 AI 演示：只用一个提示词，就能生成一款完整的应用。对着 AI 助手，输入几句自然语言之后，啪的一下，一个“打磨精良”的产品就出现了。

但在这些火爆的趋势背后，有个耐人寻味的事实：我们并没有看到成品软件数量的提升，也没有看到预期中的创新速度。

谷歌一位工程副总裁近期说过一句话：“如果大家知道有多少 LLM 生成的代码真正进入生产环境，一定会震惊。”

尽管 AI 生成代码的演示十分精彩，各种 AI 初创公司也获得了数十亿美元的资金支持，但 AI 生成的软件原型和真正可投入生产的系统之间，仍然存在巨大鸿沟。

问题出在哪？答案其实藏在三个根本性挑战里：

全新技术栈 vs. 现有技术栈：AI 非常擅长不受任何限制的原型设计，但难以与现有系统集成。此外，在生产环境中运行有各种硬性要求，也会让软件原型变得脆弱不堪。

“多莉（Dory）问题”：AI 无法调试自己的代码，因为它没有持续性的理解能力。不会记住过去的错误，也缺乏排查系统问题所需的上下文。

工具成熟度不一致：虽然代码生成工具发展十分迅速，但部署、维护、代码审查、质量保障、客户支持等环节依然停留在 AI 时代之前的速度。

下面具体来看看。

全新技术栈 vs. 现有技术栈

LLM 可以在理想状态下快速构建出一个新的微服务，使其在独立的环境里面运行良好。但一放到生产环境时，却完全是另一回事：在接入时，需要面对遗留代码、服务边界、数据契约、授权中间件、Protobuf schema、CI/CD 流水线、可观测性堆栈、SLO、性能预算……还没算上真实用户使用时会出现的各种不可预测的情况。

开发新软件时，其实更像是在做艺术创作。首先，你需要构想软件的预期行为，譬如：数据应该从初始状态流向目标状态，中间按既定的控制流程完成转换。相当于你是在“从无到有地作画”。

这也是为什么 AI 编码助手能做出让人惊叹的原型：它们非常擅长这种面向未来、毫无束缚的创造性生成。

但要让软件在生产环境里稳定、高质量地运行，靠“更多代码”是行不通的。

你需要的是能在一组明确且细致的参数范围内运行的代码。而要把这些复杂而细微的参数准确传达给一个 LLM，本身就不是一件容易的事。

虽然 LLM 擅长用自然语言与我们交流，但我们往往高估了它编写高质量软件的能力。毕竟自然语言是灵活且包容的，而代码不是。

代码必须可执行、可组合，正确性依赖文件与服务之间精确的契约。编译器和运行时环境容错率极低——微小错误都可能引发连锁崩溃、出现安全漏洞，或导致性能退化。

“多莉（Dory）问题”

前面我们已经说过，现有 LLM 很难写出能在真实复杂环境中正常运行的代码。那么为什么不能用 AI 来排查和调试这些代码呢？

要做好调试，你必须对整个架构有“全局脑图”，了解整个架构。对此，你得理解数据在系统中实际是怎么流动的，而不是它从理论上来说“本该”怎么流动。你需要具备从缺陷开始“逆向剖析”系统的能力，需要模型能够消化那些历经数十年构建的庞大系统，理解它们为什么会以特定方式运行。你需要知道系统里已有的东西、走过的路，以及那些被放弃的路径。

遗憾的是，大多数 LLM 的运行方式更像《海底总动员》里的多莉：查询之间没有持续性的上下文，而且记忆极其短暂。

现实中，很多公司维护的代码库已经有 20、30、甚至 40 年历史。这些系统会出现“涌现行为”、隐式依赖和历史遗留的各种权宜之计，它们是技术债不断积累的结果。如果没有对整个系统架构、多个仓库之间的关联、以往的决策和上线记录有足够理解，想排查复杂问题几乎是不可能的。