Linux 7.3-rc2 變「全脂」候選版：Torvalds 半開玩笑歸咎 AI，Greg KH 警告維護者被 LLM 補丁淹沒

Linux 核心進入 7.3 釋出週期後，第二個候選版（7.3-rc2）並未出現往年常見的「喘口氣」節奏。核心維護者 Linus Torvalds 在例行公告中形容這是一次「全脂」（full fat）rc2；稍早，穩定版核心負責人 Greg Kroah-Hartman 已公開預告，AI／LLM 帶來的補丁與缺陷報告噪音，會令整個 -rc 週期相當粗重。本文已對照 kernel.org 版本狀態、Phoronix 引述之 Torvalds 公告原文，以及 The Register、Phoronix 對 Greg KH 評論的報導，來源真實性已驗證。重點在於：開源基礎設施正面對「自動找洞＋自動交補丁」的吞吐挑戰，企業若依賴上游核心與供應鏈修補節奏，必須把審核容量視為營運風險。

一、核心事件：7.3-rc2 打破「最安靜一週」慣例

技術細節

根據 kernel.org 公開狀態列，最新主線版本為 Linux 7.3-rc2（穩定線現為 7.2.3）。Phoronix 於 2026 年 9 月 6 日報導，7.3 merge window 結束後，rc2 仍持續納入大量修補，並指出 AI／LLM 產生的材料持續流入，同時亦要消化 rc1 測試後的早期回歸。

Torvalds 在延遲發出的 7.3-rc2 公告中寫道（Phoronix 引述）：rc2 通常是 merge window 後最安靜的時段，人們先喘口氣，再慢慢找 bug；「但這次不是——這是一個『全脂』rc 釋出。」他表示找不到單一原因：晚到的 EDAC pull 只是小事；真正撐大體積的，是多個檔案系統修補、頗具分量的 drm 修正、networking／bpf，以及多條 driver tree。

The Register 進一步引述 Torvalds 的半開玩笑結語：看起來沒有特別古怪之處，「可能只是隨機波動，但我們當然會全部歸咎於 AI——無論那是不是真正原因，它都是最容易怪罪的對象。」重點並非字面「AI 寫了全部 diff」，而是社群已把「LLM 時代的提交量級」納入日常敘事。

二、技術原理深度解析：為何 LLM 會把維護者拖進「粗重 -rc」

Greg KH 在 7.3-rc1 剛出爐時已於 social.kernel.org 警告（Phoronix 2026-09-02 報導）：即使是理應「穩定」的舊子系統，提交量亦未放緩。他展示 USB 相關待辦信箱，首輪過濾後仍有上千封待處理，直言「這會是一個粗重的 -rc 週期」。

機制上可拆成三層：

靜態分析＋LLM 補丁流水線：Greg KH 指目前大多數補丁來自靜態分析工具，專找「握錯姿勢才會觸發」的舊有小問題；LLM 再把「明顯像 bug fix」的建議包裝成可提交的 patch。拒絕「明顯修 bug」的補丁在倫理與流程上都很困難，於是審核時間變成瓶頸。
長尾驅動與冷門子系統被重新點燃：不少補丁落在多年少人維護、甚至近乎淘汰的驅動程式。對生產環境未必立即有價值，卻仍要消耗維護者閱讀與回覆成本。
Staging 先設閘：Greg KH 已在其負責的 staging 區採取政策——除真正安全修補外，不接受 AI／LLM 補丁，以先關掉最嘈雜的入口。這顯示社群開始用「區域性政策」換取全局節奏，而不是假設上游永遠能以人力線性擴張。

Phoronix 亦指出，7.3-rc2 本身仍有真實硬體與排程價值，例如混合 CPU 的 Cache Aware Scheduling misfit 修正、把更多 kmalloc() 轉向 kmalloc_obj() 的清理、Nouveau 對 NVIDIA Blackwell 顯示修正，以及若啟用 Rust 工具鏈則預設關閉 RandStruct 等。換言之，週期「粗重」並不代表沒有實質進度；而是實質進度與噪音疊加，令審核曲線更陡。

四、日常應用場景

1. 開發者與技術團隊

上游 -rc 期間若大量引入 AI 產生的長尾修補，發行版與自建核心的 backport 清單會變長。團隊應提高對「來源標記／作者工具鏈說明／測試覆蓋」的要求，避免把未審核的自動補丁直接併入產品核心。

2. 企業與隱私敏感行業

金融、醫療、政府等環境常跟進 LTS 或發行商核心。上游維護者被噪音拖慢，可能延後穩定版時程（Phoronix 指 7.3 穩定版目標約 10 月 18 日，粗重週期或推至 10 月 25 日）。企業應把「上游審核容量」納入變更窗口與 CVE 響應 SLA，而不是假設每月修補節奏恒定。

3. 一般用戶

桌面與筆電用戶多經發行版取得核心；短線影響較間接。真正需要留意的是：若依賴 bleeding-edge 主線或自編譯核心，rc 期間回歸風險與測試負擔會上升。

4. 香港與亞洲市場視角

香港大量中小企把 Linux 跑在雲端 VPS、邊緣閘道與內部伺服器。當上游補丁吞吐被 AI 放大，本地託管與代維團隊更需要可審計的變更流程：誰批准合併、如何回滾、如何驗證驅動／網路堆疊。對數據不出境、要自行掌控主機的機構而言，可控的系統平面比盲目追最新主線更重要。

五、專業評價與潛在考量

優勢

LLM 與靜態分析確實能掃出人類長期忽略的舊缺陷，長期有助收斂技術債。
Staging 等區域性禁令證明社群能用政策調節噪音，而非被動承受。
7.3-rc2 仍帶入排程、記憶體配置與驅動等實質修正，週期並非空轉。

需要留意的地方

Torvalds 的「怪 AI」是修辭，不能當成因果鑑定；真正瓶頸是人類審核帶寬。
「明顯修 bug」難以拒絕，可能形成逆向激勵：自動工具持續投餵低價值修補。
企業若把「上游已合併」等同「已適合生產」，會低估長尾驅動與配置風險。

結語

Linux 7.3 週期把一個產業級問題攤在桌面：生成式工具提高了「提出變更」的速度，卻未必同步提高「驗證變更」的速度。對香港企業而言，下一步不是拒絕 AI，而是把主機、核心與修補流程做成可觀測、可回滾的系統。若你需要在香港自建可審計的 Linux 控制平面，可參考 YSK Limited 的 YSK Server（單機 Linux 管理面板，公開版本 v1.1.26，預設埠 9287：https://ysk.hk/products/ysk-server），並搭配雲端遷移與網絡安全服務（官網刊 99.99% SLA：https://ysk.hk/services/cloud-security），把上游節奏波動轉成可管理的營運政策。

參考來源