Zig 禁止 AI 代码贡献，引发开源社区对效率、质量与责任边界的讨论。
原文标题：开源编程语言Zig，向AI代码说「不」
原文作者：机器之心
冷月清谈：
怜星夜思：
2、如果贡献者使用 AI 辅助理解代码，但最终自己手写提交，这算不算应该被禁止？
3、AI 编程工具普及后，开源社区会不会从“欢迎所有贡献”转向“筛选可信贡献者”？
4、底层系统项目和普通应用项目，对 AI 代码的容忍度是不是应该不一样？
原文内容
在 AI 时代，拥抱 AI 显然是大势所趋，连大名鼎鼎的 Linux 之父 Linus Torvalds 已经从年初开始在个人项目中使用 AI 编程。
但总有一些坚守者，他们的态度很明确：不接受 AI 代码。开源现代编程语言 Zig 是其中的代表之一。
Zig 由一家非营利组织以及一批贡献者共同维护。任何程序员都可以向它的代码仓库提交代码，只要遵守项目的行为准则。
规则之一就是：禁止提交 AI 辅助生成的代码。政策写得很清楚：不接受任何由大语言模型生成的内容，也不接受由大语言模型改写、润色、编辑、头脑风暴或调试过的内容。简单来说，就是让 AI 离 Zig 的代码贡献远一点。
完整内容见链接：https://ziglang.org/code-of-conduct/
在近日 JetBrains 的播客节目中，Zig 创建者兼首席开发者 Andrew Kelley 将 AI 辅助贡献称为「垃圾」。
Kelley 表示：「有人给我们提交完全没有价值的贡献。它们甚至是负价值，因为会占用团队有限的代码审查时间。」
Zig 的代码贡献主要由少数核心团队成员负责审查。这正是 Kelley 所强调的项目「瓶颈」：提交的 pull request 数量超过了审查者的处理能力。在访谈中，Kelley 提到 Zig 当时还有 200 个未处理的 pull request。
他进一步表示，当我们收到 AI 生成的「垃圾贡献」，并在审核几次之后发现，他们根本不知道自己在做什么。「有些贡献者只是把我们说的话复制粘贴回对话框，并试图通过清洗聊天记录来假装自己没有使用 AI 聊天功能，但我们依然能够看出来，并意识到永远不会有高质量的贡献。」
因此，这些「垃圾贡献」只会进一步拖慢整个团队的节奏。「我们浪费了所有人的时间，其他耐心等待的人提交的代码没有得到审核和合并。」
虽然 Zig 体量相对较小，但它的影响力并不小。比如，Bun 就是用 Zig 开发的，而 Bun 后来被 Anthropic 收购。与 Zig 不同，Bun 是拥抱 AI 的，几天前，Bun 创建者 Jarred Sumner 发推表示自己使用 Claude Code 的新功能动态工作流将 Bun 从 Zig 移植到了 Rust。
在 Claude Code、OpenAI Codex 等工具推动下，AI 辅助写代码已经席卷硅谷。有些人用 AI 修改代码，有些人则直接让 AI 起草整段代码。大型科技公司也纷纷提出高目标，强调未来有多少比例的代码应该由 AI 编写，甚至声称如今已有相当比例的代码来自 AI。
但 Zig 并不像这些上市公司一样，以「最大化效率」为唯一目标。Kelley 表示，对 Zig 来说，「传帮带」本身就是项目核心使命的一部分，因此 AI 贡献反而会适得其反。「我们都在努力变成更好的程序员。那些提交 AI pull request 的人，并没有帮助实现这个目标。」
在他看来，这类 AI 代码提交者更像是「路过型贡献者」：可能提交一两个 pull request，但永远不会真正加入核心团队。
同时，全面禁止 AI 也让规则更简单。Kelley 表示，如果他说只有「好的」AI pull request 可以被接受，那么审查者就必须逐个判断哪些是好的、哪些不是。「但如果我说一律不接受，那这项政策就非常容易执行。」
其实，除了 Zig，还有其他一些开源项目对 AI 说「No」，包括开源的机器模拟器和虚拟化工具 QEMU（拒绝任何被认为包含 AI 生成内容，或源自 AI 生成内容的贡献）、老牌开源类 Unix 操作系统 NetBSD（AI 生成代码被默认视为受污染代码，不得提交）和是非常流行的开源录屏和直播软件 OBS Studio（代码必须由人类编写）。
这些项目的坚守令龙虾之父 Peter Steinberger 不禁感叹，「LLM 连找 bug 都不可以吗？」
他们的坚守最终会带来怎样的结果，现在还无法断言。但在 AI 写代码几乎成为潮流的当下，这些选择按下暂停键的开源项目，至少值得被认真看见。
原文链接：https://www.businessinsider.com/zig-programming-language-ai-rules-2026-5
© THE END
转载请联系本公众号获得授权
投稿或寻求报道：liyazhou@jiqizhixin.com