一句话看懂：Zig 语言创始人 Andrew Kelley 在 JetBrains 访谈中解释了项目彻底拒绝 AI 生成代码贡献、并从 GitHub 迁移到 Codeberg 的原因：前者会拖垮代码质量与审查效率，后者则源于持续集成服务的持续故障与激励机制错位。
事件核心：发生了什么
Andrew Kelley 是 Zig 语言的创建者，2018 年辞职全职开发该项目。Zig 目前被 Ghostty、低延迟金融数据库 TigerBeetle 以及 Uber 的交叉编译基础设施采用。在近期一次 JetBrains 采访中，他明确表示 Zig 不接受 AI 贡献，理由是固定的人力无法随代码量增长而扩展，且这类提交几乎都是低质量内容——“它们甚至带来负价值”，审查者需要耗费时间判断贡献者是否真正理解问题，而使用 AI 的人往往属于“过客式贡献者”，不会成长为长期维护者。
与此同时，Zig 将代码仓库从 GitHub 迁至德国非营利组织旗下的 Codeberg。Kelley 称 GitHub Actions 的持续集成开始无故失败，迁移后 CI 恢复正常。他认为非营利组织比追逐季度增长的初创公司更稳定。
为什么重要
这场争论的实质不是 Zig 与 Rust 的语言之争。Kelley 在评论 Bun 借助 AI 代理将代码库从 Zig 重写为 Rust 时强调，分歧在于两个项目价值观体系不同：一边用 AI 批量移植与验证代码，一边把有限的代码审查时间视为对潜在核心贡献者的“带教投入”。这提供了一个少见的对照样本：当大部分开源项目还在摸索 AI 贡献政策时，已有项目用明确规则把 AI 排除在协作流程之外。GitHub 性能下降与 AI 工作负载激增在时间上的重合，也让“AI 生成代码冲击基础设施”成为可观察的行业现象，尽管目前公开信息显示这一因果关联尚未被平台方正式确认。
对用户/开发者/创作者的影响
对开发者而言，向开源项目提 PR 前应先确认对方是否有 AI 使用政策，Zig 的做法可能被更多中小型项目参考。依靠 AI 代理批量产出补丁、再“洗白”聊天记录的做法，在审查严格的社区中会直接失效，甚至影响个人信誉。对工具链与平台方，这意味着托管平台的稳定性、CI 成本与 AI 流量治理将越来越成为选型因素，Codeberg 这类非营利代码托管可能获得更多关注。对企业采购方，若产品依赖 Zig 生态，其社区治理风格与贡献者质量管控是评估长期维护风险的参考项。
值得关注的后续
一是 Zig 迁移 Codeberg 后 CI 与协作效率能否持续稳定，是否会带动其他项目跟进迁移；二是 Bun 用 AI 重写代码库的长期质量表现，将成为验证两种路线优劣的实际案例；三是 GitHub 是否就 CI 故障与 AI 工作负载压力给出更明确的说明或调整策略。
来源：InfoQ CN
