Git 專案擬就 LLM 貢獻政策動用投票：共識機制遇上的難題
Git 專案正考慮以投票方式，決定是否接受由大型語言模型（LLM）產生的 patch——這是開源基礎設施專案中，少數試圖以正式表決處理 AI 程式碼規範的例子。據 LWN.net 報導，通往共識的路徑「相當迂迴」（somewhat circuitous），而議題本身已於近期舉行的 Git Contributor's Summit 上討論過。
Git 並非孤例。2026 年以來，開發專案如何界定 LLM 撰寫貢獻的接收條件——若這類貢獻應被接受的話——已成為社群辯論的主要主題之一：某些專案選擇全面禁止，另一些則維持沉默。Git 專案同樣未能置身事外，只是它選擇了一條少有基礎設施級專案走過的路：把價值判斷交給選票，而非擱置或默許。
為何要以投票？這又代表什麼
對開源社群而言，這則新聞的價值不在於 Git 最終會選出什麼答案，而在於它「竟需要動用選票」這件事本身。共識決議通常難以處理這類議題：它沒有單一技術正確答案，涉及價值判斷與責任歸屬，且各方對風險的容忍度不同。當共識失靈時，專案訴諸正式表決，本身就是一種治理訊號——它意味著專案已承認，沉默或擱置不再是可行選項。
其中真正的治理難題，往往不是計票方式，而是「誰有資格投票」。投票主體的定義——maintainer，或是納入所有曾有程式碼合併紀錄的貢獻者——可能比計票規則更能左右結果；這類嘗試通常正是在這一步停滯。
對撰寫自身規則的團隊有何啟示
對工程團隊而言，可移植的收穫是流程，而非 Git 的最終判斷。Git 既有的 DCO（Developer Certificate of Origin）與 Signed-off-by 簽核機制，本身就是一份可稽核的責任鏈：每一則 patch 都帶有具名署名，聲明提交者對授權與原創性負責。若 LLM 披露要求沿著同一條鏈延伸——例如在簽核行之外，增設一行聲明 patch 由 LLM 協助生成、並已由具名者審閱——揭露義務便自然嵌入既有流程，而非另起一套與日常提交脫節的表格。
反過來說，未以文字固化的 AI 程式碼慣例，在規模擴大時必然失效——失敗模式通常不是規則太嚴或太鬆，而是根本沒有規則，只能逐案臨場判斷；當團隊成長，或面對稽核方、客戶、採購流程要求出示白紙黑字規範的情況時，這種做法便無以為繼。對香港的工程團隊而言，把 LLM 披露掛鉤到已有的簽核欄位，是成本最低的起點。
接下來
建議持續關注該 Git 郵件列表討論串；若投票成案並產生結果，這將可能成為來自基礎設施級專案的首批正式、專案全域 LLM 貢獻政策之一，值得跟進報導。
來源：LWN.net（https://lwn.net/Articles/1104195/）；相關討論串：https://lwn.net/ml/all/summit-2026.94e33e9ddf234334.06@ttaylorr.com
Git 專案擬就 LLM 貢獻政策動用投票：共識機制遇上的難題
Git 專案正考慮以投票方式，決定是否接受由大型語言模型（LLM）產生的 patch——這是開源基礎設施專案中，少數試圖以正式表決處理 AI 程式碼規範的例子。據 LWN.net 報導，通往共識的路徑「相當迂迴」（somewhat circuitous），而議題本身已於近期舉行的 Git Contributor's Summit 上討論過。
Git 並非孤例。2026 年以來，開發專案如何界定 LLM 撰寫貢獻的接收條件——若這類貢獻應被接受的話——已成為社群辯論的主要主題之一：某些專案選擇全面禁止，另一些則維持沉默。Git 專案同樣未能置身事外，只是它選擇了一條少有基礎設施級專案走過的路：把價值判斷交給選票，而非擱置或默許。
為何要以投票？這又代表什麼
對開源社群而言，這則新聞的價值不在於 Git 最終會選出什麼答案，而在於它「竟需要動用選票」這件事本身。共識決議通常難以處理這類議題：它沒有單一技術正確答案，涉及價值判斷與責任歸屬，且各方對風險的容忍度不同。當共識失靈時，專案訴諸正式表決，本身就是一種治理訊號——它意味著專案已承認，沉默或擱置不再是可行選項。
其中真正的治理難題，往往不是計票方式，而是「誰有資格投票」。投票主體的定義——maintainer，或是納入所有曾有程式碼合併紀錄的貢獻者——可能比計票規則更能左右結果；這類嘗試通常正是在這一步停滯。
對撰寫自身規則的團隊有何啟示
對工程團隊而言，可移植的收穫是流程，而非 Git 的最終判斷。Git 既有的 DCO（Developer Certificate of Origin）與 Signed-off-by 簽核機制，本身就是一份可稽核的責任鏈：每一則 patch 都帶有具名署名，聲明提交者對授權與原創性負責。若 LLM 披露要求沿著同一條鏈延伸——例如在簽核行之外，增設一行聲明 patch 由 LLM 協助生成、並已由具名者審閱——揭露義務便自然嵌入既有流程，而非另起一套與日常提交脫節的表格。
反過來說，未以文字固化的 AI 程式碼慣例，在規模擴大時必然失效——失敗模式通常不是規則太嚴或太鬆，而是根本沒有規則，只能逐案臨場判斷；當團隊成長，或面對稽核方、客戶、採購流程要求出示白紙黑字規範的情況時，這種做法便無以為繼。對香港的工程團隊而言，把 LLM 披露掛鉤到已有的簽核欄位，是成本最低的起點。
接下來
建議持續關注該 Git 郵件列表討論串；若投票成案並產生結果，這將可能成為來自基礎設施級專案的首批正式、專案全域 LLM 貢獻政策之一，值得跟進報導。
來源：LWN.net（https://lwn.net/Articles/1104195/）；相關討論串：https://lwn.net/ml/all/summit-2026.94e33e9ddf234334.06@ttaylorr.com