Andrew Kelley 专访：他为何创建 Zig、禁止 AI 贡献以及将 Zig 从 GitHub 移出

Andrew Kelley 专访：他为何创建 Zig、禁止 AI 贡献以及将 Zig 从 GitHub 移出 — infoq.cn · 10 小时前 · ⚙️ 工程

Zig 由 Andrew Kelley 在 2016 年前后发起，目标是做一门能够替代 C 的系统级编程语言：没有隐藏的控制流，没有隐式的内存分配，泛型与元编程交给编译期执行机制完成，内置交叉编译工具链，并且与 C 代码双向互操作。这场专访围绕三个关键决定展开：他当初为什么要在 C、C++、Rust 之外再造一门语言；为什么在贡献指南里明确拒绝由大语言模型生成的代码与补丁；以及为什么把项目主仓库从 GitHub 迁往 Codeberg 这类非营利托管平台。语言层面的理由是可控性——系统编程最怕看不见的分配和看不见的跳转，Zig 选择把这些代价显式暴露给写代码的人，用编译期计算替代宏和代码生成。关于机器产出的贡献，他的立场集中在责任与协作：提交者必须真正理解自己提交的每一行代码，能解释、能在评审中修改、能长期维护，而批量产出的补丁把理解成本转嫁给了志愿维护者，同时在训练数据来源与许可证上难以追溯，还挤占了贡献本应承担的培养新人的作用。至于迁移，问题不只是工具好不好用，而是开源基础设施的所有权与治理：当托管平台是专有产品、由单一商业公司控制，并且公开代码可能被用于训练商业模型时，项目希望把代码放在治理透明、社区所有的地方。三条线索共享同一逻辑：把控制权、责任和可解释性留在人这一侧。

核心信息

语言设计上的取舍非常明确：Zig 不要隐藏控制流，也不要隐藏内存分配，泛型与元编程交给编译期执行机制完成，不设宏系统与预处理器；同时内置交叉编译，让同一份代码直接产出多个平台的目标文件；与 C 的双向互操作则让既有 C 库可以被直接调用，降低迁移成本。这些选择共同指向系统编程里最贵的东西：可预测的性能与可审计的行为，代价是开发者要自己承担更多显式管理。
贡献政策上，项目明确拒绝由大语言模型生成的代码、文档与补丁。理由包括四点：提交者要能解释并长期维护自己提交的内容；批量生成的低质量补丁会消耗本就有限的志愿维护者评审时间；训练数据来源与许可证难以追溯，会给项目带来法律风险；贡献过程本身是新成员学习语言设计与协作方式的路径，被自动化会削弱社区的人才培养能力。
把主仓库迁出 GitHub，转向 Codeberg 这类非营利托管平台。核心理由不是功能缺失，而是治理与所有权：专有平台由单一公司控制，接口、规则与可用性都可能被单方面改变，平台上的公开代码还可能被用于训练商业模型。迁移的目标是让基础设施归社区所有，决策过程可以被参与者审视，而不是把项目的生死系在一家公司的商业策略上。
专访还触及开源可持续性问题：非营利组织依靠捐赠与赞助维持运转，全职维护者数量有限，评审带宽是真正的稀缺资源。这解释了为什么他愿意在政策上得罪一部分潜在贡献者，也要守住代码的可理解性与评审质量。对一门尚未发布 1.0 的语言来说，生态积累速度与工程质量之间存在长期张力，他选择了后者优先。

💡 为什么值得读: 如果你关心开源治理、工具链所有权与自动化冲击下的协作伦理，这篇专访把语言设计、贡献政策和托管平台迁移串成了一个完整而少见的立场。

✍️ 小编看法: 小编看法：把这三件事放在一起看，它其实是一份关于「谁来决定技术走向」的宣言。语言设计上拒绝隐藏行为，是把复杂度还给写代码的人；贡献政策上拒绝机器批量产出，是把评审带宽当成稀缺资源来保护；迁出 GitHub，是把基础设施的控制权从一家公司手里拿回来。容易被忽略的代价也很实在。门槛会变高。一门新语言的生态本来就脆弱，拒绝一部分潜在贡献者，短期看会放慢文档、第三方库和平台支持的积累速度；更换托管平台还会牵出持续集成、镜像、议题历史、外部集成等一连串迁移成本，社区的注意力会被工程杂务吃掉。但机会同样真实：当多数项目还在比谁的合并请求数量多时，一个敢于明确说不的项目，反而更容易吸引愿意长期投入的人，审查质量与语言稳定性可能成为差异化优势。对整个行业来说，这里提供了一个反例：在自动化工具唾手可得的年代，开源项目的竞争力可能不再取决于产出速度，而取决于信任成本——别人敢不敢把关键系统交给你的代码。下一步值得观察三件事：Zig 能否在 1.0 之前把语言规范与工具链稳定下来，让企业敢用于生产；迁出之后贡献者结构与评审效率是否真的改善，还是被迁移摩擦拖慢；以及这种拒绝机器产出内容的政策，会不会被更多基础设施项目效仿，慢慢形成一种新的社区规范。技术选择从来不只是技术，它同时是在回答：这门语言、这个社区，最终属于谁。

🏷️ Zig, Andrew Kelley, AI contributions, GitHub