Contributor Poker and Zig’s AI Ban

贡献者扑克与 Zig 的 AI 禁令

Loris Cro April 29, 2026 • 6 min read

Loris Cro 2026年4月29日 • 6分钟阅读

You should always change doors when playing Monty Hall. During my tenure at the Zig Software Foundation, I’m having the opportunity to learn many interesting things about software. The one I want to share today is a key piece of understanding for any open source project big enough to attract contributors.

在玩“蒙提霍尔问题”（Monty Hall problem）时，你总是应该选择换门。在 Zig 软件基金会任职期间，我有机会学到了许多关于软件的有趣知识。今天我想分享的这一点，对于任何规模大到足以吸引贡献者的开源项目来说，都是至关重要的理解。

Open source development comes with a nuanced set of pros and cons, and it’s up to you to leverage the good that comes from it in order to compensate for having to deal with the bad, of which there’s plenty. First and foremost, open source is incompatible with many business models and it’s based on the idea that you have to give away something of value for free. Of course in exchange for giving stuff out for free, you also get stuff for free, mostly in the form of code contributions.

开源开发伴随着一系列微妙的优缺点，你需要利用其带来的好处来弥补不得不面对的坏处，而坏处往往也不少。首先，开源与许多商业模式不兼容，它基于这样一个理念：你必须免费提供有价值的东西。当然，作为免费提供东西的交换，你也会免费获得东西，主要是以代码贡献的形式。

Unfortunately not only do those contributions (let’s call them PRs from now on) not pay the bills, they themselves are often a source of extra labor and friction. In fact it’s pretty common that it would take a maintainer less effort to implement a given change directly, rather than work with a PR author to get their code to a mergeable state.

不幸的是，这些贡献（从现在起我们称之为 PR）不仅不能支付账单，它们本身往往还是额外劳动和摩擦的来源。事实上，维护者直接实现某项更改所花费的精力，往往比与 PR 作者协作以使其代码达到可合并状态所花费的精力要少，这种情况非常普遍。

Based on what I mentioned so far, open source development seems a pretty shitty deal, and yet I firmly believe it has the potential to produce higher quality products and for significantly cheaper than most alternative development models; you just have to get good at the open source game. I’ve already written on the subject in general, but today I’ll focus on one specific aspect: contributor poker.

基于我目前所提到的，开源开发似乎是一笔相当糟糕的交易，但我坚信它有潜力以比大多数替代开发模型低得多的成本生产出更高质量的产品；你只需要擅长开源这场游戏。我已经写过关于这个主题的概述，但今天我将专注于一个特定的方面：贡献者扑克。

Contributor poker

贡献者扑克

In successful open source projects you eventually reach a point where you start getting more PRs than what you’re capable of processing. Given what I mentioned so far, it would make sense to stop accepting imperfect PRs in order to maximize ROI from your work, but that’s not what we do in the Zig project. Instead, we try our best to help new contributors to get their work in, even if they need some help getting there. We don’t do this just because it’s the “right” thing to do, but also because it’s the smart thing to do.

在成功的开源项目中，你最终会达到一个阶段，即收到的 PR 数量超过了你的处理能力。鉴于我刚才提到的情况，为了最大化工作投资回报率（ROI），停止接受不完美的 PR 是合理的，但这并不是我们在 Zig 项目中所做的。相反，我们尽最大努力帮助新贡献者完成他们的工作，即使他们需要一些帮助才能达到目标。我们这样做不仅是因为这是“正确”的做法，也是因为这是明智的做法。

Contributing to an open source project is an iterated game and the majority of the value that a contributor can bring to a project lies in the later iterations. In other words, you initially invest some energy (i.e. place a bet) to onboard a new contributor, and you hope that later on that relationship starts paying you back as the contributor becomes more trusted and prolific.

向开源项目贡献代码是一个迭代博弈，贡献者能为项目带来的大部分价值在于后续的迭代中。换句话说，你最初投入一些精力（即下注）来引导一位新贡献者，并希望随着贡献者变得更受信任且产出更高，这种关系在未来能给你带来回报。

The reason I call it “contributor poker” is because, just like people say about the actual card game, “you play the person, not the cards”. In contributor poker, you bet on the contributor, not on the contents of their first PR.

我之所以称之为“贡献者扑克”，是因为就像人们评价真正的纸牌游戏时所说的那样，“你玩的是人，而不是牌”。在贡献者扑克中，你押注的是贡献者，而不是他们第一个 PR 的内容。

Having an explicit understanding of this dynamic has netted the Zig project a huge amount of value over time. Building a compiler toolchain from the ground up is a huge scope that would have been impossible to cover without significant help from contributors. Thanks to contributors like Ryan Liptak, Zig users can now enjoy the luxury of setting the executable icon (and more) on Windows because Zig can compile Windows resource script (.rc) files. Another notable example are the contributions from Frank Denis. I wouldn’t even know where to begin to give a monetary value to the work he has done in std.crypto.

