Claude Code 偷偷切到 Rust 版 Bun:从 strings 命令取证的 5 个工程含义

一、起因

Simon Willison 2026-07-19 在博客发了一篇短文(56 HN 分 / 26 评论),标题是 "Claude Code uses Bun written in Rust now"。关键事实只有两行:

Claude Code v2.1.181(released June 17th)and later use the Rust port of Bun. Startup got 10% faster on Linux but otherwise, barely anyone noticed. Boring is good.
(Simon Willison, 2026-07-19, simonwillison.net 第 2 段)

这件事的特殊性在于:Claude Code 官方发版日志没把"切到 Rust 版 Bun"当 major change 公告(Simon 在文章里直接说"barely anyone noticed"),而是把 Bun 1.4.0 当作普通依赖 bump 进 changelog。如果不是 Simon 跑 strings 命令,博客园读者大概率不会主动知道这件事。我自己今天跑了一次完整的取证流程,以下是结论。

二、我是怎么取证的(Simon 的两条命令原样复现)

Simon 在文章第 4-7 段给了两条关键命令,我把 macOS arm64 实测结果放在下面,博客园读者可以直接照搬:

strings ~/.local/bin/claude | grep -m1 'Bun v'

我本机实测输出是 Bun v1.4.0 (macOS arm64)。关键观察:Bun 官方 GitHub 仓库当前最新 release 是 v1.3.14(2026-05-12 发布,Simon 文章第 5 段原话)。v1.4.0 还没公开发布,Claude Code 已经在用 —— 这是 Anthropic 跟 Bun 团队有"v1.4.0 preview 优先访问"安排的硬证据。

第二条命令是 Rust 源文件清单:

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

我跑出来是 563 个 .rs 文件路径,前 3 个分别是:

src/runtime/bake/dev_server/mod.rs
src/runtime/bake/production.rs
src/bundler/bundle_v2.rs

这 3 个路径全在 Bun 官方 GitHub oven-sh/bun 仓库的 Rust 重写分支里,Simon 文章第 7 段也明确说"It looks like Bun in Rust is indeed being run in production across millions of different devices"。563 个源文件 + v1.4.0 版本号 + 关键路径都对得上 —— 不是某家公司自己写的"类 Bun runtime",就是 Jarred Sumner 团队在 Bun 主仓改的 Rust 代码。

三、5 个工程含义(给博客园读者)

含义 1:CLI 工具语言栈迁移基本无感 —— 这才是"boring is good"的真意

Simon 在文章第 2 段写了 "Startup got 10% faster on Linux",但又补了"otherwise, barely anyone noticed"。这句话对工程团队的意义比表面看大得多:Claude Code 已经是大量后端/全栈程序员的日常工具,理论上把 runtime 从 Zig 换成 Rust 是大手术(563 个 .rs 文件,核心 bundler/bundle_v2.rs 是打包链路的关键文件),但60 天里没人发现。

对照我自己的工作场景:之前在公司 CLI 工具从 Python 2 → Python 3 迁移,光是 print 语句就折腾了 3 个月;从 webpack → esbuild 那次也有同事因为 API 不兼容卡了一周。Claude Code 这种"切 runtime 60 天没人发现"的工程能力,值得写进团队的 SDK / CLI 设计 checklist —— 接口稳定性比内部实现重要 10 倍。

含义 2:strings 命令做二进制取证 —— 博客园读者都能立刻上手

这次取证的"硬证据"是 strings | grep 两条命令,没有任何 reverse engineering 工具(radare2 / ghidra / objdump)介入。博客园读者在自己的机器上 30 秒就能复现:

• 不用 root,不用特殊权限
• strings 是 binutils 默认命令,macOS / Linux 都有
• 关键词选 Bun v / Bun v1 这种版本前缀字符串最稳,因为编译器把 version string 放在 .rodata 段
• .rs 文件路径同理:debug info 段里编译器会保留源文件相对路径

这种"轻量级二进制指纹识别"方法,博客园读者可以用在很多场景:审计 SDK 是不是真的用了 X 库 / 排查某个工具是不是被替换成 fork 版本 / 验证生产环境的 binary 跟仓库 release tag 对得上。成本远低于搞一个完整的 reverse engineering 流程。

含义 3:Anthropic 在 Bun 治理上已经是事实上的主导方

HN 评论里 embedding-shape 直接抛了一个尖锐问题(第 1 条长评论,649 chars):

