先说结论：换的是运行时，不是整个 Claude Code

这次迁移最值得看的，不是“Rust 又赢了一次”的语言争论，而是一套已经安装在大量用户设备上的开发工具，在替换关键运行时后没有要求用户迁移配置，也没有制造明显的兼容事故。Bun 团队称，Claude Code v2.1.181 起使用 Rust 版 Bun；Linux 生产遥测中的启动时间中位数从 517ms 降至 464ms。这个数字只对应指定版本和 Linux 启动阶段，不能外推到模型响应、工具执行或所有系统。

Claude Code 本身仍包含产品逻辑、界面、模型调用和工具链。Rust 版 Bun 是其中负责运行 JavaScript/TypeScript 相关代码的底层组件。把标题写成“Claude Code 已由 Rust 重写”，会把组件迁移误写成整机换代。

为什么 Simon Willison 的检查有价值

Willison 没有只转述厂商博客。他对本机 Claude Code 可执行文件运行 `strings`，找到 `Bun v1.4.0`，又提取出 563 个以 `.rs` 结尾的源码路径；随后通过 `BUN_OPTIONS` 预加载脚本读取内嵌运行时版本，也得到 1.4.0。这些结果与 Bun 团队的说法相互印证，说明公开安装包里确实带有尚处 canary 阶段的 Rust 版 Bun。

不过，字符串扫描不能证明所有代码路径都会调用这些模块，也不能替代性能、内存和崩溃率测试。它适合核验“二进制里有什么”，不适合单独证明“迁移后一定更稳定”。

11 天重写应该怎样理解

Bun 官方复盘称，一名工程师使用预发布 Claude Fable 5 和 Claude Code 动态工作流，让 64 个 Claude 持续运行 11 天，把移植推进到全平台测试通过。文章同时描述了明确的人类控制：先写端口计划和生命周期指南，再让实现者与对抗审查者分工，审查者专门寻找不一致和失败理由，最后由工程师对照 Zig 与 Rust 代码检查。

因此，更准确的内容角度是“一个工程师如何设计高并发 AI 工程流程”，而不是“AI 11 天自动重写 Bun”。模型扩大了并行实现和审查能力，但测试标准、合并权、风险接受和生产发布仍由团队承担。

对独立开发者最实用的启示

大迁移不必靠一次性切换制造戏剧性。可以先建立行为一致性测试，为旧版和新版收集相同指标，再选择一个真实但可回滚的产品做首个生产消费者。用户无感不是新闻传播上的缺点，而是基础设施迁移的理想结果。

评估类似案例时，应至少分开看四项：功能兼容是否通过、故障和内存问题是否减少、二进制与启动性能是否改善、出现回归时能否快速退回旧运行时。语言只是手段，可靠的验证与发布纪律才是可复用的方法。