Zig项目严格禁止AI辅助贡献引发讨论
Simon Willison··作者 Simon Willison
关键信息
Zig核心团队更重视培养贡献者而非接收完美代码；他们认为即使代码技术上无误，由AI生成的PR也无法帮助建立信任或长期的贡献者关系。
资讯摘要
Zig拥有开源领域最严格的反LLM政策之一，禁止在所有贡献中使用AI辅助，包括拉取请求、错误报告和评论。这与被Anthropic收购的Zig衍生项目Bun形成鲜明对比，后者高度依赖AI，并通过并行语义分析将编译时间提升了4倍。尽管取得技术突破，Bun仍不会将这些更改合并回主干，因为Zig有此政策。
Zig社区负责人Loris Cro解释称，其背后的理念是“贡献者扑克”——维护者投资的是人而非代码本身。他们认为，审查由AI撰写的PR并不能帮助培养新贡献者，而这才是开源维护的核心目标。
资讯正文
Zig项目对其严格的反AI贡献政策的解释
<a href="https://ziglang.org/">Zig</a> 是众多主要开源项目中对大型语言模型（LLM）使用限制最严格的项目之一，其政策明确如下：
<blockquote>
<p>问题中不得使用LLM。</p>
<p>拉取请求（Pull Requests）中不得使用LLM。</p>
<p>在缺陷跟踪器上的评论中不得使用LLM，包括翻译。鼓励使用英语，但并非强制要求。你可以用母语发布内容，并依靠他人使用自己的翻译工具来理解你的表述。</p>
</blockquote>
目前最著名的Zig语言项目可能是 <a href="https://bun.com/">Bun</a> JavaScript运行时，它于2025年12月被Anthropic收购，并且毫不意外地大量依赖AI辅助开发。
Bun维护着自己的一套Zig分支，并最近实现了编译速度提升4倍的改进，方法是在LLVM后端中加入了“并行语义分析和多个代码生成单元”。相关代码见 <a href="https://github.com/oven-sh/zig/compare/upgrade-0.15.2%E2%80%A6upgrade-0.15.2-fast">此处</a>。但 <a href="https://twitter.com/bunjavascript/status/2048428104893542781">@bunjavascript表示</a>：
<blockquote>
<p>我们目前不打算将这项改动合并回主干，因为Zig对LLM撰写的贡献有严格禁止规定。</p>
</blockquote>
（更新：这里有一位 <a href="https://ziggit.dev/t/bun-s-zig-fork-got-4x-faster-compilation-times/15183/19">Zig核心贡献者</a> 提供了更详细的说明，指出即便不考虑LLM因素，该补丁也不适合被接受——并行语义分析是一个长期规划的功能，但它会对Zig语言本身产生影响。）
在 <a href="https://kristoff.it/blog/contributor-poker-and-ai/">《贡献者扑克与Zig的AI禁令》</a>（via Lobste.rs）一文中，Zig软件基金会社区副总裁Loris Cro详细阐述了这一严格禁令的理由。这是我迄今为止看到的关于全面禁止LLM辅助贡献的最佳解释：
<blockquote>
<p>在成功的开源项目中，你最终会达到一个阶段：收到的拉取请求数量超过了团队处理能力。鉴于我前面提到的情况，似乎合理的做法是停止接收不完美的PR，以最大化你工作的回报率。但我们并不这么做。相反，<strong>我们尽最大努力帮助新贡献者完成他们的工作，哪怕他们需要一些协助才能达成目标</strong>。我们这么做不仅是因为这是“正确”的选择，更是因为这是“明智”的选择。</p>
</blockquote>
Zig重视贡献者胜过他们的具体贡献。每个贡献者都代表着Zig核心团队的一项投资——审查和接受PR的主要目的不是引入新代码，而是帮助培养新的贡献者，让他们未来能够成为值得信赖且高产的开发者。
LLM辅助完全失效。无论LLM是否帮你提交了一个<em>完美</em>的Zig项目拉取请求（PR），Zig团队花在审核你工作上的时间，对帮助他们吸引新的、自信且值得信赖的贡献者加入整个项目毫无助益。
Loris在这里解释了这个名称的由来：
<blockquote>
<p>我称之为“贡献者扑克”的原因在于，就像人们说牌局时那样，“你玩的是人，不是牌”。在贡献者扑克中，你下注的是贡献者本人，而不是他们第一次PR的内容。</p>
</blockquote>
这对我来说非常有道理。它让我联想到我在别处见过的一个观点：如果一个PR主要是由LLM编写的，那么为什么项目维护者要花时间去审阅和讨论这个PR，而不是直接用自己调用的LLM来解决同样的问题呢？
来源与参考
收录于 2026-05-01