Zig 项目为何坚持反 AI 贡献政策The Zig project's rationale for their firm anti-AI contribution policy

Zig 是所有主流开源项目中反 LLM 政策最严格的项目之一：

不允许使用 LLM 处理 issue。 不允许使用 LLM 处理 pull requests。 不允许在 bug tracker 的评论中使用 LLM，包括翻译也不行。虽然鼓励使用英语，但并非强制要求。你可以用母语发帖，并请他人自行选择翻译工具来理解你的内容。

用 Zig 编写的著名项目可能是 Bun JavaScript 运行时，它于 2025 年 12 月被 Anthropic 收购，毫不意外的是，该项目大量依赖 AI 辅助开发。

Bun 运行着自己维护的 Zig 分支，最近通过在 LLVM 后端添加“并行语义分析和多个代码生成单元”，实现了 Bun 编译性能提升 4 倍。相关代码如下。但 @bunjavascript 表示：

我们目前不打算将这部分改动合并回上游，因为 Zig 对由 LLM 生成的贡献有严格禁令。

（更新：一位 Zig 核心贡献者解释了为何即使不考虑 LLM 问题也不会接受该补丁——并行语义分析本就是长期规划的功能，但其实现会“影响 Zig 语言本身”。）

在《Contributor Poker 与 Zig 的 AI 禁令》（via Lobste.rs）一文中，Zig 软件基金会社区副总裁 Loris Cro 阐述了这一严格禁令背后的理由。这是我所见过对全面禁止 LLM 辅助贡献最清晰的论述：

在成功的开源项目中，最终都会面临提交的 PR 数量远超处理能力的情况。考虑到上述情况，似乎应该停止接受不完美的 PR，以最大化投入产出比，但 Zig 项目并不这么做。相反，我们会尽最大努力帮助新贡献者完成他们的提交，哪怕他们需要一些指导才能达成目标。我们这样做不仅是因为这是“正确”的事，更是因为这是“聪明”的做法。

Zig 重视贡献者本人，而非其提交的内容。每位贡献者都是 Zig 核心团队的投资对象——评审和接纳 PR 的主要目的不是引入新代码，而是帮助培养新的贡献者，使其逐步成长为值得信赖且高产的开发者。

LLM 辅助彻底破坏了这一点。即便 LLM 帮你提交了完美的 PR，Zig 团队花费时间审核你的工作也无法帮助他们吸纳更多自信、可靠的新贡献者加入项目。

Loris 在此解释了命名缘由：

我之所以称之为“contributor poker”，正如人们常说的真实扑克游戏那样，“你是在和人打交道，而不是和牌打交道”。在 contributor poker 中，你押注的是贡献者本人，而非其首个 PR 的内容。

这对我而言非常有道理。这让我联想到一个在其他地方看到过的观点：如果一个 PR 主要由 LLM 编写，为什么项目维护者要花费时间亲自审核和讨论，而不是直接启动自己的 LLM 来解决同样的问题？