Linux 內核開發者 Dave Hansen 近日在社區發表了關於如何使用 AI 工具的政策補丁。

Dave Hansen 表示，在過去幾年中，AI 工具（包括 AI 驅動的編碼輔助工具）在開發過程中的能力大幅提升。社區越來越多地成員在詢問：當工具生成（或部分生成）內容時，貢獻者應如何使用／披露這些工具。

因此他提交的補丁旨在為內核貢獻中“工具生成內容”（tool-generated content）提供文檔指南。這個文件並非完全新增規則，而是提供一個統一的預期標準。

這份補丁明確指出：貢獻者使用工具生成內容時，應清晰披露使用方式，以便維護者／審查者能夠有效審查。當然像拼寫修正、格式化、變量重命名等小修改則不需要額外披露。

在變更日誌、提交説明中，應註明哪些內容使用了工具、工具是什麼、工具輸入／提示是什麼。

適用範圍 (“In Scope” vs “Out of Scope”)

• 不適用的情況（Out of Scope）：

  • 工具僅用於極小改動，如拼寫或語法修正、改寫為祈使句、變量重命名、格式化代碼等。

• 適用情形（In Scope）：

  • 當“重要內容”由工具而非人工撰寫。例：一個新函數由大語言模型生成、一個文件完全由腳本生成、變更日誌由 AI 編寫。 

  • 在這些情形下，必須披露工具使用情況，包括工具名稱、輸入、生成的內容範圍、人工的修改情況等。

具體指南

• 在提交時：遵循已有的貢獻者認證規則（例如開發者證書 DCO）並同時遵守本“工具生成內容”指南。 

• 在變更日誌／提交説明中，建議包括如下要素：

  • 使用了哪些工具？

  • 工具的輸入是什麼？（如：提示、腳本）

  • 工具生成了哪些內容？（例如：一個函數、一個 .c 文件、補丁註釋）

  • 哪些部分為人工撰寫／修改？並説明人工審核或修改的程度。 

• 維護者仍然保留對貢獻的審核判斷權：例如是否按常規處理，是否額外要求説明工具訓練背景，是否建議更好的提示，而非直接代碼變更。

Dave Hansen 在郵件強調，這不是新的強制限制，而是對既有期望的明確化：在 AI 輔助開發成為常態的背景下，透明度對代碼質量與審核效率至關重要。維護者仍可基於實際情況要求更多信息或拒絕質量不達標的貢獻。