Zig 專案為何全面禁止 AI 貢獻？「貢獻者撲克」理論讓整個開源社群沉默了

如果你是一個開源專案的維護者，最近應該已經感受過這種感覺——半夜醒來看到 GitHub 信箱躺著三條新的 pull request，點開一看，程式碼結構完全沒問題，格式工整，註解齊全，但總覺得哪裡不對勁。不是邏輯錯誤，而是一種說不上來的「太完美了」的違和感。

你追問作者幾個設計選擇的細節，對方開始含糊其詞。再深問下去，他承認了：「對不起，這是我用 Claude 寫的。」

這個場景正在全世界成千上萬的開源專案維護者身上不斷重演。而 Zig 程式語言專案，決定用最直接的方式來回應這個問題——全面禁止 AI 貢獻，從 issue、PR 到 bug tracker 留言，一律不許使用 LLM。

這不只是紙上談兵。Bun，這個用 Zig 寫成的最著名的 JavaScript 執行環境（2025 年底被 Anthropic 收購），因為自己的 Zig fork 在編譯效能上做出了 4 倍提升，卻沒辦法 upstream 回官方——不是因為技術問題，而是因為他們的開發流程大量使用 AI 輔助，不符合 Zig 專案的貢獻政策。

「我們目前不打算將這些改進 upstream 回去，因為 Zig 對 LLM 撰寫的貢獻有嚴格禁令。」Bun 團隊在 X 上如此表示。

這就引出一個棘手的問題：當 AI 能幫你寫出更好的程式碼時，一個開源專案為什麼要說不？

Zig Software Foundation 社群副總裁 Loris Cro 在他的文章〈Contributor Poker and Zig’s AI Ban〉中給出了精采的解釋。他把這個策略稱為「貢獻者撲克」，而這套思維模式，可能是今天所有開源維護者都該理解的功課。

Zig 的 AI 禁令，到底禁了什麼？

先來看看這道禁令的具體內容。Zig 的社群規範中，條文非常簡潔且直接：

不用 LLM 開 issue。

不用 LLM 提交 pull request。

不在 bug tracker 上用 LLM 寫留言，包括翻譯。

Zig 官方鼓勵開發者用自己的語言發言，然後讓其他人用翻譯工具來理解——但你不能讓 LLM 幫你寫那些話。

這份規範涵蓋的是 Zig 官方控制的空間：Codeberg 上的 ziglang 組織、Libera.chat 上的 #zig IRC 頻道、以及 Zig 的 Zulip 開發聊天室。非官方的社群空間不受此限制。

值得注意的是，Zig 專案並不是第一個針對 AI 貢獻設限的開源專案。Gentoo Linux 在 2025 年初也發布了類似的政策，要求所有貢獻必須由人類撰寫；GNOME 的某些子專案也針對 AI 產生的程式碼進行了討論；FreeBSD 的社群內部持續在討論如何處理越來越多由 AI 輔助產生的 patch。但 Zig 的版本可能是目前最全面的——它不是只說「請標註 AI 輔助」，而是直接說「不要用」。

而且這背後有一套完整而且相當令人信服的邏輯。

開源維護者真正的困境

要理解 Zig 為什麼這麼做，首先得了解開源貢獻的真實面貌。

Loris Cro 在文章中用了一個犀利的觀察開場：「開源與許多商業模式不相容，它的基礎是你必須免費提供有價值的東西。當然，作為交換，你也會免費獲得一些回報，主要是程式碼貢獻的形式。」

問題在於，這些免費的貢獻，很多時候反而是維護者的額外負擔。

Loris 坦率地說：「一個維護者自己動手實現某個改動，往往比指導一個 PR 作者把程式碼改到可以合併的狀態要省力得多。」

這背後的現實是：一個第一次提交 PR 的貢獻者，通常對專案的編碼風格、測試規範、程式碼架構都不夠熟悉。一份看起來正確的程式碼，可能違反了專案的內部結構規則，可能遺漏了邊界條件處理，可能與未來的開發方向衝突。維護者需要花時間逐一點出這些問題，然後等待對方修正——有時候修正又帶來新的問題，如此往復數次，最終才達到可合併的狀態。

而同樣的改動，如果由維護者自己來寫，因為他對專案的一切都了然於心，可能只需要一半甚至更少的時間。

對於一個小專案來說，這個問題還不明顯——因為 PR 數量很少，每一個都可以慢慢處理。但當一個專案成長到一定程度時，情況就完全不一樣了。

