當矽谷那群人還在為了 AGI 到底能不能解決納維-斯托克斯方程吵得不可開交時，OpenAI 的工程師顯然還沒學會怎麼寫一個合格的垃圾回收機制。最近在技術圈傳得沸沸揚揚的 Codex 崩潰文件堆積事件，與其說是技術失誤，不如說是這家公司的傲慢已經溢出了用戶的硬碟空間。一個號稱要改變人類生產力的工具，在用戶的 Mac 裡悄悄塞滿了 330GB 的 Crashpad 轉儲文件，這種「負向生產力」的諷刺程度，甚至超過了它生成的那些跑不通的代碼。
這類問題在 ChatGPT 的桌面端或相關 Agent 組件中並非孤例。核心痛點在於，當我們把模型從雲端的 API 搬進本地環境，開發者似乎忘了本地系統資源是有邊界的。以 Codex 為例，它在處理 3D 場景微調或財務流程自動化時，會產生大量的臨時工件與 git worktrees。問題在於，這些 Agent 像是一個只會瘋狂產出的流水線工人，卻沒有配備掃帚。當程序崩潰，Crashpad 機制啟動，本意是為了診斷，結果卻演變成了硬碟空間的黑洞。用戶如果不裝個 DaisyDisk 之類的工具手動清掃，可能連系統都進不去。
從技術層面看，OpenAI 在處理本地 Agent 的執行邊界時顯得極其草率。這涉及一個具體的場景：當 Agent 在多個 git 分支間頻繁切換以嘗試不同代碼路徑時，它會重複生成大量的構建產物。如果這時候模型邏輯出現異常觸發崩潰，Crashpad 就會忠實地記錄下當前內存鏡像。在短時間內高頻迭代失敗的情況下，幾百個 GB 的垃圾數據就這麼誕生了。相比之下，Claude 在處理長文本與代碼生成時，雖然也會在本地緩存一些上下文片段，但在文件系統的佔用上顯然克制得多。Anthropic 似乎更傾向於讓模型在雲端完成繁重的預處理，而不是在用戶的本地環境裡橫衝直撞。
這種穩定性的差異，在橫向對比時變得更為刺眼。當我們看到 DeepSeek 在近期社區討論中頻繁被提及時，OpenAI 卻還在處理這種低級的資源洩漏問題。相較於 DeepSeek 在推理成本上的極致壓縮，OpenAI 在客戶端維護上的敷衍，簡直讓人懷疑他們是不是把所有的優秀工程師都派去餵算力集群了。同樣是面對高併發的代碼生成任務，Gemini 在集成開發環境中的資源占用雖然也不低，但至少 Google 還有幾十年的客戶端開發經驗，知道什麼叫作「不要塞爆用戶的磁碟」。Grok 則乾脆走另一條路，目前依然維持著相對輕量化的接口交互，避開了這種複雜本地環境帶來的負擔。
說到底，這是一種「SLOP 寫碼風格」的勝利。當模型生成的代碼本身就帶著不確定性，而包裝這些模型的工程結構又缺乏對宿主系統的敬畏時，用戶就成了那個買單的倒霉蛋。OpenAI 試圖讓 Agent 擁有自主修復代碼的能力，但如果這個 Agent 連自己產生的崩潰文件都修不乾淨，我們真的能放心讓它去操作真實的財務系統，或是修改關鍵的生產環境？
這背後隱藏著一個更深層的技術斷層：大模型廠商正在瘋狂追求邏輯上的「神性」，卻在基礎工程實踐上顯得極度「業餘」。當一個工具需要用戶去 GitHub Issue 區哀求開發者進行基本的 Triage 處理時，這東西離真正的商業化生產力工具還差得遠。
我們是否已經進入了一個「代碼膨脹」的新紀元？在這個時代，模型的智商每提升一點，背後的工程代碼就腐爛得更快。如果未來的 AI 真的能解決物理難題，卻依然會在你的電腦裡留下幾百 GB 的垃圾，這種智能到底是在服務人類，還是在消耗人類？又或者，我們其實根本不在乎這些細節，只要它能寫出那行讓我們交差的代碼，哪怕它把硬碟撐爆也無所謂？