Assisted-by: tag 列明使用咗邊款 AI 工具、咩版本嘅模型,同埋用過嘅輔助分析工具。除此之外,各個子系統嘅 maintainer 有權力訂立更嚴厲嘅規則。2026 年 8 月,負責 Linux 無線網絡子系統(包括 802.11、mac80211、WWAN、rfkill 等)嘅 maintainer Johannes Berg,就公布咗一個仲嚴厲嘅政策嚟應對 AI/LLM 生成嘅 patch :
呢個政策之前,另一關鍵維護者 Greg Kroah-Hartman 已經公布咗 drivers/staging/ 子系統會 reject 所有 LLM 生成嘅 patch,除非係真實嘅保安修正。
Kernel 社群認為有三個核心問題令到佢哋要出政策:
2026 年 8 月 5 日,Rust 項目入面嘅五個團隊一齊通過咗一個正式嘅 LLM 政策,適用於 rust-lang/rust 嘅 monorepo 。呢個政策唔係整個 Rust 項目嘅官方立場,只係適用於核心儲存庫同呢五個團隊。
呢個政策嘅核心總結係:「用 LLM 嚟問問題、分析、提煉、檢查、建議、審閱係冇問題嘅,但唔可以用嚟創作。」
政策作者 Jynn Nelson 喺官方公告 blog 入面指出咗三個核心問題:
rust-lang/rust 當時有成 1,281 個 open PRs。令寫 code 容易啲,但冇增加 reviewer 嘅數量,只會令樽頸問題更嚴重。此外,政策都係為咗將之前唔正式、唔一致嘅裁決方式,變成清晰、有文件可以跟嘅規則,等 reviewer 同新貢獻者都有所依從。
兩個政策都展示咗一個共同模式,同埋一系列共同嘅管治挑戰:
| 維度 | Linux Kernel | Rust Project |
|---|---|---|
| 範圍 | 全項目政策 + 子系統級別嘅硬性規定 | 五個團隊,限於核心儲存庫 |
| 人類責任 | 絕對:提交者孭曬所有法律同技術責任 | 絕對:冇披露同理解就唔可以提交 AI 內容 |
| AI 生成嘅代碼 | 容許,但要披露同有人簽署 | 基本上禁止,除非預先得到 reviewer 批准 |
| AI 生成嘅文字/文件 | 政策冇特別針對 | 嚴格禁止 |
| 子系統自主權 | Maintainers 可以更嚴(例如無線嘅「三秒規則」) | 限於團隊採用嘅範圍 |