5 月 17 日，Linus Torvalds 在 Linux 內核郵件列表（LKML）上發布了 7.1-rc4。每周發一個 RC 是他的慣例，過去三十多年從未間斷。但這一次，公告的后半段不是代碼變更統計，而是一段措辭罕見的警告：

“AI 報告的持續涌入，已經讓安全郵件列表幾乎完全不可管理了?！?/blockquote>

他說的是 security@kernel.org —— Linux 內核的私有安全披露渠道。這個郵件列表存在的意義是讓安全研究者在補丁準備好之前私下報告漏洞，避免被惡意利用。三十多年來，這套機制運轉良好，確保 Linux 內核代碼安全運行在全球數十億臺設備上，從 Android 手機到 AWS 服務器，從新能源汽車到國際空間站。

但如今 AI 正在瓦解這套機制的基本運轉邏輯。

重復的 AI 報告“攻擊”

“不同的人用同樣的工具發現了同樣的問題，產生了巨大的重復?！盠inus 寫道。維護者們把時間花在轉發報告、回復“這個問題一個月前就修了”、指向公開討論上。他把這稱為“完全沒有意義的空轉”。

問題出在一個簡單的邏輯上：當一個漏洞可以被 AI 工具輕易發現，它就不再是秘密?！?strong>如果你用 AI 工具發現了一個Bug，別人大概率也發現了。”Linus寫道，“AI 發現的漏洞從定義上就不算秘密，放在私有列表上處理只會讓情況更糟 —— 因為報告者看不到彼此的報告?！?/p>

這不是他第一次因為 AI 的事上 LKML 頭條。兩個月前的 4 月 12 日，內核社區經過長達數月的爭論，正式發布了 AI 輔助代碼的提交規范。當時爭論的焦點是：AI 生成的代碼能不能提交到內核？

Linus 堅持了一貫的實用主義終結了爭論，最終出臺的規范允許 AI 輔助編碼，但要求標注“Assisted-by”標簽，AI 代理不得使用具有法律效力的“Signed-off-by”簽名。核心原則只有一條：每一行 AI 生成的代碼，出了問題由點擊“提交”的人全權負責。

一份文檔，五條規矩

和 4 月的代碼規范一樣，這次 Linus 也不是只在郵件里抱怨。隨 7.1-rc4 一同合并的，還有一份由長期內核開發者 Willy Tarreau 撰寫的新文檔，標題是“什么才算安全 Bug”。

文檔先澄清了一個事實：送到安全團隊的大部分報告，根本不是安全 Bug，它們只是被錯誤歸類為安全問題的普通 Bug，原因是對 Linux 內核威脅模型缺乏了解。

緊接著是針對 AI 輔助發現 Bug 的五條規矩：

第一，報告要短。AI 生成的報告往往冗長無比，分段堆砌。文檔要求把關鍵信息放在最前面，不要讓審查者在多頁文本里大海撈針。 第二，純文本。AI 報告經常帶著 Markdown 格式標簽，但郵件列表的轉發和回復過程會破壞這些格式。要求一律轉成純文本。 第三，只說事實。AI 報告經常羅列一堆“可能的影響”和理論推導，文檔要求只提供可驗證的事實。 第四，確認復現。如果 AI 工具提供了一個復現步驟，先自己跑一遍。如果復現不了，這份報告的可靠性就要打一個大大的問號。 第五，帶上補丁。既然 AI 工具能發現 Bug，就讓它順便寫一個修復補丁。測試過再提交，并且必須包含“Fixes:”標簽指向引入 Bug 的那個 commit。

最關鍵的一條規則寫在前面：“如果你借助 AI 發現了 Bug，你必須將其視為公開信息。不要公開發布復現步驟，也不要再走私有安全披露渠道。因為當你的 AI 能發現這個問題的時候，別人的 AI 大概率也已經發現了?！?/p>

Greg KH 和他自己搭的 t1000

幾乎在同一時間，內核社區的“二把手”Greg Kroah-Hartman 正在做一件看起來和 Linus 的抱怨完全相反的事。

Greg 是 Linux 穩定版分支的主要維護者，負責把修復補丁回移到各個 LTS 內核版本。從今年 4 月初開始，他開始在自己的桌面上跑一臺 AI 模糊測試機器，名字叫 gkh_clanker_t1000。

硬件是一臺 Framework Desktop，搭載 AMD Ryzen AI Max + Strix Halo 處理器。這臺機器完全本地運行，不連任何云服務。后來他又加了一臺，叫 gkh_clanker_2000。

4 月 7 日以來，這套系統已經貢獻了近二十個被合并到主線內核的補丁。覆蓋的子系統包括 ALSA（音頻）、HID（人機接口設備）、SMB（文件共享）、Nouveau（NVIDIA開源顯卡驅動）和 IO_uring（異步I/O）。

Greg KH沒有公開這套工具的軟件棧細節 —— 用了什么模型、什么模糊測試框架、怎么把 LLM 和內核測試運行器串起來。Phoronix 在 4 月首次報道了這套系統，此后 Greg 只是在 Mastodon 上零星發了幾張機器的照片。

