貢獻 Linux 核心時的 AI 輔助規範 （★ 89 分）
Linux 核心最新納入一份關於 AI 程式撰寫助手的文件，重點不是全面禁止，而是把 AI 納入既有的核心開發流程管理。文件明定，任何使用 AI 協助的開發者與工具，都必須遵守 Linux 核心一貫的開發流程、程式風格與修補程式提交流程；換句話說，AI 不會降低審查標準，也不會改變可併入核心的基本門檻。
在授權與法律層面，文件要求所有貢獻都必須與 GPL-2.0-only 相容，也就是 GNU General Public License 第 2 版，且不含後續版本選項，並使用 SPDX ( Software Package Data Exchange，常用的授權識別格式 ) 標註。更關鍵的是，AI 代理不得自行加入 Signed-off-by 簽署註記，因為只有人類才能在法律上確認 DCO ( Developer Certificate of Origin，開發者原始聲明 )；實際送件的人必須逐一審閱 AI 產生的程式碼、確認授權無誤、補上自己的簽署註記，並對整份貢獻負完全責任。為了讓 AI 在開發流程中的角色可追溯，文件也建議新增 Assisted-by 欄位，寫明所用代理名稱、模型版本，以及 coccinelle、sparse、smatch、clang-tidy 等專門分析工具，但 git、gcc、make 或編輯器這類一般工具不必列出。
討論區多數人認為，這套規則的用意是把現實制度化：到了 2026 年，很難期待開發者完全不用 AI，因此與其一刀切，不如要求人類送件者承擔責任並清楚揭露 AI 參與情形。有些人甚至認為，BSD 等其他開放原始碼專案也可能跟進。也有人補充，核心維護者在意的不只是出了問題之後能不能究責，更重要的是送件者是否真的理解自己交出的程式碼，未來也願意持續維護；如果作者本來就能自己寫、只是拿 AI 當輔助，這份規則影響不大，但若是靠大型語言模型 ( LLM, Large Language Model ) 代寫自己根本不懂的內容，風險就高得多。幾位留言者也區分了讓 LLM 幫忙找漏洞，和讓它直接代寫修補程式：前者比較像提供線索，後者才會把維護負擔轉嫁給核心團隊。
反對聲音則集中在著作權與法律責任。質疑者指出，LLM 的訓練語料混有多種授權，甚至可能包含未經同意取得的封閉原始碼，因此人類送件者很難真正保證輸出內容完全符合 GPL 規範；若日後出現侵權爭議，責任未必只落在個別貢獻者身上，允許這類流程的基金會或維護體系也可能被追究。也有人反駁，侵權風險並非 AI 獨有，人類開發者本來就可能把不相容的程式碼帶進核心，現階段最務實的做法仍是由實際審閱並散布變更的人承擔後果。另一些人不滿 Assisted-by 這種寫法，認為它過度擬人化模型；但也有人回應，這個欄位同樣會記錄 coccinelle 或 clang-tidy 之類的工具，本質上是來源揭露與稽核線索，而不是承認 AI 具有人格。整體看來，較多意見不是把 AI 視為可靠作者，而是把它當成必須被揭露、被審閱、也可能在日後被全面清查的風險工具。
👥 74 則討論、評論 💬
https://news.ycombinator.com/item?id=47721953