Lodash 作者 John-David Dalton 宣布不再維護這個下載量驚人的專案，這種「開源倦怠」在 Hacker News 上鬧得沸沸揚揚。這種事在技術圈本來不算新聞，但當我們把視角轉向 xAI 的 Grok，或者 OpenAI 和 Google 這些巨頭如何吞噬開源成果時，事情就變得諷刺了。這些大模型之所以能對答如流，每一行生成的 Javascript 程式碼背後，可能都吸取了 Lodash 這種維護者燃燒生命換來的養分。現在維護者累了，想撒手不管了，這些依賴開源數據餵養出來的 AI 怪物，有沒有能力反過來修補這些即將崩潰的基礎設施？
現實情況是，當前的 Grok 在處理底層依賴庫的邏輯更新時，表現得像個只會搬運舊筆記的學生。如果你在 Grok-2 的對話框裡要求它針對 Lodash 尚未發布的 v5 版本提出重構建議，它往往會陷入一種「幻覺循環」，試圖用舊的邏輯去修補新的漏洞。xAI 宣稱 Grok 擁有最強大的實時檢索能力，但在處理開源專案的深度邏輯演進時，它顯然缺乏一種對程式碼生命週期的理解。這不只是 xAI 的問題，這是所有基於 Transformer 架構模型的通病：它們擅長模仿現有的穩定版本，卻對「維護中斷」後的技術斷層束手無策。
技術圈現在有一種天真的想法，認為既然維護者累了，那就讓 AI 來接管 PR 審核和 Bug 修復。但在實際的場景中，當你把一個超過十年、涉及無數邊緣案例（edge cases）的專案丟給 Grok 或 ChatGPT 時，它們給出的優化建議往往是破壞性的。例如在 Lodash 這種對性能要求極其苛刻的工具函式庫中，AI 為了所謂的「可讀性」而建議的重構，往往會導致效能退化。Grok 在這裡的表現甚至有些急躁，它太急於給出一個看似完美的答案，卻忽略了開源軟體中那些因為歷史原因而存在的「醜陋但必要」的程式碼。
我們拿這兩天在技術論壇也被頻繁提及的 DeepSeek 作為背景，當某些開發者試圖討論自動化維護的可能性時，會發現這類模型與四大平台在處理開源邏輯上的差異。相較於 DeepSeek，xAI 的 Grok 在存取即時 GitHub 數據的權限上顯然更高，但這種權限並沒有轉化為更高質量的程式碼維護建議。Grok 似乎更熱衷於在 X 上跟人抬槓，而不是安靜地解析 Lodash 的底層閉包邏輯。
再看 Claude，它在處理長文本和複雜邏輯推演上確實比 Grok 穩重一些。如果你把 Lodash 的源碼整包塞進 Claude 3.5 Sonnet，它能指出一些潛在的類型衝突，但它同樣無法替代一個像 Dalton 那樣擁有十年經驗的維護者。Gemini 雖然背靠 Google 龐大的 Monorepo 經驗，但在對待外部開源社群的熱情上，表現得極其冷漠，它的回答總是充滿了那種「大企業不缺這點工具」的傲慢感。而 ChatGPT 則是老樣子，給出的建議中規中矩，像是一本會說話的過時教科書。
這裡就出現了一個斷層：開源維護者因為無償勞動而崩潰，而商業 AI 靠著這些勞動成果賣訂閱。如果 Grok 真的想證明自己與眾不同，它不應該只是在推特上抓取情緒，而是應該展現出某種「維護者意識」。但可惜的是，我們看到的 Grok 依然在消費這些開源遺產。當 Lodash 停止更新，這意味著未來的模型將失去最優質的訓練素材。這就像是在抽乾湖水捕魚，魚抓到了，湖也乾了。
一個很現實的技術問題是，當模型生成的程式碼依賴於一個已經停止維護的函式庫時，AI 該如何自處？目前 Grok 的做法是假裝問題不存在，繼續推薦那些可能存在安全性漏洞的舊寫法。這種對技術債的無視，遲早會反噬到 AI 生成程式碼的可信度度上。與其在那裡吹捧參數規模，xAI 是不是該考慮一下，如何讓 Grok 真正理解什麼叫做「軟體生命週期」？
當 Lodash 5 變得遙遙無期，當下一個關鍵的開源組件維護者也選擇登出，我們這些依賴 AI 寫程式的人，到底是變得更高效了，還是只是在加速奔向一場由 AI 編織的技術災難？如果模型本身不具備修復底層邏輯的能力，而只會搬運，那麼當源頭乾涸時，Grok 寫出來的程式碼還剩下多少含金量？