當大量由生成式 AI 產出的程式碼修補系列（patch series）如洪水般湧入開源社群的那一刻，整個 Linux 核心的維持機制正悄悄面臨一場前所未有的產能危機。這不只是程式碼數量的暴增，而是一場關於誰來審查、誰來把關的生存壓力測試。
表象
表面上看起來，開源生態系似乎正迎來前所未有的繁榮，各種自動化工具與人工智慧生成內容不斷推陳出新。然而，在光鮮亮麗的技術突破背後，第一線的軟體工程師與核心維護者們卻正面臨嚴重的過勞與信箱爆炸危機。長期參與核心開發的工程師們開始紛紛選擇卸下部分非核心職責，只為了讓自己的工作負荷能夠回到稍微健康的狀態。
從產業面來看，AI 工具的普及大幅降低了程式碼的產出門檻，卻沒有同步降低「驗證與審查」所需的碳基大腦成本。當生成式 AI 讓 patch 的數量從過去的「一週一次」變成「每天大量湧入」，甚至佔去審查工作的一半時，開源社群長久以來仰賴的信任與人工審查機制正在瀕臨極限。對一般人來說，這凸顯了技術自動化並不等於效率提升，反而把瓶頸轉移到了最稀缺的人力資源上。
真相
深入探討這場危機的源頭，會發現問題的核心在於「審查頻率與人力」的嚴重失衡。任職於安謀（Arm）的高級軟體工程師羅倫佐・斯托克斯（Lorenzo Stoakes）近期公開表示，由於目前核心中充斥著 AI 生成的修補系列，他已經沒有足夠的精力去處理維護範圍之外的程式碼審查工作。
身兼記憶體對應、記憶體對應鎖定、madvise 以及反向對應等多項重要維護職責的斯托克斯坦言，他必須有所取捨，好讓自己的收件匣不至於太過崩潰。這不僅是個人的燃燒殆盡，更是整個開源世界長年累積的結構性疲勞。
各方角力
不只是斯托克斯一人發出警訊，在日前舉行的開源高峰會（Open Source Summit）「詢問專家」問答環節中，核心開發者葛雷格・克勞哈特曼（Greg Kroah-Hartman）也直言不諱地指出，大型語言模型（LLM）產生的修補程式數量實在太龐大，根本沒有足夠的人手可以一一審查。
克勞哈特曼甚至指出，所有的維護者都已經過勞了十年之久，甚至連長期支援版本的數量與商業軟體的長期支援模式都應該重新檢討。各方在維持產品生命週期、商業利益與開發者身心健康之間，正拉鋸出極大的張力。
深層影響
當核心開發者選擇退居二線或減少非必要審查時，最直接受到衝擊的就是整個作業系統核心的穩定性與安全性。開源軟體之所以能夠成為全球數位基礎設施的基石，靠的就是嚴謹的同儕審查與社群信任。如果把關的人因為過勞而逐一離去或減少工作量，漏洞與低品質的程式碼將更有機會滲透進底層架構中，對全球資訊安全帶來隱憂。
未解之問
話說回來，當生成式 AI 帶來的程式碼浪潮已經無法擋下，開源社群究竟該如何調整遊戲規則，才能在自動化效率與人類審查極限之間找到一條永續的平衡道路？
如果您也是軟體開發從業人員或開源愛好者，不妨思考一下：當我們盲目追求產出速度的同時，是否正在透支下一代數位基礎建設的維護能量？建議隨時關注社群規範的更迭，並在技術應用與人力負荷之間做好風險評估。
本文改寫整理自公開新聞來源，原始報導由The Register發布。
常見問題 FAQ
為什麼 Linux 核心開發者會面臨過勞危機？
因為近期由 AI 生成的程式碼修補系列大量湧入，導致審查工作量暴增，現有人力根本無法負荷龐大的審查需求。
羅倫佐・斯托克斯（Lorenzo Stoakes）辭去所有 Linux 核心職務了嗎？
沒有，他保留了所有的維護職責，只是退回部分非維護範圍的程式碼審查工作，以減輕收件匣的負擔。
開源社群對目前大量出現的 AI 程式碼有什麼看法？
許多核心維護者認為人手嚴重不足，且大家已經過勞多年，呼籲必須正視審查人力枯竭與長期支援版本過多的問題。
※ 此篇文章由 AI 改寫或生成，內容僅供參考，可能存在錯誤或不準確之處。
