Zig 向 AI 代码说不：开源世界的一声另类呐喊

2026 年，当整个硅谷都在高呼"AI 写代码是未来"的时候，有一个开源项目选择了逆行。

它叫 Zig——一门被寄予厚望的"21 世纪 C 语言"，由创始人 Andrew Kelley 全职开发多年，驱动着 Ghostty 终端、TigerBeetle 数据库、Uber 跨平台编译器，被 Stack Overflow 连续多年评为"最受钦佩的编程语言"前五名。

但它最近一次登上新闻头条，不是因为又发布了什么新特性，而是因为它的代码贡献政策：全面禁止 AI 生成的代码进入其代码仓库。

不只是"不鼓励"，是明文写入《行为准则》（Code of Conduct）的硬性规定：不接受任何由大语言模型（LLM）生成的内容，不接受由 LLM 改写、润色、编辑、头脑风暴或调试过的内容。简单来说——让 AI 离 Zig 的代码贡献远一点，再远一点。

这条政策在 2026 年引爆了开源社区的激烈争论。它触及了一个深刻的问题：在 AI 辅助编程已成气候的当下，开源社区到底应该如何处理效率与传承、质量与参与之间的张力？

本文将深入剖析 Zig 做出这一选择的深层逻辑，探讨其背后的"贡献者扑克"（Contributor Poker）哲学，以及这一选择在技术、社区和商业层面引发的连锁反应。

一、事件始末：一条规则引发的风暴

1.1 从 JetBrains 播客开始

2026 年 4 月底，Zig 创始人兼首席开发者 Andrew Kelley 接受了 JetBrains 的播客采访。在节目中，他毫不客气地将 AI 辅助贡献称为"垃圾"（Garbage）。

这番言论随即在 Hacker News、Lobsters、Twitter/X 等平台引发热议。Kelley 的核心观点是：

"有人给我们提交完全没有价值的贡献。它们甚至是负价值，因为会占用团队有限的代码审查时间。"

Kelley 进一步描述了他在审核过程中遇到的具体情况：

"我们收到过这样的 PR——贡献者把我们在 issue 里说的话原封不动地复制到 AI 对话框里，再把 AI 生成的内容贴回来当成自己的贡献，试图通过清除聊天记录来掩盖自己使用了 AI 工具。但我们依然能看出来，并意识到永远不会有高质量的贡献。"

这些"垃圾贡献"让本就紧张的代码审查资源雪上加霜。Kelley 透露，当时 Zig 的 Pull Request 待审队列里还积压着 200 多个 PR。

1.2 Zig 的官方政策

在 Zig 官网的《行为准则》中，AI 相关条款写得清清楚楚：

No LLMs for issues.
No LLMs for pull requests.
No LLMs for comments on the bug tracker, including translation. English is encouraged, but not required. You are welcome to post in your native language and rely on others to have their own translation tools of choice to interpret your words.

注意最后一句：它甚至专门提到，欢迎用母语发帖，也欢迎用自己的翻译工具来理解别人的话——但不允许用 AI 改写评论内容。这说明 Zig 团队对"AI 辅助"的边界划得非常细致。

1.3 不只是 Zig 一家

Zig 并非孤例。几乎在同一时期，多个知名开源项目也表态拒绝 AI 代码：

就连苹果公司的 WebKit 团队也在内部讨论过类似问题。彭博社科技记者 Mark Gurman 报道，苹果工程师对 AI 生成代码进入 Safari 渲染引擎表示担忧。

这些项目形成了一个有趣的"联盟"——他们并非技术上的落后者，而是恰恰相反：QEMU 是全球最重要的虚拟化和模拟器项目之一，NetBSD 是历史最悠久的开源 Unix 系统之一，OBS Studio 则是直播和录屏领域的事实标准。

二、核心哲学：贡献者扑克（Contributor Poker）

2.1 为什么不能"择优录用"？

