谷歌工程VP：AI代碼難以在生產環境存活！初創創始人神點評：AI只能用于真空環境，問題在于代碼之外的環節！ 原創
編輯 | 云昭
出品 | 51CTO技術棧（微信號：blog51cto）
過去兩年，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與生產環境之間的“代際差”所決定的。
當然，代際差不會自動消失。它必須靠新的工具、新的架構設計方式、甚至新的工程文化去解決。
參考鏈接：
??https://thenewstack.io/ai-code-doesnt-survive-in-production-heres-why/??
本文轉載自??51CTO技術棧??，作者：云昭
