过去两年，AI 生成代码的Demo一个比一个炸裂：
一个 prompt，整个应用直接出来；几句自然语言，啪的一下，一套后台系统就生成了。
看上去，软件开发似乎要进入“无限加速”的时代。但现实的魔幻程度只有身处其中的团队有体会：
相应上线的产品数量并没变多，也没看到期待的创新速度，甚至不少团队感觉比以前更累。
谷歌一位工程副总裁曾说过一句很扎心的话：
“如果大家知道 LLM 生成的代码真正进到生产里的比例有多低，一定会非常震惊。”
为什么从“100 行代码 1 秒出”到“上线”之间，会有这么深的黑洞？
近日，一位技术背景极丰富的AI初创公司PlayerZero的创始人 Animesh Koratana 给出了一个非常深刻的观察。他指出，这个问题其实并不是因为大模型还不够好，责任页并不是出在 AI Coding 产品侧。
答案其实很简单，但常被忽略：AI 写代码强，但生产环境不只是写代码。原因主要来自三个根本挑战：
全新项目（greenfield） vs 既有技术栈：AI 在没有约束的原型环境里表现极佳，但在真实生产环境里，它面临各种硬性限制，代码会变得非常脆弱。
“多莉问题”（Dory Problem）：AI 无法持久理解，也记不住自己的行为，因此很难有效调试代码。
工具成熟度不一致：代码生成工具进步极快，但部署、维护、代码审查、质量保证、客服等工作流程仍停留在“前 AI 时代”。
一、AI 在“真空环境”里很强，一接入真实系统就露馅
AI 擅长的是“从零开始造一个东西”。在真空环境中，LLM 可以很快起草出一个新的微服务，并且在隔离情况下运行良好。
开发新软件其实是一种“艺术过程”。你从一个想象的行为路径开始：数据如何从初始态流向最终态，如何被转换，如何被控制流处理。这种“从无到有的创造性过程”，AI 完成得非常漂亮。
这正是为什么 AI Coding 的原型效果如此惊艳——它擅长面向未来的、无约束的创造。
但绝大多数生产软件，并不是从零开始造，而是接入一个堆了 10 年、20 年的系统。
只要进入生产，在用户使用这款软件之前，AI 就必须接入各种“真实世界的混乱”：
各种历史遗留代码、服务边界、数据契约、认证逻辑、protobuf schema、CI/CD 流程、可观测性体系、SLO 与性能预算、若干代工程师留下的补丁……
随便一个环节，就能让原本“完美运行”的原型代码瞬间脆到不行。
生产环境下的软件，真正的问题并不在于“写更多代码”，而在于“写在严格边界内也能正常运行的代码”。
而把这些复杂、细腻的运行参数都准确传达给一个 LLM，本身就是个艰难的任务。
可能因为 LLM 能用自然语言跟我们交流得很好，大家自然就高估了它写高质量软件的能力。但语言是宽容的，代码不是。代码是可执行的、结构化的，它的正确性必须跨文件、跨服务保持精确契约。
毕竟，编译器和运行时可不会对错误留情：小错误就能导致级联故障、安全漏洞或性能崩塌。
AI 还停留在理想国，工程师却活在人间。AI 写的代码不稳定，不是因为它不聪明，而是因为它还不知道真实世界有多么艰辛复杂。
二、“多莉问题”：5 秒前发生的事它就忘了
现在，我们已经知道当前 LLM 在受控环境之外写代码有困难。那还有一条思路，即，为什么不能反过来让 AI 来Debug这些代码？
想法很好，但遗憾的是，真正的 Debug，需要的却不是大模型的“聪明”，而是：
读懂几十年累积下来的系统架构，以及它为什么会是现在这个样子
弄清楚数据真实的流动方式，而非设计文档中的理想流动方式
理解历史遗留的每一个 workaround
追踪多个代码仓库的交互
从一个缺陷逆推整个系统的状态
换句话说，你需要理解系统的“当下”和“过去”。但绝大多数 LLM 的思维方式更像《海底总动员》里的多莉：上下文极短，没有记忆，无法把前后语境联系在一起。
“我是谁？我刚刚做了什么？算了，从头来吧。”
当你的代码库有 20~40 年的维护历史时，这种记忆模型根本不够用。这里面有涌现的行为、隐含依赖、历史妥协，是技术债务的复利。
没有对整个系统架构的广泛理解，没有对多个代码仓库、历史变更、过去发布情况的掌握，你几乎不可能调试真正复杂的问题。
这也是为什么 AI 可以快速生成一个“看上去能跑”的模块，但当它试图修自己写的 bug 时，立刻跑偏。AI 缺的是“持续理解”，缺的是“系统级记忆”。没有记忆，就没有真正的调试能力。
三、工具成熟度不一致
AI 代码难以在生产站稳脚跟的最后一个原因，是因为支撑整个软件生命周期（SDLC）的工具成熟度并不同步。
这里，历史上也有一个可类比的例子：数码相机。
最初的数码相机只是模拟胶卷相机的外形，只是“把数字技术塞进旧框架”。
但一旦人们明白可以用更广的想象空间，摄像头就无处不在：电脑、手机、门铃、汽车。它现在已经不止用来拍照，还可以用来导航等等。
AI 代码生成工具也经历了类似变化。
第一代产品（例如最初版的 GitHub Copilot）就像“把 AI 塞进 IDE”，本质是超级自动补全。
但近几年，Cursor、Windsurf、Claude Code 等产品彻底改变了工作流：你不再写代码，而是在对话框里表达意图，代码自然发生变化。
可见，现在的代码生成已经进入第二代，重新定义了编码方式。
但这仅仅改变了“写代码”这一段。软件上线不是写完就完了。剩下的流程都没跟上 AI 的速度：
代码生成之外的 SDLC 其他环节——部署、测试、维护、支持——还停留在第一代。
这就造成了很尴尬的效率不升反降的境地：
AI 嗖嗖地加速写代码，人类却在泥沼里给AI修Bug。
如果我们真的想提升工程效率，就必须超越“写代码”这一步，重新想象整个 SDLC 的工作方式。
四、前路在哪里？
今天市场上有很多致力于现代软件运维的工具，更多还是在老流程上贴 AI：
AI 代码审查、AI SRE、AI 文档助手、AI 监控助手……
但这些工具往往是“各管一段”。它们依然在打造各自更好的“数码相机”，缺乏从零重塑整个流程的想象力。
固然，一个更好的 AI 代码审查工具或一个 AI 版本的 SRE 能带来增量效率提升，但真正的突破，来自重新设计整个端到端的软件运维流程，而不是给旧流程“上一层 AI”。
未来能在生产环境真正帮到工程师的 AI 工具，将会具备这些能力：
能逆向解析复杂系统
能系统性枚举所有状态
能帮开发者找出导致异常行为的具体条件
既能“艺术创作”，也能“科学调查”
它们必须整体地看问题，而非割裂处理。
在那之前，相信我们还会继续看到冰火两重天的“奇观”：原型很惊艳、生产环境体验却糟异常糕透、无数令人抓狂的生产事故。
而这种“认知错位”，本质上并不是AI或大模型的责任，而是AI与生产环境之间的“代际差”所决定的。
当然，代际差不会自动消失。它必须靠新的工具、新的架构设计方式、甚至新的工程文化去解决。
启天配资提示：文章来自网络，不代表本站观点。
- 上一篇：配资讨论网几近第二至第十名销量总和
- 下一篇：没有了