面对"为什么不能只拒绝差的 AI PR，接受好的 AI PR"的质疑，Zig 给出了深刻的回答。

Zig Software Foundation 社区副总裁 Loris Cro（维罗·克罗）在一篇名为《贡献者扑克与 Zig 的 AI 禁令》的博客中，详细解释了背后的逻辑。这篇文章被 Simon Willison 称为"迄今见过的对全面禁令最有力的论证"。

Cro 的核心论点是：

在成功的开源项目中，你迟早会遇到一个临界点——收到的 PR 数量超出了你能处理的极限。

这时，大多数项目会想当然地选择：减少接受不完美的 PR，以提高单位时间的投入产出比。

但 Zig 没有这样做。Cro 写道：

"我们 Zig 项目选择了相反的路径——我们尽一切努力帮助新的贡献者把他们的工作合并进来，即便他们需要一些帮助才能到达终点。我们这样做不只是因为这是'正确'的事，更是因为这是聪明的事。"

这个"聪明"体现在一个关键洞察上：Zig 看重的是贡献者本身，而不是他们的贡献。

2.2 贡献者 > 贡献

Cro 将这一理念命名为"贡献者扑克"（Contributor Poker），灵感来自于真实扑克游戏中的一句话："你玩的是人，不是牌。"（You play the person, not the cards.）

在 Zig 的语境中，这意味着：当你审查一个 PR 时，你下的赌注不只是这段代码，而是这个人的未来。

"一个优秀的 PR 内容只是入场券。真正的赌注是这个贡献者能不能在接下来的一年、三年、五年里，持续成为项目可信赖、有价值的一员。"

这就解释了为什么 Zig 愿意花大量时间帮助新手贡献者完成他们的第一个 PR——因为这不是在"做好事"，而是在投资未来的核心维护者。

2.3 AI 贡献如何破坏这一模式

当一个 PR 是由 AI 主要生成的时候，上述整个逻辑链条就断裂了。

即使这个 PR 完美无缺，Zig 团队花在审查它上面的时间，也不会帮助他们增加一个未来的核心贡献者。因为你审查的是 AI 的"手"，而不是开发者的"脑"。

Cro 说得毫不客气：

"如果一个 PR 是由 LLM 主要生成的，那为什么项目维护者要花时间讨论这个 PR，而不是直接启动自己的 LLM 来解决同样的问题？"

这不只是一个反讽，而是一个真实的效率问题：当你无法通过审查一个 PR 来发现和培养潜在的人才时，这个 PR 的审查价值就大打折扣。

2.4 简单规则的执行优势

Cro 还指出了全面禁令的一个实际好处：规则越简单，执行越容易。

"如果我说只有'好的' AI PR 可以被接受，那审查者就必须逐个判断哪些是好的、哪些不是。这个判断本身就要消耗大量精力，而且容易引发争议。但如果我说一律不接受，那这条政策就非常容易执行。"

换句话说，"禁止 AI 贡献"不是因为 AI 生成的所有代码都不好，而是因为**"允许好的 AI 代码"这个判断本身需要消耗稀缺资源**，这与开源社区的现实矛盾。

三、技术视角：Zig 语言的哲学与 AI 天然对立

3.1 显式优于隐式

Zig 语言有一个核心设计哲学：显式优于隐式（Explicitness over implicitness）。

这体现在很多方面：

// Zig 的内存管理是显式的
const buffer = try allocator.alloc(u8, 1024);
defer allocator.free(buffer);

// 比较：Rust 的借用检查器是隐式的（但有生命周期标注）
// C++ 的隐式构造和析构
// JavaScript/Python 的自动垃圾回收

Zig 的创始人 Kelley 明确表示：

"我设计 Zig 的核心目标是：让程序员的意图完全体现在代码中，不要有任何隐藏的行为。不要有隐藏的控制流，不要有隐藏的内存分配，不要有隐藏的函数调用。"

这与 AI 代码生成的本质形成了根本对立。

