Translate the following blog post title into English, concise and natural. Return plain text only without quotes. AI 生成代码速度像“开挂”，一上线却疯狂“踩雷”！
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 年历史。这些系统会出现“涌现行为”、隐式依赖和历史遗留的各种权宜之计，它们是技术债不断积累的结果。如果没有对整个系统架构、多个仓库之间的关联、以往的决策和上线记录有足够理解，想排查复杂问题几乎是不可能的。
工具成熟度不一致
AI 生成的代码难以进入生产环境，另一大原因是：软件交付生命周期（SDLC）中用于支撑 AI 的工具，并没有同步成熟。
以数码相机的演变为例。最初的数码相机长得和胶片相机几乎一样——因为我们当时无法想象更好的应用方式。但很快我们意识到，相机可以嵌入任何地方：笔记本、手机、门铃、汽车。相机不再只是用来拍照，还能帮你导航。
AI 代码生成工具也经历了类似的快速迭代。刚开始，我们尝试把 AI 塞进 IDE，就像把相机做成“数码单反”。最早的 GitHub Copilot，本质上只是更聪明的自动补全。
但过去几年里，Cursor、Windsurf、Claude Code 等工具出现后，情况完全变了。它们构想的是一整套新的工作流：你不再直接写代码，而是在聊天框里表达意图，然后代码自然发生改变。你从“写代码”转变为“描述你想让系统做什么”。
如今的 AI 代码生成已经进入第二代产品，整个工作方式都被改写了。但放眼代码生成以外的 SDLC 其他阶段，我们很多工具仍停留在第一代。如果我们真想提升工程效率，必须跳出“只关注代码生成”的思路，转向 AI 驱动的端到端 SDLC 重构。
前进的方向
如今已经有不少工具在尝试解决现代软件运维的问题，但它们仍然把整个流程拆成一个个相互孤立的环节来看。它们可以打造出非常好用的“数码相机”，却却缺乏从零重构整个运维流程的想象力。
你当然可以通过更强的 AI 代码审查系统，或者引入一个“智能代理版”的 SRE（站点可靠性工程师）获得一些渐进式提升。但真正的大突破，不会来自对现有流程的局部优化，而是来自那些能够重新设计整条软件运维链路的工具。
想要在生产环境中真正发挥作用的 AI 工具，需要具备以下几项关键能力：
-
能逆向理解复杂系统；
-
能系统化地枚举各种状态；
—— 能帮助开发者精准定位导致异常行为的特定条件。
换句话说，它们不仅要像艺术家一样擅长创造，还要像科学家一样擅长调查与推理。而且必须从整体出发看问题，而不是只盯住某一个环节。
在此之前，我们只能继续看到惊艳的原型，和令人沮丧的生产环境体验。
这种“认知错位”短时间内不会消失——它根植于这些系统的工作方式本身。
