Zig 项目坚持反 AI 贡献政策的理由

Zig 在主要 open source project 中拥有最严格的反 LLM 政策之一：issues 不得使用 LLM。pull requests 不得使用 LLM。bug tracker 上的评论不得使用 LLM，包括翻译。鼓励使用英语，但不强制。你可以用自己的母语发帖，并依赖他人使用自己选择的翻译工具来理解你的文字。用 Zig 编写的最知名项目可能是 Bun JavaScript runtime；它在 2025 年 12 月被 Anthropic 收购，并且不出所料地大量使用 AI assistance。Bun 维护着自己的 Zig fork，最近在为 llvm backend 添加“parallel semantic analysis and multiple codegen units”后，使 Bun compile 获得了 4x 的性能提升。代码在这里。但 @bunjavascript 表示：我们目前不计划将其 upstream，因为 Zig 严格禁止 LLM-authored contributions。（更新：这里有一位 Zig core contributor 详细说明了为什么即使不考虑 LLM 问题，他们也不会接受那个特定 patch——parallel semantic analysis 是一个长期规划的 feature，但会对“Zig language itself”产生影响。）在 Contributor Poker and Zig's AI Ban（via Lobste.rs）中，Zig Software Foundation 社区副总裁 Loris Cro 解释了这项严格禁令的理由。这是我见过的、对全面禁止 LLM-assisted contributions 最好的阐述：在成功的 open source projects 中，你最终会到达一个阶段：收到的 PR 数量开始超过你能够处理的范围。考虑到我前面提到的内容，为了最大化你工作的 ROI，停止接受不完善的 PR 似乎是合理的，但 Zig project 并不是这样做的。相反，我们会尽力帮助新 contributors 把他们的工作合入，即使他们需要一些帮助才能做到。我们这样做不仅因为这是“正确”的事，也因为这是聪明的做法。Zig 重视 contributors 胜过他们的 contributions。每位 contributor 都代表 Zig core team 的一项投入——review 和接受 PR 的主要目标并不是合入新代码，而是帮助培养新的 contributors，使他们随着时间推移变得可信、稳定且高产。LLM assistance 会彻底打破这一点。即使 LLM 帮你向 Zig 提交了一个完美的 PR，也无关紧要——Zig team 花时间 review 你的工作，并不能帮助他们为整个项目增加新的、自信的、值得信任的 contributors。Loris 在这里解释了这个名称：我之所以称之为“contributor poker”，是因为就像人们谈论真正的纸牌游戏时所说的那样，“你打的是人，不是牌”。在 contributor poker 中，你押注的是 contributor，而不是他们第一个 PR 的内容。这对我来说很有道理。它也关联到我在其他地方看到的一个想法：如果一个 PR 大部分是由 LLM 写的，为什么 project maintainer 应该花时间 review 和讨论这个 PR，而不是启动自己的 LLM 来解决同一个问题？Tags: anthropic, zig, ai, llms, ai-ethics, open-source, javascript, ai-assisted-programming, generative-ai, bun