AI在生成原型方面表现出色，但在实际生产环境中面临三大挑战：与现有技术栈集成困难、调试能力不足（“多莉问题”）、以及部署维护等工具链成熟度不一。AI擅长从零开始的创造，却难以处理复杂的遗留系统和进行有效的故障排查。未来的AI工具需整体性地革新软件开发生命周期，而不仅仅是代码生成，才能弥合原型与生产间的鸿沟。
译自：AI Code Doesn't Survive in Production: Here's Why
作者：Animesh Koratana
我每天都会看到一个新演示，看起来大致如此：一个提示就能生成一个完整的应用程序。几行自然语言，瞧：一个精致的产品就出现了。然而，尽管这些趋势广为流传，一个令人困惑的事实却持续存在：我们没有看到已发布产品数量的增加，也没有达到我们预期的创新速度。
一位谷歌工程副总裁最近被引用说：“如果人们知道有多少LLM代码真正投入生产，他们会感到震惊。”尽管有令人印象深刻的演示和数十亿美元的资金，人工智能生成的原型与生产就绪系统之间仍存在巨大差距。但为什么呢？真相在于以下三个基本挑战：
- 从零开始（Greenfield）与现有技术栈：人工智能擅长无限制的原型开发，但难以与现有系统集成。除此之外，在生产环境中运行会施加严格限制，使原型变得脆弱。
- 多莉问题（The Dory problem）：人工智能难以调试自己的代码，因为它缺乏持久的理解能力。它无法从过去的错误中吸取教训，也无法获得足够的上下文来排除系统故障。
- 工具成熟度不一致：尽管人工智能代码生成工具发展迅速，但部署、维护、代码审查、质量保证和客户支持功能仍以人工智能时代之前的速度运行。
从零开始（Greenfield）与现有技术栈
大型语言模型（LLM）可以在隔离的环境中快速起草一个表现良好的新微服务。但在生产环境中运行需要与混乱的现实集成：遗留代码、服务边界、数据契约、授权中间件、protobuf schema、CI/CD 流水线、可观测性堆栈、服务水平目标（SLO）、性能预算……我还可以继续列举。所有这些都发生在不可预测的用户与软件交互之前。
当你构建新软件时，你参与的是一个可以称之为艺术的过程。你从对预期行为的设想开始：数据应该从这个初始状态流向这个最终状态，通过特定的控制流以这种特殊方式进行转换。你是在用可能性作画，从无到有地创造事物。
这就是为什么人工智能编码助手能产出如此令人印象深刻的原型。它们在这种前瞻性、无约束的创造性生成方面表现非凡。但是，要良好运行高质量的软件，更多的代码并非答案。你需要能够在非常具体的参数集内运行的代码。挑战在于，将这些众多而细致的参数传达给LLM并非易事。
因为LLM擅长用自然语言与我们交流，我们高估了它们编写高质量软件的能力。但是，尽管语言灵活且宽容，代码却不然。代码是可执行和可组合的：正确性取决于文件/服务间精确的契约。编译器和运行时是无情的；小错误会导致连锁故障、安全漏洞或性能退化。
多莉问题（The Dory Problem）
我们已经确定，当前的LLM难以编写能在受控的从零开始（greenfield）环境之外运行的代码。但为什么我们不能用人工智能来排除故障和调试这些代码呢？
要正确调试，你需要全面了解整个架构。你需要理解数据在系统中实际的流动方式，而不仅仅是它应该如何流动。你需要从缺陷开始逆向工程系统的能力。你需要能够处理数十年构建的庞大复杂架构并理解它们行为方式的模型。你需要了解已存在的事物、过去发生的一切以及未曾选择的路径。
不幸的是，大多数LLM的运作方式很像《海底总动员》中的角色多莉：它们在不同查询之间没有上下文，记忆力极短。
许多公司运行着累积了20、30甚至40年的代码库。这些系统具有涌现行为、隐式依赖和历史遗留的权宜之计——这是其技术债务的复利。如果没有对整个系统架构、多个代码仓库的互连、过去的决策和部署的广泛理解，几乎不可能排除复杂问题。
工具成熟度不一致
人工智能代码在生产环境中表现不佳的最后一个原因是，支持软件交付生命周期（SDLC）的人工智能工具并非都以相同的速度成熟。以数码相机的发展为例。第一批数码相机看起来很像它们的模拟同行——我们无法想象另一种应用该技术的方式。但很快我们了解到可以将摄像头嵌入到任何地方：从笔记本电脑到手机，从门铃到汽车。摄像头不再仅仅用于拍照；它们还可以帮助我们从A点到达B点。
尽管只过了几年，人工智能代码生成工具已经经历了快速转型。我们最初尝试将人工智能整合到SDLC中，看起来很像将人工智能嵌入到我们的IDE中——这相当于一台数码单反相机。GitHub Copilot的最初版本本质上是增强型的IDE自动补全。
但在过去几年里，像 Cursor、Windsurf 和 Claude Code 这样的工具以一种截然不同的方法占据了主导地位。它们设想了一种全新的工作流程，你根本不需要实际编写代码。你不是在代码编辑器中工作，而是在聊天框中表达你的意图，代码的改变自然而然地发生。
今天的人工智能代码生成标准是改变了整个工作流程的第二代产品。但当我们超越代码生成，审视SDLC的其余部分时，这些产品仍处于第一代。如果我们真的想提高工程速度，我们需要超越代码生成。我们需要能够帮助我们用人工智能重新构想和管理端到端SDLC的工具。
前进之路
有许多工具致力于解决现代代码操作，但它们都是孤立地看待过程中的每一步。它们正在构建非常有效的数码相机，但却没有从头开始重新思考整个过程的想象力。
你可以从更好的人工智能代码审查系统或代理型站点可靠性工程师那里获得增量收益，但最大的进步将来自于那些重新思考整个软件操作过程，而不仅仅是增强现有过程的工具。
那些能够成功帮助运营生产环境的人工智能工具，将是那些能够逆向工程复杂系统、系统地枚举状态并帮助开发人员找出产生意外行为特定条件的工具。它们需要不仅仅是艺术性的构建者——它们还必须是科学的调查者。而且它们将整体地看待问题，而不是孤立地。
在此之前，预计会看到令人印象深刻的原型和令人沮丧的生产体验。认知不匹配不会消失——这是这些系统工作方式的基础。
