Zig项目为何严格禁止AI贡献：投资人而非代码

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

Zig编程语言项目拥有目前主流开源项目中最严格的反LLM政策。其行为准则明确规定：

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

Zig是一门诞生于2015年的系统级编程语言，由Andrew Kelley创建，定位为"更好的C语言"。它的设计哲学强调可读性、可调试性和对底层硬件的精确控制，同时消除C/C++中那些容易导致安全漏洞的隐式行为（如隐式类型转换和未定义行为）。Zig不使用垃圾回收，可以直接调用C语言的ABI和头文件，并且自带一个可以编译C/C++代码的工具链。正因为这种"从根基重新思考系统编程"的野心，Zig项目对贡献者的技术深度和语言哲学理解有着极高的要求——这也是理解其反AI政策的重要前提。

在AI辅助编程日益普及的当下，这一政策显得格外引人注目。近日，Zig软件基金会社区副总裁Loris Cro在文章《Contributor Poker and Zig's AI Ban》中，详细阐述了这一严格禁令背后的深层逻辑。

Bun的4倍性能提升与无法上游合并的尴尬

用Zig编写的最知名项目当属Bun JavaScript运行时。Bun是一个旨在替代Node.js的全栈JavaScript/TypeScript运行时，由Jarred Sumner于2022年发布。它之所以选择Zig而非C++来编写核心引擎，正是看中了Zig在性能和内存安全之间的平衡——Bun的HTTP服务器性能在多项基准测试中显著超越Node.js和Deno，这在很大程度上归功于Zig对底层资源的精细控制能力。

Bun于2025年12月被Anthropic收购，自然大量使用AI辅助开发。Anthropic是Claude大语言模型的开发商，也是OpenAI最主要的竞争对手之一。收购Bun被广泛解读为Anthropic在AI基础设施层面的战略布局——一个高性能的JavaScript运行时对于构建AI应用的服务端基础设施至关重要。这一收购也使得Bun团队与Zig项目之间的关系变得微妙：一个由AI公司拥有、大量使用AI辅助开发的项目，依赖于一个明确禁止AI贡献的上游语言。

Bun维护着自己的Zig分支，最近通过为LLVM后端添加"并行语义分析和多代码生成单元"，实现了编译速度4倍的提升。

这里需要解释几个关键技术概念。LLVM（Low Level Virtual Machine）是当今最重要的编译器基础设施之一，被Clang（C/C++）、Rust、Swift等众多语言的编译器用作后端——它负责将高级语言的中间表示转换为针对特定CPU架构优化的机器码。"语义分析"是编译流程中的关键阶段，位于词法分析和语法分析之后，负责检查代码的类型正确性、变量作用域、函数调用合法性等深层逻辑。传统编译器通常在单线程中串行完成语义分析，而"并行语义分析"意味着将这一过程拆分到多个CPU核心上同时执行。"多代码生成单元"则是将最终的机器码生成阶段也并行化。这两项优化叠加，在多核处理器上可以带来接近线性的编译速度提升，这就是Bun团队实现4倍性能提升的技术基础。

然而，Bun团队明确表示：

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

有意思的是，Zig核心贡献者也指出，即使不考虑LLM问题，这个特定补丁也不会被接受——并行语义分析是一个长期规划的功能，对Zig语言本身有深远影响。编译器的语义分析阶段与语言的类型系统、泛型实现（Zig中称为comptime）、错误处理模型等核心设计紧密耦合，任何并行化改造都需要极其谨慎地处理数据依赖和执行顺序问题，否则可能引入难以复现的并发Bug或改变语言的语义行为。但这一事件仍然生动地展示了AI禁令在实践中造成的现实张力。

核心逻辑："贡献者扑克"哲学

投资人，而非投资代码

Loris Cro的解释揭示了一个深刻的项目管理哲学：Zig团队看重的是贡献者本身，而非他们提交的代码。

在成功的开源项目中，维护者最终都会面临PR数量超出处理能力的局面。这一现象在开源社区中被称为"维护者倦怠"（maintainer burnout），是困扰整个开源生态的系统性问题。Linux内核每个开发周期收到超过一万个补丁，Kubernetes项目积压的PR经常超过数百个，即使是中等规模的项目也常常面临PR审查队列不断增长的困境。每一个PR的审查不仅需要理解代码本身的正确性，还需要评估它对项目架构的长期影响、与其他正在进行的工作的兼容性，以及贡献者是否理解项目的设计原则。

Zig的策略不是只接受完美的PR来最大化投入产出比，而是尽力帮助新贡献者完善他们的工作。这不仅是"正确的事"，更是"聪明的事"。

