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

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

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

• Issue中禁止使用LLM
• Pull Request中禁止使用LLM
• Bug追踪器的评论中禁止使用LLM，包括翻译

Zig是一门诞生于2015年的系统级编程语言，由Andrew Kelley创建，定位为C语言的现代替代品。它强调手动内存管理、编译期计算（comptime）和与C语言的无缝互操作性，同时消除了C/C++中许多容易导致安全漏洞的设计缺陷。Zig项目由非营利性的Zig软件基金会（ZSF）管理，采用完全社区驱动的开发模式，不接受任何企业的直接控制。这种治理结构对理解其反LLM政策至关重要——ZSF的使命是维护语言的长期健康发展，而非追求短期的功能交付速度。

这一政策在AI辅助编程日益普及的当下显得格外引人注目。尤其是当我们考虑到，用Zig编写的最知名项目——Bun JavaScript运行时——已于2025年12月被Anthropic收购，并大量使用AI辅助开发时，这种对比更加鲜明。Bun是由Jarred Sumner于2022年发布的高性能JavaScript/TypeScript运行时，以极快的启动速度和执行性能著称，被视为Node.js和Deno的竞争者。而Anthropic是由前OpenAI研究副总裁Dario Amodei和Daniela Amodei于2021年创立的AI安全公司，以其Claude系列大语言模型闻名。一个以AI为核心业务的公司接管了一个用Zig编写的关键基础设施项目，这使得Zig的反LLM政策与Bun的发展方向之间产生了直接而耐人寻味的张力。

Bun编译性能提升4倍，却无法合并回上游

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

要理解这项改进的技术含义，需要先了解其背后的编译器架构。LLVM（Low Level Virtual Machine）是一个广泛使用的编译器基础设施框架，许多现代编程语言（包括Rust、Swift、Zig）都使用LLVM作为后端来生成高效的机器代码。所谓"并行语义分析"是指编译器在分析源代码含义（类型检查、作用域解析等）时同时处理多个编译单元，而"多代码生成单元"则是将最终的机器代码生成过程拆分为多个并行任务。传统上Zig的编译器采用单线程顺序处理，这在大型项目中会成为瓶颈。Bun团队的改进本质上是将编译流水线的多个阶段并行化，这是一项涉及编译器架构根基的深层改动，而非简单的性能优化补丁。

然而，Bun官方明确表示：

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

你可能没注意到，Zig核心贡献者也指出，即使不考虑LLM问题，这个特定补丁也不会被接受——并行语义分析是一个长期规划中的功能，对"Zig语言本身"有深远影响。技术决策和政策立场在此处形成了某种交汇。

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

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

投资人才，而非投资代码

Loris的核心论点可以归结为一句话：Zig重视贡献者胜过贡献本身。

在成功的开源项目中，维护者最终都会面临PR数量超出处理能力的局面。面对这种情况，Zig选择的策略不是拒绝不完美的PR，而是尽力帮助新贡献者完善他们的工作。这不仅是"正确的事"，更是"聪明的事"。

每一次代码审查的本质目的不仅是合并新代码，更是培养新的贡献者——让他们逐步成长为可信赖的、高产的项目核心成员。这是一种面向未来的长期投资策略。在成熟的开源项目中，这种层级化的信任体系有着深厚的传统：新贡献者从修复小bug开始，经过反复的PR提交和审查，逐步获得更大的代码库访问权限，最终可能成为核心维护者。Linux内核的"信任网络"（Web of Trust）和Apache基金会的"提交者晋升"机制都是这一模式的典型代表。每次审查都是维护者对贡献者能力的评估和指导，这个过程中积累的隐性知识——对项目架构的理解、对设计哲学的认同、对代码风格的内化——是无法通过文档传递的。

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

LLM辅助从根本上瓦解了这套培养机制。即使LLM帮助你提交了一个完美的PR，Zig团队花在审查上的时间也无法帮助他们收获一个有能力的、值得信赖的新贡献者。审查过程变成了单向的资源消耗，而非双向的能力建设。

更深层的问题在于，LLM的介入使得开源社区赖以运转的"信任信号"变得不再可靠。传统开源社区依赖一系列信号来评估贡献者：commit历史的一致性、代码审查中的讨论质量、对issue的响应深度、以及在邮件列表或论坛中展现的技术理解力。这些信号共同构成了一个去中心化的声誉系统。LLM的介入使得这些信号的可靠性大幅下降——一个对项目架构毫无理解的人可以借助LLM提交看似专业的PR和评论。这种"信号污染"问题意味着维护者无法再确认与其交互的对象是否真正具备其展现出的能力，整个信任评估体系面临失效的风险。

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

就像人们常说的扑克牌游戏一样，"你在玩的是人，而不是牌"。在贡献者扑克中，你押注的是贡献者，而不是他们第一个PR的内容。

AI时代开源协作面临的本质矛盾

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

这个问题触及了AI时代开源协作的本质矛盾。传统开源模式建立在人与人之间的信任网络之上——通过持续的贡献建立声誉，通过代码审查传递知识，通过社区互动形成共识。LLM的介入让这些信号变得模糊不清。

拥抱AI还是坚守人本？两种路线的分野

当前开源社区正在形成两种截然不同的路线：

1. 拥抱AI辅助：以Bun/Anthropic为代表，将AI视为提升生产力的工具，追求代码质量和开发效率的最大化
2. 坚守人本主义：以Zig为代表，将社区建设和人才培养置于代码产出之上，维护贡献者成长的生态系统

两种路线各有其合理性。Zig的选择或许不适用于所有项目，但它提供了一个清晰的思考框架：开源项目的核心资产究竟是代码库，还是围绕代码库形成的人才网络？

结语：技术社区的可持续发展靠人而非代码

Zig的反LLM政策不是简单的技术保守主义，而是基于对开源社区运作机制的深刻理解做出的战略选择。在AI工具日益强大的今天，这种"以人为本"的坚持反而显得弥足珍贵。它提醒我们，技术社区的可持续发展最终取决于人的成长，而非代码的堆积。

核心要点

• Zig项目实施了开源社区中最严格的反LLM政策，禁止在Issue、PR和评论中使用任何LLM生成内容
• Bun团队在Zig分支上实现了4倍编译性能提升，但因LLM禁令无法将改进合并回上游
• Zig的核心理念是"贡献者扑克"——投资于培养贡献者而非获取代码，LLM辅助会破坏这一人才培养机制
• 该政策引发了深层思考：如果PR由LLM编写，维护者为何不直接用LLM解决问题，而要花时间审查他人的AI生成代码
• 开源社区正在形成拥抱AI辅助与坚守人本主义两条分化路线，Zig的选择代表了对社区可持续发展的长期思考