Zig语言为何全面禁止AI贡献？投资人而非代码的开源哲学

开源项目中最严格的反AI政策

Zig编程语言项目近期因其在开源社区中最为严格的反LLM（大语言模型）贡献政策而引发广泛讨论。该政策明确规定：

不得使用LLM提交Issue
不得使用LLM提交Pull Request
不得使用LLM在Bug追踪器中发表评论，包括翻译

Zig是一种系统级编程语言，由Andrew Kelley于2015年开始开发，定位为C语言的现代替代品。它强调手动内存管理、编译时计算（comptime）和与C/C++的无缝互操作性，刻意避免了C++和Rust中常见的隐式行为和复杂特性。Zig项目由非营利性质的Zig软件基金会（ZSF）管理，核心设计决策主要由Andrew Kelley本人主导。这种高度集中的治理模式使得项目能够保持极高的设计一致性，但也意味着每一次外部贡献都需要与核心愿景严格对齐——这为理解其反AI政策提供了重要的组织背景。

这一政策在AI辅助编程日益普及的当下显得格外引人注目。截至2025年，AI辅助编程已从实验性工具演变为主流开发实践。GitHub Copilot拥有超过百万付费用户，Cursor、Windsurf等AI原生IDE迅速崛起，超过70%的专业开发者在日常工作中使用某种形式的AI辅助。在这样的行业大背景下，Zig的全面禁令显得尤为醒目。

尤其是当我们考虑到，用Zig编写的最知名项目——Bun JavaScript运行时——已于2025年12月被Anthropic收购，并大量使用AI辅助开发时，这种对比更加鲜明。Bun是由Jarred Sumner于2022年发布的JavaScript/TypeScript运行时，以极致性能为卖点，在启动速度、包安装和HTTP服务等基准测试中大幅领先Node.js和Deno。Anthropic收购Bun团队被广泛解读为在AI基础设施层面的战略布局——高性能JavaScript运行时对于AI应用的服务端部署至关重要。收购后的Bun团队大量使用AI辅助开发工具，这与Zig上游项目的反AI立场形成了尖锐矛盾。

Bun的4倍性能提升与上游困境

Bun团队最近在其维护的Zig分支上取得了令人瞩目的成果：通过为LLVM后端添加"并行语义分析和多代码生成单元"，将Bun编译速度提升了4倍。

要理解这一成果的技术含义，需要了解其背后的编译器架构。LLVM（Low Level Virtual Machine）是当今最广泛使用的编译器基础设施框架，Clang、Rust编译器、Swift编译器等几乎所有主流编译器都构建在LLVM之上，Zig编译器同样使用LLVM作为其代码生成后端。Bun团队所实现的优化涉及两个关键层面：其一，将语义分析（检查类型正确性、解析符号引用等）从串行改为并行执行，充分利用现代多核CPU；其二，将编译输出拆分为多个独立的代码生成单元，使LLVM后端能够并行生成机器码。在大型项目中，编译瓶颈往往在于LLVM的代码生成阶段，因此这种优化效果尤为显著。4倍的编译加速意味着开发者的迭代周期大幅缩短，对Bun这样的大型Zig项目而言是实质性的生产力提升。

然而，Bun团队明确表示：

我们目前不打算将此上游合并，因为Zig对LLM生成的贡献有严格禁令。

这一事件将Zig的反AI政策推到了聚光灯下。说个细节，Zig核心贡献者也指出，即便不考虑LLM问题，这个特定补丁也不会被接受——并行语义分析是一个长期规划的功能，对Zig语言本身有深远影响，它涉及编译器内部状态管理、错误报告顺序确定性等一系列复杂的设计决策，不是简单的性能补丁所能覆盖的。但这并不改变政策本身引发的讨论热度。

核心理念：贡献者扑克哲学

Zig软件基金会社区副总裁Loris Cro在其文章《Contributor Poker and Zig's AI Ban》中，给出了迄今为止对全面禁止LLM辅助贡献最有说服力的论述。

投资人，而非投资代码

Loris的核心论点可以概括为：Zig重视贡献者胜过贡献本身。每一位贡献者都代表着Zig核心团队的一笔投资。审查和接受PR的首要目标不是获取新代码，而是培养新的贡献者——让他们随着时间推移成为值得信赖的、高产的项目成员。

