Zig禁止AI代码贡献的真正原因：投资人而非代码

开源世界最严格的反AI政策

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

Zig是一门系统级编程语言，由Andrew Kelley于2015年开始开发，定位为C语言的现代替代方案。它的设计哲学强调可读性、可调试性和对底层硬件的精确控制，同时避免了C/C++中常见的未定义行为陷阱。Zig不使用垃圾回收，也不依赖libc，可以直接与C代码互操作。Zig软件基金会（ZSF）是一个501(c)(3)非营利组织，负责维护和推进Zig语言的发展，其运营模式高度依赖社区志愿贡献者——这也是理解其反AI政策的重要背景。

该政策明确规定：

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

这一政策的严格程度在主流开源项目中几乎无出其右。而让这场讨论进一步升温的，是Bun JavaScript运行时的一则声明——作为Zig语言编写的最知名项目，Bun在其Zig分支上实现了4倍的编译性能提升，却明确表示不会将代码上游合并，原因正是Zig对LLM生成代码的严格禁令。

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

Bun是一个高性能JavaScript运行时，由Jarred Sumner创建，旨在替代Node.js，其核心卖点是极致的启动速度和运行性能。Bun选择Zig而非C/C++或Rust作为底层实现语言，正是看中了Zig在系统编程中的性能优势和与C的无缝互操作能力。2025年12月，AI公司Anthropic（Claude的开发商）收购了Bun，这一收购使得Bun团队在开发流程中大量引入AI辅助工具成为必然趋势，也直接加剧了与Zig上游反AI政策之间的张力。

Bun团队在其维护的Zig分支中，通过为LLVM后端添加「并行语义分析和多代码生成单元」，将Bun的编译速度提升了4倍。这里涉及编译流水线的两个关键阶段：LLVM（Low Level Virtual Machine）是许多现代编程语言（包括Rust、Swift、Zig）共同使用的编译器基础设施；语义分析是编译器检查代码逻辑正确性的阶段，而代码生成单元（CGU）是将中间表示转换为机器码的模块。传统编译器通常串行处理这些阶段，而并行化意味着同时处理多个编译单元，充分利用现代多核CPU的能力。Rust编译器此前也通过类似的多CGU策略显著提升了编译速度，但这类改动往往涉及语言语义的深层约束。

然而，Bun团队公开表示：「我们目前不打算将此上游合并，因为Zig严格禁止LLM生成的贡献。」这一声明将Zig的反AI政策推上了风口浪尖。

说个细节，Zig核心贡献者后来补充说明，即使抛开LLM问题，这个特定补丁也不会被接受——并行语义分析是一个长期规划的功能，对Zig语言本身有深远影响，需要作为语言层面的整体设计来推进，而非接受一个外部的局部实现。但这并不改变政策本身引发的讨论价值。

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

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

投资人，而非投资代码

Loris指出，成功的开源项目最终都会面临PR数量超过处理能力的问题。在GitHub等平台上，外部贡献者通过Fork仓库、修改代码、提交PR的方式参与项目。维护者对PR的审查远不止于检查代码是否能运行——它包括代码风格一致性、架构设计合理性、边界条件处理、性能影响评估，以及与贡献者的反复讨论和修改。对于资源有限的开源项目，每一次PR审查都是一笔显著的时间投入。Linux内核、Python等大型项目每天收到的PR数量远超维护者的处理能力，因此如何分配审查资源本身就是一个战略决策。

面对这种情况，Zig项目的选择并非拒绝不完美的PR以最大化投入产出比，而是尽最大努力帮助新贡献者完成他们的工作，即使他们需要一些帮助才能达到标准。

这不仅是「正确的事」，更是「聪明的事」。Zig团队审查和接受PR的首要目标，不是合并新代码，而是培养新的贡献者——那些随着时间推移能够成为值得信赖、高产出的核心成员。

为什么LLM从根本上打破了这个模型

LLM辅助从根本上破坏了这一投资逻辑。即使LLM帮助你提交了一个完美的PR，Zig团队花在审查你工作上的时间，也无法帮助他们获得一个新的、有能力的、值得信赖的贡献者。

用Loris的话说：

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

这段话精准概括了Zig禁止AI贡献的底层逻辑：开源项目的长期健康，取决于人的成长，而非代码的堆积。

一个值得深思的反问

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

这个问题直击要害。开源项目的代码审查从来不仅仅是质量把关——它是一个双向的学习和信任建立过程。审查者在评估代码的同时，也在评估贡献者的思维方式、技术判断力和沟通能力。当LLM成为中间层，这一切都变成了对机器输出的审查，而非对人的了解。

换句话说，LLM生成的PR让代码审查失去了「识人」的功能，维护者投入的时间无法转化为对贡献者能力的判断，这对资源本就紧张的开源项目来说是一种浪费。

并非唯一正确答案，但逻辑自洽

需要强调的是，Zig的反AI政策并非适用于所有开源项目的通用方案。不同项目有不同的目标和约束：

以代码产出为核心的项目可能更欢迎任何能提高效率的工具
以社区建设为核心的项目（如Zig）则有充分理由限制AI介入
企业主导的开源项目往往更关注功能交付速度

Zig的独特之处在于，它将贡献者的成长明确置于代码质量之上，并且将这一优先级贯彻到了政策层面。这种做法在短期内可能意味着错过一些优质代码（如Bun的4倍性能提升），但从长期来看，它保护了项目最核心的资产——一个有能力、有信任基础的贡献者社区。

对开源社区的启示

随着Cursor、GitHub Copilot等AI编程工具的普及，每个开源项目都将不得不面对类似的选择。截至2025年，AI辅助编程工具已形成庞大生态：GitHub Copilot基于OpenAI的Codex模型，可在IDE中实时生成代码建议；Cursor是一款AI原生代码编辑器，深度集成了多种大语言模型，支持对话式编程和全项目上下文理解；此外还有Codeium、Tabnine、Amazon CodeWhisperer等竞品。这些工具已经从简单的代码补全进化到能够理解项目架构、生成完整功能模块、甚至自动修复Bug。据GitHub统计，Copilot用户接受了约30%的AI建议代码，这意味着大量进入开源项目的代码可能包含AI生成的成分，而这些成分在代码审查中几乎无法被可靠识别——这也让Zig式的「全面禁止」政策在执行层面面临现实挑战。

Zig的案例提供了一个清晰的思考框架：在制定AI政策之前，先明确你的项目最看重什么。

如果答案是「代码」，那么拥抱AI工具是合理的选择。如果答案是「人」，那么限制AI介入就不是保守，而是战略。

Zig用「贡献者扑克」这个比喻告诉我们：在开源的牌桌上，最值得下注的永远不是眼前这手牌的好坏，而是坐在对面的那个人。