团子技术日报 中文看懂全球开发者趋势
Anthropic 的 AI 编码助手 Claude Code 悄悄换上了 Rust 版 Bun 运行时

Anthropic 的 AI 编码助手 Claude Code 悄悄换上了 Rust 版 Bun 运行时

AIClaude CodeBunRustZigJavaScript运行时Anthropic

数据源：HN + Lobsters

一段 strings 命令掀开的隐秘升级

2026 年 7 月 19 日，知名 Python 生态开发者 Simon Willison 发布了一篇简短博客，标题直白得不能再直白——「Claude Code 现在用的是 Rust 写的 Bun 了」。

事情的起因是 Bun 的作者 Jarred Sumner 在一篇关于「用 Rust 重写 Bun」的公告中顺带提了一句：Claude Code 自从 v2.1.181（6 月 17 日发布）之后就已经在用 Rust 版本的 Bun 了。

Willison 没有直接相信这句话，他打开终端，对着自己的 Claude Code 安装目录敲了两条命令：

strings ~/.local/bin/claude | grep -m1 'Bun v1'
strings ~/.local/bin/claude | grep -Eo 'src/[[:alnum:]_./-]+\.rs'

第一条返回了 Bun v1.4.0——这个版本号甚至还没有出现在 Bun 的正式发布版中（当时最新正式版是 5 月 12 日的 v1.3.14）。第二条返回了 563 个 .rs 文件路径，从 src/runtime/bake/dev_server/mod.rs 到 src/bundler/bundle_v2.rs，铁证如山：Claude Code 的二进制里确实嵌着一个 Rust 实现的 Bun。

Claude Code 启动时间对比：从 Zig 版的 517ms 降到 Rust 版的 464ms，提升约 10%

从 Zig 到 Rust：一个「AI 写 AI 运行时」的故事

要理解这件事的分量，得先回到 Bun 的原点。

Bun 最初是 Jarred Sumner 在 2021 年用 Zig 写的一个 JavaScript 运行时。它的野心很大——要做 Node.js 的替代品，集打包器、转译器、包管理器、测试框架于一身。Zig 给了 Sumner 极致的底层控制力和对性能的专注，他在一年内（没有 LLM 辅助的情况下）用 Zig 独自搭建了 Bun 的初版。

但 Zig 的灵活是一把双刃剑。内存生命周期需要手动管理，use-after-free、内存泄漏这类问题像幽灵一样缠绕着这个快速增长的项目。到 2026 年，Bun 的 CLI 已经拥有每月 2200 万以上的下载量，Claude Code 和 OpenCode 等工具都在用它做运行时，Vercel、Railway 等云平台也提供了原生支持。规模的扩大让稳定性压力成倍增加。

转折点在 2025 年 12 月到来——Anthropic 收购了 Bun 团队。此后 Sumner 和团队成员开始在 Anthropic 工作，能使用到 Claude Fable 5（当时尚未公开发布的顶级模型）的预发布版本。

2026 年 5 月，Sumner 做了一个大胆的决定：让 AI 把 Bun 从 Zig 翻译成 Rust。

11 天，100 万行，1 个人

整个重写过程的规模惊人：

  • 6,755 个提交
  • 2,188 个文件被修改
  • 1,009,257 行代码被添加
  • 4,024 行被删除

但如果以为这是 AI 全自动完成的，那就错了。实际的工作流更像一条精密的 AI 辅助流水线：

  1. 预处理：Sumner 先手动写了一份「Zig 到 Rust 移植指南」和「生命周期管理指南」，作为 Claude 的知识锚点
  2. 试跑：让 Claude Code 先尝试翻译一个小模块，验证流程是否可行
  3. 逐模块翻译：将 Zig 源文件分发给 Claude Code，按照「一次一个 Zig 文件 → 生成对应 Rust 代码」的方式推进
  4. 对抗性代码审查：不止是让 AI 写代码，还让另一个 AI（专门配置的审查 Agent）去挑 AI 写的代码的毛病，检查是否遵循了移植指南和生命周期规则
  5. 编译器错误当任务队列：Rust 编译器产生的每条错误信息都被当作下一个修复任务的输入——这恰好是 AI 最擅长处理的确定性工作
  6. 测试套件验证：从本地到 CI，逐步通过 Bun 已有的全部测试

最终结果：从开始到全部平台测试套件 100% 通过，只用了 11 天。

「一个工程师今天能做的事情比一年前多太多了。」Sumner 在博客里写道。

为什么要换运行时？

从外部看，Claude Code 的这次升级几乎是「无感」的——Linux 上启动速度从 517ms 降到 464ms，快了 10%。没有新功能，没有 API 变化，没有用户可见的裂变。

但这种「无感」恰好是最好的结果。

从工程角度看，这次切换解决了几个深层问题：

内存安全：Zig 要求开发者手动跟踪每个分配的生命周期。对于一个人（或一个 AI Agent）维护的百万行级项目来说，use-after-free 和内存泄漏是一个无穷无尽的 bug 来源。Rust 的借用检查器在编译期自动消除了整个类别的错误。

AI 友好的护栏：HN 上一位用户 mrothroc 的评论一针见血——「人类和 AI Agent 有一个共同点：它们都是非确定性的。编译器错误正好是那种你需要放在编码 Agent 周围的确定性护栏。Claude 在拥有测试正确性的方式时工作得最好，而『让它通过编译』就是一个非常好的目标。」确定性的测试将 Agent 的随机性输出变成了硬性保证。

更小的体积、更少的内存：Rust 版本在多个维度上优于原来的 Zig 实现——二进制体积更小、栈空间使用更少，性能还提升了 2%-5%。

Bun 官方博客的 Rust 重写公告 OG 图片

社区怎么看？

这篇发现帖在 Hacker News 上获得了 469 分和 628 条评论（截至目前），讨论热度说明这件事触动了不止一根神经。

点赞最高的讨论线集中在 Zig vs Rust 的语言哲学之争上：

  • 有观点认为「Zig（和 C）本质上不适合大量小对象的自由生命周期分配。如果你用 arena 或固定缓冲区的模式写 Zig，它和 Rust 一样稳健。但如果你想要『托管语言』风格的分配模式——LLM 们普遍更喜欢这种——那 Zig 就不是好选择。」
  • 另有人提到 TigerBeetle（另一个知名的 Zig 项目）的做法是「所有内存在初始化时分配完毕，运行时不允许任何分配」，这种极端自律的风格保证了 Zig 代码的稳健，但不是每个项目都能承受这份自律的成本。
  • 也有人看到了更深层的趋势：AI 编码工具正在从 Node.js 生态迁移到更现代化的运行时。Claude Code 拥抱 Bun，Bun 拥抱 Rust，而 Rust 的编译器恰好为 AI 生成的代码提供了天然的质量关卡。

什么是真正的「无感迁移」

技术圈里每天都在谈论「迁移」——从 Python 2 到 3，从 JavaScript 到 TypeScript，从 monolith 到微服务。大多数迁移劳民伤财，用户怨声载道。

Claude Code + Bun + Rust 的这次串联实验提供一个反例：最成功的迁移是用户感觉不到的迁移。百万行代码重写，底层运行时整体替换，而最终用户只看到了「启动快了 10%」这一行 release note。

在 Bun 的 GitHub 上，v1.4.0（第一个 Rust 版本）已经以 canary 形式可用。运行 bun upgrade --canary 就能体验到。

Sumner 说的那句话可能就是这个故事最好的总结：

Boring is good.

参考链接：

  • Simon Willison 博客
  • Bun 官方博客：Rust 重写公告
  • HN 讨论

相关阅读