「我覺得 Copilot 建議的這個 patch 可以直接送 PR。」這句話在許多台灣開發者的 workspace 聊天群組裡出現的頻率越來越高。AI 程式碼生成工具已經成為日常開發的標配，當你正在寫一個 PR，Copilot 自動補上 commit message，GitHub Copilot 幫你重構程式碼，甚至建議測試案例，這些都不再是新鮮事。

但當你要貢獻給 Linux 內核時，這個故事變得複雜了。

Linus Torvalds 的團隊最近在官方文件中新增了 Documentation/process/coding-assistants.rst，明確規範在貢獻 Linux 內核時如何使用 AI 輔助工具。這不是一份「禁止使用 AI」的檔案，而是一份「如何負責任地使用 AI」的指南。這份文件的出現，標誌著最保守的開源專案開始正式面對 AI 時代。

為什麼 Linux 內核需要特別規範

Linux 內核不是普通的開源專案。它是全球最大的協作專案之一，維護者對程式碼品質的要求近乎苛刻。每一個 patch 都經過嚴格的 review，維護者會逐行檢查程式碼邏輯、記憶體管理、並發安全性、硬體相容性。一個看似無害的變更可能導致整個系統崩潰，這是 Linux 內核維護者最在意的問題。

AI 工具帶來了新的挑戰。Copilot、ChatGPT、Claude Code 等工具生成的程式碼，表面上可能看起來正確，但可能隱藏著微妙的 bug、不當的記憶體使用方式，或者不符合 Linux 內核的 coding style。更嚴重的是，AI 模型訓練資料中包含大量網路上的程式碼，如果貢獻者直接使用 AI 生成的程式碼而不進行深入理解，可能會導致版權問題。

維護者擔心的不是「工具本身」，而是「貢獻者是否真的理解自己送出的程式碼」。如果一個 patch 是 AI 生成，貢獻者沒有仔細審查就送出，這與直接從網路上複製貼上程式碼沒有兩樣。這正是 Linux 內核長期以來反對的行為。

官方文件的三大核心原則

讀完這份官方文件後，可以整理出三個核心原則：

原則一：你是對程式碼負責的人

文件開頭就明確指出：「使用 coding assistant 並不會改變你作為貢獻者的責任。」無論程式碼是自己手寫的，還是 AI 協助生成的，送出 patch 時，你就是這個 patch 的負責人。維護者不會因為「這是 AI 生成的」就降低標準，你仍然需要回答關於程式碼邏輯、設計決策、潛在問題的所有問題。

這意味著什麼？如果你使用 AI 生成了一段程式碼，但自己不了解它的工作原理，無法解釋為什麼這樣寫，那麼你不應該送出這個 patch。維護者期望的是你能夠「擁有」你送出的每一行程式碼，即使有工具協助。

原則二：AI 生成內容必須標註

文件強烈建議在 commit message 中標註 AI 工具的使用。例如：

This patch was written with assistance from [AI tool name].

為什麼需要標註？首先是透明度。維護者有权知道一個 patch 的來源，這有助於他們更好地理解程式碼的上下文。其次是責任歸屬。如果一個 AI 生成的程式碼後來被發現有問題，標註有助於追蹤問題的來源。

這個要求與學術界對 AI 生成內容的規範類似——如果你使用了工具，就應該誠實地說出來。

原則三：不要讓 AI 替你做「理解」

文件中最有趣的一段話是：「不要讓 AI 替你做你應該做的理解工作。」這句話直指 AI 工具的核心問題——它們可以生成程式碼，但無法替你理解程式碼。

舉個例子，你正在寫一個驅動程式，Copilot 建議了一段中斷處理程式碼。這段程式碼可能看起來正確，甚至能夠編譯通過。但如果你不理解中斷處理的完整機制、不知道這段程式碼為什麼要這樣寫、不了解可能的邊緣情況，那麼你不應該直接使用它。AI 工具是「協助」，不是「替代」。

對台灣開發社群的實際影響

這份文件對台灣開發者有什麼實際意義？我們來看幾個具體場景。

場景一：使用 AI 輔助 Linux 驅動開發

假設你在一家台灣的半導體公司，正在開發 Linux 驅動程式。你遇到一個棘手的記憶體管理問題，決定詢問 Claude Code。Claude 提供了一段程式碼，看起來解決了你的問題。

根據 Linux 內核的新規範，你應該：

  1. 仔細閱讀並理解這段程式碼：確保你知道每一行在做什麼，為什麼要這樣寫。
  2. 手動測試：不要依賴 AI 的聲稱，自己編寫測試案例，驗證程式碼在真實硬體上的行為。
  3. 標註 AI 使用：在 commit message 中清楚說明使用了 AI 工具，以及哪部分程式碼是 AI 生成的。
  4. 準備回答維護者的問題：維護者可能會問「為什麼要用這種記憶體分配方式」，你必須能夠回答，不能說「是 AI 建議的」。

場景二：AI 幫你寫 commit message

另一個常見場景是 AI 幫你生成 commit message。你寫完程式碼後，Copilot 自動生成了一段 commit message。