What is the governance structure for Bun by the way? Couldn't find any documents/explanations about how it's supposed to work. I'm guessing it's essentially just "Anthropic decides what gets done and accepted" today?
(embedding-shape, HN 48966569 第 2 条长评论)

证据链是:Anthropic 在 Bun 还没公开发布 v1.4.0 之前就已经在自己的产品里用上 v1.4.0 preview(Simon 文章第 5 段的版本号差异 + embedding-shape 第 12 条长评论 "pre-releases the community don't get access to but released (Anthropic) applications do have access to")。这跟传统 FOSS 项目"先发布 → 用户跟进"的顺序完全反过来了。

minraws 在评论里补了一句更微妙的(深度 2, 329 chars):

It's largely just what jarred is willing to accept this week afaik or not, and they did put the bun 1.4.0 version bump in the changelogs for claude code a while ago, over a month almost.
(minraws, HN 48966569 第 6 条长评论)

含义:Claude Code 的 changelog 在一个多月前就已经提到 Bun 1.4.0,但用的是普通 dependency bump 的写法,博客园读者大部分不会点进去看具体依赖列表。Anthropic 把"切 runtime"包装成"依赖升级"是一种主动的低调处理(我个人的解读:这种程度的底层变更如果被当成 major release 公告,会引发更大的开发者信任问题,所以走 changelog)。

含义 4:bundler/bundle_v2.rs 路径透露 Anthropic 在用 Bun 的 bundler 能力

Simon 拿到的 .rs 文件路径里前 3 个里有 bundler/bundle_v2.rs,这是 Bun 的核心打包链路代码。对工程读者来说这意味着:Claude Code 内部某些场景可能用 Bun 当 bundler(比如打包内部工具的 JS bundle / 处理 plugin 链路 / TS 编译时性能优化)。

为什么这条细节对博客园读者有用:之前我评估"Claude Code 启动慢是 Node.js runtime 拖累"的优化方案时,假设的是"换成 Bun 跑 Claude Code 这个 CLI 本身"。但现在看 Simon 的取证结果,Claude Code 早就已经跑在 Bun runtime 上了 —— 启动慢不是 Node.js 拖累,而是 Claude Code 自己启动时要加载的模型/MCP server 配置太多。这改变了优化方向:不要再去想"换 runtime",而是想"启动时 lazy load 哪些 MCP server / 哪些 sub-agent 真正需要 eager init"。

含义 5:"AI 重写 + 闭源协作"的开发者信任成本

这是 HN 评论里最分裂的话题,几条核心长评论全在这个点上:

having an LLM rewrite the entire thing as an experiment and then just going with it a few weeks later kills any incentive for a community to build up around it. It's a clear signal that every basic aspect of the runtime can change on a whim.
(jeroenhd, HN 48966569 第 1 条长评论, 697 chars)

I'm concerned that the complete rewrite in an entirely different language is not a sound technical decision and instead is a ploy to shed copyright claims from past contributors.
(locknitpicker, HN 48966569 第 4 条长评论, 642 chars)

Switching from Zig to Rust effectively alienates that community.
(pdp, HN 48966569 第 9 条长评论, 237 chars)

博客园读者对这种争议天然敏感,因为国内很多团队这两年也在做"AI 重写 legacy 系统"的项目,踩的坑跟 Bun 这件事结构上很相似:AI 重写 2-3 个月看起来很爽,6 个月后维护成本 + 团队信任成本一起爆发。Bun 这件事是一个公开的、有人监督的实验,博客园读者可以拿它当 checklist:

• 原贡献者版权处理:Rust 重写后,原 Zig 代码贡献者的版权在 Bun 后续版本里还算不算?locknitpicker 的质疑虽然没被官方回答,但 GitHub 仓库 oven-sh/bun 的 LICENSE 文件改了没?
• AI 协作的可追溯性:563 个 .rs 文件里有多少是 Claude Code / Cursor / Aider 类 agent 生成的? foxes 提的 "thousands of PRs from claude agents or whatever" 是真的吗?(我目前没法独立验证,只能引用 HN 评论原文)
• 社区贡献者激励:从 Zig 切到 Rust 之后,Zig 社区的 contributor 还会不会回去贡献?Bun 之前靠 Zig 的"小而精"开发者社区吸引人,现在这部分人已经被 _pdp_ 那条评论说 "effectively alienated"

四、Jarred Sumner 的辩护(atonse 替代发言)

有意思的是 HN 长评论里 atonse 的发言(682 chars, 第 3 条长评论)看起来是替 Jarred Sumner 团队 / 维护者发言,核心论点:

