當 AI 可以寫出能運作的程式碼，誰該為這些程式碼負責？這不是哲學問題，而是 Linux 內核社群剛剛給出的具體答案。

一份只有 200 字的關鍵文件

2026 年初，Linus Torvalds 的程式碼庫裡多了一個新文件：coding-assistants.rst。這份文件不長，全文不到 200 字，卻清楚地界定了 AI 工具在全球最大協作專案中的角色。

文件開頭就說明，這是為「使用 AI 協助參與 Linux 內核開發的開發者」提供的指引。重點不是「是否可以使用」，而是「如何正確使用」。

這份文件的核心很簡單：AI 工具可以幫忙，但不能取代人類責任。

為什麼需要這份文件？

Linux 內核開發有著嚴格的流程和規範。每行程式碼提交前，都要經過 code review、測試，最後由維護者批准。這套流程運作了三十多年，確保了內核的穩定性和可靠性。

當 AI 工具開始被廣泛使用時，問題就來了：AI 寫的程式碼，誰負責審查？誰負責署名？誰負責確保授權合規？

這不是理論問題。2025 年就發生過開發者直接用 AI 生成的程式碼提交到內核，結果因為授權問題被拒絕的案例。這名開發者使用了一個 AI 工具生成一段驅動程式碼，但 AI 的訓練資料中包含了 GPL 不相容的程式碼片段。雖然程式碼可以運作，但法律上無法被接受。

Linux 內核使用 GPL-2.0-only 授權，所有貢獻必須相容。如果 AI 工具訓練資料中包含非 GPL 授權的程式碼，生成的程式碼可能就會產生授權衝突。這不是小問題，一旦授權混亂，整個專案的法律地位都可能受到影響。

這就是為什麼需要明確規範的原因。

三個核心規則

1. 遵守標準開發流程

文件列出了三個必須遵守的開發流程文件：
– development-process.rst：開發流程
– coding-style.rst：程式碼風格
– submitting-patches.rst：補丁提交

這意味著，無論程式碼是人類還是 AI 寫的，都要經過同樣的審查標準。AI 寫的程式碼不會因為「來自 AI」就得到放水。

例如，coding-style.rst 要求程式碼遵循特定的縮排、命名規範。如果 AI 生成的程式碼不符合這些規範，維護者會要求修改。你不能說「這是 AI 寫的，風格不重要」。

2. 授權合規是硬性要求

所有程式碼必須與 GPL-2.0-only 相容，並使用正確的 SPDX 授權識別符。這不是可以商量的部分。

SPDX（Software Package Data Exchange）是一套標準化的授權識別方式。例如，你會在原始碼檔案開頭看到這樣的標註：

// SPDX-License-Identifier: GPL-2.0-only

AI 生成的程式碼如果缺少這些標註，或者標註錯誤，就會被拒絕。維護者會要求你檢查 AI 的輸出，確保符合授權要求。

3. AI 不能簽名，人類必須負責

這條規則最關鍵：「AI 代理必須不能加入 Signed-off-by 標籤。只有人類才能在法律上證實開發者原始憑證（DCO）。」

DCO（Developer’s Certificate of Origin）是 Linux 社群使用的法律框架。每次提交程式碼時，開發者必須用 Signed-off-by 標籤證實：
1. 我有權利提交這個程式碼
2. 程式碼的授權合規
3. 我理解並同意 DCO 條款

這不僅僅是技術要求，而是法律承諾。當你在 commit message 中加上 Signed-off-by: Your Name <email@example.com> 時，你在法律上聲明你對這個程式碼負責。

AI 工具無法在法律上做出這樣的承諾，因此不能加上 Signed-off-by 標籤。即使 AI 工具幫你寫了 99% 的程式碼，最終的簽名必須來自人類。

人類的責任有哪些？

文件明確列出，人類提交者必須負責：
1. 審查所有 AI 生成的程式碼
2. 確保符合授權要求
3. 加入自己的 Signed-off-by 標籤以證實 DCO
4. 承擔貢獻的全部責任

這意味著，即使程式碼 90% 都是 AI 寫的，人類還是要仔細檢查每一行。你說「我沒仔細看，是 AI 寫的」在 Linux 內核社群行不通。

實際上，因為 AI 生成的程式碼可能包含潛在的問題，人類的審查變得更重要。常見的 AI 生成問題包括：
– 授權風險：AI 可能複製訓練資料中的程式碼片段，導致授權衝突
– 安全漏洞：AI 可能生成有安全問題的程式碼，例如緩衝區溢出
– 邏輯錯誤：AI 可能理解錯誤需求，生成不符合預期的程式碼
– 風格不符：AI 可能不符合社群的程式碼風格

這些問題都需要人類開發者仔細檢查和修正。

Assisted-by 標籤：透明地使用 AI

為了追蹤 AI 在開發過程中的角色，文件建議使用 Assisted-by 標籤。

格式是：

Assisted-by: AGENT_NAME:MODEL_VERSION [TOOL1] [TOOL2]

