從 2950 個週期降到 725 個：Torvalds 首個 LLM 協作補丁，先看的是工程時間那一欄

10 月 14 日，科技媒體 LWN 報導，Linus Torvalds 在其個人 Git 倉庫推送名為 noref-filemap-read-with-llm 的開發分支，這是他首次由大語言模型輔助完成的核心補丁系列，協作工具為 Anthropic 的 Claude Code。值得注意的是，Torvalds 過去在 torvalds/linux.git 倉庫通常只維護 master 分支，這次罕見另開分支，且後綴直接標上「llm」。

事件的時間軸很清楚：10 月 13 日提交補丁，主題為「提高頁面引用計數可擴展性」，10 月 14 日經 LWN 報導後引發討論。該補丁目前仍屬實驗性分支，尚未合入 Linux 7.4 正式主線。

效能帳：兩組數字

這組補丁解決的是 Linux 記憶體管理的長期瓶頸。當多個執行緒高頻微量讀取同一個檔案時，傳統機制會反覆觸發頁面快取（Page Cache）的引用計數更新，導致多核 CPU 之間嚴重的競態爭搶。

Torvalds 在關閉部分安全防護後的測試環境量測：8 個執行緒同時讀取同一檔案的特定負載下，吞吐量從每秒約 990 萬至 1040 萬次，躍升至 3000 萬至 3300 萬次，提升約 3 倍。更值得看的是單位成本那欄：單次讀取消耗的核心時脈週期，從約 2950 次降至 725 次，降幅約 75%。

吞吐量是結果，週期數才是結構。每次讀取省下 2200 多個週期，乘上每秒數千萬次的呼叫頻率，這是系統層級的邊際成本改寫，而非單點最佳化。

誰出的力：Torvalds 的分工聲明

託瓦茲明確交代了分工：補丁的核心程式碼、測試程式、漏洞審查與公告文件初稿，全部是在他本人指導下由 Claude Code 協作完成。這句話的關鍵在於「指導下」三個字。核心維護者的判斷仍是瓶頸定位、方案取捨與最終驗收，模型承擔的是把意圖轉為程式碼與文件的大量機械工作。

同一批報導還提到兩件旁證。其一，在近期的維護者峯會（Maintainers Summit）上，Torvalds 已談及 LLM 在核心維護上的應用。其二，在另一處 assoc_array 程式碼庫清理中，他藉 LLM 重構陳舊程式碼，並找出 3 個可追溯至 2013 年首次提交、藏匿長達 13 年的隱蔽 Bug。

13 年未被發現的缺陷，指向的是核心維護長期的人力結構問題：維護者時間稀缺，老舊子系統的審查優先序永遠排在後面。AI 工具在此的作用，是把「重讀整個子系統並交叉比對」這類過去無人有意願支付的工時成本壓到可負擔區間。這與微軟先前以 12 萬美元 token 成本將 Copilot 運行時移植到 Rust、換取 15.9 倍吞吐的帳，屬於同一條技術替代曲線下的移植成本邏輯：先算工程時間的單價，再算效能回報。

影響推演：誰受惠、誰承壓

受惠端分兩層。第一層是高並發 I/O 場景的營運方，資料庫、物件儲存、容器密度高的雲端主機，凡是有多執行緒反覆讀同一檔案的負載，都能喫到這 3 倍的吞吐紅利，前提是補丁走完審查流程進入主線。第二層是核心維護社羣本身，如果文件初稿、測試程式與重構工作可由 LLM 承擔，長尾子系統的維護瓶頸有機會鬆動。

承壓與風險端同樣具體。核心補丁的信任基礎是人工審查，AI 生成的程式碼在進入主線前，勢必面臨更嚴格的 review 要求，這會拉長合併週期，事實上該補丁至今仍在實驗分支。此外，Torvalds 為了測試而關閉部分安全防護一事，也說明這類工具的執行環境本身有安全管理成本，這一點與我們先前討論過的 Claude Code 擴充機制中程式權限與維護成本的取捨是同一個問題的兩面。

收束判斷

可以確認的事實是：效能數字由 Torvalds 本人量測公布，分工方式由本人聲明，補丁狀態為實驗分支。不能確認的是這條路線能否複製到核心其他子系統，以及主線審查圈的接受度。

但數字本身的對照已經足夠：一次讀取 2950 個週期變 725 個，13 年的 Bug 在一次重構中被翻出。當核心維護這種對正確性要求最嚴苛的工程領域，開始出現由維護者主導、AI 執行的分工實例，工程時間的單價結構正在被重新定義。至於這是孤例還是曲線起點，要看 Linux 7.4 之後的主線合併紀錄。