每一位贡献者都代表着Zig核心团队的一笔投资。审查和接受PR的首要目标不是合并新代码，而是培养新的贡献者——让他们随着时间推移成为值得信赖且高产的项目成员。这种模式在开源世界中并非Zig独创——Linux内核的"子系统维护者"体系、Apache基金会的"提交者晋升"机制，本质上都是通过长期互动来识别和培养核心贡献者。但Zig将这一理念推向了极致，将其作为拒绝AI贡献的核心理由。

LLM为什么会破坏这一模型

LLM辅助从根本上破坏了这个投资模型。即使AI帮你提交了一个完美的PR，Zig团队花在审查上的时间，对于培养一个自信、可靠的贡献者毫无帮助。

这就是"贡献者扑克"的含义——正如真正的扑克牌游戏中常说的那样，"你玩的是人，而不是牌"。在贡献者扑克中，你押注的是贡献者本人，而不是他们第一个PR的内容。

AI辅助编程对开源协作的深层冲击

这一政策引发了一个值得深思的问题：如果一个PR主要由LLM编写，项目维护者为什么要花时间审查和讨论它，而不是自己用LLM来解决同样的问题？

当前AI辅助编程工具已经深度渗透到软件开发的各个环节。GitHub Copilot拥有超过百万付费用户，Cursor编辑器在开发者社区中迅速走红，Claude、ChatGPT等通用大模型也被广泛用于代码生成和调试。据GitHub 2024年的数据，其平台上已有超过四分之一的PR包含AI生成的代码。面对这一趋势，不同开源项目采取了截然不同的态度：Linux内核要求所有贡献者对代码承担个人责任但未明确禁止AI工具，Gentoo Linux明确禁止AI生成的代码贡献，而一些新兴项目则积极拥抱AI辅助。Zig的立场在这个光谱中处于最严格的一端。

这个逻辑链条揭示了AI辅助编程在开源协作中的一个根本矛盾：

1. 信任建立的断裂：开源社区的信任通过反复的人际互动建立，LLM将这一过程中介化了。在传统的开源协作中，维护者通过观察一个贡献者如何回应代码审查意见、如何在讨论中阐述设计决策、如何处理边界情况，来逐步建立对这个人的技术判断力和可靠性的信任。当LLM介入这一过程，维护者实际上是在与一个算法的输出互动，而非与一个正在成长的工程师互动。

2. 技能评估的失效：维护者无法通过审查AI生成的代码来判断贡献者的真实能力。这在系统级编程中尤为关键——一个能让LLM生成正确Zig代码的人，未必理解该代码在内存布局、编译期求值（comptime）或跨平台兼容性方面的深层含义。而这些深层理解恰恰是成为可靠的长期贡献者所必需的。

3. 社区投资的贬值：花在指导和反馈上的时间无法转化为贡献者的实际成长。如果一个贡献者在收到审查意见后，只是将反馈喂给LLM来生成修改后的代码，那么维护者精心撰写的技术指导实际上是在"培训"一个大语言模型的提示词，而非培养一个人类工程师的技术直觉。

并非所有开源项目都适用

补充一点，Zig的策略有其特殊性。作为一个仍在快速发展的编程语言项目，培养深度理解语言设计哲学的核心贡献者至关重要。编程语言项目与一般的应用软件项目有本质区别：语言的每一个设计决策都会影响数以万计的下游用户，一个不当的语法糖或类型系统变更可能在未来数年内造成无法逆转的技术债务。Zig目前尚未发布1.0稳定版本（截至2025年仍处于0.x阶段），这意味着语言的核心设计仍在演进中，每一个贡献都可能对语言的最终形态产生深远影响。

对于其他类型的项目——比如以快速交付功能为主要目标的应用层项目——AI辅助贡献可能完全合理。例如，一个Web应用的前端组件库、一个数据处理的CLI工具，或者一个文档翻译项目，其核心价值更多在于功能的完备性和交付速度，而非贡献者对底层原理的深度理解。在这些场景中，AI辅助可以显著降低贡献门槛，加速项目迭代。

但Zig的案例提供了一个清晰的思考框架：当开源项目的核心价值在于社区建设和人才培养时，AI辅助可能不仅无益，反而有害。 这不是技术保守主义，而是对开源协作本质的深刻理解。它迫使整个开源社区重新审视一个根本问题：开源的价值究竟在于代码本身，还是在于创造代码的人和他们之间形成的协作网络？

核心要点

• Zig项目实施了主流开源项目中最严格的反LLM政策，禁止在Issue、PR和评论中使用AI
• Bun（已被Anthropic收购）的Zig分支实现了4倍编译性能提升，但因AI禁令无法上游合并
• Zig的核心哲学是"贡献者扑克"——投资于人而非代码，通过PR审查培养长期贡献者
• LLM辅助破坏了开源社区的信任建立模型：维护者无法通过AI生成的代码评估贡献者真实能力
• 这一政策引发深层思考：如果PR由AI编写，维护者为何不直接用自己的AI解决问题