「在成功的開源專案中，你最終會到達一個點——收到的 PR 數量超過了你能夠處理的能力。」

Zig 專案目前的狀況正是如此。他們在 2025 年的年度財務報告中坦言，已經有一些好的 PR 長時間未被審查，可能導致有價值的貢獻者失去興趣。這不僅僅是效率問題，更是一個生態系統的健康問題——當審查堆積如山，優秀的貢獻者就會轉向其他更活躍的專案。

在這種資源緊張的情況下，正常人的直覺是什麼？會挑選成果最成熟的 PR，跳過那些需要大量投入的，對吧？

但 Zig 團隊選擇了相反的路。

貢獻者撲克：你在賭的是人，不是程式碼

這就是 Loris 提出的核心概念——貢獻者撲克（contributor poker）。

「就像人們對撲克牌的描述一樣：『你打的是人，不是牌。』在貢獻者撲克中，你賭的是貢獻者本身，而不是他們第一個 PR 的內容。」

這句話非常關鍵。Zig 團隊認為，他們投資在每一個新貢獻者身上的時間和精力，是一個反覆博弈的過程。第一次的 PR 可能很差——充滿 bug、沒有遵循規範、需要大量修改——但如果這個貢獻者願意學習、願意改進，那麼隨著時間推移，這個人會變得越來越有價值。

Zig 能從零開始打造一個完整的編譯工具鏈，正是因為這個策略奏效了。

Loris 提到了兩個具體的例子。Ryan Liptak 貢獻了 Windows 執行檔圖標的支援——這件事看起來簡單，但實際上涉及到 Zig 需要能夠編譯 Windows resource script（.rc）檔案，背後牽涉到整個資源檔格式的支援。因為他的貢獻，Zig 使用者現在可以在 Windows 上設定執行檔圖標，這個功能對跨平台開發者來說極其實用。

另一個例子是 Frank Denis 在 Zig 標準加密函式庫中做的大量工作。Loris 說他「甚至不知道該如何用金錢來衡量這份貢獻的價值」。加密函式庫是編譯器工具鏈中最敏感的元件之一——一個小 bug 就可能導致安全漏洞。正因為 Zig 團隊長期投資在 Frank Denis 這樣的貢獻者身上，建立了信任關係，才能夠放心地讓他在這個領域中發揮。

這些人的第一個 PR 可能都不完美，但 Zig 團隊賭對了他們。

而現在，AI 貢獻打破了這個博弈的基礎。

AI 貢獻為什麼無法打撲克？

Loris 直言不諱地說：「AI 讓事情變得更糟了。」

Zig 專案在實施 AI 禁令之前，已經累積了大量的負面經驗。他描述了幾種典型的狀況：

第一種是「廢棄驅動式 PR」——一堆充滿幻覺、連編譯都過不了的程式碼。這些 PR 的作者可能連專案的建置流程都沒跑過，就讓 AI 吐出上百行程式碼然後直接提交。對於維護者來說，這只是浪費時間的雜訊。

第二種更驚人——有些第一次提交的 PR 長達一萬行。一萬行。任何人都可以想像這對審查者造成的負擔。要從一萬行程式碼中找出真正的問題，往往需要數小時甚至數天的時間，而到頭來發現這些程式碼大部分都是 AI 憑空生成的幻覺。

第三種最棘手——那些表面上看起來沒問題的 PR。Loris 指出，他們收到過不少明確聲稱沒有使用 LLM 的 PR，但在進一步的討論中，作者對自己提交的程式碼完全無法解釋。「為什麼這裡用這個演算法？」「我不知道，但 CI 過了。」「這個邊界條件的處理邏輯是什麼？」「嗯⋯⋯讓我想想。」

Loris 說：「要提供有影響力的工作，貢獻者需要熟悉程式碼庫和問題領域，需要讓核心團隊信任他們已經思考過 PR 引入的所有變更，並努力尋求最佳方案——而不只是提交一個恰好通過 CI 的隨機解法。」

更重要的是，貢獻者合併程式碼之後，還會有一段時間要對自己的程式碼負責。沒有人是完美的，有時候問題會在事後才被發現。後續的修正討論，正是擁有迭代關係的工程師之間最有價值的互動之一——因為這些討論不僅解決了當前的問題，還讓整個團隊對程式碼的理解更深入。

但 LLM 無法參與這個過程。LLM 提交了一個 PR，合併了，然後呢？沒有人會對它負責，沒有人能參與後續的討論，沒有人能從錯誤中學習——因為根本就沒有人。

