Zig 项目为何禁止使用 AI 生成代码？背后是开源社区的生存危机

当大多数开源项目还在忙着接入 GitHub Copilot、Claude 或 ChatGPT 来加速开发时，Zig 编程语言的核心团队却做了一件“不合时宜”的事——全面禁止任何由大语言模型生成的代码或注释进入项目仓库。这不是一时兴起，而是一场经过数月内部争论后，由项目创始人和核心维护者共同签署的正式政策。

“我们不是讨厌 AI，”Zig 核心贡献者 @andrewrk 在一次社区 AMA 中说，“我们讨厌的是，有人把 AI 当成替身，替他学习、替他思考、替他承担责任。”

代码不是终点，人才是

Zig 的代码审查流程，至今仍保留着上世纪开源黄金时代的痕迹：每一个 PR（Pull Request）都要经过至少两位核心成员逐行讨论。不是为了挑错，而是为了确认：这个人，真的理解他写的每一行代码吗？

一位新贡献者提交了一段优化内存分配的代码。维护者没有直接合并，而是问：“你为什么选这个算法？如果在嵌入式设备上运行，它会有什么副作用？”

对方花了三天，翻了三篇论文，补了两份测试用例，回来详细解释了缓存行对齐的原理和实际性能测试数据。最终，PR 被合并了。不是因为代码完美，而是因为这个人，值得信任。

但如果是 AI 生成的代码呢？

“它能写出漂亮的代码，但它不会说‘我其实不太懂这里为什么这么写’，”一位维护者说，“我们见过太多 PR，表面逻辑严密，一问就哑火。我们不想把社区变成一个 AI 代码的垃圾桶。”

Bun 用 AI 写代码，却进不了 Zig 的门

这政策听起来极端，但它的逻辑在行业里有真实对照。

高性能 JavaScript 运行时 Bun，内部几乎全员使用 AI 辅助开发。他们的 CI/CD 流程里，AI 生成的单元测试占比超过 40%。Bun 的团队公开表示：“AI 让我们能更快地迭代，更专注在架构上。”

可即便如此，Bun 团队提交到 Zig 的任何补丁，只要被检测出有 AI 生成痕迹，一律被拒。不是因为代码质量差——事实上，很多 AI 生成的补丁比人类写的还干净。

“我们接受的是人，不是工具的输出，”Zig 维护者明确表示，“Bun 的代码很好，但我们不关心它怎么来的。我们只关心：是谁在背后为它负责？”

开源不是代码超市，是学徒制

开源社区曾经是程序员成长的摇篮。你写第一行贡献代码，可能是在修复一个拼写错误；你第一次提交性能优化，可能被骂得狗血淋头；但你熬过三次被拒，终于被接纳时，你才真正成了这个项目的一部分。

今天，AI 让这一切变得太容易了。你不用懂编译原理，也能写出能通过 CI 的 Zig 代码；你不用读文档，也能生成符合风格的注释；你不用参与讨论，也能拿到“贡献者”头衔。

“我们不是在阻止技术进步，”一位资深贡献者在 Reddit 上写道，“我们是在阻止一种更隐蔽的侵蚀——当所有人都用 AI 写代码，没人再愿意花时间搞懂底层，开源就不再是‘共同建设’，而变成‘集体抄袭’。”

真实案例：一个被拒的 PR，改变了一个人

去年，一位 19 岁的德国学生提交了一个 Zig 标准库的优化 PR。AI 生成的版本流畅、简洁，但被拒绝了。维护者没有直接说“别用 AI”，而是回复：

“你写的这段代码，确实能跑。但你有没有试过在没有内存管理器的裸机上跑它？我们有个测试用例，你去跑一下，把输出贴上来，我们再聊。”

那名学生没放弃。他花了一个月，搭了裸机环境，用 QEMU 模拟硬件，记录了内存访问时序，写了一篇 3000 字的分析报告，附上波形图。最后，他的 PR 被合并了。他现在是 Zig 的长期贡献者，去年还受邀参加了 RustConf 的分享。

“如果不是那次被拒，我可能永远不知道，代码背后还有这么多东西。”他在个人博客里写道。

这不是反 AI，这是反躺平

Zig 的政策，没有禁止使用 AI 作为学习工具。你可以在本地用它查文档、生成示例、解释错误信息——但当你准备提交时，你必须能解释清楚：为什么这么写？为什么不是另一种方式？

这就像学钢琴。你可以用 AI 生成乐谱，但如果你连音阶都弹不准，那你的“演奏”只是录音机的复读。

在 AI 能写 90% 代码的今天，Zig 选择守住那剩下的 10%：人的理解、人的责任、人的成长。

这不是反技术，这是对技术的尊重。

开源的未来，不该属于那些能最快调用 API 的人，而属于那些愿意花时间，把代码从“能跑”变成“懂了”的人。