例如：

Assisted-by: Claude:claude-3-opus coccinelle sparse

這裡：
– AGENT_NAME：AI 工具或框架的名稱
– MODEL_VERSION：使用的具體模型版本
– [TOOL1] [TOOL2]：可選，使用的專門分析工具（如 coccinelle, sparse, smatch, clang-tidy）

注意，基本開發工具（git, gcc, make, 編輯器）不需要列出。

這個標籤的好處是透明化。維護者可以一眼看出哪些程式碼有 AI 協助，可能需要更仔細的檢查。同時，這也幫助社群追蹤 AI 工具的使用趨勢，了解 AI 在開發過程中扮演的角色。

一個完整的 commit message 範例可能長這樣：

drm/amdgpu: Fix memory leak in display cleanup

The display cleanup path was missing a kfree call, causing memory to leak
when the driver was unloaded.

This patch was generated with assistance from AI tools for the initial
implementation, but has been thoroughly reviewed and tested.

Signed-off-by: Developer Name <email@example.com>
Assisted-by: Claude:claude-3-opus

DCO 的歷史背景

為什麼 Linux 內核社群如此重視 Signed-off-by 標籤？這要追溯到 2004 年。

當時，內核社群遇到了一個問題：開發者無意中提交了來自其他專案的程式碼，但沒有聲明來源。這導致了法律風險。為了避免這種情況，Linus Torvalds 推出了 DCO 機制。

DCO 的核心思想很簡單：每次提交程式碼的人，都要聲明「我有權利提交這個程式碼」。這是一種「信任但驗證」的機制。你聲明你有權利提交，但如果後來發現你沒有，法律後果由你承擔。

這個機制運行了 20 多年，證明是有效的。現在面对 AI 工具，Linux 社群選擇延續這個機制，而不是建立新的規則。這體現了社群對穩定性的重視。

AI 工具在內核開發中的實際應用

雖然這份文件強調了責任，但這不代表 AI 工具在內核開發中沒有用處。實際上，許多內核開發者已經在使用 AI 工具來提高效率。

常見的應用場景包括：
– 程式碼重構：AI 可以幫忙將舊式程式碼轉換為新的 API
– 測試案例生成：AI 可以根據需求描述生成測試程式碼
– 文件撰寫：AI 可以幫忙生成或改進註釋和文件
– Bug 分析：AI 可以協助分析 crash dump 或日誌

但無論哪種應用，最終的審查和責任都要由人類承擔。

一個真實案例：2025 年末，一位內核開發者使用 AI 工具重構了一個舊的驅動程式。AI 生成了大部分程式碼，但開發者花了兩天時間仔細檢查每一行，進行了多次修改，最後才提交。提交時，他加上 Assisted-by 標籤，並在 commit message 中說明哪些部分是 AI 生成，哪些是他自己修改的。這個 patch 被接受了，因為開發者清楚地說明了情況，並承擔了責任。

這不是「拒絕 AI」，而是「規範使用」

有些人可能會認為，這是 Linux 社群在抗拒 AI。但實際上，這是接受 AI 的同時，建立合理的規範。

Linus Torvalds 本人在多個場合表示，他不反對使用 AI 工具，前提是遵守社群的規範。他在 2025 年的 kernel summit 上說：「如果 AI 能幫忙寫出更好的程式碼，為什麼不用？但你還是要自己審查，自己負責。」

這與許多開源專案的態度一致。GitLab 在 2024 年就發布了 AI 開發指南，強調「AI 是工具，不是責任的替代品」。GitHub 也提醒開發者，Copilot 生成的程式碼可能包含授權問題。

Linux 內核的文件並不是要禁止 AI，而是要確保 AI 的使用不會破壞社群運作了三十多年的核心價值：質量、責任、透明。

對開發者的實際影響

好消息

  1. 你可以合法使用 AI 工具協助開發
  2. 不用擔心「用了 AI 就被拒絕」
  3. 有明確的署名方式，可以透明展示 AI 的貢獻
  4. 社群接受這是一個進化的過程，不要求你立刻改變工作方式

壞消息

  1. 你不能偷懶，必須仔細審查 AI 生成的程式碼
  2. AI 幫忙越多，你的責任越重
  3. 如果出問題，你不能怪 AI
  4. 維護者可能會對標記 Assisted-by 的 patch 進行更嚴格的審查

實用建議

如果你打算在內核開發中使用 AI 工具：
1. 先了解規範：閱讀 coding-assistants.rst 和相關文件
2. 透明使用：總是加上 Assisted-by 標籤
3. 仔細審查：把 AI 生成的程式碼當作「初稿」，而不是最終版本
4. 測試徹底：AI 可能會生成表面正確但有隱藏問題的程式碼
5. 承擔責任：一旦提交，就是你的責任，不要怪 AI

適用於所有開源專案的啟示