Loris 一語道破：「從貢獻者撲克的角度來看，當我們有一大堆不具備這種風險因素的貢獻者在排隊時，賭在 LLM 使用者身上就是不理性的。」

Zig 不是不知道有些負責任的開發者也能有效使用 LLM。問題是比例——絕大多數 LLM 貢獻呈現的就是濫用的樣子。在資源有限的情況下，你只能設定邊界來保護自己的生態系統。

Simom Willison 在他對這件事的評論中補充了一個更犀利的觀點：「如果一個 PR 主要是由 LLM 寫的，那麼為什麼專案維護者要花時間去審查和討論這個 PR，而不是自己打開 LLM 來解決同樣的問題？」

這是一個讓人無法迴避的問題。如果每個人都可以用 AI 產生程式碼，那維護者為什麼要審查你的 AI 程式碼，而不是直接用 AI 產生自己的版本？

換句話說，AI 讓程式碼的邊際成本趨近於零，但審查成本沒有變。當生產過剩而審查稀缺時，維護者自然會去審查那些「有附加價值」的貢獻——也就是他們信得過的人。

這不是保守，這是理性。

Bun 效應：AI 友善與開源 upstream 的矛盾

這個案例特別值得細看。Bun 是市面上最重要的 Zig 專案之一，它不僅用 Zig 寫成，而且還維護著自己的 Zig fork。

最近 Bun 團隊宣布了一個令人驚豔的成果：他們在 Bun compile 的效能上做出了 4 倍的提升，方法是加入了「並行語義分析和多個程式碼生成單元到 LLVM 後端」。

這是一個貨真價實的技術突破，不是那種 LLM 胡亂產生的幻覺程式碼。

但 Bun 團隊明確表示：不打算把這個改動 upstream。原因不是 Zig 團隊不歡迎，而是他們的使用 AI 輔助開發流程不符合 Zig 的貢獻政策。

值得注意的是，這裡有細微的區別。Zig 核心貢獻者後來在討論串中指出，即使不考慮 AI 問題，並行語義分析這個功能本身就是 Zig 長期規劃中的核心特性，需要更全面的語言層級考量。所以 Bun 的那個 patch 未必會被接受——但問題的核心仍然是：AI 使用者的貢獻，在 Zig 的框架下就是不被視為可信投資。

這背後有一個更深層的結構性矛盾：當一個專案的開發流程完全擁抱 AI 輔助時，它的產出在「純人類」的開源專案眼中就變成了一個黑盒子。

Bun 的 Zig fork 能夠做出 4 倍效能提升，無疑證明了 AI 輔助開發的生產力優勢。但對 Zig 核心團隊來說，他們不知道哪些程式碼是人類寫的、哪些是 AI 產生再經人類修改的、哪些是完全由 AI 生出的。在無法有效區分的情況下，他們的選擇只有全部接受或全部拒絕。

而他們選擇了全部拒絕。

這不是針對 Bun 或任何特定的開發者。就像 Loris 說的，從貢獻者撲克的角度來看，這只是一個理性的風險管理決策。

AI 貢獻：程式碼過剩時代的經濟學

把視角拉遠來看，Zig 的做法其實指向了開源世界正在面對的一個更深層次的問題。

過去二十年，開源世界的運作基礎是「程式碼稀缺」。因為寫程式碼很難、很花時間，所以貢獻者提交的每一行程式碼都是稀缺且珍貴的。維護者的工作就是幫助他們把這些珍貴的貢獻打磨到可合併的狀態。

但 AI 改變了這個根本假設。

2025 年以來，GitHub 上的 PR 數量已經出現了驚人的增長，不少大型專案回報說 AI 相關的 PR 佔比已經超過了三成。這不是因為突然湧入了一批超級勤奮的開發者，而是因為每個人都可以用 AI 在幾分鐘內產生一個看起來合理的 PR。

當程式碼從稀缺變為過剩，決定價值的就不再是產出，而是審查。

而審查是無法被 AI 取代的——至少現在還不行。審查需要對專案的深入理解，需要對程式碼長期影響的判斷，需要對作者的信任。

這就形成了一個新的經濟模型：程式碼無限供給，但審查資源有限。當供給大於需求時，市場就會自動產生過濾機制。維護者的時間和注意力就是最稀缺的資源，他們會把這些資源分配給他們最信任的人。

從這個角度來看，Zig 的 AI 禁令不是一個道德判斷，而是一個理性選擇。他們選擇把稀缺的審查資源投資在「有可能成為長期貢獻者」的人身上，而不是投資在「可能用 AI 產生大量無效程式碼」的人身上。

