10年未发1.0、全面禁止 AI 编程：Zig创始人的“反商业”生存法则

Zig 是一门试图成为现代版 C 语言替代品的编程语言。相比 C，它希望在保持底层控制能力的同时，提供更好的内存安全能力。这个项目目前由一个非营利组织和一群开源贡献者共同维护。 但在 AI 编程大热的今天，他们选择站到另一边：Zig 已经明确禁止提交 AI 辅助生成的代码。在 JetBrains 的一档播客中，Zig 基金会主席 Andrew Kelley 对这类贡献的评价非常不客气：AI 辅助贡献“几乎总是垃圾”。 Kelley 说，有人给他们提交的贡献“完全没有价值”。更麻烦的是，这些贡献不是零价值，而是负价值，因为它们会消耗维护团队本就稀缺的代码审查时间。Zig 的 pull request 数量已经超过了审查者能够处理的范围。录制播客时，Kelley 提到，Zig 还有 200 个开放的 pull request，而这些 AI 生成的“垃圾贡献”，只会让整个团队更慢。他说：“我们浪费了所有人的时间。” 这和大公司对 AI 写代码的态度形成了鲜明对比。过去一段时间，不少科技巨头都在设定激进目标，宣称公司内部已经有多少代码由 AI 写成，或者未来应该有多少代码交给 AI。但 Zig 并不是一家背着效率指标狂奔的上市公司。Kelley 说，对 Zig 来说，“指导和培养”本身就是核心使命的一部分。因此，AI 贡献不但没有帮上忙，反而会破坏这个目标。他说：“我们都在努力成为更好的程序员。那些提交 AI pull request 的人，并没有帮助这个目标。” 在这期节目中，Andrew Kelley 还详细回顾了创建 Zig 的动机、非营利基金会的运营、对 AI 的强硬态度，以及为何坚持十年不发 1.0 版本。 本文基于该播客视频整理，经 编辑。 核心观点如下：非营利组织作服务比用初创公司或大型企业更稳定，那些大公司总在追逐下一个目标，努力让下季度利润更高，而非营利只是想继续做好它在做的事。如果要我界定“只接受好的 AI PR”，那我还得去当裁判。如果一刀切地什么都不要，执行起来非常简单。任何 C 能做到的事情，Zig 都能做到，而且做得更好，少了很多 Footgun，出了问题也更容易调试。甚至可以说，Zig 拥抱 C 的程度胜过了 C 自己拥抱自己。委员会或更民主的流程出于合作的意图更倾向于找出妥协，我承认这有社会性上的好处，但代价就是难以保持项目的连贯愿景。如果你在一家没有灵魂的大公司，那就别再拼了，下午五点就回家，干点别的，不用那么使劲。为什么构造 Zig？Vitaly：我们已经有 C、C++、Rust、Go ，你为什么决定做 Zig？ Andrew：有意思的是，你列出的这几种语言，恰恰就是我刚开始做 Zig 之前，用来构建数字音频工作站的几个语言。每换一种语言，我都会撞上一堵看似无法逾越的墙。最后我得出结论：不是我有技术短板，是语言本身有问题。就是在那之后，我萌生了创造一门新语言的狂妄想法。 我先试着在浏览器里用 JavaScript 做，但很快就发现层次太高了，我根本触碰不到能让这款音频工作站提供一流用户体验的底层能力。于是我直接扔掉这条路，投入原生编译语言。 接着我试了 Go。Go 的问题有两个：一，想调用现有的 C 库来创建窗口、按钮什么的，体验非常糟糕；二，垃圾回收器的问题。做音频处理有一个硬实时截止时间，如果你不能在精确的时间窗口内处理完，就会产生杂音或卡顿，这对现场演出软件来说绝对无法接受。所以 Go 也出局了。 然后我转向 Rust，那时 Rust 还没到 1.0。我拼命地写代码想要满足 Rust 的规则，可一旦勉强满足了，哪怕做一点点小改动，都会引发一连串编译错误，彻底阻断进展。我记得花了整整一个月去折腾字体渲染，结果卡在那儿寸步难行，沮丧得不行，就放弃了 Rust，换到了 C++。 用 C++ 一开始确实感觉效率高多了。但很快，一个小小的拼写错误，一个不起眼的失误，就会造成内存破坏 bug，让我一调就是好几周。这种反复出现的小错误以周为单位吞噬我的时间，对于这么大难度的项目来说，实在太慢了。之后我甚至试过“C 风格的 C++”，就是用 C++ 编译器编译，但链接时用 C 链接器，一旦使用花哨的 C++ 特性就报错。即便这样，还是动辄伤到自己。就在那时，我对自己说：我可以做得更好。比 C++ 好，比 Rust 好，比 Go 好，比 JavaScript 好，比 D 语言好。这就是我的狂妄。 Vitaly：现在 Zig 用来做什么？它解决什么问题？ Andrew：当你想完全掌控计算机，不想留下任何性能尾巴，要榨取最佳性能和最低内存占用，最终打磨出引人入胜的用户体验时，就会用 Zig。就在开始 Zig 之前，我为自己确立了一条新哲学：不再在用户体验上妥协。我再也不会说“因为我用 Go，所以我得接受这个限制”。如果为了交付最好的体验必须更换工具链，我就换，哪怕自己创造一个。 对我来说，这在当时是一种完全不同的编程思维方式：不是我手头的工具链能做什么，而是这台计算机从根本上能做什么，我又如何用一切可能的工具链，甚至自己造一个，去做到这件事。 Vitaly：Zig 在生产环境里具体用在哪里？ Andrew：眼前一个很好的例子是 Ghostty。这是 Mitchell Hashimoto 做的终端模拟器，代码质量非常高，Mitchell 在社区治理和模糊测试上都做得特别到位。 还有 TigerBeetle，一个用 Zig 写的金融交易数据库。他们把操作批量组合，达到了行业内罕见的效率水平。别的方案可能在 PostgreSQL 之上搭 OLTP，而他们打造了专用数据库，比那种策略快上上千倍。这个项目特别注重预分配资源，一旦启动，就预先分配好未来要用到的所有内存，此后永不再进行任何动态分配，这就让延迟变得非常可预测、非常一致。这个场景恰恰说明了 Zig 的优势：你可以在低延迟、可预测延迟和类似垃圾收集的高吞吐之间做出选择。 Vitaly：Bun 呢？ Andrew：Bun 是一个 JavaScript 引擎，使用了 JavaScriptCore 和一堆 C++ 库，而所有胶水代码都用 Zig 写成。这个项目最近应该是卖给了 Anthropic，我们也因此看到越来越多人开始用 Zig 做 AI。 Vitaly：我还听说 Uber 在用 Zig。 Andrew：对，Uber 在用 Zig 的工具链。他们用 zig cc 来交叉编译 ARM64 的项目，而且是与 Go 搭配使用。他们有一堆 Go 代码，Go 本身的交叉编译没问题，但如果 Go 代码还依赖 C 代码，原生工具就搞不定了。你只要把 Zig 当作 Go 的 C 编译器来用，就能连 C 依赖一起交叉编译。 Vitaly：为什么叫 Zig？ Andrew：我想要一个短词，搜“编程语言”时谷歌结果为零。我用 Python 脚本随机生成了些词，Zig 一下子就抓住了我，就选了。 Vitaly：Zig 在最受钦慕的语言里排前五，可十年过去了，还没有 1.0 release，是什么在拖住它？ Andrew：1.0 对不同项目意义不同：Go 标记 1.0 后很长时间基本不再动语言。Rust 很早标记了 1.0，但有“版本”机制，在保持向后兼容的同时仍然可以大幅改变语言。写现代 Rust 和当年 1.0 时的 Rust 已经很不一样了。所以 1.0 到底是什么？本质上是一个向后兼容的承诺。 Zig 软件基金会不是一家创业公司，我们没有投资款，没有投资人盯着我们。我们是一个 501(c)(3) 非营利组织，我们不需要烧光钱倒闭，不需要被收购，不存在退出计划。我们的计划就是做出一个伟大的项目，并在很长时间里持续改进它，我们有时间稳步前进。我们是一个非常精简高效的小组织，不太烧钱，所以我们会一直在这里，持续改进 Zig 直到抵达那里，而不必过早地锁死版本。等我们标记 1.0，它将是真正不妥协的心血结晶，我们不会被迫仓促锁定任何糟糕的决策。 Vitaly：软件圈有个概念叫“worse is better（更差就是更好）”，就是快速发布、以后再修。PHP、Go 都这么干成了。你却选择了完全相反的路。为什么？ Andrew：这个说法是我的一个雷区，语言学上它根本讲不通。我觉得不如说成“用更少做更少”和“用更多做更多”，而 Zig 是第三种选择：我们在尝试用更少做更多。我们仍然想提供卓越的东西，想找到那种一丁点复杂性就能释放巨大效用的甜蜜点。你看语言中的编译期功能，小复杂度、大产出；再看工具链，只用一个 flag 就能让编译器把代码瞄准差异巨大的操作系统和架构，而且直接能用。 Vitaly：你觉得没有 1.0 会伤害到用户或者企业的采用吗？ Andrew：毫无疑问，一旦标定 1.0，我们会看到采纳量激增。但我把眼光放在长远未来，我想让 Zig 成为未来 50 年的语言。我们已经开始在即将到来的 0.16 版本中看到这种长期投入的回报了。 Vitaly：能分享一个截止日期吗？ Andrew：我们把它变成一场比赛吧，看是你上传这个视频快，还是我 0.16 版本上线快。67 万美元总收入Vitaly：为了开发这门语言，你成立了 Zig 软件基金会。2024 年的总收入是 67 万美元。主要赞助方都有谁？ Andrew：在我们公布的博文里有一张漂亮的饼状图。让我自豪的是那张图的多样化，大量赞助来自个人捐赠者，此外还有不少来自不同公司的捐款组合。没有任何单一实体能对我们说：“嘿，你得做这个、做那个。”我们可以面对任何一个赞助者说：“对不起，我们不会照你说的做。如果你把钱拿回去，我们也能活。”这是一种非常互利的合作关系，跟商业组织之间设有健康的边界线。 Vitaly：赞助方有谁能影响 Zig 的开发吗？ Andrew：影响的方式和其他任何人完全一样。他们可以在缺陷追踪器上参与，可以发拉取请求，可以在开发频道里聊天。最终就是人和人之间的交流，他们没有秘密切高端渠道。在这里，每个人都在同一水平线上。 Vitaly：你的薪水是每年 15.4 万美元，这和一名高级工程师差不多，可你是在构建整个语言生态，你自己的薪资是怎么定出来的？ Andrew：这是 Zig 软件基金会首次董事会时定下来的，取的是当时纽约市（非营利成立地）中级高级软件工程师的薪酬中位数。你的问题好像在暗示我或许值得拿更多钱，但说实话，我感觉自己就是个上层中产，我拿到的钱很多了，买菜轻松，在俄勒冈波特兰还房贷也没问题。我很舒服，不需要更多。 对我而言，经营一个精益、稳固、能够在今天这种混乱金融环境里站得住脚的非营利组织的这种自主权，远胜过再多一些零花钱。正是这一点让我们能够说：不，再等等。我们需要为 1.0 再留出一点时间。也让我们在到处大规模裁员的那一年，还能给我们的合同工涨工资。对此我很骄傲，我们是一个健康的组织，这种满足感是再多收入也填不满的。 Vitaly：如果一家大公司无条件向 Zig 提供 1 亿美元，你会接受吗？ Andrew：放到背景下来看，我们每年的总收入从来都不到 100 万美元，今年或许开始接近了。面对这笔钱，我有两个限制条件。第一个是基金会的可持续性。我不想拿了这笔钱之后，花掉其中一大部分，以至于将来还得再找同样量级的钱。那样就成了依赖，而不是惊喜礼物。 第二个限制是团队规模。我现在管理一个五人的团队，我不认为我有能力管比这多太多的人，也没这个动力，我肯定不会拿了钱就膨胀成管理一百个员工的角色。不过我能做的是：如果真有 1 亿美元，我可以把它存进银行，然后 100 年都不用再募资。所以，我当然会接受这笔钱，但绝不扩大规模。 这个问题本质上在问：如果有机会，我们会不会扩张？我想答案是稍微扩张一点儿。我可能会把团队开到超过 5 个人，但超过 10 个就有点勉强了。 Vitaly：所以团队是五个人，你的薪水就是基金会所有的开销吗？ Andrew：基金会只有我一名正式雇员，另外有一些合同工，总共大约五位是全职投入的。去年 91% 的款项都直接付给了投入项目的合同工，也就是说，我们收到的捐款绝大部分都直接转化为了对 Zig 项目的开发付出。 Vitaly：在金钱上如此公开透明，是因为非营利的法律义务，还是对你个人来说也很重要？ Andrew：非营利确实有一些义务。我们是在美国注册的 501(c)(3)，我借这个机会说明一下它和 501(c)(6) 的区别。501(c)(6) 是商业联盟，Rust 基金会就是这种。像亚马逊、Netflix、微软、Meta，它们对 Rust 的成功有共同利益，所以都向这个 501(c)(6) 捐款，这样它就能帮他们游说政府之类。 501(c)(3) 不允许去游说政府，也不存在别的企业利益，只服务于它的使命本身。我们在博文里分解收入和支出、分享细节，这是自愿的透明。但这也是一种营销，因为我们在这些指标上做得不错，可以增强人们的信心，证明我们干得不错，同时也是一次筹款机会。 Vitaly：2022 年，你们离开了 Reddit 和 Twitter。为什么？ Andrew：我觉得在这些网站上发内容，已经越来越像在 Slashdot 或 Digg 上发东西了，它们正变得越来越无关紧要。我们是软件工程师，想做尽可能少的营销，这些东西已经不再给我们带来相应回报了。我们开始做更多线下活动，比如 Zig Day，而不是依赖那些被算法控制、还要跟喷子打交道的社交媒体，这是我们现在认为更好的社区增长投资方向。 Vitaly：到 2025 年末，你又进一步把 Zig 主仓库从 GitHub 迁到了 Codeberg，为什么？ Andrew：GitHub 对我们来说直接罢工了，我们的持续集成运行结果再也出不来。于是我们迁到 Codeberg，CI 服务器一下子就恢复正常了。 Vitaly：但你们在 GitHub 上有赞助者，他们跟过来了吗？ Andrew：离开那些赞助渠道是一个艰难的决定。任何涉及资金的事情，失去一个收入来源总有点令人心惊。但归根结底，我们是来写软件的，如果 CI 服务器不能工作，就必须去找好用的，这是最高优先级。 Vitaly：基金会因此损失了钱吗？ Andrew：在资金方面我们完全没问题。我们产出的是 MIT 许可的软件，可以说是一场无附带条件、面向软件世界的捐赠。而为这个项目捐款的人，同样也是无附带条件的赠予。在这种关系下，我发现双方对彼此都怀有很高的尊重。如果有人停止捐赠，我绝不会说：“你这混蛋，怎么不捐了？”当然不会，这本来就是无附带条件的。同样，当我们决定迁出 GitHub 时，我发现人们都非常理解和宽容。 Vitaly：为什么是 Codeberg，而不是 GitLab 或自建服务器？ Andrew：Codeberg 基本就是 GitHub 的复制品，迁移起来很容易。同时 Codeberg 是一个德国非营利组织，我个人觉得用非营利组织作服务比用初创公司或大型企业更稳定，那些大公司总在追逐下一个目标，努力让下季度利润更高，而非营利只是想继续做好它在做的事。我要的正是代码锻造平台上的这种稳定，所以选了 Codeberg。 Vitaly：离开社交媒体，离开 GitHub，这些都在社区引发了巨大争论。很多人说这会阻止 Zig 的成长，把它边缘化成小众语言。个人怎么看？ Andrew：代码锻造平台并不是项目的营销渠道。我不认为大家是通过 GitHub 或 Codeberg 发现 Zig 的，而是通过各种演讲、见面会、YouTube 视频，以及 Zig Day 线下聚会群，这些才是人们听说一门语言的地方。我们用 Git 还是 Mercurial，缺陷追踪器在哪里，这些影响的是开发语言本身的便利程度，根本不是营销，所以我完全无法理解为何有人会觉得这是场受众危机。 Vitaly：你们脱离了 LLVM，为什么？ Andrew：我玩一个叫《Killer Queen》的十人竞技街机游戏，非常好玩，但开发者选择用 Unity 的物理引擎。问题在于，这个物理引擎对竞技玩法来说极其核心，哪怕微小的改动都会让竞技玩家完全觉得手感变化，技术也得重来。结果这些开发者连新版 Unity 都不能升级，因为即便修掉了 Bug，社区都会炸锅。他们犯了一个错误：为自己的核心产品引入了一个外部依赖。 我认为这是一个关键洞见：要避免你的核心产品存在依赖。而 Zig 当初依赖了 LLVM，我们正在纠正这个错误。我把它看作是自行车上的辅助轮，我已经开发 Zig 十多年了，在编译器方面比十年前懂得更多，现在可以把辅助轮摘掉，与 LLVM 正面竞争了。 正因拥有了自己的核心产品、消除了依赖，我们才能做以前做不到的事。例如，当我们使用自研的 x86 后端时，就有了增量编译能力。对于百万行的代码库，修改一次后，到新二进制就绪，只需要 50 毫秒甚至更少。这是 LLVM 根本不可能做到的，但借助我们自己的代码，现在可以了。所有 AI PR 都是垃圾Vitaly：Zig 对 issue 和拉取请求有着严格的禁止 LLM、禁止 AI 政策。为什么？ Andrew：第一个理由，这些贡献无一例外都是垃圾。人们提交上来的东西毫无价值，不仅无益，还有负价值，因为它们抢走了团队极其有限的审查时间。我们有超过 200 个开放 PR 都在等着审核，我们努力不落下太多。可当开发团队人数少而贡献者众多时，审核时间的瓶颈就永远存在。那些粗制滥造的 AI 贡献会吃掉我们的审核时间，几轮来回后，我们发现对方根本不知道自己在干什么。他们只是把我们给的建议粘贴回对话里，再把对话“洗”一遍想掩盖 AI 的痕迹，可我们还是看得出来。最终我们意识到这代码永远也达不到质量要求，因为他们一窍不通。结果大家都浪费了时间，那些耐心排队的人没被审到，代码也合并不了。 我们把审核和贡献的过程叫做“贡献者扑克”。除了我们自己写码，接受贡献的核心目的是传帮带。整个目标是让贡献者将来能成为一名核心成员，或者成为更有价值的贡献者，这既有助于项目本身获得能熟练贡献的人手，也能丰富他们的履历，让他们成为更好的系统程序员。 我们的时间有限，所以要识别出：哪些人值得我们投入时间去帮助他们成长为更好的程序员、更好的贡献者，哪些人只是一次性的路过，发个东西，然后消失。显然使用 AI 的人永远属于第二类，根本不值得给这些人投资，他们学不到任何东西，以后也不可能加入核心团队。 这个政策合情合理。Zig 本身也是一个教育项目，写在我们的使命里：为学生提供指引和教育。我们都在学习，都在精进编程。发来 AI PR 的人，无助于这个目标，甚至可以说在损害它。所以对我们项目来说，严格的禁 AI 政策是恰如其分的。如果要我界定“只接受好的 AI PR”，那我还得去当裁判。如果一刀切地什么都不要，执行起来非常简单。 Vitaly：你们怎么检测 AI 生成的内容？容易吗？ Andrew：并不总是很容易，我敢肯定有些已经混进来了。最近他们已经开始“洗”LLM 的文本了，不是直接复制粘贴那么明显，而是试图用自己的语气重写，或者试图装得更像人。我已经审查过太多 PR，慢慢就能察觉到这不是一个人在收到反馈后会做的反应，暴露后就很清楚了。但最近这势头太猛了，我猜我们可能得改变当前允许任何人来贡献的策略，可能需要一个更强的过滤器，获得权限后才能发送贡献。 Vitaly：Zig 代码用的是 MIT 许可，那是什么？是怎么用的？ ...