Linux 核心與 Rust 專案通過 AI 生成程式碼政策

此外，各子系統維護者也有權制定更嚴格的規則。2026 年 8 月，核心無線網路子系統（802.11、mac80211、WWAN、rfkill）的維護者 Johannes Berg 宣布了針對 AI/LLM 生成修補程式的強硬立場 ：

• 「三秒審查」規則： 任何在審查的三秒內無法明顯看出其正確性的修補程式，都將直接被忽略 。
• 拒絕來回修正： 他拒絕參與旨在修正 AI 生成修補程式的審查循環 。
• 拒絕低品質「垃圾內容」： 不是明顯正確的修補程式，將直接被駁回，不再進一步討論 。

在此之前，Greg Kroah-Hartman 也宣布了 drivers/staging/ 子系統的規則：除非是真正的安全性修復，否則拒絕所有 LLM 生成的修補程式 。

Linux 核心採取此方針的原因

核心社群指出了驅動這項政策的三個核心問題：

1. 審查頻寬危機： 維護者被大量 AI 生成的修補程式淹沒，其中許多雖然表面看起來不錯，但在語意上是錯誤的，甚至具有危險性 。
2. 訊號失真： 精巧的修補程式不再能可靠地代表真正的努力、理解或長期貢獻的意願 。
3. 責任歸屬： 社群得出的結論是，人類的責任無可妥協——機器無法認證法律上的原創性，也無法為錯誤承擔責任 。

Rust 專案：五個團隊的 LLM 政策（2026 年 8 月 5 日）

2026 年 8 月 5 日，Rust 專案的五個團隊通過了一項正式的 LLM 政策，適用於 rust-lang/rust 的單一儲存庫 。這項政策明確 不是 一個官方專案層級的立場，僅適用於核心儲存庫與採用該政策的團隊 。

允許的行為（需揭露）

• 使用 LLM 回答問題、分析程式碼或為了個人理解而學習程式碼庫 。
• 貢獻者進行私下的程式碼或文字審查 。
• 貢獻者自行驗證的錯誤發現 。
• 內容的機器翻譯 。

禁止的行為

• 提交 LLM 生成的文件，包括文件註解與安全性註解 。
• 發布 LLM 生成的 GitHub 評論、問題主體、拉取請求說明、編譯器診斷訊息或大量的原始碼註解 。
• 發布 LLM 創作的程式碼，除非事先獲得審查者同意並明確揭露 LLM 的使用 。
• 提交未經理解或審查的 AI 生成內容 。

這項政策的核心總結是：「可以使用 LLM 來回答問題、分析、提煉、精煉、檢查、建議和審查，但不能用來『創作』。」

Rust 採取此方針的原因

政策作者 Jynn Nelson 在官方公告文章中列出了三個核心問題 ：

1. 精巧的技術產品不再代表付出與理解： LLM 可以產出看起來很漂亮的修補程式，但提交者可能完全不了解其內容，這打破了原先一個精心製作的 PR 代表真正投入的社會訊號。
2. 審查頻寬已不堪負荷： rust-lang/rust 儲存庫有 1,281 個未處理的 PR。讓寫程式碼變簡單，卻沒有增加審查者的能量，只會讓既有的瓶頸更加惡化。
3. 機械式的複製貼上浪費所有人的時間： 貢獻者將審查評論貼給 LLM，再將 LLM 的回應貼回 GitHub，這樣的流程侵蝕了信任，也繞過了人類的深思熟慮。

此外，這項政策也意圖將過去非正式、不一致的審查方式，轉變為明確、公開的規則，讓審查者可以引用，新進貢獻者也可以查找 。

對開源治理的深遠影響

這兩項政策揭示了共同的模式與治理挑戰：

這代表什麼？

• 「審查危機」是核心張力。 兩個專案都認知到，LLM 大幅增加了貢獻的數量，卻沒有增加合格的審查者。這是目前最大的治理壓力點 。
• 訊號崩潰是真實的。 兩個社群都指出，過去一個設計完善的 PR 代表著付出與理解；LLM 已經打破了這個訊號 。
• 正式化取代臨機應變的審查。 兩個專案之所以從非正式規則轉向正式政策，正是因為不一致的執行方式讓貢獻者感到困惑，也讓維護者筋疲力盡 。
• 子系統的自主性至關重要。 Linux 核心的做法允許個別維護者制定更嚴格的規則，例如 Johannes Berg 對無線網路所做的。Rust 的做法則是讓各團隊選擇是否採用 。
• 對 AI 本身沒有共識。 Rust 的政策明確承認，專案層級對 AI 永遠不會有共識，因此政策僅聚焦於貢獻機制，而非對 LLM 做出道德判斷 。