但結果擺在那里：從 4 月到現在，一個又一個真實的內核 Bug 被其發現、被修復、被合并。不是重復報告，也不是理論推導，而是實實在在的、有價值的代碼補丁。

AI 對內核社區的真實影響

Linus 的抱怨和 Greg 的實踐看起來矛盾，但放在時間線上看，它們指向的是同一個轉折點。

3月26日，Greg 在接受媒體采訪時說了一段話：“幾個月前，我們收到的是我們稱之為‘AI 垃圾’的東西，AI 生成的安全報告要么是錯的要么質量很低，當時覺得還挺搞笑的，并不太擔心?！?/p>

“但一個月前，發生了一些事情，世界突然變了?，F在所有開源項目都有用 AI 生成的真實報告，而且質量很好，是真正的 Bug?！?/p>

他說不清楚原因?！皼]人知道為什么，要么是很多工具突然變好了，要么是很多人開始認真對待這件事了。似乎是不同的團隊、不同的公司同時在做。”

在這次采訪中，他提到了自己的一次實驗：“我寫了一個特別簡單的提示詞，說‘給我找出這些’，它吐出了 60 個問題，還附帶了修復方案。大約三分之一是錯的，但仍然產生了三分之二正確的、有價值的補丁?！?/p>

他的結論是：“AI 工具已經很好了，我們沒法無視這件事，它在變得更好?！?/p>

但 Greg 也特別提到，Linux 內核能應對這個量級的 AI 報告，因為其團隊夠大，維護者分布也廣。他真正擔心的是小型開源項目，可能維護者沒有足夠的精力去處理這些指數級增長的 AI 報告。

對于 AI 工具近來對內核社區造成的真實影響，雖然 Linus 在吐槽，Greg 在猛夸，但實際上兩位內核社區大佬的表述并不矛盾：Linux 內核社區作為一個整體也許扛得住 AI 帶來的變化，但安全郵件列表這個特定的工作流確實已接近崩潰。

AI 只是工具，關鍵在于怎么用

看到 Linus 的抱怨后，有人提了一個自然的反問：既然 AI 在制造問題，為什么不用 AI 來篩選和過濾那些垃圾報告？

答案是，這等于在套娃。

AI 生成的假報告之所以煩人，恰恰是因為它們看起來像真的 —— 格式正確、堆棧信息齊全、問題描述有條理。傳統垃圾郵件過濾器能工作，是因為垃圾郵件有統計特征（批量發送、相似文本）。但 AI 生成的每條 Bug 報告都不一樣，這正是 AI 最難過濾的那類內容。更重要的是，AI 篩選器的誤殺代價遠比漏殺高 —— 一條垃圾報告被放過，最多浪費幾秒；但一條真實的內核 Bug 報告被誤殺，可能會導致永遠沒人去修。

Linus 的核心立場從來沒有變過：人要為代碼負責。每個補丁都有 Signed-off-by 簽名，每個子系統都有明確的維護者。這條責任鏈條的核心是可追溯的人類行為。引入 AI 做初篩，等于在最前端加了一個黑箱 —— 它為什么放過了這條、丟掉了那條，沒有人能給出有意義的解釋。

但這不意味著 Linus 反對 AI，他吐槽歸吐槽，并沒有對 AI 采取一刀切的行動，只是提出新的規范，促使有 AI 參與的工作流程與時俱進地優化。Greg 的 gkh_clanker 恰恰證明了他的邏輯：AI 是一個工具，關鍵在于誰在用它、怎么用。

Linus 抱怨的那些報告，是隨手用 AI 掃了一遍、把結果粘貼到郵件里就發出去的人。他們不理解代碼，不驗證結果，不提供補丁，不承擔任何責任。而 Greg 是自己跑 AI、自己驗證結果、自己寫補丁、自己 Signed-off-by、自己維護子系統。工具是一樣的工具，使用者是截然不同的人。

5 月 17 日，Linus 在 7.1-rc4 的公告末尾寫了一句總結：

“AI 工具很棒，但前提是它們真的有幫助，而不是造成不必要的麻煩和毫無意義的假裝工作。隨便用，但用在能提高效率的地方。”

然后他補了一句對那些只發報告不干活的人說的話：

“如果你真的想貢獻價值，讀文檔，寫個補丁，在 AI 做的事情之上加一些真正的價值。別做那種隨便發個報告、實際上什么都不理解的路過黨，好嗎？”

參考來源：

• Linus Torvalds, Linux 7.1-rc4 Release Announcement, LKML-https://lkml.org/lkml/2026/5/17/896

• The Register-https://www.theregister.com/security/2026/05/18/linus-torvalds-says-ai-powered-bug-hunters-have-made-linux-security-mailing-list-almost-entirely-unmanageable/5241633

• Phoronix-https://www.phoronix.com/news/Clanker-T1000-AMD-Ryzen-AI-Max

• 老牌開源項目該不該接受 AI 代碼？-https://my.oschina.net/u/4487475/blog/19585524