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生态的影响 |
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的工程师已经不再手写代码，这个政策就成了不可调和的矛盾。与其与上游文化对抗，不如换语言。
Theo提出了一个非常犀利的观点：Bun的运行时性能优势被严重高估了。
Bun在包管理（bun install）和打包（bundling）上的速度确实碾压级——这一点没有争议。但在运行时场景中，Theo引用了具体数据：
他的原话很直接："如果你的本地agent需要从20K到60K的请求速度差异中受益，那说明你的代码写得烂。"
[延伸分析] 这正是OpenCode团队选择离开Bun的原因。Dax（OpenCode负责人）公开表示：他们在基准测试中并没有从Bun的运行时性能中获益，反而在Windows上吃了大量稳定性亏。Electron桌面应用可以轻松嵌入Node.js但难以嵌入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的最佳工具。
这是视频中最具技术深度的部分。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迁移的复杂度——复制结构比重新思考结构简单得多。
AI Weekly报道中最令人震惊的数据：新的Rust代码库中有13,044个unsafe块，而一个同等规模的手写Rust项目通常只有约73个。这个差距量化了AI速度迁移带来的"安全债务"。
Theo对此的态度是审慎的：测试通过不代表没有bug，基准测试正常不代表所有边界条件都覆盖了。"测试和基准测试无法捕获的东西——基准测试面之外的性能回归、平台特定行为、unsafe边界、长期可维护性——仍然需要人类和长期运营的目光。"
[延伸分析] 这是一个深层的工程哲学问题。Rust的核心价值就是通过编译器在编译期消除内存安全问题。但如果你的Rust代码中有13,044个
unsafe块，你实际上绕过了这个安全系统。这些unsafe块需要逐一审计——这可能是未来几个月甚至几年Bun团队最大的工程负担。一个在高流量代码路径上的可利用unsafe块，可能在广泛采用后的几个月内产生关键CVE。
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给出了一个充满张力的总结："Bun的未来既比以往任何时候都更光明，也比以往任何时候都更可怕。"
更光明：编译器帮助捕获内存bug，减少人工调试时间；Anthropic有经济动力持续投入；Rust生态更大更容易招人。
更可怕：13,044个unsafe块需要审计；Claude Code的稳定性与Bun深度绑定；百万行AI生成的代码需要长期验证；Zig旗舰项目流失对整个语言生态的打击。
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代码迁移新范式
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清理、性能优化。这是一个持续的过程，不是一个一次性事件。
Bun用6天让AI重写了100万行代码，证明了AI驱动的语言级迁移在技术上的可行性，但13,044个unsafe块提醒我们：速度和质量之间的张力，AI并不能帮你抹平。
本文由「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 等场景全覆盖。