Zig 專案對大型語言模型（LLM）輔助的貢獻設有最嚴格的政策之一：禁止在問題回報中使用 LLM。禁止在拉取請求中使用 LLM。禁止在錯誤追蹤器的評論中使用 LLM，包括翻譯。鼓勵使用英文，但非強制。歡迎使用您的母語發文，並讓其他人自行選擇翻譯工具來理解您的內容。 以 Zig 編寫的最知名專案可能是 JavaScript 執行環境 Bun，它於 2025 年 12 月被 Anthropic 收購，並且毫不意外地大量使用 AI 輔助。Bun 運行著自己的 Zig 分支，最近透過在 LLVM 後端加入「平行語義分析和多個程式碼生成單元」，使 Bun 的編譯速度提升了四倍。這是相關程式碼。但 @bunjavascript 表示：「我們目前不打算將此上游（upstream），因為 Zig 嚴格禁止 LLM 撰寫的貢獻。」（更新：一位 Zig 核心貢獻者提供了詳細說明，解釋了他們為何不接受該特定修補程式，這與 LLM 問題無關——平行語義分析是一個長期規劃的功能，但對「Zig 語言本身」有影響。） 在《貢獻者撲克與 Zig 的 AI 禁令》一文中，Zig 軟體基金會社區副總裁 Loris Cro 解釋了這項嚴格禁令的理由。這是我見過對全面禁止 LLM 輔助貢獻最清晰的闡述：在成功的開源專案中，最終你會達到一個拉取請求（PR）數量超出處理能力的地步。鑑於我目前所說的，為了最大化工作投資報酬率，停止接受不完美的 PR 似乎是合理的，但這不是我們在 Zig 專案中所做的。相反地，我們盡力幫助新的貢獻者完成他們的工作，即使他們需要一些協助。我們這樣做不僅因為這是「正確」的事情，也因為這是「明智」的事情。 Zig 重視貢獻者本身勝過他們的貢獻。每個貢獻者都代表著 Zig 核心團隊的一項投資——審查和接受 PR 的主要目標不是為了引入新程式碼，而是為了幫助培養新的貢獻者，讓他們隨著時間的推移成為值得信賴且多產的成員。 LLM 輔助完全破壞了這一點。即使 LLM 幫助你提交了一個完美的 Zig PR，Zig 團隊花時間審查你的工作，也無助於他們為整個專案增加新的、自信的、值得信賴的貢獻者。 Loris 在此解釋了這個名稱：「我稱之為『貢獻者撲克』的原因是，就像人們談論實際的撲克牌遊戲一樣，『你玩的是人，而不是牌』。在貢獻者撲克中，你押注的是貢獻者，而不是他們第一個 PR 的內容。」 這對我來說很有道理。它與我在其他地方看到的一個觀點相關：如果一個 PR 大部分是由 LLM 撰寫的，那麼專案維護者為何要花時間審查和討論該 PR，而不是啟動他們自己的 LLM 來解決相同的問題呢？