It's made absolutely no negative difference, as we've seen in the real world in the last 60 days since the merge. ... I've never met Jared or the bun team but I don't understand all the personal attacks, I just feel the need to correct the facts. Literally who cares what language a JS toolset is written in? It's not like they ported JavaScriptCore (the actual JS runtime) to rust even. All that stuff is largely untouched.
(atonse, HN 48966569 第 3 条长评论)

这条评论里有个关键事实澄清:Bun 切到 Rust 不是整个 runtime 切,JavaScriptCore(JSC)还在原位。我之前误以为 Bun runtime 整体都被重写了,atonse 这条纠正了 —— Rust 重写的是 bundler / dev_server / production server 这层,JS 引擎还是 WebKit 的 JSC。这条细节写进我自己的项目笔记了,博客园读者如果之前也误解了可以同步更新。

五、目前还没完全搞清楚的几个点(局限与待验证项)

按博客园实操文章惯例,以下 6 条是我跑完取证后还没解决的开放问题,留给读者一起判断:

• Bun v1.4.0 完整 changelog 何时公开(待验证) —— Simon 文章发出来 5 小时内我去看 Bun GitHub,还是只有 v1.3.14 的 release tag。Anthropic / Jarred 是否会同步公开 v1.4.0 的 release notes?如果会,大概什么时候?
• bundler/bundle_v2.rs 在 Claude Code 启动链路的实际调用点(不足) —— 我只确认了文件存在于 binary 里,但没确认 Claude Code 启动时是不是真的会触发 bundler。这个需要 hook strace -f -e openat 看实际 syscall 才能验证
• Anthropic 跟 Bun 团队的 preview access 协议是不是有书面条款(待验证) —— embedding-shape 那条评论问的"governance structure",目前 Bun 官方仓库我没看到任何 governance doc。Anthropic 的 engineering blog 也没发文解释 Bun 合作模式
• Zig → Rust 切换后的 contributor 流失率(待验证) —— _pdp_ 提的 Zig 社区"effectively alienated"我没法独立核实。GitHub 仓库 oven-sh/bun 在 6 月 17 日 merge 后的 30 天 contributor 数变化我没统计,博客园读者可以拿这个数据做对比
• strings 命令取证的盲点(坑点) —— 如果 Claude Code 后续版本 strip 了 .rs 文件路径或者 version string(比如用 objcopy --strip-debug),strings | grep 这套方法就失效了。取证结论的"硬"是相对当前的 binary 状态,不是绝对真理
• atonse 这条评论是不是 Jarred 本人或团队成员发的(不足) —— 我没法独立验证。HN handle atonse 没有任何 "I am Jarred" 自陈,如果按字面证据,我只能当成"立场偏支持 Jarred 的第三方"引用。如果有人能在评论区确认 atonse 的身份,博客园读者可以重新评估这条评论的权重

六、适用场景与不适用建议

场景	建议
你日常用 Claude Code,想验证它跑在什么 runtime 上	直接跑本文 §二 两条 strings 命令,5 秒拿到答案
你在评估"AI 重写 legacy 系统"的可行性	把 Bun 这件事当公开的、有人监督的实验样本,跟踪 3-6 个月再下结论
你在做 CLI 工具的依赖治理	看 Claude Code 的 changelog 时,主动 grep Bun / Node.js / Rust 这些 runtime 关键词,别只看 major feature
你在国内团队推动 SDK / CLI 重写	§三 含义 1 提到的"接口稳定性" + §三 含义 5 的"贡献者信任成本"两个维度都做一次 impact analysis
你想参与 Bun 项目的开源贡献	暂时观望 governance 透明度,等 Anthropic / Jarred 出书面 governance doc 再判断

七、参考链接

1. Simon Willison 原博客:https://simonwillison.net/2026/Jul/19/claude-code-in-bun-in-rust/
2. HN 讨论:https://news.ycombinator.com/item?id=48966569
3. Bun 官方仓库:https://github.com/oven-sh/bun
4. Jarred Sumner 关于 Rust 重写的原帖(HN 上的"Rewriting Bun in Rust"讨论):https://news.ycombinator.com/item?id=48496123 (注:这是 earlier 讨论的 ID,Simon 文章引用,具体 ID 请以 Simon 原文为准)
5. Claude Code changelog:https://docs.claude.com/en/release-notes/claude-code (v2.1.181 release notes, 2026-06-17)

(本文不构成对 Bun 项目 / Anthropic 公司的任何投资 / 采用建议,所有数字均来自 Simon Willison 文章原文 + HN 公开评论引用,博客园读者可独立查证)