JavaScript 运行时 Bun 宣布，原本约 53.5 万行的 Zig 代码已经被迁移到 Rust。整个过程持续了 11 天，产生了 6778 次提交，迁移后的代码通过了 Linux、macOS 和 Windows 上的完整测试。
更夸张的是，这件事主要由 Bun 创始人 Jarred Sumner 一个人组织完成。
他使用了 Claude Fable 5 的预发布版本，让 Claude Code 同时运行约 50 套动态工作流，高峰时期维持 64 个 Claude 实例持续工作。按照 Anthropic API 的公开价格估算，整个迁移消耗约 16.5 万美元。这几乎像一个不太靠谱的营销故事，但它真的发生了。
Bun为什么突然从Zig转向Rust先补一个容易被误传的背景。
Anthropic 不是今年 6 月才收购 Bun，而是在 2025 年 12 月完成收购。Bun 随后成为 Claude Code 的重要底层运行环境，Anthropic 自然也开始更加关注它的稳定性、内存占用和长期维护成本。 Zig，并不是一个错误。
Jarred Sumner 在官方文章里仍然明确表示，如果没有 Zig，他不可能在早期一年内独立完成 Bun。Zig 提供的底层控制能力、编译期能力和开发效率，是 Bun 能快速跑出来的重要原因。
问题出现在项目变大之后。
Bun 同时包含运行时、包管理器、构建工具、测试框架、HTTP 服务、Node.js API 兼容层等大量能力，又混合了 JavaScriptCore 的垃圾回收和手动内存管理。随着代码量不断膨胀，use-after-free、double-free、内存泄漏以及复杂清理逻辑开始成为长期负担。
在 Zig 中，一些资源释放需要开发者在每个调用位置手动处理。Rust 的所有权、Drop 和借用检查不能消灭所有 Bug，但能提前拦住一部分内存生命周期问题。
所以 Bun 团队最终选择的并不是“重新设计一个 Rust 版 Bun”，而是先完成一次尽可能机械化的迁移：
架构不大改，行为不大改，测试不删除，功能不趁机重做。
先把 Zig 文件映射成 Rust 文件，让旧测试全部通过，之后再逐步减少 unsafe，慢慢把代码调整得更符合 Rust 的习惯。来就喊“推倒重做”，其实不是一回事。
Zig创始人的质疑也有道理Bun 公布迁移过程后，Zig 创始人 Andrew Kelley 很快写了一篇长文回应。
他的语气不算客气，甚至直接讽刺 Bun 的文章写得过于专业，“像是某家巨头公司的营销部门在这篇文章上押了很多钱”。
但他真正提出的技术问题，值得认真看。
比如 Bun 把稳定性提升归因于 Rust，但 Andrew 认为，很多问题本质上是过去没有投入足够的工程资源，而不是 Zig 语言本身解决不了。
Bun 还强调迁移后的测试全部通过。Andrew 则反问：如果这些测试足够覆盖一百万行新代码，为什么过去没有发现 Zig 版本里的那些 Bug？
除此之外，Bun 展示的部分性能和体积改善，来自 LTO、减少过度使用 comptime、链接优化以及重新整理代码。这些工作并不天然属于 Rust，理论上也可以在原来的 Zig 项目中完成。
他还指出，Bun 公布了启动速度、内存和二进制体积，却没有公布迁移前后的完整编译速度对比。“Rust 重写没有价值”。
它提醒我们，语言迁移经常会夹带大量清理技术债的工作。最后效果变好了，到底是新语言带来的，还是团队终于愿意投入资源把旧问题处理掉了，很难完全分开。
当然，Andrew 也不是完全中立的一方。
他后来修改了文章结尾，承认自己对 Bun 团队带有尚未处理好的怨气，也承认公开批评可能让其他 Zig 用户担心：将来自己离开 Zig，会不会同样被语言创始人追着骂。
这场争论里有技术，也有商业，还有两支团队合作破裂后积累的情绪。
真正变化的，是重构的经济账
过去的软件工程里，“重写”几乎是一个危险词。
一个运行多年的核心系统，代码可能有几十万行，文档不全，测试不足，业务逻辑藏在大量细节里。即使团队知道技术栈已经不合适，也不敢轻易动手。
因为传统重构要面对几笔很现实的成本：
旧系统还要继续修复，功能不能完全停更；新旧系统需要同时维护；核心人员可能在迁移过程中离职；等新系统上线时，原来的业务需求可能又变了。
Bun 团队自己估计，如果完全依赖人工，这次迁移大约需要三名熟悉代码库的工程师工作一年。
现在，这个过程被压缩到了 11 天。
虽然 16.5 万美元的模型费用并不便宜，但和三名高级工程师一年的成本相比，已经进入企业可以认真计算投入产出比的范围了。原本“想都不敢想”的项目，可能会重新摆上会议桌：
十年前的 Java 服务升级到新版本，Python 服务迁移到 Go，旧前端框架替换，单体系统拆分，跨平台客户端重写，甚至数据库和基础设施迁移。
AI 没有让重构变得没有风险，但它正在快速降低搬运代码、修复编译错误和进行机械替换的成本。
代码便宜了，测试反而更值钱
Bun 能完成这次迁移，有一个经常被标题忽略的前提：它拥有一套基本不依赖底层语言的 TypeScript 测试。
迁移过程中，Claude 不是凭感觉判断代码有没有写对，而是不断执行编译、测试、对比和修复。
Bun 团队还让不同 Claude 实例承担不同角色：一个负责实现，另外两个只负责挑错。审查模型看不到实现模型的完整推理，只拿到代码差异，并被要求假设这段代码存在问题。
这种对抗式审查发现了不少“能够正常编译、看起来也很合理”，但运行后会产生内存错误或边界异常的代码。发很直接。
未来真正值钱的，可能不再是那几十万行旧代码，而是围绕它建立起来的：
业务测试、接口契约、数据校验规则、性能基线、监控指标、故障案例和验收标准。
代码可以让 Agent 快速重写，但什么结果才算正确，不能临时让模型猜。
很多企业现在急着引入 AI 写代码，却还没有完整的自动化测试。这样的项目一旦大规模重构，生成速度越快，风险积累得反而越快。
程序员的工作也在变化这次迁移不是 Claude 接到一句“把 Bun 改成 Rust”之后，自己默默完成的。
Jarred Sumner 先让模型整理 Zig 到 Rust 的迁移规则，又分析了不同结构体字段的生命周期，把复杂问题拆成多个工作队列，再持续观察 Agent 输出、调整流程和处理异常。
他做的事情已经不只是写代码。
更像是在管理一支不会疲劳、但很容易自信犯错的工程团队。
这可能也是未来高级程序员的重要能力：
不再亲手完成每一行代码，而是定义迁移规则、搭建验证环境、分配 Agent 任务、设计审查机制，并在系统出问题时判断究竟是代码错误、测试缺失，还是整个生成流程出了问题。
代码生产越来越便宜，但责任并没有跟着消失。
凌晨系统报警时，仍然需要有人知道数据为什么错了；线上出现边界 Bug 时，仍然需要有人理解业务和架构；模型生成了一百万行代码，最后也必须有人决定它能不能进入生产环境。
企业可以重构，但别为了展示AI而重构
Bun 的迁移确实也是一次效果惊人的 Fable 5 能力展示。
“一个人、11 天、百万行代码”，这种数据天然适合传播。Anthropic 收购 Bun 后，用自家模型完成如此大规模的迁移，也很难完全排除产品宣传和技术展示的考虑。
但有营销价值，不代表没有工程价值。
真正需要警惕的是，企业因为看到了这个案例，突然决定把所有旧系统推倒重来，只为了证明自己也在使用 AI。
一次重构是否值得启动，至少要回答几个朴素的问题：
旧系统到底遇到了什么问题？迁移后准备改善哪些可量化指标？有没有能够跨语言验证结果的测试？谁负责维护新系统？迁移失败后能不能回滚？
这些问题没有答案，Agent 数量再多，也只是更快地制造一套新技术债。
Bun 的故事不是在证明 Rust 全面战胜了 Zig，也不是在证明以后所有系统都应该重写。
它真正证明的是：在测试足够完整、核心工程师足够熟悉系统，并且能够建立自动生成、审查和验证闭环的情况下，过去需要一年完成的大型迁移，已经可能被压缩到几周甚至十几天。
软件工程里最昂贵的东西，正在从“写出代码”转向“判断代码是否正确”。
这才是 Bun 百万行重写背后，最值得程序员和企业认真看的变化。
你觉得以后企业会更愿意重写旧系统，还是会因此制造出更多看似先进、实际上没人敢维护的新项目？