Zig为何严禁AI贡献？投资贡献者而非代码

开源世界中最严格的反LLM政策

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

• 不得使用LLM提交Issue
• 不得使用LLM提交Pull Request
• 不得在Bug追踪器的评论中使用LLM，包括翻译功能

Zig是由Andrew Kelley于2015年开始开发的系统级编程语言，定位为C语言的现代替代品。它强调手动内存管理的可控性，同时消除了C/C++中许多容易导致bug的设计缺陷——如隐式类型转换、未定义行为等。Zig的编译器本身是自举的（用Zig编写），并且可以作为C/C++的交叉编译工具链使用。Zig软件基金会（ZSF）作为非营利组织负责项目的长期维护和发展方向，其治理模式强调小而精的核心团队对代码质量和项目方向的严格把控。

这一政策在AI辅助编程日益普及的当下显得格外引人注目。尤其是当我们考虑到，基于Zig编写的最知名项目——Bun JavaScript运行时——已于2025年12月被Anthropic收购，并大量使用AI辅助开发。

Bun是由Jarred Sumner创建的JavaScript/TypeScript运行时，以极致性能著称，其核心部分使用Zig编写而非传统的C/C++。Bun选择Zig的原因包括其与C ABI的无缝互操作性、编译期计算能力以及比C++更可控的内存模型。Anthropic收购Bun被视为AI公司布局开发者基础设施的重要信号——Anthropic希望将Bun整合进其AI编码工具链生态中，这也意味着Bun的开发流程将更深度地融入AI辅助工作流，与Zig主项目的理念形成了鲜明对比。

Bun的4倍编译性能提升与无法上游的尴尬

这一政策的现实影响已经显现。Bun团队在其维护的Zig分支中，通过添加"并行语义分析和多代码生成单元到LLVM后端"，实现了Bun编译速度4倍的性能提升。然而，Bun官方明确表示：

我们目前不计划将此上游合并，因为Zig严格禁止LLM编写的贡献。

要理解这项技术改进的难度，需要了解其背后的编译器工程原理。传统编译器的语义分析阶段——检查类型正确性、作用域规则、生命周期等——通常是单线程串行执行的，因为代码中的符号依赖关系形成复杂的有向图，难以简单并行化。并行语义分析意味着将这些依赖关系拆解为可并发处理的单元，这在工程上极具挑战性。LLVM是一个广泛使用的编译器基础设施框架，其后端负责将中间表示（IR）转换为目标机器码。"多代码生成单元"指的是将LLVM IR拆分为多个独立的编译单元并行生成机器码，类似于Rust编译器中的codegen-units策略。这种优化能显著缩短大型项目的编译时间，但可能影响跨单元的内联优化效果，需要在编译速度和运行时性能之间做出权衡。

你可能没注意到，Zig核心贡献者后续也解释了即便不考虑LLM问题，这个特定补丁也不会被接受——并行语义分析是一个长期规划中的功能，对"Zig语言本身"有深远影响。但LLM禁令无疑是一个更为根本性的阻碍因素。

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

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

他提出了一个名为"贡献者扑克"（Contributor Poker）的概念：

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

这个比喻精准地揭示了Zig团队的核心逻辑：项目真正重视的是贡献者本身，而非他们提交的代码。

代码审查的投资回报率被重新定义

在成功的开源项目中，维护者最终都会面临PR数量超过处理能力的困境。这一现象被称为"维护者瓶颈"，是开源可持续性研究中的核心议题。随着项目影响力增长，外部贡献的数量呈指数增长，但核心维护者的时间和精力是有限的。Linux内核、Python、Rust等大型项目都面临这一挑战，研究表明许多知名开源项目的核心维护者存在严重的倦怠问题。这也是为什么"培养新的可信赖维护者"被视为开源项目可持续性的关键指标——项目的"巴士因子"（bus factor，即多少核心成员离开会导致项目停滞）直接决定了其长期健康度。

