Bun 在自己的 Zig fork 里做了一组编译器相关改动，让 Bun compile 获得约 4 倍性能提升。

按开源世界的正常剧本，这应该是一个好故事：有人解决了性能问题，补丁回流上游，大家一起受益。

但现在卡住了。

Bun 表示，目前不计划把这组改动 upstream 到 Zig。原因不是 Zig 已经审了补丁并拒绝，而是 Zig 对 LLM-authored contributions 有非常硬的禁令。Bun 的开发方式又大量使用 AI 辅助。更微妙的是，相关材料提到 Bun 已在 2025 年 12 月被 Anthropic 收购，这让双方的工程文化差异变得更刺眼。

这条线索把旧争议往前推了一步。它补强的不是“Bun 有多快”，而是 Zig 为什么敢为一条反 AI 协作规则付出性能代价。

发生了什么：4 倍优化没有进入 Zig 上游

核心事实很短：

问题当前信息
谁做了优化Bun 在自己的 Zig fork 中做了改动
优化效果Bun compile 约 4 倍提速
涉及改动parallel semantic analysis、LLVM backend 的 multiple codegen units 等
是否回流 ZigBun 目前不计划 upstream
主要障碍Zig 禁止 LLM 参与 issues、PR 和 bug tracker comments
不能误读的点目前不是 Zig 审核后拒绝了补丁，而是 Bun 暂不提交上游

Zig 的规则比很多项目更硬。

issues 不能用 LLM 代写。PR 不能用 LLM 生成。bug tracker comments 也不能用 LLM，包括翻译。语言上，Zig 鼓励英文，但不强制；你可以用母语发，让别人自己决定是否用工具翻译。

这不是一句“别拿 ChatGPT 写代码”那么简单。

它等于把 LLM 挡在协作区外。不是只挡最终代码，也挡问题描述、讨论文本和修复解释。

为什么重要：争议不在一段补丁，而在开源项目怎么分配审核成本

Zig Software Foundation 社区副总裁 Loris Cro 给出的解释，比普通的“AI 代码质量差”更有说服力。

他的核心判断是：成功的开源项目迟早会遇到一个时刻，PR 数量超过维护者处理能力。

维护者最缺的不是代码。

缺的是审核时间、讨论耐心、设计判断、长期责任。

按最短期 ROI 算，一个项目应该只收成熟补丁，拒绝所有需要反复打磨的贡献。但 Zig 没这么做。它愿意花时间帮新人把贡献合进去。

原因也很现实。

一次 PR 审核，不只是看这段代码能不能跑。它也在观察一个人：能不能理解项目风格，能不能接受反馈，能不能解释取舍，能不能以后继续承担维护责任。

Loris 把这个叫 contributor poker。那句老话是：you play the person, not the cards。

打的是人，不是第一手牌。

LLM 把这个模型搅乱了。

如果一个 PR 主要由 LLM 生成，哪怕表面很漂亮，维护者投入的审核时间也未必会换来一个更可靠的合作者。你审完了代码，却没有真正培养出一个理解项目的人。下一次，对方可能还是扔来一包 AI 产物。

这才是 Zig 禁令最硬的地方。

它不是在证明 AI 一定写烂代码。它是在说：开源协作的核心资产不是代码库存，而是可信的人。

谁受影响：维护者和重度 AI 开发团队最先撞墙

受影响最大的不是普通用户。

普通用户短期只会看到一个结果：Bun 自己可能继续享受更快编译，Zig 上游暂时吃不到这组优化。

真正被夹在中间的是两类人。

一类是开源维护者。尤其是编译器、语言、数据库、运行时这类底层项目。它们的代码寿命长，设计取舍重，风格一致性很值钱。它们怕的不是多一段代码，而是多一批需要人肉验货的半成品。

另一类是重度 AI 辅助开发团队。它们追求速度，写代码、补测试、改实现都希望借助模型。这套流程在公司内部可以跑，因为责任链条清楚：出了问题，公司自己背。

但进入开源上游就不一样了。

开源维护者没有义务替你的 AI 工作流兜底。你省下来的生成时间，可能变成别人增加的审核时间。

“天下熙熙，皆为利来。”放到这件事上，就是谁拿走了 AI 提效，谁承担了验证成本。很多 AI 编程争论绕不开这一点：收益和成本经常不在同一个人身上。

我的判断：Zig 这次不是保守，是在守协作边界

我不太买账一种说法：Zig 因为反 AI，所以挡住了先进生产力。

这说法太省事。

Bun 的 4 倍优化当然诱人。性能摆在那里，谁都看得见。Zig 因为政策原因可能错过一组有价值的改动，这个代价也是真的。

但开源项目不是代码收购站。

尤其是 Zig 这种底层语言项目。它要维护的不是一个功能清单，而是一套长期品味：语义怎么定，编译器怎么演进，错误怎么处理，抽象边界放在哪里。

这些东西不是 PR 数量堆出来的。

Bun 的处境也能理解。它是产品导向的 runtime 项目，目标是快、稳、能交付。背后又和 Anthropic 绑定，重度使用 AI 辅助开发并不奇怪。它为自己的目标维护 fork，也谈不上原罪。

问题在于，Bun 的最优解不一定是 Zig 的最优解。

公司项目可以把 AI 当加速器。底层开源项目更像一座长期修的桥。桥不是不能用新机器修，但每一根梁最后都得有人签字、解释、维护。

AI 让代码便宜，信任变贵。

这句话听起来冷，但很接近现实。

过去，开源维护者面对的是“代码稀缺”。有人愿意修 bug、补测试、改后端，哪怕不成熟，也可能是社区扩张的开始。

现在，LLM 把提交门槛打低了。PR 可以更多，文字可以更顺，解释可以更像样。但维护者的大脑没有扩容。审核仍然要人做，责任仍然要项目背，设计判断仍然靠长期经验。

于是维护者会重新算账。

审一个新人 PR，可能是在培养未来维护者。审一个 AI-heavy PR，可能只是在替别人验证一次性输出。

早期报业遇到廉价印刷时，也有类似结构。纸面内容突然变多，不代表编辑部更轻松。筛选、署名、责任、信誉，反而更贵。这个类比不完全一样，但它照出了同一个问题：生产成本下降之后，治理成本会上升。

接下来真正该看什么

这件事后面有三个观察点。

一是 Bun 会不会把这组优化拆成更可审核、更可归责的形式。比如明确哪些代码由人主导，哪些设计可以由维护者独立复核。Zig 禁的是 LLM 参与贡献，不是拒绝所有来自 Bun 的工程经验。

二是 Zig 会不会在政策上留出非常窄的例外。比如对工具生成、机械重构、翻译辅助做更细区分。现在的规则胜在清楚，代价是硬。硬规则能保护维护者，也会挡住一些本来有价值的外部工作。

三是其他开源项目会不会跟进类似边界。尤其是那些维护者人数少、用户很多、底层责任重的项目。它们未必会像 Zig 一样一刀切，但一定会开始问同一个问题：AI 生成的贡献，到底由谁负责？

我倾向于认为，Zig 这次少见地把话说在了前面。

很多项目现在还在享受 AI 贡献带来的热闹。issue 更多，PR 更多，社区看起来更活跃。但活跃不等于健康。维护者被淹没以后，项目会变慢，争论会变差，最后连好贡献也会被一起挡在门外。

Zig 的禁令难看，硬，甚至会错过一些性能红利。

可它至少承认了一个行业现实：代码可以批量生产，信任不能。