10 月 29 日前後，The Register 報導了一項針對 LibreOffice 今年提交程式碼的分析，發現至少有三處明確提及使用了 LLM。開發者社羣裡，Claude、GitHub Copilot 這些工具名就這樣寫在註解裡。
這件事的微妙之處在於前後落差。開發 LibreOffice 的 The Document Foundation（TDF）先前表態過，這款辦公軟體不會內建 AI 功能，核心開發者也不使用 LLM 輔助程式設計。但「核心開發者不用」和「所有貢獻者都不用」是兩回事。大型開源專案的程式碼來源是全世界各地志願者，組織能約束的是自己人，管不到每一份從外部寄來的修補。
有點像一家餐廳宣布廚房不用味精，主廚也確實不用。但週末來幫忙的打工族自備了一小罐，而且很誠實地在菜單上註明了。客人看到註記會覺得被欺騙嗎？還是覺得至少坦白？
重點在「標記」，不是「使用」
細看這次的分析結果，被找到的三處都是開發者主動揭露的。TDF 對外的回應也說清楚了規則：要求貢獻者在使用 LLM 時必須披露，整體上不鼓勵使用。換句話說，被發現的不是偷用，而是照規定申報後留下來的紀錄。
真正值得看的，是 TDF 和 Debian 採取的同一套邏輯：不禁止，但要求開發者理解自己提交的每一行程式碼，確保品質。這個立場把責任放在「人」身上，而不是工具上。你用機器幫你寫可以，但出了問題，簽名的是你。
這套思維對任何團隊都適用。企業內部對 AI 工具的規範，最難落實的往往不是禁止條款，而是「用了要說」的申報文化。LibreOffice 的案例顯示，即使組織高層明確表態不用，基層的實際行為仍會走在政策前面，差別只在於有沒有誠實標註。
開源專案躲不開 LLM，那規則該長什麼樣
Solidot 在整理這則消息時的判斷很直接：大型開源專案基本上不可能完全避開 LLM。這也是為什麼「揭露義務」比「全面禁止」更務實。禁止條款在志願者為主的社羣裡缺乏執行手段，你無法審查每個貢獻者的寫作過程，只能審查結果。
這與我們先前觀察到的Linux 核心大量新手貢獻者湧入現象屬於同一個大方向：開源專案的貢獻者結構正在變寬、變雜，治理手段也得跟著從「信任熟人」轉向「信任流程」。程式碼審查、揭露要求、對提交內容的理解責任，這些機制的價值會越來越高。
對一般使用者的意義其實很有限。LibreOffice 本體並沒有因此內建 AI 功能，也不代表辦公軟體突然會把你的文件送去哪裡。這則消息真正影響的是軟體供應鏈裡的信任結構：當程式碼的作者身分越來越模糊，「誰為這行字負責」就成為每個專案都必須回答的問題。
TDF 的下一步值得觀察的是，揭露的標記會不會發展成提交規範裡的正式欄位，以及審查流程會不會因為 LLM 標註而加深力道。答案還沒出來，但問題已經寫進程式碼裡了。