# Bun弃Zig投Rust：AI百万行重写的真相 ## 导语 2026年5月14日，一个Pull Request悄无声息地合并进了Bun的main分支。这个PR改动了2,188个文件，新增超过100万行代码，删除仅4,024行——它把整个Bun运行时从Zig语言搬到了Rust。整个迁移用了大约6天，主要"开发者"是Claude AI。这不是科幻小说，这是真实发生了的工程事件。Theo（t3.gg频道）在这期27分钟的视频里，从三个维度拆解了这个决定：Zig生态的问题、Bun自身的困境、以及用AI重写一切的风险。这期视频之所以值得每个开发者花时间看，是因为它不仅仅是一个运行时换语言的故事——它揭示了AI时代软件工程的新范式：当AI可以在一周内翻译百万行代码，语言选择的意义本身正在被重新定义。 ## 视频背景卡片 | 项目 | 内容 | |------|------| | 视频标题 | I wish this was clickbait | | 频道 | Theo - t3.gg | | 频道订阅 | 539K+ | | 时长 | 27分钟 | | 发布日期 | 2026年5月13日 | | 核心主题 | Bun从Zig重写为Rust的技术决策、AI驱动的百万行代码迁移、对JavaScript生态的影响 | ## 核心内容拆解 ### 一、三层嵌套的问题：Zig → Bun → 重写本身 Theo开门见山地指出，这不是一个简单的故事，而是"三层问题嵌套"。第一层是Zig语言生态的问题——Zig是一门强大但充满争议的语言。Theo对Zig的comptime（编译期计算）能力赞不绝口，认为它是"C语言真正的继承者"，但同时也指出Zig社区存在"各种奇怪的问题"，而Bun团队与Zig核心团队之间的关系也"微妙而紧张"。 第二层是Bun自身的稳定性问题。Theo坦言，作为Bun的长期支持者，他"最近越来越难使用Bun了"。尤其在Windows平台上，内存管理问题频发。他个人在使用Bun做Advent of Code编程挑战时，经常"触碰内存管理的边界"。 第三层是"用AI重写一切"本身的风险——百万行代码的迁移，质量如何保证？13,044个`unsafe`块怎么办？ > **[延伸分析]** Zig的no-AI-contributions政策是这次迁移的关键推手。根据AI Weekly的报道，Zig核心团队明确禁止AI生成的代码贡献。当Anthropic在2025年12月收购Bun后，Bun的工程师已经不再手写代码，这个政策就成了不可调和的矛盾。与其与上游文化对抗，不如换语言。 ### 二、Bun的性能优势：被高估的"快" Theo提出了一个非常犀利的观点：**Bun的运行时性能优势被严重高估了**。 Bun在包管理（`bun install`）和打包（bundling）上的速度确实碾压级——这一点没有争议。但在运行时场景中，Theo引用了具体数据： - Node.js在Express框架下可以处理约20,000 requests/s - Bun在同样条件下约60,000 requests/s - 这是3倍性能差距，但基数已经是20,000 rps 他的原话很直接："如果你的本地agent需要从20K到60K的请求速度差异中受益，那说明你的代码写得烂。" > **[延伸分析]** 这正是OpenCode团队选择离开Bun的原因。Dax（OpenCode负责人）公开表示：他们在基准测试中并没有从Bun的运行时性能中获益，反而在Windows上吃了大量稳定性亏。Electron桌面应用可以轻松嵌入Node.js但难以嵌入Bun，这才是实际的工程约束。 ### 三、Claude Code的命运与Bun绑在一起 这是一个很多人忽略的关键事实：**Claude Code本身就运行在Bun上**。当你安装Claude Code时，你安装的是一个Bun编译的可执行文件——Bun把自身和你的代码打包成一个单独的二进制文件。 Theo直接点出了问题核心："如果Bun坏了，Claude Code就坏了。"Anthropic收购Bun时，官方声明听起来很安抚：保持开源、MIT许可证、同一个团队继续开发。但Theo引用社区文章的话说："现在Claude Code本身在走下坡路，这个保证就不那么让人安心了。" > **[延伸分析]** Anthropic收购Bun的真正动机在这里变得清晰——不是为了Bun的技术本身，而是为了确保Claude Code的运行时基础。当Bun的内存bug影响到Claude Code的稳定性时，Anthropic有了直接的经济动机去解决这些问题。Rust的编译期内存安全检查，正是减少这类bug的最佳工具。 ### 四、AI重写的工作流：Claude的多分支并行策略 这是视频中最具技术深度的部分。Theo揭示了Bun团队使用AI进行百万行迁移的具体工作流——通过PR分支名称可以窥见一斑： - `claude/phase-a-port` — 主端口迁移 - `claude/bench-until-green` — 专门循环跑基准测试直到通过 - `claude/code-dedup` — 代码去重，连续多个commit分别减少了968、692、1320、1946、480、717行代码 - `claude/ci-auto-fix-53852` / `claude/ci-auto-fix-53863` — 按issue编号自动修复CI失败 这个工作流的关键洞察是：**6,755个commit、百万行的diff，人类根本无法正常review。** 让它work的，是Bun已有的完善测试套件和基准测试。"通过相同的测试和基准测试"成为了一个机器可验证的目标，让AI的"生成→验证"循环有了具体的收敛条件。 > **[延伸分析]** 根据lilting.ch的深度分析，这次迁移明确是"语言替换，不是重新设计"。相同架构、相同数据结构、相同的JavaScriptCore FFI、不用async Rust。Jarred Sumner在PR中明确说："不是用另一种形状的重新设计。"这大大降低了AI迁移的复杂度——复制结构比重新思考结构简单得多。 ### 五、13,044个unsafe块：AI迁移的安全债务 AI Weekly报道中最令人震惊的数据：新的Rust代码库中有**13,044个`unsafe`块**，而一个同等规模的手写Rust项目通常只有约73个。这个差距量化了AI速度迁移带来的"安全债务"。 Theo对此的态度是审慎的：测试通过不代表没有bug，基准测试正常不代表所有边界条件都覆盖了。"测试和基准测试无法捕获的东西——基准测试面之外的性能回归、平台特定行为、unsafe边界、长期可维护性——仍然需要人类和长期运营的目光。" > **[延伸分析]** 这是一个深层的工程哲学问题。Rust的核心价值就是通过编译器在编译期消除内存安全问题。但如果你的Rust代码中有13,044个`unsafe`块，你实际上绕过了这个安全系统。这些`unsafe`块需要逐一审计——这可能是未来几个月甚至几年Bun团队最大的工程负担。一个在高流量代码路径上的可利用`unsafe`块，可能在广泛采用后的几个月内产生关键CVE。 ### 六、Zig生态失去旗舰项目的连锁反应 Bun是Zig生态中最大、最有影响力的项目。Theo没有说"Zig不好所以他们切换了"——相反他明确说Bun选择Zig的原始决策仍然合理：底层控制、JavaScriptCore FFI、单二进制分发在Zig中都工作得很好。 但GitHub的语言统计已经翻转：Rust占46.6%，Zig占32.2%。README还写着"written in Zig"，但代码已经变了。 Theo的判断是客观的：Zig社区保留的是Bun展示的那些实用模式——JSC集成、自定义事件循环、单二进制分发、底层I/O实现。Bun的语言选择变了，但用Zig构建生产运行时的路径保留在了commit历史中，作为未来Zig项目的参考。 ### 七、Theo的最终判断：更光明也更黑暗 视频结尾Theo给出了一个充满张力的总结："Bun的未来既比以往任何时候都更光明，也比以往任何时候都更可怕。" 更光明：编译器帮助捕获内存bug，减少人工调试时间；Anthropic有经济动力持续投入；Rust生态更大更容易招人。 更可怕：13,044个unsafe块需要审计；Claude Code的稳定性与Bun深度绑定；百万行AI生成的代码需要长期验证；Zig旗舰项目流失对整个语言生态的打击。 ## 知识结构图 ```mermaid mindmap root((Bun Zig→Rust迁移)) 动因 Zig生态问题 no-AI-contributions政策 社区与Bun团队关系紧张 Windows兼容性差 Anthropic收购 Claude Code运行在Bun上 需要内存安全保障 有经济动力投入 技术实施 Claude AI主导编码 6天完成迁移 6755个commits 多分支并行策略 保持架构不变 相同数据结构 相同JavaScriptCore FFI 不使用async Rust 成果 99.8%测试通过率 二进制缩小3-8MB 100万+行代码变更 风险 13044个unsafe块待审计 0.2%未通过测试 平台特定行为不确定 生态影响 Zig失去旗舰项目 JavaScript运行时格局变化 AI代码迁移新范式 ``` ## 实战启示 ### 对JavaScript/TypeScript开发者的意义 **1. 暂时不需要任何行动。** 目前`bun upgrade`仍然会安装v1.3.14（最后的Zig版本），Rust版本仅通过`bun upgrade --canary`获取。在canary版本稳定之前，生产环境无需迁移。 **2. 重新评估运行时选择。** Theo的数据很重要：如果你的场景是本地开发工具、CLI应用，Bun的包管理和打包速度优势是实打实的。但如果你在做服务端应用，Node.js的20K rps已经对绝大多数场景足够了，而Bun的稳定性风险（尤其在Windows上）是真实存在的。 **3. 关注AI驱动迁移的质量审计。** 13,044个unsafe块不是小数字。如果你正在考虑用AI做大规模代码迁移，Bun的案例提供了关键教训：**功能正确性（测试通过）≠ 安全正确性（内存安全）**。AI可以快速翻译代码，但unsafe块的审计、性能回归的检测、平台兼容性的验证，仍然需要人类的工程判断。 **4. 语言选择的考量因素正在变化。** Zig→Rust的迁移不是因为Zig"不好"，而是因为生态系统和工具链成熟度的考量。对技术选型来说，语言本身的特性只是决策的一部分——社区生态、招聘市场、AI工具的适配性、长期维护成本，都在变得越来越重要。 **5. "Phase A"暗示后续还有更多。** 分支名叫`claude/phase-a-port`，意味着还有Phase B、Phase C。接下来可能是代码去重、内部API清理、性能优化。这是一个持续的过程，不是一个一次性事件。 ## 延伸学习路径 1. **[Bun PR #30412](https://github.com/oven-sh/bun/pull/30412)** — 直接阅读这个百万行PR的描述和讨论，理解Jarred Sumner的官方解释 2. **[lilting.ch深度分析](https://lilting.ch/en/articles/bun-zig-rust-ai-port)** — 日文开发者社区对PR的技术拆解，包括commit级别的分析 3. **[The Register报道](https://www.theregister.com/devops/2026/05/14/anthropics-bun-rust-rewrite-merged-at-speed-of-ai/5240381)** — 英文科技媒体视角的事件报道 4. **[DasRoot: Rustification of the Runtime](https://dasroot.net/posts/2026/05/rustification-runtime-bun-rewrite-lessons/)** — 从运行时架构角度分析迁移的技术教训 5. **[AI Weekly: 960K行重写](https://aiweekly.co/alerts/bun-rewrites-960k-lines-of-zig-to-rust-using-claude)** — 聚焦AI作为编码代理的里程碑事件 ## 一句话总结 Bun用6天让AI重写了100万行代码，证明了AI驱动的语言级迁移在技术上的可行性，但13,044个unsafe块提醒我们：速度和质量之间的张力，AI并不能帮你抹平。 ## 参考来源 1. [I wish this was clickbait - Theo - t3.gg](https://www.youtube.com/watch?v=gILMoijqeGA) — 本文分析的核心视频 2. [Bun PR #30412 merged: 1M-line Zig-to-Rust rewrite](https://lilting.ch/en/articles/bun-zig-rust-ai-port) — lilting.ch技术深度拆解 3. [Anthropic's Bun Rust rewrite merged at speed of AI - The Register](https://www.theregister.com/devops/2026/05/14/anthropics-bun-rust-rewrite-merged-at-speed-of-ai/5240381) — 英文媒体报道 4. [Bun Rewrites 960K Lines of Zig to Rust Using Claude - AI Weekly](https://aiweekly.co/alerts/bun-rewrites-960k-lines-of-zig-to-rust-using-claude) — AI行业分析 5. [Bun's Zig to Rust Rewrite: Engineering Realities - DasRoot](https://dasroot.net/posts/2026/05/bun-zig-to-rust-rewrite-engineering-realities-language-backend-migration/) — 工程视角分析 --- > 本文由「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 等场景全覆盖。