其他開源專案的應對之道

當然，不是所有專案都選擇了和 Zig 一樣的路徑。整個開源生態系統對 AI 貢獻的態度大致可以分為幾個陣營。

最寬容的是 Apache Software Foundation。ASF 的政策是要求貢獻者必須標註 AI 輔助的使用情況，但並不禁止。他們認為 AI 只是一個工具，重點是貢獻者要對自己的程式碼負責。如果一個貢獻者願意為 AI 產生的程式碼背書，並且能夠在審查過程中解釋這些程式碼的設計決策，那麼 ASF 願意接受。

中間路線是要求標註但不明確禁止。這種做法的好處是保留了 AI 生產力的優勢，壞處是執行難度很大——如何驗證一個貢獻者是否如實標註了 AI 使用情況？如果一個開發者在本地使用 Copilot 或 Claude 輔助寫了幾行程式碼，他需要在 PR 中逐行標註嗎？這條界線非常模糊。

最嚴格的路線就是 Zig 的做法——全面禁止。這種做法的好處是簡單明確，不會有模糊地帶。壞處是可能錯失一些有價值的貢獻——就像 Bun 的那個 4 倍效能提升。

值得注意的是，即使在 Zig 內部，這個政策也不是沒有爭議。Loris 在文章中坦承：「我們知道還有許多未解決的問題，並計劃隨著獲得更多 insight 來調整我們的政策。」

換句話說，這不是一個永久的答案，而是一個階段的選擇。

對開發社群的啟示

Zig 的案例對開源貢獻者來說，至少有三個值得深思的啟示。

首先，程式碼的品質不只是語法正確。你可能用 AI 產生了一個功能完全正確、格式無可挑剔的 PR，但如果這是你第一次接觸這個專案，維護者仍然需要花大量的時間來審查你。而且，因為你對自己的程式碼沒有深入的了解，維護者無法從審查過程中獲得「這個人值得信任」的訊號。這不代表你的 PR 一定會被拒絕，但代表你從一開始就處於劣勢。

其次，貢獻文化是雙向的。開發者在挑選要貢獻的專案時，也在選擇一種貢獻文化。如果你習慣了用 AI 輔助開發，那麼像 Zig 這樣有嚴格政策的專案可能不適合你——不是因為你不好，而是因為雙方的模式不匹配。同樣的，如果你選擇了一個寬容 AI 的專案，也要做好你的程式碼會和大量 AI 產生的程式碼競爭審查資源的心理準備。

最後，建立信任比產生程式碼更重要。這可能是最難被接受的一點——在 AI 時代，成為一個「可信的貢獻者」比「產出大量的貢獻」更有價值。這聽起來違反直覺，但在審查資源稀缺的世界裡，這正在變成現實。

Zig 的做法雖然極端，但背後其實指向了一個更根本的問題：我們到底想要什麼樣的開源社群？

是所有人都可以用 AI 大量生產程式碼、但維護者被淹沒在審查中的世界？還是每個人對自己的程式碼負責、人與人之間建立信任關係的世界？

Zig 選擇了後者。你可以不同意他們的做法，但你很難說他們的選擇沒有道理。

這讓我想起一個有趣的類比。軟體開發曾經歷過「框架狂熱」的年代——每個人都急著用最新的框架來證明自己與時俱進，結果建出了大量難以維護、過度設計的系統。後來大家才慢慢明白，選擇什麼框架遠不如團隊對這個框架的理解深度來得重要。

AI 開發工具正在經歷類似的階段。大家都在擁抱 AI 輔助開發，好像誰不用誰就落伍了。但真正的問題不是「你用不用 AI」，而是「你用 AI 產出的程式碼，你自己到底懂不懂」。

Zig 的禁令或許太過極端，它可能會錯失一些真正有價值的 AI 輔助貢獻。但也許這就是這個階段需要的——一個明確的邊界，提醒我們不要把效率當成唯一的價值標準。畢竟，開源的本質從來都不是程式碼本身，而是圍繞著程式碼建立起來的人與人之間的關係。沒有了這些關係，再多的程式碼也只不過是 GitHub 上的一串位元組而已。

當程式碼變成了最不值錢的東西，那些無法被自動化的東西——判斷力、責任感、信任——反而變得最珍貴。也許在 AI 時代，真正稀缺的不是寫程式碼的能力，而是願意為自己的程式碼負責的態度。