根據新規範，這是可以接受的，因為 commit message 本身不是程式碼邏輯。但你仍然需要審查這個 commit message，確保它準確描述了你做的變更。如果 AI 生成的描述不準確或誇大了變更範圍，你應該修正它。

場景三：AI 建議程式碼重構

你在 review 自己的程式碼時，AI 工具建議重構某個函數。你接受建議後，程式碼變得更簡潔。

這也是可以接受的，前提是你理解重構後的程式碼為什麼更好，並且能夠向維護者解釋你的設計決策。如果維護者問「為什麼要重構這個函數」，你的回答不應該是「AI 說這樣更好」，而應該是「因為這樣可以減少記憶體複製，提升效能」。

程式碼品質標準沒有放鬆

一個重要的誤解是：「有了 AI 工具，我可以寫更快的程式碼，標準可以放鬆嗎？」答案是「不」。Linux 內核維護者強調，標準沒有放鬆，只是工具變了。

如果你送出的 AI 生成程式碼有 bug，維護者的反應會和你手寫程式碼有 bug 一樣——要求你修正。如果你無法理解或修復問題，維護者會拒收 patch。AI 工具不會給你任何「豁免權」。

事實上，AI 工具帶來的新風險，可能導致維護者對某些貢獻者更加謹慎。如果一個貢獻者送出的 patch 有模式化的 AI 生成痕跡，但 commit message 模糊不清，維護者可能會要求更詳細的解釋，甚至要求重寫。

AI 版權與許可問題

Linux 內核使用 GPL-2.0 許可證，這意味著所有貢獻的程式碼必須符合開源許可要求。AI 生成的程式碼帶來了新的版權問題——AI 模型訓練時使用了大量 GPL 程式碼，生成的程式碼是否也帶有 GPL 義務？

這份文件沒有直接回答這個法律問題，但提供了一個實務建議：如果你使用了 AI 工具，應該確保生成的程式碼可以被你合法貢獻給 Linux 內核。這意味著你應該仔細檢查 AI 生成的程式碼，避免直接複製來源不明或許可不清晰的程式碼片段。

如何判斷 AI 工具使用是否過度

一個實際的問題是：怎麼判斷自己是否「過度依賴」AI 工具？這份文件提供了一些判斷標準：

健康的 AI 工具使用方式應該是：AI 幫你生成初步方案，你負責理解、審查、測試、優化。你是駕駛者，AI 是導航，不是自動駕駛。

維護者的態度：不是反對，而是規範

這份文件傳遞的一個重要訊息是：Linux 內核維護者不是反對 AI 工具，而是試圖建立規範。他們理解 AI 工具可以提高生產力，減少重複性工作，甚至在某些情況下發現人類容易忽略的 bug。

他們擔心的是，AI 工具的便利性可能導致貢獻者放棄深入理解程式碼，這與 Linux 內核長期以來建立的開源文化相衝突。開源的核心是「透明」和「理解」，而不是「快速」和「便利」。

這與其他開源專案的態度一致。許多大型開源專案都在制定類似的 AI 使用規範，核心原則都是：工具是輔助，責任在人類。

給台灣貢獻者的具體建議

最後，給打算貢獻 Linux 內核的台灣開發者一些具體建議：

  1. 先學會不用 AI 貢獻：在你熟悉 Linux 內核的 coding style、review 流程、維護者期望之前，先嘗試手動貢獻。這會幫助你建立基礎能力，之後再用 AI 工具加速。

  2. AI 生成後，手動重寫一遍：不要直接使用 AI 生成的程式碼。讀完後，關閉 AI 工具，自己重新寫一遍。這能確保你真的理解程式碼邏輯。

  3. 標註 AI 使用，但不要以此為藉口：在 commit message 中標註 AI 工具，但不要認為這樣維護者就會降低標準。你仍然需要對程式碼負責。

  4. 小心許可問題：如果 AI 生成的程式碼看起來來源不明，特別是與現有 GPL 程式碼高度相似，不要直接使用。自己重寫，確保版權清晰。

  5. 參與討論：這份文件是「草稿」，Linux 內核社群正在討論 AI 規範的最佳實踐。如果你有經驗或見解，參與討論，幫助社群建立更好的規範。

AI 時代的開源貢獻新標準

Linux 內核的這份文件，代表了 AI 時代開源貢獻的一個重要轉折點。AI 工具已經成為開發流程的一部分，但開源社群正在建立新的標準——使用工具可以，但不能放棄理解和責任。

對台灣開發者來說，這是一個機會。如果你能建立「善用 AI 工具同時保持深入理解」的能力，你將在 AI 時代的開源貢獻中具有優勢。你不是被 AI 取代的開發者，而是善用 AI 的開發者。

Linux 內核維護者給出的答案很明確：AI 是工具，你是主導。當你送出下一個 patch 時，無論程式碼來源如何，記得問自己一句：「我能不能解釋清楚這段程式碼為什麼這樣寫？」

如果答案是肯定的，那就送出去。如果不是，那就再想想。

參考資料