AI生成代碼速度像“開掛”，一上線卻瘋狂“踩雷”！

AI 寫代碼的速度已經(jīng)快到離譜了，一句話就能生成一堆“看起來能跑”的函數(shù)。但問題是：這些代碼真正上生產(chǎn)環(huán)境后，往往不是崩就是漏，維護成本甚至比人類敲的還高。我們現(xiàn)在遇到的，不是“代碼不夠多”，而是“代碼不靠譜”。那么，既然生產(chǎn)力爆炸了，為什么可靠性沒跟上？又該怎么補上這塊短板？這成了所有工程團隊必須面對的新問題。

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

作者 | Animesh Koratana 責編 | 蘇宓

出品 | CSDN（ID：CSDNnews）

我?guī)缀趺刻於寄芸吹筋愃频?AI 演示：只用一個提示詞，就能生成一款完整的應(yīng)用。對著 AI 助手，輸入幾句自然語言之后，啪的一下，一個“打磨精良”的產(chǎn)品就出現(xiàn)了。

但在這些火爆的趨勢背后，有個耐人尋味的事實：我們并沒有看到成品軟件數(shù)量的提升，也沒有看到預(yù)期中的創(chuàng)新速度。

谷歌一位工程副總裁近期說過一句話：“如果大家知道有多少 LLM 生成的代碼真正進入生產(chǎn)環(huán)境，一定會震驚。”

盡管 AI 生成代碼的演示十分精彩，各種 AI 初創(chuàng)公司也獲得了數(shù)十億美元的資金支持，但 AI 生成的軟件原型和真正可投入生產(chǎn)的系統(tǒng)之間，仍然存在巨大鴻溝。

問題出在哪？答案其實藏在三個根本性挑戰(zhàn)里：

1. 全新技術(shù)棧 vs. 現(xiàn)有技術(shù)棧：AI 非常擅長不受任何限制的原型設(shè)計，但難以與現(xiàn)有系統(tǒng)集成。此外，在生產(chǎn)環(huán)境中運行有各種硬性要求，也會讓軟件原型變得脆弱不堪。

2. “多莉（Dory）問題”：AI 無法調(diào)試自己的代碼，因為它沒有持續(xù)性的理解能力。不會記住過去的錯誤，也缺乏排查系統(tǒng)問題所需的上下文。

3. 工具成熟度不一致：雖然代碼生成工具發(fā)展十分迅速，但部署、維護、代碼審查、質(zhì)量保障、客戶支持等環(huán)節(jié)依然停留在 AI 時代之前的速度。

下面具體來看看。

全新技術(shù)棧 vs. 現(xiàn)有技術(shù)棧

LLM 可以在理想狀態(tài)下快速構(gòu)建出一個新的微服務(wù)，使其在獨立的環(huán)境里面運行良好。但一放到生產(chǎn)環(huán)境時，卻完全是另一回事：在接入時，需要面對遺留代碼、服務(wù)邊界、數(shù)據(jù)契約、授權(quán)中間件、Protobuf schema、CI/CD 流水線、可觀測性堆棧、SLO、性能預(yù)算……還沒算上真實用戶使用時會出現(xiàn)的各種不可預(yù)測的情況。

開發(fā)新軟件時，其實更像是在做藝術(shù)創(chuàng)作。首先，你需要構(gòu)想軟件的預(yù)期行為，譬如：數(shù)據(jù)應(yīng)該從初始狀態(tài)流向目標狀態(tài)，中間按既定的控制流程完成轉(zhuǎn)換。相當于你是在“從無到有地作畫”。

這也是為什么 AI 編碼助手能做出讓人驚嘆的原型：它們非常擅長這種面向未來、毫無束縛的創(chuàng)造性生成。

但要讓軟件在生產(chǎn)環(huán)境里穩(wěn)定、高質(zhì)量地運行，靠“更多代碼”是行不通的。

你需要的是能在一組明確且細致的參數(shù)范圍內(nèi)運行的代碼。而要把這些復(fù)雜而細微的參數(shù)準確傳達給一個 LLM，本身就不是一件容易的事。

雖然 LLM 擅長用自然語言與我們交流，但我們往往高估了它編寫高質(zhì)量軟件的能力。畢竟自然語言是靈活且包容的，而代碼不是。

代碼必須可執(zhí)行、可組合，正確性依賴文件與服務(wù)之間精確的契約。編譯器和運行時環(huán)境容錯率極低——微小錯誤都可能引發(fā)連鎖崩潰、出現(xiàn)安全漏洞，或?qū)е滦阅芡嘶?/p>

“多莉（Dory）問題”

前面我們已經(jīng)說過，現(xiàn)有 LLM 很難寫出能在真實復(fù)雜環(huán)境中正常運行的代碼。那么為什么不能用 AI 來排查和調(diào)試這些代碼呢？

要做好調(diào)試，你必須對整個架構(gòu)有“全局腦圖”，了解整個架構(gòu)。對此，你得理解數(shù)據(jù)在系統(tǒng)中實際是怎么流動的，而不是它從理論上來說“本該”怎么流動。你需要具備從缺陷開始“逆向剖析”系統(tǒng)的能力，需要模型能夠消化那些歷經(jīng)數(shù)十年構(gòu)建的龐大系統(tǒng)，理解它們?yōu)槭裁磿蕴囟ǚ绞竭\行。你需要知道系統(tǒng)里已有的東西、走過的路，以及那些被放棄的路徑。

