編按：本文綜合整理自 Ars Technica 原報導及 Linux Kernel Mailing List (LKML) 原信,並加入 Siami 編輯部觀點與分析。
LKML 上的發難:Linux 不歡迎反 AI 派
Linux 核心創始人 Linus Torvalds 這個禮拜在 Linux Kernel Mailing List (LKML) 上發了一篇長篇答覆,直接對想禁止 LLM 輔助開發的開源社群人士開火。他明確表示「Linux 不是反 AI 專案,如果有人對此有意見,開源社群的老辦法就是 fork 出去,或者直接離開」。這段話擺在 Sashiko 工具爭論的脈絡裡,卻意外成了整個開源社群關於 AI 編碼工具的十字路口宣言。
「我們沒有強迫任何人使用 LLM 工具,但我會大聲地忽略那些試圖阻止別人使用它的人。」 — Linus Torvalds 於 LKML
Torvalds 強調自己的立場是務實主義,「基於技術價值,不是對新工具的恐懼」。他補充說「AI 跟我們使用的其他工具一樣,只是另一個工具。它明顯是有用的一個」,並指出現在已經不是一年前那種「AI 工具是否有用」的爭辯時機了。
導火線:Sashiko 與 maintainer 被 AI 假警報淹沒的問題
這場爭議的核心不是「AI 能不能寫程式」,而是「AI 工具對開源 maintainer 的工作量衝擊」。源頭是一款叫做 Sashiko 的「代理式 Linux 核心程式碼審查系統」。它的開發者宣稱,在測試中可獨立找出 53.6% 由人類開發者在後續 commit 中修復的 bug。聽起來很厲害,但反過來,Sashiko 也會浪費 maintainer 的時間,因為它同時會送出實際不存在的 bug 報告(假陽性),而且假陽性率「落在 20% 區間之內」。
這才是真正的痛點:如果一個 maintainer 一天要收到幾百封這樣的信,其中五分之一是憑空捏造的,他怎麼有時間做真正的工作?論串中引用了 Software Freedom Conservancy 的近期聲明,該機構呼籲開源社群「應該支持(而非只是容忍)那些明確拒絕 LLM-gen-AI 系統的人」,並強調「每個 FOSS 貢獻者都應對 LLM-gen-AI 有自我決定權」。
- Sashiko 工具官方 repo:GitHub 上
sashiko-dev/sashiko - 反方觀點代表:Software Freedom Conservancy 的 LLM 政策建議書
- 雙方摩擦的本質:工具效用 vs maintainer 負擔,而不是「AI 是否該存在」
Torvalds 反擊:不是基於恐懼,而是基於結果
Torvalds 的答覆完全不談工作量管理,他選擇正面迎戰「AI 工具是否值得用」這個命題。他寫道,「AI 並不完美」,但任何批評 AI 的人都應該對照人類開發者自己的表現 — 「批評 AI 缺點的人,最好同時對著鏡子指著自己」。他延續一貫的務實風格,認為任何工具的價值,都要用最終產出的程式碼品質來衡量,而不是看程式碼是「人寫的」還是「AI 寫的」。
值得注意的是 Torvalds 自己的實踐。今年一月他公開表示,自己正在實驗所謂「vibe coding」工具,目的是為一個業餘吉他效果器專案打造 Python 音訊視覺化元件。他在 commit message 中寫道:「一開始還是老派『Google 一下、照著做』的程式寫法,但後來我把中間人 — 我自己 — 拿掉,直接用 Google Antigravity 做音訊取樣視覺化。」這個專案就放在他的個人 GitHub repo torvalds/AudioNoise 上。Linux 之父親手拿 AI 工具當程式設計幫手,是這整個事件的具體證明:他不是抽象支持 AI,他個人就在用。
「任何懷疑 AI 是否有用的人,顯然真的沒用過。」 — Torvalds
對照數據:METR 研究顯示 AI 對開發者速度影響並非單向
Torvalds 的實務觀點需要參考獨立研究來檢驗。去年 METR(Model Evaluation and Threat Research)發布的研究指出,使用 AI 工具的開源開發者比不使用的開發者生產力低 19%,但這些使用 AI 的開發者主觀感受自己速度提升了 20%。METR 在今年二月的後續更新中修正了立場,認為「2026 年初相較於 2025 年初,開發者受 AI 加速的可能性更高」,但也坦言「AI 採用面擴大後,任務層級的生產力測量變得更困難」。
這個數據擺出來,跟 Torvalds 的「AI 是工具,當然有用」形成有趣的對照:
| 研究指標 | METR 2025 數據 | METR 2026 年初更新 |
|---|---|---|
| 客觀速度(任務完成時間) | 慢 19% | 預期加速 |
| 主觀感受速度 | 快 20% | 持續正向 |
| 工具適用性結論 | 仍待觀察 | 認為「已是事實」 |
Torvalds 引用這個研究的順序不可考,但他的「現在不是辯論 AI 工具是否實用的時候了」這句話,明顯是站在 METR 2026 更新那邊的立場。
Siami 編輯部:為什麼這件事重要
這件事之所以重要,不只是因為 Linux 之神又嗆人了,而是因為它標誌著開源社群 AI 路線之爭正式進入分水嶺。從 Red Hat 到 Debian,從 SFC 到 Linux Foundation,過去兩年開源社群面對 LLM 工具的態度一直是避而不談,先觀望再說。Torvalds 這次直接掀桌,等於宣告「Linux 核心不再中立」 — 接受 AI 工具是它的預設立場,反對者要嘛 fork 要嘛走人。這對 SFC 等組織主張的「自我決定權」立場,是直接的對撞。
更深一層,這也關係到 AI 工具對開源治理的長期影響。當 AI 開始參與核心審查、bug triage、甚至 patch 撰寫時,誰來負責?Sashiko 模式如果擴大到 Linux 之外的專案,fork 出去的社群勢必要重新建立 maintainer 審查流程。這是技術問題,也是社群治理問題。
Siami 數據解讀 / 質疑
幾個值得追蹤的後續指標:第一,Sashiko 在 Linux 核心上游的實際採用率。Ars Technica 報導引用的 53.6% 準確率是工具開發商自測,未經獨立驗證。METR 的「實驗室研究」與「真實專案數據」之間仍有一段距離。第二,Torvalds 的 commit log 接下來幾個月是否會明顯出現 AI 協助提交的 patch。如果沒有,他「務實主義」的力道就稍打折扣。第三,SFC 是否會真的 fork Linux 核心(極端情況)或推出對應的「無 AI 認證」發行版,這會是開源社群分家的真實試金石。第四,GCC / Clang 上游維護者是否跟進表態,因為編譯器是比核心更深層的基礎設施,他們的 AI 立場會更具示範效應。
編按：本文綜合整理自 Ars Technica 原報導、Linux Kernel Mailing List (LKML) Torvalds 原信、METR 研究更新、Software Freedom Conservancy 政策聲明,並加入 Siami 編輯部觀點與分析。
網友熱門留言 (3)