Zig 语言禁用 AI 生成代码的立场与理由

Zig 是所有主流开源项目中，对 LLM 限制最严格的项目之一：

禁止使用 LLM 创建 pull request。

禁止在 bug tracker 中使用 LLM 发表评论，包括使用 LLM 进行翻译。我们鼓励使用英语，但不强制要求。欢迎使用你的母语发帖，其他人可以自行选择翻译工具来理解你的文字。

使用 Zig 编写的最知名项目或许是 JavaScript runtime Bun。它于 2025 年 12 月被 Anthropic 收购，并且毫不意外地大量使用 AI 辅助。

Bun 维护着自己的 Zig fork。最近，它为 LLVM backend 添加了「并行语义分析和多个 codegen 单元」，让 Bun 的编译性能提升至原来的 4 倍。相关代码就在这里。但 @bunjavascript 表示：

我们目前不打算将其 upstream，因为 Zig 严格禁止由 LLM 编写的贡献。

（更新：一位 Zig core contributor 详细解释了为什么即使不考虑 LLM 问题，他们也不会接受这个特定 patch——并行语义分析是一项规划已久的功能，但它会「对 Zig 语言本身」产生影响。）

在《Contributor Poker and Zig's AI Ban》（经由 Lobste.rs）一文中，Zig Software Foundation 社区副总裁 Loris Cro 解释了实施这项严格禁令的理由。这是我迄今见过的，对全面禁止 LLM 辅助贡献最清晰有力的阐述：

成功的开源项目最终都会走到这样一个阶段：收到的 PR 数量超过了自身的处理能力。结合我前面提到的内容，为了让工作投入获得最大回报，停止接受不够完善的 PR 似乎是合理的选择，但 Zig 项目并没有这样做。相反，即使新贡献者需要一些帮助才能完成工作，我们也会尽最大努力帮助他们，让他们的贡献得以合入。我们这样做，不仅因为这是「正确」的事，也因为这是聪明的做法。

Zig 看重贡献者，胜过贡献本身。每位贡献者都代表着 Zig core team 的一笔投资——审核并接受 PR 的首要目标不是合入新代码，而是帮助新贡献者成长，让他们随着时间推移，成为值得信赖且高产的贡献者。

LLM 辅助彻底破坏了这套机制。即使 LLM 帮助你向 Zig 提交了一份完美的 PR，也无济于事——Zig 团队花在审核这份工作上的时间，并不能帮助项目增加新的、有信心且值得信赖的贡献者。

Loris 在这里解释了这个名称的由来：

我之所以称它为「贡献者扑克」，是因为这就像人们评价真正的扑克游戏时所说的那样：「你是在和人博弈，而不是和牌博弈。」在贡献者扑克中，你押注的是贡献者，而不是他们第一份 PR 的内容。

这对我来说非常有道理。它也呼应了我在其他地方看到的一种观点：如果一份 PR 大部分是由 LLM 编写的，项目维护者为什么要花时间审核和讨论这份 PR，而不是直接启动自己的 LLM 来解决同一个问题？

OpenAI 意外对 Hugging Face 发起的网络攻击，是已经成为现实的科幻故事——2026 年 7 月 22 日

与 Claude Code 团队的 Cat 和 Thariq 炉边对谈——2026 年 7 月 21 日

Kimi K3，以及我们仍能从 pelican benchmark 中学到什么——2026 年 7 月 16 日

这是 Simon Willison 于 2026 年 4 月 30 日发布的一则笔记。

每月赞助我 10 美元，即可收到一份精心整理的邮件摘要，汇集当月最重要的 LLM 进展。

付钱让我少给你发点内容！