# Zig为何禁AI、弃GitHub、不发布1.0：Andrew Kelley的72分钟思想核爆 ## 导语 当所有编程语言都在拥抱AI、所有开源项目都在GitHub上狂欢的时候，有一个人站出来说："不。" 2026年5月27日，JetBrains发布了一段长达72分钟的访谈视频，Zig语言创始人Andrew Kelley在其中做出了一系列"反潮流"的宣言：Zig禁止AI生成的代码贡献、Zig把仓库从GitHub搬到了Codeberg、Zig十年不发布1.0版本——而且这些都是**刻意为之**。这段视频在两周内斩获了59万播放量，引发了整个编程社区的地震。 这不是一个技术教程。这是一份来自系统编程最深处的**独立宣言**。 ## 视频背景卡片 | 项目 | 内容 | |------|------| | 视频标题 | Zig 2026: No-AI Policy, $670K Foundation, Left GitHub & Why Zig Isn't 1.0 - Andrew Kelley Explains | | 频道 | JetBrains | | 时长 | 约72分钟 | | 播放量 | 59万+（截至2026年6月10日） | | 发布日期 | 2026年5月27日 | | 访谈人 | Vitaly Bragilevsky | | 核心主题 | Zig语言的设计哲学、开源治理、AI立场与系统编程的未来 | ## 核心内容拆解 ### 一、Rust、Go和C都"失败"了——Zig凭什么说自己没失败？ 视频开头就放了一颗炸弹：Andrew Kelley直言Rust、Go和C三种语言都"失败了"。但他的"失败"定义非常精确——不是市场失败，而是在**取代C语言**这个历史使命上的失败。 **视频原话要旨：** C语言已经统治系统编程50年，每一代人都试图创造"更好的C"。Rust选择了完全不同的路线——borrow checker和所有权系统让它成为一门全新的语言，学习曲线陡峭到劝退了大量C程序员。Go选择了垃圾回收，在系统编程的语义上就已经偏离了C的哲学。而之前的C替代者（D语言、Nim等）则因为各种原因未能获得主流采纳。 **我的延伸分析：** 这个论点的核心在于"**渐进式迁移**"的可行性。Rust虽然在安全性和性能上无可挑剔，但它要求开发者完全改变思维模型。据统计，一个有经验的C/C++程序员平均需要3-6个月才能"熟练"写Rust，而Zig的设计目标是让C程序员能在**一周内上手**。这不是技术优劣的问题，而是**采用成本**的问题。Kelley的洞察是：一门系统语言的成败，不取决于它有多先进，而取决于它有多容易被现有生态接受。 Zig做到这一点的关键是：**与C的完全互操作性**。Zig可以直接import C头文件，直接调用C函数，甚至可以把Zig编译出的对象文件和C代码无缝链接。这意味着你不需要重写整个项目，可以一个文件一个文件地迁移。 ### 二、谁在用Zig？从Ghostty到Uber的生产级验证 Andrew Kelley在视频中列举了Zig在生产环境中的重要用户： - **Ghostty**：由 Mitchell Hashimoto（HashiCorp创始人）开发的下一代终端模拟器，用Zig编写，性能远超传统终端 - **TigerBeetle**：金融级分布式数据库，处理实时支付交易，用Zig编写，对正确性要求极致 - **Uber**：将Zig用作Go服务的交叉编译工具链，利用Zig开箱即用的交叉编译能力 - **Bun**：高性能JavaScript运行时，用Zig编写，直接挑战Node.js的性能王座 - **Anthropic**：AI公司，在基础设施层使用Zig **延伸分析：** 这份名单的含金量极高。Mitchell Hashimoto是基础设施领域的传奇人物（Vagrant、Terraform的创造者），他选择Zig而非Rust来构建Ghostty，这本身就是一个强烈信号。更值得注意的是Uber的使用方式——他们并没有用Zig重写服务，而是用Zig解决了Go生态中一个长期痛点：**交叉编译的复杂度**。Zig自带交叉编译工具链，一条命令就能编译出任意平台的目标二进制，这对于Uber这种需要同时部署在多种架构上的公司来说简直是利器。 这说明Zig的定位非常聪明：它不必取代你现有的语言，它可以作为你工具链中**解决特定痛点的那一块拼图**。 ### 三、十年不发布1.0——这是故意的设计选择 Zig从2015年开始开发，到2026年已经超过10年，仍未发布1.0版本。很多人把这看作是项目不成熟的标志。Andrew Kelley在视频中的解释彻底翻转了这个认知。 **视频核心论点：** 发布1.0意味着**承诺API稳定性**。一旦你承诺了稳定性，你就不能随意改变语言设计。Kelley认为，过早发布1.0是最危险的决策——你会被自己当初不成熟的设计决策锁死。 他引用了经典的"**Worse is Better**"理论：很多成功的软件之所以成功，恰恰因为它们"足够好但不完美"，然后通过锁定用户来阻止改进。Kelley宁可让Zig缓慢进化到真正完美的状态，也不愿为了迎合市场而发布一个半成品。 **延伸分析：** 这种策略在商业上是"逆天"的，但在技术上是极其谨慎的。Python从2到3的迁移花了十多年，至今仍有大量项目停留在Python 2——这就是过早承诺稳定性的代价。Rust花了多年才稳定async/await，期间经历了多次breaking change。Zig的策略是：**把所有breaking change都放在1.0之前完成，一旦发布1.0就真正做到向后兼容**。 从资金角度看，Zig Software Foundation有$670K的资金储备，Andrew Kelley本人的年薪是$154K。这些数字说明Zig的运营极其精简——不需要VC级别的资金来维持一个语言项目，但需要足够的钱来让核心开发者全职工作。 ### 四、为什么离开GitHub？——一场关于开源基础设施的抗议 Zig把代码仓库从GitHub迁移到了Codeberg，这个决定在开发者社区引起了巨大反响。 **Andrew Kelley的理由：** 1. **微软对GitHub的AI化改造**：GitHub Copilot使用开源代码训练，而这正是很多开源项目所反对的 2. **平台锁定风险**：当所有开源项目都在一个商业平台上，那个平台就拥有了不成比例的权力 3. **Codeberg是非营利组织**：由社区治理，不会有被收购或改变使命的风险 **延伸分析：** Zig不是唯一这么做的项目。近年来，越来越多的开源项目开始重新审视对GitHub的依赖。当一个由非营利组织维护的语言项目把代码托管在一家市值万亿美元公司的平台上时，这里面的张力是显而易见的。Codeberg基于Forgejo（Gitea的社区fork），虽然功能不如GitHub丰富，但它代表了一种**开源精神的回归**——工具应该服务于社区，而非将社区作为数据资产。 Zig还离开了Reddit和Twitter，选择Mastodon等去中心化平台。这不是"技术洁癖"，而是一套完整的**开源治理哲学**——项目的每一个环节，从代码托管到社区讨论，都应该在不受商业利益驱动的平台上运行。 ### 五、Zig的AI政策：禁止AI生成代码，但欢迎AI用户 这是视频中最具争议性的部分。Zig项目明确规定：**不接受AI生成的代码贡献**。 **Andrew Kelley的解释框架（视频中的"AI悖论"）：** - Zig可以检测AI生成的代码（约26:38处讨论） - 禁止AI贡献的原因不是反技术，而是**代码质量责任** - 当一个贡献者提交AI生成的代码时，他们往往不理解代码的每一个细节——而在系统编程中，不理解每一个细节就意味着潜在的安全漏洞 - Zig用于Bun、TigerBeetle等对正确性要求极高的场景，容不得任何"差不多对"的代码 **但Kelley同时承认了一个悖论（Zig's AI Paradox，约30:48处）：** Anthropic这样的AI公司本身就在使用Zig。Zig不反对AI产品，不反对开发者使用AI辅助工具，但**在Zig项目自身的代码贡献中**，要求人类完全理解他们提交的每一行代码。 **延伸分析：** 这个立场让我想起航空业的一个原则——飞行员可以使用自动驾驶，但必须随时准备手动接管。Kelley对"Vibe Coding"（2026年的热门概念，指完全依赖AI生成代码的编程方式）的态度是明确的：如果你不能理解AI为你生成的代码，你就不能对这段代码负责。 这实际上是两个不同层面的讨论： - **产品层面**：AI工具可以帮助开发者更快地构建应用——这没问题 - **语言/基础设施层面**：编译器、操作系统内核、数据库引擎——这些需要人类完全理解每一个bit——这里AI只能做辅助，不能做替代 ### 六、离开LLVM：50ms编译百万行代码的野心 视频约24:22处讨论了Zig从LLVM迁移的重大技术决策。 **背景：** Zig早期使用LLVM作为后端编译器。LLVM是业界标准的编译器基础设施，Rust、Swift、Clang都基于它。但LLVM的编译速度一直是痛点——一个大型项目的增量编译可能需要数十秒甚至数分钟。 Andrew Kelley的目标是：**百万行代码在50ms内完成编译**。这不是渐进优化，而是一个数量级的飞跃。 **延伸分析：** 这个目标的野心在于它改变了开发者的工作流。当编译时间从"可以去倒杯咖啡"变成"眨眼之间"，你使用语言的方式会根本性改变——你会更频繁地编译、更快地迭代、更愿意做实验性的修改。这正是Zig的核心设计理念之一：**开发体验是语言设计的第一优先级**。 为了实现这个目标，Zig团队在开发自己的后端编译器，不依赖LLVM的优化pass管线。这意味着放弃了LLVM积累的数十年的优化工作，但也获得了对编译管线的完全控制。这是一个高风险高回报的赌注。 ### 七、Zig vs Rust：不是竞争，而是不同哲学 视频43:39处直接对比了Zig和Rust——这是社区里最火热的话题。 **Andrew Kelley的核心观点：** Rust和Zig解决的是不同的问题。Rust选择了**编译时安全保证**（borrow checker），代价是学习曲线和开发速度。Zig选择了**运行时安全检查+极致的简洁性**，代价是没有编译时的内存安全保证。 Kelley特别提到了Zig的"杀手级特性"（47:23处）： - **comptime**：编译时代码执行，Zig用普通代码而非宏来实现编译时计算 - **未使用变量检测**：更严格的质量控制 - **I/O接口设计**（50:28处）：统一的异步I/O模型 **我的延伸分析：** 在实际工程中，Rust和Zig的选择往往取决于团队和场景： - 如果你的团队有能力和时间学习Rust，且项目对内存安全有绝对要求（如浏览器引擎、操作系统内核），Rust是更好的选择 - 如果你需要快速迁移现有的C代码库，或者团队背景以C为主，Zig的迁移成本远低于Rust - 如果你需要极致的交叉编译体验，Zig是目前最好的选择 ### 八、开发者的心理健康：Burnout建议与编程之外的快乐 视频最后部分（1:05:49起）Andrew Kelley分享了他对开发者倦怠的看法，这部分出人意料地动人。 **核心观点：** - 开源维护者的倦怠是一个系统性问题，不仅仅是"休息一下"就能解决的 - 他个人通过编程之外的活动（音乐、户外）来保持心理健康 - 对Zig而言，"成功"不是成为最流行的语言，而是**成为它应该成为的那个工具** ```mermaid mindmap root((Zig 2026深度解读)) 设计哲学 渐进式C替代 零隐藏控制流 comptime编译时计算 与C完全互操作 开源治理 $670K Foundation 搬离GitHub到Codeberg 离开Reddit/Twitter 社区驱动的非营利模式 AI立场 禁止AI生成代码贡献 支持AI产品使用Zig 反对Vibe Coding 代码质量责任论 生产应用 Ghostty终端模拟器 TigerBeetle金融数据库 Uber交叉编译工具链 Bun JavaScript运行时 技术愿景 摆脱LLVM依赖 50ms编译百万行 一流的交叉编译 开发体验优先 人生哲学 十年不发布1.0 抵抗过早承诺 开发者倦怠防护 编程之外的快乐 ``` ## 实战启示 ### 对系统程序员的启示 1. **不要被语言的"流行度"绑架选择**。Zig在Stack Overflow调查中位列"最受推崇"语言前五，但它的用户群远小于Rust或Go。选择语言的标准应该是：它是否适合你的具体场景？你的团队能否高效上手？它能与现有代码库共存吗？ 2. **交叉编译是Zig的杀手级特性**。如果你在做嵌入式开发、多平台部署、或者需要为不同操作系统构建工具链，Zig的交叉编译体验是目前所有语言中最好的——一条命令，零配置。即使你的主要项目用的是Go或Rust，也可以把Zig作为构建工具链的一部分。 3. **学习Zig的"显式编程"思维**。即使你不打算使用Zig，它的设计哲学也值得学习：没有隐藏的内存分配、没有隐式的控制流、没有魔法。这种思维方式会让你在任何语言中写出更清晰、更可维护的代码。 ### 对开源项目维护者的启示 Andrew Kelley的治理策略值得所有开源项目参考： - **基础设施独立性**：不要把所有鸡蛋放在GitHub这一个篮子里。Codeberg、SourceHut等替代方案虽然功能不如GitHub丰富，但它们不受商业公司控制 - **节奏控制**：不被社区压力驱赶着发布不成熟的版本。1.0是一个承诺，不是一个里程碑 - **可持续运营**：$670K的基金会资金+$154K的创始人年薪，证明了开源项目不需要巨额融资也能持续运转 ### 对AI时代程序员的启示 Zig的AI政策不是反AI，而是**划分了AI的适用边界**： - 应用层：AI可以大幅提升开发效率 - 基础设施层：每一行代码都需要人类完全理解和负责 - 关键问题是：**你能否为AI生成的每一行代码负责？** 如果不能，那这段代码就不应该出现在关键基础设施中 ## 延伸学习路径 1. **[Zig官方文档](https://ziglang.org/documentation/master/)** — 从零开始学习Zig的最佳入口，文档质量极高 2. **[Zig's "Why Zig When There's X"](https://ziglang.org/learn/why_zig/)** — Zig官方对"为什么选Zig而不是其他语言"的详细解释 3. **[Bun源码](https://github.com/oven-sh/bun)** — 阅读一个大型Zig生产项目的代码，理解Zig在实际项目中的组织方式 4. **[Codeberg上的Zig仓库](https://codeberg.org/zig)** — 在新的托管平台上参与Zig社区 5. **[TigerBeetle文档](https://docs.tigerbeetle.com/)** — 了解Zig在金融级正确性要求下是如何被使用的 ## 一句话总结 > Zig用十年的耐心、对AI的审慎、对开源基础设施的独立思考，向我们展示了另一种可能：一个不被市场裹挟、不被AI浪潮冲昏头的编程语言，依然可以赢得生产级用户的尊重。 ## 参考来源 1. [Zig 2026: No-AI Policy, $670K Foundation, Left GitHub & Why Zig Isn't 1.0 - Andrew Kelley Explains](https://www.youtube.com/watch?v=iqddnwKF8HQ) — 本文分析的核心视频 2. [Zig官方站点](https://ziglang.org/) — Zig语言官方网站 3. [Andrew Kelley on Mastodon](https://mastodon.social/@andrewrk) — Zig创始人的社交账号 4. [Stack Overflow Developer Survey](https://survey.stackoverflow.co/) — Zig在"最受推崇语言"排名中的数据来源 5. [JetBrains YouTube频道](https://www.youtube.com/@JetBrains) — 访谈发布方 --- > 本文由「51学通信」技术团队出品。51学通信由通信行业18年老兵**爱卫生**（微信ID: gprshome201101）维护，聚焦5G/6G核心网、3GPP标准解读、通信前沿技术深度分析。 > 出版作品有《5G核心网原理与实践》《IMS原理与实践》等4本通信专业书籍。知识星球「51学通信」提供深度技术答疑和行业洞察。 > [!tip] 51学通信知识星球 > **星主：爱卫生**（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 > **星球定位**：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 > **当前规模**：5200 篇主题 / 990 个回答，198 元/年。 > **加入福利**：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 > **AI 加持**：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。