Zig团队的应对策略并非简单地拒绝不完美的PR，而是尽力帮助新贡献者完善他们的工作。Loris解释道：

我们尽最大努力帮助新贡献者将他们的工作合并进来，即使他们需要一些帮助才能达到目标。我们这样做不仅因为这是"正确"的事情，更因为这是聪明的事情。

每一次代码审查都是对贡献者的一次投资。核心团队花费时间审查和指导PR的首要目标，并不是合并新代码，而是培养新的贡献者——让他们逐步成长为可信赖的、高产的长期项目成员。

LLM贡献为何从根本上破坏了这一模型

LLM辅助贡献之所以被视为威胁，并非因为代码质量问题。即便LLM帮助你提交了一个完美的PR，Zig团队在审查过程中投入的时间也无法帮助他们培养出新的、有能力独当一面的贡献者。

这里的逻辑链条非常清晰：

1. 审查成本是固定的：无论PR来源如何，核心团队都需要投入时间审查
2. 传统模式下有双重回报：代码被合并 + 贡献者能力得到提升
3. LLM模式下只有单一回报：代码被合并，但贡献者的真实能力并未得到验证和提升
4. 投资回报率大幅下降：团队无法判断这个贡献者未来是否能独立承担更复杂的任务

正如Simon Willison在评论中指出的一个尖锐问题：如果一个PR主要由LLM编写，项目维护者为什么要花时间审查和讨论它，而不是自己启动一个LLM来解决同样的问题？

Simon Willison是Django Web框架的联合创始人，也是开源社区中对AI工具持开放态度的知名开发者。他创建了多个AI相关的开源工具（如LLM命令行工具、Datasette等），并长期撰写关于LLM在软件开发中应用的深度博客。他的评论之所以具有特殊分量，正是因为他本人是AI辅助编程的积极倡导者，却依然能理解Zig团队立场的合理性——这种来自"对立阵营"的认可，使得Zig的论点更具说服力，也表明这一问题的复杂性远超简单的"拥抱AI vs 抵制AI"二元对立。

对开源社区治理的深层启示

Zig的政策代表了一种极端但逻辑自洽的立场。它迫使我们重新思考开源贡献的本质：开源项目的可持续性不仅取决于代码的数量和质量，更取决于社区中有能力、有责任心的贡献者的数量。

当然，这一政策也面临现实挑战。随着AI辅助编程成为行业常态，如何区分"LLM编写"和"LLM辅助"的边界将越来越模糊。一个开发者使用LLM生成代码框架后进行深度修改和理解，与完全复制粘贴LLM输出之间存在巨大的灰色地带。Bun的案例已经表明，严格的禁令可能导致有价值的技术改进无法回馈上游，形成事实上的项目分裂。

值得注意的是，其他开源项目对此问题采取了截然不同的策略。例如，Linux内核社区允许AI辅助但要求贡献者对代码承担完全责任；Rust项目则更关注代码质量本身而非其生成方式。Zig的选择处于光谱的最严格一端，这与其项目规模（核心团队较小）、语言特性（系统级编程对正确性要求极高）以及发展阶段（尚未达到1.0稳定版本）密切相关。

但Zig团队的选择至少提醒了整个开源社区一个容易被忽视的事实：代码是暂时的，贡献者才是永恒的资产。在AI时代，如何平衡工具效率与社区建设，将是每个开源项目都需要认真思考的问题。

核心要点

• Zig项目实施了开源社区中最严格的反LLM政策，禁止在Issue、PR和评论中使用任何LLM工具
• Bun团队在Zig分支上实现了4倍编译性能提升，但因LLM禁令无法将改进上游合并到Zig主项目
• Zig的核心理念是"贡献者扑克"——投资贡献者而非代码，每次PR审查的首要目标是培养长期可信赖的社区成员
• LLM辅助贡献从根本上破坏了这一投资模型：即便代码完美，维护者也无法评估贡献者的真实能力和成长潜力
• 该政策引发了开源社区关于AI时代效率与社区建设如何平衡的深层讨论