Zig项目为什么全面禁止AI贡献？贡献者扑克理论深度解析

哎李博，最近我看到一个特别反直觉的事儿，你知道Zig吧？ 嗯，系统编程语言嘛，怎么了？ 他们居然全面禁止AI贡献。不光PR不能用LLM生成代码，连issue评论、bug tracker、甚至翻译都不让用。我第一反应是——这也太极端了吧？ 哈哈，你这个反应很正常。但我跟你说，我仔细研究过他们的理由之后，觉得这事儿没那么简单。甚至可以说，这是我今年见过最清醒的技术决策之一。 真的假的？你平时不是最爱用Cursor写代码的吗，怎么突然站他们了？ 诶，我个人用AI写代码是一回事，开源项目的协作模式是另一回事。这两个问题的逻辑完全不同，你听我慢慢说。 好好好，洗耳恭听。 先说他们为什么连翻译都禁。你可能觉得矫枉过正对吧？但你想，一旦你允许'部分使用LLM'，这个边界就完全模糊了。 谁来判定一段代码是LLM辅助还是LLM生成？谁来审计一条评论有没有被GPT润色过？根本没法查。所以他们选了最简单粗暴的方案——一刀切。 嗯，这个我能理解。我们做产品也是，灰度规则越复杂，执行越走样。但这执行得了吗？你怎么知道别人偷偷用了？ 执行当然不可能完美。但他们传递的信号比政策本身更重要——我们要的是你的大脑，不是你的prompt。他们甚至说你可以用母语发帖，不用写完美英语，要的就是真实表达。 哎等等，说到这个我想起一件事。Bun不是用Zig写的吗？那个超快的JavaScript运行时。后来被Anthropic收购了，然后就开始大量用AI开发。 对！这个冲突简直是2025年开源圈最精彩的一出戏。你听这个剧情—— Bun用Zig写出了最成功的项目，被AI公司收购，用AI大幅改进了Zig的编译器，实现了4倍编译性能提升。然后发现这些改进没法合并回Zig上游。 4倍？！这也太香了吧！就因为LLM禁令不让合？ 你看，这就是最精彩的地方。Zig核心团队说了——即使没有LLM禁令，这个补丁也不会被接受。 啊？为啥？ 因为Bun的方案是把语义分析阶段并行化来加速编译。但并行化会引入执行顺序的不确定性，可能改变语言的行为表现。 等会儿让我想想……就是说跑得快了，但结果可能不一样了？ 差不多这个意思。Zig的核心哲学就是'无隐式行为'，一切都要确定、可预测。你给我4倍速度，但代价是语义可能不确定，对Zig来说这笔账根本算不过来。 所以本质上不是AI不AI的问题，是两个团队对语言未来的愿景不一样。 Bun要的是一个够快的编译器，Zig要的是一个语义正确的语言。这是路线分叉，不是技术分歧。 好吧，这我服了。那你刚才说他们禁AI有一套完整的哲学，具体是什么？ 这个才是真正炸裂的部分。Zig社区VP Loris Cro提了一个概念叫'贡献者扑克'，Contributor Poker。我觉得这是今年对开源协作本质最精辟的阐述。 贡献者扑克？什么意思？ 核心逻辑是这样的——成功的开源项目最终都会收到超出处理能力的PR。Zig面对这个问题，选择的不是快速拒绝不完美的PR，而是花时间帮助新贡献者把PR做好。 因为他们重视的是贡献者本身，不是贡献内容。每个贡献者都是核心团队的一笔投资。审查PR的主要目标不是合并代码，而是培养可信赖的长期贡献者。 哦！就像带新人。我花三小时帮你改代码，不是为了这个PR，是为了你下次能独立搞定。 对对对！就像教授花三小时批改论文。目的是让学生成长。但如果论文是ChatGPT写的—— 那教授的时间就白费了！因为没有任何学生从反馈中成长。 Bingo。这就是为什么叫'扑克'——看人不看牌。一个粗糙但展现出理解力的PR，比一个完美但来路不明的PR更有价值。 等等，我突然想到一个更狠的问题。如果你的PR主要是LLM写的，维护者为什么不自己用LLM解决同样的问题？ 这个问题是真的杀手级。 你能prompt出来的东西，维护者也能prompt出来。而且维护者对项目上下文的理解远超外部贡献者。 所以LLM辅助的贡献在很多情况下不是在帮忙，而是在制造额外的审查负担。你以为你在贡献代码，其实你在给人家加班。 哈哈哈这个扎心了。那你觉得这个模式适用于所有开源项目吗？ 说实话不一定。很多项目缺的就是代码不是人，没有培养贡献者的余裕。但Zig的选择至少证明了一件事—— 在AI浪潮中，'不用AI'本身也可以是一种深思熟虑的技术决策，不仅仅是恐惧或保守。 嗯，我觉得Zig问了一个特别根本的问题——开源到底是为了写出更多代码，还是为了培养更多能写代码的人？ 这个答案可能会决定开源运动在AI时代是进化还是异化。说真的，我现在也没有确定答案，但至少Zig让我重新想了一遍这个问题。