AI 生成代码的能力，依赖于在大量现有代码上的训练。当 AI 生成一段 Zig 代码时，它只是在模仿它见过的 Zig 代码模式，而不是在表达一个明确的意图。

3.2 编译期计算（ comptime ）：需要真正理解的特性

Zig 的一个标志性特性是编译期计算（Compile-Time Execution，comptime）。这是一个强大的元编程能力，允许在编译阶段执行任意 Zig 代码：

// 在编译期计算斐波那契数列
fn fibonacci(comptime n: usize) usize {
    if (n < 2) return n;
    return fibonacci(n - 1) + fibonacci(n - 2);
}

const fib_20 = fibonacci(20); // 编译时求值，结果为 6765

理解 comptime 需要开发者真正理解 Zig 的执行模型，而不仅仅是语法。AI 工具在处理这类元编程特性时，经常会生成看似正确但实际上存在微妙问题的代码——因为这类特性的边缘情况在训练数据中可能很少见。

3.3 无隐藏控制流的哲学延伸

Kelley 在多个场合表达过，AI 代码生成最大的问题之一是**"看起来对，但有隐藏问题"**：

// AI 可能生成这样的"优雅"代码
fn process(data: []const u8) !void {
    // 但这段代码可能有内存泄漏、资源未释放、
    // 错误处理不完整等问题，AI 自己可能都不知道
    try writeToFile(data);
    writeToStdout(data); // AI 忘了加 try！
}

在 Zig 的严格错误处理模型下，这类问题会被编译器捕获。但在更宽松的语言中，AI 生成代码中的这类隐蔽问题可能在审查中被遗漏。

3.4 Zig 的包管理新特性：减少 AI 可趁之机

2026 年 2 月的更新中，Zig 改进了包管理工作流：依赖的包现在存储在 zig-pkg 本地目录，全局缓存使用压缩文件以便于不同计算机间共享。

这些改进让 Zig 的工具链更加自包含，减少了对外部依赖的依赖——而 AI 生成代码的问题，往往在跨依赖调用时暴露。

四、连锁反应：Bun 的离开与 4 倍性能提升的代价

4.1 最著名的 Zig 项目：被 Anthropic 收购的 Bun

Zig 最知名的"产出"是 Bun——一个高性能 JavaScript/TypeScript 运行时，由 Jarred Sumner 开发。2025 年 12 月，Bun 被 Anthropic（Claude 的母公司）收购。

被收购后，Bun 的 AI 使用程度大幅提升。Sumner 自己在社交媒体上表示，他使用 Claude Code 的动态工作流功能，将 Bun 从 Zig 迁移到了 Rust。

这条消息震惊了整个技术圈——Bun 这个让 Zig 引以为豪的旗舰项目，选择离开 Zig 生态。

4.2 4 倍性能提升：但无法回馈 Zig

更讽刺的是，在 Bun 宣布离开 Zig 的同时，它的 Zig 分支刚刚实现了4 倍的编译性能提升。

Bun 团队在 X（Twitter）上宣布：通过对 Zig 编译器后端添加"并行语义分析和多 Codegen 单元"，Bun 的编译时间缩短到了原来的四分之一。

但 Bun 团队紧接着表示：

"我们目前没有计划将这一优化提交回上游 Zig 仓库，因为 Zig 有严格的 LLM 代码禁令。"

这揭示了这一政策最尖锐的悖论：如果允许 AI 辅助优化，那么 4 倍的性能提升本可以惠及所有 Zig 用户。但现在，这项改进只能留在 Bun 的私有分支中。

4.3 Zig 核心成员的回应

一位 Zig 核心贡献者在 Ziggit 论坛上解释了这一情况：并行语义分析确实是一个规划已久的特性，但它的合并"对 Zig 语言本身有影响"——也就是说，这不仅仅是一个 AI 生成 vs 人类编写的问题，更涉及语言设计的根本权衡。