遺憾的是，大多數(shù) LLM 的運行方式更像《海底總動員》里的多莉：查詢之間沒有持續(xù)性的上下文，而且記憶極其短暫。

現(xiàn)實中，很多公司維護的代碼庫已經(jīng)有 20、30、甚至 40 年歷史。這些系統(tǒng)會出現(xiàn)“涌現(xiàn)行為”、隱式依賴和歷史遺留的各種權(quán)宜之計，它們是技術(shù)債不斷積累的結(jié)果。如果沒有對整個系統(tǒng)架構(gòu)、多個倉庫之間的關(guān)聯(lián)、以往的決策和上線記錄有足夠理解，想排查復(fù)雜問題幾乎是不可能的。

工具成熟度不一致

AI 生成的代碼難以進入生產(chǎn)環(huán)境，另一大原因是：軟件交付生命周期（SDLC）中用于支撐 AI 的工具，并沒有同步成熟。

以數(shù)碼相機的演變?yōu)槔Ｗ畛醯臄?shù)碼相機長得和膠片相機幾乎一樣——因為我們當時無法想象更好的應(yīng)用方式。但很快我們意識到，相機可以嵌入任何地方：筆記本、手機、門鈴、汽車。相機不再只是用來拍照，還能幫你導(dǎo)航。

AI 代碼生成工具也經(jīng)歷了類似的快速迭代。剛開始，我們嘗試把 AI 塞進 IDE，就像把相機做成“數(shù)碼單反”。最早的 GitHub Copilot，本質(zhì)上只是更聰明的自動補全。

但過去幾年里，Cursor、Windsurf、Claude Code 等工具出現(xiàn)后，情況完全變了。它們構(gòu)想的是一整套新的工作流：你不再直接寫代碼，而是在聊天框里表達意圖，然后代碼自然發(fā)生改變。你從“寫代碼”轉(zhuǎn)變?yōu)椤懊枋瞿阆胱屜到y(tǒng)做什么”。

如今的 AI 代碼生成已經(jīng)進入第二代產(chǎn)品，整個工作方式都被改寫了。但放眼代碼生成以外的 SDLC 其他階段，我們很多工具仍停留在第一代。如果我們真想提升工程效率，必須跳出“只關(guān)注代碼生成”的思路，轉(zhuǎn)向 AI 驅(qū)動的端到端 SDLC 重構(gòu)。

前進的方向

如今已經(jīng)有不少工具在嘗試解決現(xiàn)代軟件運維的問題，但它們?nèi)匀话颜麄€流程拆成一個個相互孤立的環(huán)節(jié)來看。它們可以打造出非常好用的“數(shù)碼相機”，卻卻缺乏從零重構(gòu)整個運維流程的想象力。

你當然可以通過更強的 AI 代碼審查系統(tǒng)，或者引入一個“智能代理版”的 SRE（站點可靠性工程師）獲得一些漸進式提升。但真正的大突破，不會來自對現(xiàn)有流程的局部優(yōu)化，而是來自那些能夠重新設(shè)計整條軟件運維鏈路的工具。

想要在生產(chǎn)環(huán)境中真正發(fā)揮作用的 AI 工具，需要具備以下幾項關(guān)鍵能力：

• 能逆向理解復(fù)雜系統(tǒng)；

• 能系統(tǒng)化地枚舉各種狀態(tài)；

—— 能幫助開發(fā)者精準定位導(dǎo)致異常行為的特定條件。

換句話說，它們不僅要像藝術(shù)家一樣擅長創(chuàng)造，還要像科學(xué)家一樣擅長調(diào)查與推理。而且必須從整體出發(fā)看問題，而不是只盯住某一個環(huán)節(jié)。

在此之前，我們只能繼續(xù)看到驚艷的原型，和令人沮喪的生產(chǎn)環(huán)境體驗。

這種“認知錯位”短時間內(nèi)不會消失——它根植于這些系統(tǒng)的工作方式本身。

【活動分享】2025 年是 C++ 正式發(fā)布以來的 40 周年，也是全球 C++ 及系統(tǒng)軟件技術(shù)大會舉辦 20 周年。這一次，C++ 之父 Bjarne Stroustrup 將再次親臨「2025 全球 C++及系統(tǒng)軟件技術(shù)大會」現(xiàn)場，與全球頂尖的系統(tǒng)軟件工程師、編譯器專家、AI 基礎(chǔ)設(shè)施研究者同臺對話。

本次大會共設(shè)立現(xiàn)代 C++ 最佳實踐、架構(gòu)與設(shè)計演化、軟件質(zhì)量建設(shè)、安全與可靠、研發(fā)效能、大模型驅(qū)動的軟件開發(fā)、AI 算力與優(yōu)化、異構(gòu)計算、高性能與低時延、并發(fā)與并行、系統(tǒng)級軟件、嵌入式系統(tǒng)十二大主題，共同構(gòu)建了一個全面而立體的知識體系，確保每一位參會者——無論是語言愛好者、系統(tǒng)架構(gòu)師、性能優(yōu)化工程師，還是技術(shù)管理者——都能在這里找到自己的坐標，收獲深刻的洞見與啟發(fā)。詳情參考官網(wǎng)：https://cpp-summit.org/