核心補丁不用再貼「AI協助」標籤：Linux 把責任放回開發者身上，而不是工具上

Linux 郵件列表上的一則消息，披露了 2026 年 10 月 8 日在捷克布拉格舉行的維護者峯會（Maintainers Summit）達成的一項決策：向核心提交程式碼時，不再需要使用「Assisted-by」標籤。換句話說，核心開發者遞交補丁時，無需聲明這段程式碼是否由 AI 輔助編寫。

消息由 Solidot 於 10 月 18 日刊出，短時間內被多次瀏覽。這條新聞表面上是一個標籤規範的調整，實際上涉及一個更根本的問題：開源社羣到底要管「工具」，還是管「結果」。

Linus 的類比：禁止 AI，就像禁止文字編輯器

Linus Torvalds 在討論中的立場很直接。他認為禁止使用 AI，就像禁止使用文字編輯器一樣，是極其愚蠢的規定。他的理由建立在核心開發的既有門檻上：能進到這一層的開發者，本來就經過長期的審查與信任累積，「他們知道自己在做什麼」。

這個類比值得停下來想一下。文字編輯器改變的是書寫效率，不會替你決定程式邏輯；AI 編碼助手則可能生成一整段你沒逐行理解過的程式碼。兩者對「作者對作品的掌握程度」影響不同，這也是外界對此決策最常見的疑慮。但核心社羣的治理傳統向來以審查與問責為軸心：補丁出了問題，追究的是遞交者與維護者，而非遞交者用了什麼工具。

同一週的插曲：AI 補丁被抓出競態條件

事件的時間點讓這個決策多了幾分對照意味。Linus 本週自己遞交了一組用 Claude Code 開發的補丁，結果被發現存在競態條件（race condition），記憶體回收部分也被認為有問題。這組補丁的後續開發，交給了人類開發者 Kiryl Shutsemau。

這段插曲其實正好演示了核心社羣的立場：AI 生成的程式碼一樣要過審查這一關，抓到問題就退回、就有人接手修。工具不豁免品質責任，流程照走。對照決策本身，可以看出維護者峯會的判斷是：標籤宣告沒有增加多少審查資訊，審查該做的永遠是看程式碼本身。

對一般開發團隊的「所以呢」

這項決策雖然發生在核心這個最講究信任鏈的社羣，訊號卻值得所有寫程式的人參考。近年 AI 工具的成本結構與工作流整合快速演進，例如我們先前分析過的GPT-6 提示快取對開發帳單的重構判斷，AI 輔助已從嘗鮮變成日常。當 AI 滲透到 Linux 核心這種等級的專案，多數公司的程式碼規範再要求逐條申報「是否用 AI」，實質意義只會越來越低。

比較務實的做法，方向與核心社羣一致：把治理重心從申報移到驗收。程式碼審查、測試覆蓋、競態與記憶體管理的檢查，這些關卡不管程式碼是人寫的還是模型生成的，標準應該相同。Linus 那組被退回的補丁就是最好的範例，出問題的不是「用了 AI」這件事，而是補丁本身，而流程確實把它攔下來了。

下一步看什麼

值得持續觀察的訊號有兩個方向。其一是核心審查流程會不會因 AI 生成補丁數量增加而需要新的工具或規範，例如更嚴格的靜態分析與併發檢查；其二是其他大型開源專案是否跟進取消 AI 申報要求。這與產業界模型公司從供給走向平臺生態的路徑，例如中信證券點名 DeepSeek 的平臺化邏輯，屬於同一條線：AI 編碼不再是要不要用的問題，而是流程怎麼接住它的問題。

至於 10 月 8 日布拉格那場會議的完整討論細節，目前公開的資訊有限，僅能確認決策本身與 Linus 的表態。後續若郵件列表有更多爭論浮出，這個「不申報」的共識會不會動搖，是接下來幾個月值得留意的看點。