这说明，即使没有 AI 禁令，Bun 的这个 PR 也不一定会被接受。但 AI 禁令的存在，让 Bun 团队有了一个明确的"不提交"的理由。

五、开源社区的两难：效率主义 vs 传承主义

5.1 效率主义的逻辑

AI 辅助编程的倡导者有一个强大的论据：软件工程的根本目标是交付可工作的软件，AI 可以显著加速这一过程。

这一观点在商业公司中几乎无懈可击：

• GitHub Copilot 的用户报告代码生产效率提升 55%（GitHub 官方数据）
• 麦肯锡的研究显示，AI 辅助编程可将开发速度提升 30-50%
• 大量公司正在设定目标：未来 X% 的代码由 AI 生成

在"时间就是金钱"的商业逻辑下，不用 AI 就是低效，低效就是劣势。

5.2 传承主义的逻辑

但 Zig 的立场代表了一种不同的价值观——开源社区的传承主义：

"开源社区不只是生产代码的地方，更是培养开发者的地方。"

这种观点有其现实基础：

1. 知识断层风险：如果所有核心贡献都由 AI 完成，人类开发者的知识和经验无法代际传递
2. 社区凝聚力的瓦解：当贡献变得"无门槛"，社区归属感和共同成长文化也会稀释
3. 质量控制的两难：AI 代码的质量在大多数情况下"够用"，但无法达到顶尖水平
4. 伦理和法律的灰色地带：AI 生成代码的版权归属至今没有定论

5.3 Linux 之父的转变 vs Zig 的坚守

有趣的是，当 Zig 选择对 AI 说"不"的时候，Linus Torvalds——Linux 之父——选择了全面拥抱 AI。

据报道，Torvalds 从 2026 年初开始在个人项目中使用 AI 编程辅助。Linux 内核作为世界上最大的开源协作项目之一，对 AI 代码的态度正在从最初的谨慎走向开放。

这两种选择哪个更"正确"？也许都不是——它们反映的是不同规模、不同阶段、不同使命的项目，对效率与传承有不同的权重。

六、代码审查的深层逻辑：为什么"看起来对"不够

6.1 来自前线的证言

Zig 团队在实践中发现了一个令人沮丧的现象：AI 生成的 PR 往往第一眼看起来还不错，但深入审查后会发现：

• 架构决策缺乏上下文：AI 不了解项目的历史债务和未来路线图
• 风格不一致：AI 生成的代码与项目现有代码风格存在微妙差异
• 边界情况被忽视：AI 倾向于处理"happy path"，忽略异常分支
• 过度工程化或过度简化：AI 在复杂度和简洁性之间摇摆

6.2 真实的案例

一位 Zig 核心贡献者在博客中分享了一个具体案例：

一个 AI 辅助生成的 PR 修改了 Zig 标准库中的一个文件，添加了一个看起来"更优雅"的函数实现。代码通过编译，测试也通过了。但经过仔细审查，团队发现：

1. 新实现对某些输入类型会产生不同的行为
2. 这个行为差异在现有测试套件中没有被覆盖
3. 如果这个 PR 被合并，未来的重构可能会因为这个隐式行为而失败

AI 生成代码的"通过测试"≠ 代码正确——这在系统级编程语言中尤其危险。

6.3 代码审查的真正价值

在传统开源项目中，代码审查（Code Review）有多重价值：

代码审查价值分解：
├── 发现 Bug（表面价值）
├── 保证代码风格一致（维护价值）
├── 传递项目知识和上下文（传承价值）← AI PR 无法提供
├── 识别和培养潜在核心贡献者（战略价值）← AI PR 无法提供
└── 建立社区信任和归属感（文化价值）← AI PR 无法提供

当一个 PR 由 AI 生成时，第三、四、五项价值完全消失。代码审查变成了纯粹的"人工编译检查"，失去了其作为社区互动核心环节的意义。

七、实践指南：如何在 Zig 项目中正确贡献

