Bun 在自己的 Zig fork 里做了一组优化，让 Bun compile 获得约 4 倍性能提升。

改动方向包括 parallel semantic analysis，以及 LLVM backend 中多个 codegen units。按工程结果看，这是一组很有价值的改动。但 Bun 表示，由于 Zig 严格禁止 LLM-authored contributions，目前不计划把它 upstream 到 Zig。

这就是反常点：AI 辅助带来了明确收益，收益却暂时卡在上游门外。

我更在意的不是“Zig 是否反 AI”。这个说法太粗。Zig 的规则针对的是项目协作入口：issue、PR、bug tracker 评论，甚至包括翻译。它要管的不是开发者电脑里装了什么工具，而是维护者每天面对的协作成本。

Zig 的禁令硬在入口，不是口号

Zig 的行为准则写得很直接：

  • No LLMs for issues.
  • No LLMs for pull requests.
  • No LLMs for comments on the bug tracker, including translation.

后面还有一个细节：英文被鼓励，但不是强制。贡献者可以用母语发言，让其他人用自己选择的翻译工具理解。

这个细节很关键。Zig 不是在说“非英语贡献者别来”，而是在说“不要把 LLM 生成内容塞进项目协作入口”。

和很多开源项目相比，这条线划得更硬。常见做法是要求披露 AI 辅助，或者要求作者对 AI 生成代码负责。Zig 选择了另一条路：先降低维护者识别成本。

对象处理方式直接影响我的判断
Zig禁止 LLM 参与 issue、PR、bug tracker 评论及翻译入口更窄，审核噪音更少更像治理规则，不是技术路线宣言
Bun使用 Zig，并维护自有 Zig fork优化可先服务 Bun 自身商业产品会优先保交付
许多开源项目接受披露或作者担责能吃到效率红利，也要承担甄别成本更依赖维护者经验

这三种选择没有哪一种天然正确。限制越少，贡献入口越宽；入口越宽，维护者越容易被低质量提交淹没。开源项目最缺的，往往不是代码想法，而是能长期审代码、解释设计、承担后续维护的人。

这才是 Zig 规则的底层约束。

Bun 拿到收益，但回流上游变难

Bun 的位置比较特殊。它是用 Zig 写成的 JavaScript runtime，也是 Zig 生态里能见度很高的项目之一。Bun 在 2025 年 12 月被 Anthropic 收购后，重度使用 AI 辅助并不意外。

这次争议要把边界说清。

约 4 倍提升，指的是 Bun compile，不是 Zig 语言整体性能提升。Bun 也没有说这组优化已经被 Zig 拒绝合并。它的说法是：因为 Zig 禁止 LLM-authored contributions，目前不计划 upstream。

这一区别很重要。现在能确认的是，Bun 基于上游规则预判了回流成本；还不能说 Zig 已经审过并拒掉了这组代码。

对 Bun 用户来说，短期影响可能不大。优化在 Bun 自己的 fork 里，可以先服务 Bun 的构建速度。真正的影响在更后面：如果这类改动长期留在 fork 里，Bun 团队就要承担更多维护成本，上游 Zig 用户也未必能直接吃到这部分收益。

对 Zig 用户来说，也不必把它理解成“Zig 不要性能优化”。更准确的限制是：只要改动进入 Zig 的协作流程，就要符合 Zig 对贡献来源和协作方式的要求。

这里的冲突很现实：商业团队要速度，开源上游要可维护的信任关系。两边都不荒唐，只是优化目标不同。

维护者审 PR，是在押注人

Zig Software Foundation 社区副总裁 Loris Cro 在《Contributor Poker and Zig's AI Ban》里给出的解释，是这件事最有价值的部分。

他的核心意思是：成功的开源项目迟早会遇到 PR 过载。最省事的办法，是只接受接近完美的 PR，把不成熟的贡献挡掉。但 Zig 不这么做。Zig 会尽力帮助新贡献者把工作推进去，因为这不只是“正确”，也是“聪明”。

他把这叫 contributor poker。像打牌一样，看的不是第一手牌面，而是人。放到开源里，就是赌贡献者本人，不是赌他第一份 PR 的代码质量。

这句话解释了 Zig 为什么对 LLM 这么敏感。

如果一个 PR 主要来自 LLM，维护者花时间审查、讨论、解释，未必能培养出一个更理解项目的人。最坏的情况是，维护者变成了模型输出的验收员。代码看似更快出现，维护成本却没有一起下降。

这对两类人最直接。

开源项目维护者要做的是提前写清规则。能不能用 LLM？能用到哪一步？是否必须披露？翻译、issue、测试、文档算不算？如果不写清，后面每个 PR 都会变成一次临时判案。

使用 AI 辅助编程的开发者要做的是调整提交方式。给 Zig 这类项目贡献时，不能只交一个“看起来能跑”的补丁。你要能用自己的话解释问题、设计、取舍、测试和后续维护。解释不了，就别急着提交。

这不是道德洁癖，而是协作成本核算。

接下来最该看两件事。

观察点如果发生意味着什么
Bun 是否长期维护这条 Zig fork 优化线优化留在 fork 内，不回流上游性能收益存在，但维护成本由 Bun 承担
Zig 是否细化“AI 辅助但由人负责”的边界出现更细规则入口禁令可能从一刀切变成可执行分类

目前看，Zig 的选择很清楚：它宁愿错过一部分 AI 辅助贡献，也要保护维护者时间的投资方向。

这条路会有代价。比如 Bun 这样的项目，可能把有效优化留在自己的 fork 里。但反过来，如果所有项目都把维护者当成 LLM 输出的免费验收层，开源协作也会被慢慢掏空。

代码越来越容易生成，可信贡献者没有一起变多。这就是 Zig 这条硬规则真正戳中的地方。