这一理念与开源社区长期以来的PR审查文化一脉相承。Pull Request审查远不止于检查代码正确性——在成熟的开源项目中，它是一个多层次的社会化过程。审查者需要评估代码风格是否符合项目规范、架构决策是否合理、测试覆盖是否充分，更重要的是评估贡献者是否理解项目的设计哲学。Linux内核、PostgreSQL等长寿项目都有严格的贡献者晋升路径：从小补丁开始，逐步获得信任，最终可能成为子系统维护者。这种"学徒制"模式是开源项目可持续发展的关键，而Zig的"贡献者扑克"理念正是这一传统的显式表达。

在成功的开源项目中，你最终会达到一个节点：收到的PR数量超过了你的处理能力。按理说应该停止接受不完美的PR以最大化工作投入产出比，但Zig项目不这么做。相反，我们尽最大努力帮助新贡献者完成他们的工作，即使他们需要一些帮助才能达到要求。我们这样做不仅因为这是正确的事情，更因为这是聪明的做法。

LLM为什么会破坏这一培养模型

LLM辅助从根本上打破了这个培养模型。即便LLM帮助你提交了一个完美的PR，Zig团队花在审查你工作上的时间，对于为项目增添新的、有信心的、值得信赖的贡献者这一目标而言，几乎毫无价值。

这里存在一个深层的"理解鸿沟"问题。研究表明，AI生成的代码在安全漏洞、边界条件处理和长期可维护性方面存在系统性弱点。更关键的是，开发者可能提交了功能正确的代码，却无法解释其工作原理或在边缘情况下的行为。在开源贡献中，维护者无法通过代码审查来可靠地区分"理解后编写"和"生成后提交"。当维护者花费数小时审查一个PR、提出修改建议、解释项目的设计权衡时，如果对方只是将反馈输入LLM再生成新版本，那么这个教学过程就完全失效了。

Loris将这种策略命名为"贡献者扑克"：

我之所以称之为"贡献者扑克"，是因为就像人们对真正的纸牌游戏所说的那样，"你玩的是人，而不是牌"。在贡献者扑克中，你押注的是贡献者，而不是他们第一个PR的内容。

AI时代开源协作的本质追问

这一理念引出了一个在开源社区中日益被讨论的深层问题：如果一个PR主要由LLM编写，项目维护者为什么要花时间审查和讨论它，而不是自己启动一个LLM来解决同样的问题？

这个问题触及了AI辅助编程时代开源协作的本质。当代码的生成成本趋近于零时，真正稀缺的资源是什么？Zig的答案很明确：是人——是那些理解项目设计哲学、能够做出判断、承担长期维护责任的人类贡献者。

这一追问也暴露了AI生成代码在知识产权层面的隐忧。AI模型的训练数据可能包含各种许可证下的代码，生成内容的版权归属至今没有明确的法律定论。对于严格遵循开源许可证的项目而言，接受来源不明的AI生成代码可能引入额外的法律风险——这是除了贡献者培养之外，另一个值得开源项目认真考量的维度。

对开源生态的启示

并非所有项目都适用同一策略

Zig的策略有其特殊性。作为一个仍在快速发展的编程语言项目，其核心团队规模有限，每一次代码审查都是宝贵的教学和筛选机会。对于更成熟、更大规模的项目，完全禁止AI辅助可能并不现实，也未必是最优策略。

事实上，开源社区中的AI政策已经形成了一个完整的光谱。Zig的全面禁令处于极端一侧；在另一端，一些项目明确欢迎AI辅助贡献，只要求贡献者能够解释和维护其提交的代码。中间地带则有各种折中方案：Linux内核要求所有代码必须由人类审查并签署"Developer Certificate of Origin"；Python社区要求贡献者对AI生成代码承担完全责任；FreeBSD则禁止在版权敏感区域使用AI生成内容。每个项目都需要根据自身的规模、治理模式和发展阶段，找到适合自己的平衡点。

信任与验证的困境

即便不采用Zig这样的全面禁令，所有开源项目都面临一个共同挑战：如何在AI时代建立和维护贡献者信任？当你无法确定一个贡献者是否真正理解他们提交的代码时，代码审查的意义和方式都需要重新思考。

长期主义的价值

Zig的做法本质上是一种长期主义策略。短期来看，它可能会错过一些高质量的代码贡献（比如Bun的4倍编译加速）。但长期来看，它确保了项目核心团队的有机增长，以及每一位贡献者对代码库的深度理解。

在AI能力飞速增长的今天，Zig的选择提醒我们：技术项目的可持续发展，最终依赖的不是代码的数量或质量，而是背后那个理解、维护和推动项目前进的人类社区。这或许是AI时代最反直觉、却也最值得深思的洞见之一。