7.1 贡献前的准备工作

如果你对 Zig 项目感兴趣，正确的参与方式是什么？以下是来自 Zig 社区的实践建议：

7.1.1 从理解开始，而非从生成开始

正确路径：
1. 深入阅读 Zig 项目的 issue 和讨论
2. 理解问题的历史上下文（为什么是这样设计的？）
3. 在本地环境中复现问题
4. 思考解决方案，尝试自己编写
5. 如果卡住了，在社区中寻求指导
6. 提交 PR，并在 PR 中解释你的思考过程

7.1.2 与社区建立真实连接

Zig 社区鼓励贡献者先在论坛和 issue 中参与讨论，而不只是提交 PR。Crock 强调：

"不要害怕提问，也不要害怕展示你正在尝试解决问题。即使你最终没有提交 PR，你在讨论中的参与本身就是在为社区做贡献。"

7.2 技术层面的高质量贡献

以下是 Zig 项目在代码风格上的一些具体要求：

7.2.1 错误处理

Zig 没有异常机制，所有错误都必须显式处理：

// ✅ 正确的错误处理方式
const file = try std.fs.cwd().openFile("data.txt", .{});
defer file.close();

// ❌ AI 可能生成的"简化"版本（遗漏了错误处理）
const file = std.fs.cwd().openFile("data.txt", .{});

7.2.2 内存管理

// ✅ 显式且安全的内存管理
const data = try allocator.alignedAlloc(u8, 16, 1024);
defer allocator.free(data);

// ❌ 使用 defer 确保资源释放，避免泄漏

7.2.3 编译期计算

// ✅ 利用 comptime 的力量
fn Matrix(comptime rows: usize, comptime cols: usize, comptime T: type) type {
    return [rows][cols]T;
}

const Mat4x4 = Matrix(4, 4, f32);

7.3 什么样的 PR 会被认真对待

Zig 社区贡献者分享了他们判断一个 PR 质量的几个关键指标：

1. PR 描述说明了"为什么"：不只是描述改了什么，还解释了为什么要这样改
2. 包含历史上下文：引用了相关的 issue 或讨论，说明与项目路线图的关系
3. 展示了学习过程：如果这是一个新手贡献，他们愿意看到尝试和探索的痕迹
4. 风格与项目一致：代码格式、注释风格与项目现有规范匹配

八、对比分析：不同开源项目对 AI 的立场

8.1 主流立场：适度欢迎

大多数开源项目对 AI 辅助持开放态度，但有一些基本要求：

• 内核（Linux）：不禁止 AI 代码，但要求提交者对代码负责
• React：接受 AI 辅助代码，但需要通过严格的测试和质量标准
• TypeScript：AI 生成代码与人类代码一视同仁，标准一致

8.2 少数派：明确拒绝

上文提到的 QEMU、NetBSD、OBS Studio 采取了明确拒绝的立场。

有趣的是，这些项目的拒绝理由各有侧重：

8.3 灰色地带：默许但不鼓励

还有一些项目处于中间地带：

• CPython：没有明确禁止 AI 代码，但维护者对 AI 生成的代码持高度怀疑态度
• Rust 官方：接受了大量 AI 辅助贡献，但核心团队对"AI 优化"保持警惕

九、深度思考：开源在 AI 时代的存在意义

9.1 从"众智"到"机器智能"

传统开源模式建立在"人类集体智慧"之上：

开源协作模型（传统）：
人 A → 想法 → 代码 → PR → 审查 → 合并
人 B → 想法 → 代码 → PR → 审查 → 合并
人 C → 想法 → 代码 → PR → 审查 → 合并
           ↓           ↓
      知识积累    人才成长

这个模型中，人是核心。代码是人的意志的延伸，PR 是人与人沟通的媒介，审查是导师与学徒之间的知识传递。

当 AI 进入这个链条后：

