Debian 關於 LLM 使用的決議草案：提案 A-D 解析

概述

Debian 於 2026 年 7 月 25 日進行的決議投票提出了四項競爭性提案，討論該專案應如何處理涉及大型語言模型 (LLM) 或其他生成式 AI 工具的貢獻。這些提案的範圍從完全禁止到附帶條件的寬鬆框架不等，社群正在進行辯論，隨後將做出最終決定。

提案 A：完全禁止

提案 A 尋求明確禁止任何使用 LLM 或其他生成式 AI 工具輔助所撰寫的 Debian 貢獻。其範圍涵蓋 Debian 源軟體包、官方專案軟體、網路資源、文件、翻譯及官方溝通，但不包括使用 LLM 的上游專案和 AI 相關軟體。其理由引用了四個疑慮：LLM 輸出之版權狀態不明確、品質與準確性問題、對社群審核者的壓力，以及 LLM 訓練數據抓取與資源消耗帶來的倫理損害。為了消除疑慮，該提案在社會契約 (Social Contract) 中增加了一項條款，聲明 Debian 將不允許透過 LLM 直接進行的貢獻。執行層面被認為具有挑戰性，但將依賴社群的誠信。

提案 B：附帶條件的允許

提案 B 允許 AI 輔助的貢獻（由 LLM 部分或全部生成），前提是必須滿足六個條件：(1) 工具法律相容性，確保 AI 的條款與 Debian 的發行、修改或使用不衝突；(2) 授權與歸屬，要求驗證輸出中任何第三方版權材料均可在相關開源授權下使用；(3) 責任歸屬，要求提交者對技術價值、安全性、授權合規性和實用性負全責；(4) 披露，規定必須明顯標註 AI 生成或 AI 輔助的工作（例如透過 Git trailer）；(5) 對於大量或自動化變更需事先討論，類似於大量錯誤提交 (mass-bug filing) 流程，並由人類監督；以及 (6) 保密與隱私，禁止使用可能洩露非公開或敏感專案資訊的雲端 AI。

提案 C：勸阻並附帶披露要求

提案 C 並不實施完全禁止，而是要求所有貢獻者在 Debian 工作中避免使用 LLM，要求決策者在實務上勸阻使用 LLM，並呼籲更廣泛的自由軟體社群遠離該技術。它在行為準則 (Code of Conduct) 中補充了八項要求：(1) 給人類的訊息必須完全由人類撰寫，不得有 LLM 輔助；(2) 任何在 Debian 工作中使用 LLM 的行為都必須披露；(3) 個別專案和維護者可以完全禁止 LLM 貢獻，且此類禁令必須受到尊重；(4) 違規行為將被視為違反行為準則，並受到迅速且成比例的紀律處分；(5) 無法在沒有協助的情況下用英文寫作的貢獻者可以用母語撰寫，歡迎並非強制要求提供人類撰寫的英文摘要；(6) 該提案承認，鑑於上游的使用情況，目前實施完全禁止是不切實際的。

提案 D：接受用於 Debian 特定工作的 AI 貢獻

提案 D 承認 AI 輔助實踐已在被使用，並選擇將責任歸於貢獻者而非禁止使用。這些指南僅適用於專門為 Debian 專案所做的程式碼和工作（網站、應用程式、資源、軟體包）。貢獻者必須確保工作符合 DFSG，對提交的工作負全責，必須理解並能夠為其辯護，必須親自套用任何 Signed-off-by 標籤和 GPG 簽章，並必須確保任何上傳到生產基礎設施的內容都是由其明確提交的。由生成式 AI 代理或工具輔助的工作應在適當位置（提交訊息、變更日誌等）標註，並註明可能在不知情的情況下使用了如自動補全等輕量級工具，且貢獻者應評估規則適用的時機。最後，當傳輸的數據對專案敏感或非公開時，不得使用雲端 AI。

Hacker News 上的社群討論

評論者強調了幾個爭議點與需要澄清之處：

• @simonw 指出該頁面呈現的是三個獨立的提案 (A, B, C) 將進行辯論與投票，而非最終決定。
• @hkalbasi 糾正了「LLM 僅產生訓練數據的『語法上可能的組合』」之說法，指出強化學習使 LLM 能夠超越其訓練數據。
• @Meneth 觀察到 Gentoo 在兩年前就禁止了 LLM，且表現似乎良好。
• @rixed 疑惑即將發布的 Trixie 版本中，已有多少比例違反了提案 A 所建議的禁令。
• @zzo38computer 建議將提案 A 的元素（僅限於實際涉及 LLM 輸出或盲目信任的貢獻）與提案 C 針對其他情況結合，並質疑提案 C 中「協助」的定義。
• @russfink 詢問使用 Claude Code 尋找錯誤並建議修復，同時由人類編輯與測試原始碼，是否算作協助。
• @mike_hock 表示希望社群選擇提案 C。
• @dismalaf 質疑將 Gemini 作為無廣告的 Google 搜尋前端使用，是否會被視為被禁止的「使用」或「協助」。
• @mmooss 對於貢獻者如何驗證 LLM 輸出不包含既有版權材料提出疑慮，並指出實務上的困難與潛在責任。
• @nilespotter 將提案 D 描述為「使用 LLM 但別告訴任何人」。
• @sublinear 認為真正的問題在於缺乏解釋變更的正當討論，而非 LLM 本身，且適當的審核可以降低風險。
• @JuettnerDistrib 認為在開源軟體 (OSS) 促成了其發展後，開源專案卻考慮禁止 LLM，這很諷刺。
• @TZubiri 批評這些提案未能區分「使用 LLM 輸出」與「使用 LLM 進行對話或分析的協助」。
• @Kon5ole 預測隨著 LLM 的進步，嚴格的「無 LLM」政策將變得難以維持，儘管他承認關於能源消耗的倫理疑慮。
• @logicallee 總結了權衡點：LLM 可以快速生成與測試程式碼，但可能會忽略源自維護者經驗的潛規則。

結論

Debian 專案面臨著在嚴格禁止、附帶條件的寬鬆框架、強烈勸阻並要求披露，或是有準則的接受方式之間做出選擇。每項提案都反映了對版權風險、品質保證、社群影響和倫理考量的不同權重。正如 Hacker News 評論所示，目前的討論揭示了在執行面、「協助」的定義，以及鑑於上游廣泛使用 LLM 的情況下禁令的實踐性方面，存在著深刻的不確定性。