Linux 內核的做法為其他開源專案提供了參考模式。如果你的專案在思考如何規範 AI 使用，可以考慮：

  1. 明確責任歸屬：AI 可以協助，但人類必須最終負責
  2. 保持標準流程：AI 生成的程式碼不應得到特殊待遇
  3. 要求透明化：使用 Assisted-by 或類似標籤
  4. 法律合規：確保授權和法律要求得到滿足
  5. 文檔化規範：像 Linux 內核一樣，寫下清晰的指引

不同的專案可能有不同的需求。有些專案可能接受 AI 生成的程式碼只要通過測試，有些可能要求完全人類撰寫。關鍵是明確規則，讓所有貢獻者都清楚了解。

其他開源專案的經驗

Apache 基金會

Apache 基金會在 2025 年初發布了 AI 使用指引，要求所有貢獻者必須聲明是否使用了 AI 工具，並對 AI 生成的程式碼負責。Apache 的規範與 Linux 類似，但增加了關於 AI 偏見和公平性的考慮。

Mozilla

Mozilla 採用了更保守的做法。雖然允許使用 AI 工具協助開發，但要求所有關鍵安全相關的程式碼必須由人類撰寫。這反映了 Mozilla 對瀏覽器安全性的重視。

Python 軟體基金會

Python 社群正在討論 AI 工具的使用規範。目前，核心開發團隊建議使用 AI-assisted 標籤來標記有 AI 協助的貢獻，但最終的決定權仍在討論中。

這些不同的經驗顯示，沒有「一個答案」適用所有專案。每個社群都需要根據自己的價值和需求，找到合適的平衡點。

對台灣開發者的啟示

台灣有許多活躍的開源貢獻者，從大型科技公司到個人開發者。Linux 內核的政策提供了一個重要啟示：工具可以進步，但責任不能退步。

企業開發者

如果你在台灣的科技公司工作，負責內部或開源專案：
1. 建立內部規範：參考 Linux 內核的文件，制定公司的 AI 使用指引
2. 培訓團隊：確保所有開發者了解 AI 工具的風險和責任
3. 建立審查流程：AI 生成的程式碼應該經過額外的 code review
4. 法律諮詢：如果你的產品涉及開源，諮詢法律專家關於授權問題

獨立開發者

如果你是自由開發者，參與開源專案：
1. 了解專案規範：每個專案可能有不同的 AI 使用政策
2. 透明溝通：如果使用了 AI，清楚說明，不要隱藏
3. 提升審查技能：學習如何有效審查 AI 生成的程式碼
4. 保持警惕：特別注意授權和安全問題

學生和新手

如果你正在學習開發：
1. AI 是學習工具，不是抄襲工具：可以用 AI 學習概念，但不要直接複製
2. 理解原理：即使 AI 生成了程式碼，也要確保你理解它是如何工作的
3. 建立正確習慣：從一開始就養成仔細檢查和承擔責任的習慣
4. 參與社群：加入開源社群，學習經驗豐富的開發者如何處理 AI 問題

無論你在開發什麼，從個人專案到企業級軟體，問自己幾個問題：
1. 如果這個程式碼出問題，你敢不敢說「我負責」？
2. 你仔細檢查過 AI 生成的每一行程式碼嗎？
3. 你知道 AI 的訓練資料來源和潛在的授權風險嗎？
4. 如果有人問你這段程式碼是怎麼來的，你能清楚說明嗎？

如果答案是否定的，或許該重新思考你的工作流程。

未來的發展

Linux 內核的 coding-assistants.rst 文件可能只是一個開始。隨著 AI 工具的進化，社群可能需要更新和擴充這些規範。

可能的發展方向包括：
– 更細緻的 AI 工具分類：不同類型的 AI 工具可能有不同的使用規範
– 自動化檢查工具：開發工具來檢測 AI 生成的程式碼中的潛在問題
– 授權風險評估：建立機制來評估 AI 工具的訓練資料是否包含授權問題
– 社群監督：建立機制來監督和審查 AI 工具的使用

但無論如何發展，核心原則可能不會改變：人類責任不能被取代。

技術進步與責任的平衡

Linux 內核的這份文件很短，但它傳遞的信息很清晰：技術在進步，但人類的責任不會消失。

AI 工具讓我們能更高效地開發，但這不代表我們可以降低標準。相反，因為效率提高了，我們有更多的時間來確保品質，來承擔責任，來維持社群的健康。

這或許就是開源社群長久的秘訣：在擁抱新技術的同時，不放棄最核心的價值。

Linux 內核不是拒絕改變。它運作了三十多年，經歷了無數技術變革。從 C 語言的演進，到 Git 的採用，到 CI/CD 的引入，內核社群一直在進化。現在，它正在進入 AI 時代，但帶著它的核心價值：質量、責任、透明。

這份文件不是結論，而是開始。它開啟了一個關於 AI 和開源未來的對話。這個對話會持續很多年，隨著技術的進化而演變。但有一點是肯定的：人類開發者的角色不會消失，只會改變。

或許是時候問問自己：你在使用 AI 工具時，是在讓它幫你，還是在讓它替你？

這兩者的區別，可能比任何技術細節都更重要。