对这种动态有明确的理解，随着时间的推移，为 Zig 项目带来了巨大的价值。从零开始构建编译器工具链是一个巨大的工程，如果没有贡献者的大力帮助，是不可能完成的。多亏了像 Ryan Liptak 这样的贡献者，Zig 用户现在可以享受在 Windows 上设置可执行文件图标（以及更多功能）的便利，因为 Zig 可以编译 Windows 资源脚本（.rc）文件。另一个值得注意的例子是 Frank Denis 的贡献。我甚至不知道该如何用金钱来衡量他在 std.crypto 中所做的工作。

Growing pains

成长的烦恼

In the early days of Zig it was possible to invest on every new contributor, but now the project has grown to the point where the amount of incoming PRs far exceeds the amount of energy core contributors have at their disposal to play contributor poker. In practice this means that there have been instances of good PRs that have gone un-reviewed for extended periods of time, potentially causing valuable contributors to lose interest in contributing to Zig.

在 Zig 的早期，我们有可能对每一位新贡献者进行投入，但现在项目已经发展到收到的 PR 数量远远超过了核心贡献者能够投入到“贡献者扑克”中的精力。在实践中，这意味着出现了一些好的 PR 在很长一段时间内没有得到审查的情况，这可能会导致有价值的贡献者对向 Zig 贡献代码失去兴趣。

This is something we have mentioned in our yearly financial reports, and more importantly it’s an issue we’re actively aware of, and that we hope to solve (or at least mitigate) in the future. Unfortunately, not only is this an inherently hard problem to tackle, but AI has made things worse.

这是我们在年度财务报告中提到过的问题，更重要的是，这是一个我们积极意识到并希望在未来解决（或至少缓解）的问题。不幸的是，这不仅是一个本质上难以解决的问题，而且人工智能让情况变得更糟了。

Banning AI contributions

禁止 AI 贡献

There has been a lot of speculation about why the Zig project bans AI contributions, but now that you understand the importance of contributor poker, it’s easy to see why we do it. To be able to provide impactful work a contributor needs to be familiar with the codebase and the problem space, and they need to be trusted by the core team to have thought through all the changes introduced by their PRs in order to strive for an optimal approach, rather than just submitting a random solution that happens to pass CI.

关于 Zig 项目为何禁止 AI 贡献，外界有很多猜测，但现在你理解了“贡献者扑克”的重要性，就很容易明白我们为什么要这样做。为了提供有影响力的工作，贡献者需要熟悉代码库和问题领域，并且需要得到核心团队的信任，确保他们已经深思熟虑了 PR 中引入的所有更改，以追求最优方案，而不是仅仅提交一个碰巧通过 CI（持续集成）的随机解决方案。

Additionally, as part of the process of becoming more trusted, contributors are expected to be responsible for the code they submit for a while more after their code is merged. Nobody is perfect and sometimes issues are discovered after the fact. Follow up discussions to decide how to course-correct are another example of the value of having an iterated relationship with engineers that have built significant insight on a given problem space.

此外，作为获得更多信任过程的一部分，贡献者被期望在代码合并后的一段时间内，继续对自己提交的代码负责。没有人是完美的，有时问题会在事后被发现。后续讨论如何纠正方向，是与那些在特定问题领域积累了深刻见解的工程师建立迭代关系所带来的价值的另一个例子。

This is important because users of Zig have in turn bet on the Zig Software Foundation to provide them with a language and toolchain that strives to be as good as we can make it.

这一点很重要，因为 Zig 的用户反过来也押注于 Zig 软件基金会，希望我们能为他们提供一种我们尽力做到最好的语言和工具链。

Unfortunately the reality of LLM-based contributions has been mostly negative for us, from an increase in background noise due to worthless drive-by PRs full of hallucinations (that wouldn’t even compile, let alone pass CI), to insane 10 thousand line long first time PRs. In-between we also received plenty of PRs that looked fine on the surface, some of which explicitly claimed to not have made use of LLMs, but where follow-up discussions immediately made it clear that the author was sneakily consulting an LLM and regurgitating its mistake-filled replies to us.

不幸的是，基于大语言模型（LLM）的贡献对我们来说大多是负面的。从充斥着幻觉、毫无价值的“路过式”PR（甚至无法编译，更不用说通过 CI）带来的背景噪音增加，到长达一万行的疯狂的首次 PR。在此期间，我们也收到了许多表面上看起来不错的 PR，其中一些明确声称没有使用 LLM，但后续讨论立即表明，作者是在偷偷咨询 LLM，并将其中充满错误的回应照搬给我们。

To be clear, the point here is not to say that we believe that… 需要明确的是，这里的重点并不是说我们认为……