开源协作模型（AI 介入后）：
人 A + AI → 代码 → PR → 审查（无法判断 A 的能力）→ 合并
人 B + AI → 代码 → PR → 审查（无法判断 B 的能力）→ 合并

知识传递和人才发现这两个关键价值开始消失。

9.2 维护者的疲惫与希望

开源社区面临一个冷酷的现实：维护者的疲惫是真实的，而 AI 看起来是一个解决方案。

许多维护者每天要处理数十个 PR，其中大量是低质量的。他们没有时间逐一指导每一个新手。AI 辅助可以帮助他们处理一些"填充工作"。

但 Zig 的教训告诉我们：用 AI 来减少维护工作负担的代价，可能是整个社区文化的瓦解。

9.3 我们真正在保护什么？

在争论中，Peter Steinberger（1Password 联合创始人，"龙虾之父"）提出了一个令人深思的问题：

"LLM 连找 bug 都不可以吗？"

这个问题没有简单的答案。但它揭示了争论背后真正的分歧：

• 一些人认为 AI 的价值在于加速现有工作流
• 另一些人认为 AI 正在重新定义什么是"贡献"本身

Zig 的选择是：在找到更好的平衡点之前，宁可保守一点。

十、未来展望：分歧会如何演进

10.1 可能的发展路径

路径一：两极分化

开源社区可能走向两个极端：

• AI 友好派：以效率为核心，接受 AI 作为标准工具
• AI 拒绝派：以传承为核心，维护人类贡献的纯粹性

两个群体可能逐渐分化，各自维护不同的生态系统。

路径二：规范和标准出现

随着时间推移，行业可能形成对 AI 代码贡献的共识规范：

• 披露要求：明确说明哪些代码是 AI 辅助的
• 责任框架：明确 AI 生成代码的法律责任归属
• 质量门槛：AI 代码需要达到的最低标准

路径三：工具层面的融合

新一代 AI 工具可能提供更好的"透明度"——例如，能够证明代码是基于特定人类意图生成的，从而缓解一些关于"贡献者身份"的担忧。

10.2 对程序员的意义

对于普通程序员来说，这场争论有直接的现实意义：

1. 如果你想在 Zig 等反 AI 项目中贡献：学习如何真正理解一个项目，而不是依赖 AI 的表面生成能力
2. 如果你在 AI 友好的项目中工作：了解你所在社区对 AI 使用的态度和边界
3. 无论在哪里：培养真正理解代码的能力，而不是仅仅能操作 AI 工具

10.3 一种新的可能性

也许，最理想的状态不是"用 AI"或"不用 AI"的二选一，而是：

在需要快速原型和探索时使用 AI，在需要深度理解和传承时依靠人类。

这是一个需要社区共同探索的平衡艺术。Zig 的选择也许过于严格，但它至少指出了一个被效率叙事淹没的重要问题：开源不只是生产代码的地方，它还是培养开发者的地方。

结语：值得认真看见的另一种声音

在 AI 写代码几乎成为大势所趋的当下，Zig 的选择是罕见的"另类"。

它的反 AI 政策是否正确，也许需要很多年才能验证。但有一点是确定的：在所有人都高喊拥抱 AI 的时候，愿意停下来问一句"这样做是否真的对我们有益"的声音，值得被认真听见。

开源社区的核心价值，从来不只是"产出最好的代码"。它更是一个人类知识传递、文化积累和精神传承的容器。Zig 的选择，无论最终成败，都在提醒我们：效率不是衡量一切的标准，成长才是。

也许，当十年后的程序员回顾 2026 年这段历史时，他们会发现 Zig 当时的"逆行"，恰恰是 AI 时代最珍贵的一种理性声音。

参考来源：Zig 官方行为准则（ziglang.org/code-of-conduct）、JetBrains 播客访谈、Loris Cro《Contributor Poker and Zig's AI Ban》、Simon Willison 博客文章《The Zig project's rationale for their firm anti-AI contribution policy》、腾讯新闻机器之心报道、Bun 官方博客。