加载失败
Zig 是一个面向系统编程的低级语言及其自举编译器项目，维护者长期强调 review 不是单纯收代码，而是筛选和培养可信 contributor。争议起点是 Bun（一个 JavaScript runtime）团队提交的 Zig fork 性能 PR，被外界解读为 AI 贡献被拒；但评论指出，这个 PR 还存在语义不一致、非确定性和与 Zig 路线图冲突等问题。文章里常提到的 contributor poker 解释了为什么 Zig 宁可错过一些看似高产的 PR，也不想把维护者时间耗在不透明的 LLM 输出上。讨论还牵涉到 Codeberg（一个 Git 托管平台）上垃圾 PR 减少后是否更容易坚持严格门槛，以及 LLM 是否会重塑开源的协作方式。
支持这一政策的人认为，LLM 贡献在实际中带来的往往不是高质量补丁，而是大量 drive-by PR 噪音：代码充满幻觉、连编译都过不了、CI 也通不过。评论里还反复提到，第一次就上来几千到上万行的 PR 会把维护者的时间吞掉，而后续讨论中一旦发现作者在隐瞒 LLM 使用，更会损害信任。有人把这类行为类比成作弊或“fake it till you make it”，认为开源项目没有义务替任何人消化这种低质量产物。还有人指出，真正的问题不只是代码本身，而是维护者被迫为别人节省思考成本。
另一派强调，Zig 的拒绝不是单纯“反技术”，而是把 review 当作培养可信 contributor 的入口。评论引用 contributor poker 的思路：项目资源有限时，维护者更愿意押注那些会长期参与、能被熟悉和信任的人，而不是只交一次看上去漂亮的 PR。有人把这和 ZeroMQ 的 collective ownership 联系起来，认为健康的 contributor community 比性能数字或功能数量更重要。也有人说 review 过程本身就是和新人建立协调与共同方向的方式，一旦 LLM 把这层人际互动削弱了，OSS 的社交机制就会变弱。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6]
不少人指出，围绕 Bun 的争议里，真正阻挡合并的并不只是“用了 LLM”，而是 PR 本身和 Zig 的路线图冲突。评论提到该 fork 会引入非确定性行为，没有采用 Zig 为 parallel semantic analysis 设计的新语义规则，而且很多性能改动本来就已经在 Zig 自己的计划里。也有人说，这类大 PR 即使来自人类维护者也会被审，因为 compiler 改动牵涉面太广；问题不是 AI 标签，而是代码是否足够正确、可维护、且符合项目长期设计。另一部分评论则质疑一刀切是否公平，认为对老贡献者和核心维护者也禁用 LLM 会显得过于机械。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8] [来源9]
也有许多重度使用者强调，LLM 在熟悉或陌生仓库切换、不同语言语法、git grep、甚至快速搭一个小应用时确实能显著提速。问题在于，真正的瓶颈往往变成验证：你仍然要自己测试、读懂代码、确认 blast radius，否则很容易从“提效”滑到“把思考外包给机器人”。有评论坦承，长期大量使用 Claude Code 之后，自己对项目内部结构的直觉反而变差了，虽然能读代码，但很难像以前那样在脑中形成完整实现模型。也有人说 LLM 更像工具而不是作者；只要人类明确目标并持续纠错，它就能帮忙，但这和让它直接代写 PR 是两回事。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8] [来源9]
另一条更宏观的线索是：开源真正有价值的不是“现成代码”，而是多年使用沉淀出的设计判断、边界案例和被修过无数次的细节。有人说他们现在更看重 software 的 usage depth，因为 docs 和 tests 都能被 LLM 快速伪造，但真实使用中踩过的坑不行；也有人担心 LLM 会让人更愿意在自己的小分叉里重新造轮子，而不是回流上游。评论还提到，LLM access 并不普及、模型质量和可用性会波动，这会进一步把贡献门槛变成“谁有资源、谁会用工具”的问题。总体上，这些讨论都在担心 OSS 的 unit economics 和社区协作方式被重写。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8] [来源9]
contributor poker: 一种开源协作筛选策略，重点评估贡献者是否会长期可靠地参与，而不是只看单个 PR 的代码质量。
vibe coding: 靠提示词和 AI 大量生成代码、再人工修补的开发方式，往往强调速度而弱化对实现细节的把握。
technical debt: 为快速交付埋下的后续维护成本，之后会让修复、扩展和重构变得更贵。
parallel semantic analysis: 编译器中并行处理代码语义的设计，会牵动语言语义和确定性。