Bun 的这个 PR 合并以后，很多人第一反应是：又一个 JavaScript runtime 投向 Rust 了。
这个反应不奇怪。Deno 最早是 Go 写的，后来换成 Rust；Bun 原来是 Zig 写的，也切到了 Rust。我就是在 Deno 用 Rust 重写的时候一边学 Rust 一边给 Deno 修 bug 的，所以看到 Bun 这次迁移，多少有点熟悉的感觉。
不过这篇文章不想写「Rust 赢了」「Zig 输了」。
我更想聊的是另一件事：Bun 这次最大的看点，它展示了一种未来软件开发会越来越常见的方式：用 AI 参与一个庞大真实产品的跨语言迁移。
PR #30412 的标题就是 Rewrite Bun in Rust，已经在 2026 年 5 月 14 日合并。规模很大：6755 个提交，2188 个文件变更，新增代码超过 100 万行。
PR 作者 Jarred 后来补充了一段说明，比一开始的信息更完整：
-
• 已经通过 Bun 既有测试套件的全平台测试。
-
• 顺手修了一些内存泄漏和 flaky tests（Rust 最擅长的领域）。
-
• 二进制体积缩小了 3MB - 8MB。
-
• benchmark 结果从持平到更快。
-
• 代码库整体上还是同样的架构、同样的数据结构。
-
• Bun 仍然很少使用第三方库，也没有改成 async Rust。
-
• 想试的话，可以跑
bun upgrade --canary。
这段说明很关键。它告诉我们，这并非「生成了一堆 Rust 文件，还没跑起来」的状态。至少按作者的说法，Bun 已经把这次迁移推进到了 canary 可以试用的阶段。但作者也保留了边界：进入非 canary 版本之前还有优化工作，清理会在后续 PR 里继续做。
如果只看语言选择，这件事很容易和 Deno 放在一起讲。
Deno 从 Go 换到 Rust，Bun 从 Zig 换到 Rust。两个项目都在 JavaScript runtime 这个方向上，最后选择了 Rust 作为底层实现语言。这当然说明 Rust 在这类系统软件里的吸引力很强：性能、内存安全、工具链、生态、跨平台能力，都很适合这类项目。
但 Bun 这次比「换语言」更有意思。
Deno 当年换 Rust，本质上还是一个比较传统的软件工程迁移。人读代码，人写代码，人修 bug。Bun 这次发生在 AI 编程工具已经比较成熟的阶段，它的仓库里出现了 PORTING.md 和大量 .claude/workflows，它更像是把迁移过程拆成一条流水线。
PORTING.md 里有一个很重要的设定：Phase A 先把 Zig 文件翻译成同目录下的 Rust 草稿，目标是忠实捕捉逻辑，不要求马上编译；Phase B 再按 crate 去解决编译、所有权、平台和性能问题。
这和很多人想象的 AI 写代码不一样。不是对模型说一句「帮我把 Bun 改成 Rust」，然后等一个奇迹。真正有用的是：先把迁移规则写清楚，再让 AI 按规则批量执行。比如哪些库不能引入，哪些架构不能动，哪些类型不能乱换，哪些 allocator 语义要保留，哪些 unsafe 边界只是从 Zig 世界搬到了 Rust 世界。规则越细，AI 越不容易自由发挥。
这也是未来软件开发里很重要的变化。以前开发者主要产出代码，以后在很多大型工程里，开发者的一个重要产出会变成「约束」。
你写的不只是代码，还有：
-
• 迁移手册。
-
• 类型映射规则。
-
• 测试策略。
-
• review 标准。
-
• CI 检查。
-
• 不允许改变的架构边界。
Bun 这次的 .claude/workflows 很能说明问题。
有的工作流负责把 Zig 文件翻译成 Rust 草稿，有的负责对照规则做验证，有的负责修复，有的负责 lifetime 分类，有的负责 unsafe audit，有的负责 Windows bughunt。
以前的流程是：「AI 帮我补一个函数」了，现在的流程是：「AI 参与一个跨语言、跨模块、跨平台的工程迁移」。
我觉得这会对未来的软件开发产生很大影响。很多以前太贵、不敢动的迁移，可能会重新进入工程选项。老 C/C++ 模块迁到 Rust，大型脚本工具链的热点部分迁到 Rust，内部 DSL 迁到更标准的语言，甚至多年没人敢碰的遗留服务做结构化重写，都可能因为 AI 的加入变得没那么离谱。
当然，没那么离谱不等于没风险。
跨语言迁移最难的地方从来不是语法。Zig 里的很多东西，靠 allocator、deinit、comptime、手写指针结构和项目约定维持。Rust 可以用 Drop、借用检查、类型系统、lint、工具链接住一部分问题，但前提是映射正确。
如果只是把 *T 改成一个看起来更 Rust 的类型，那可能只是把 bug 包装得更现代。所以 Jarred 那句「架构和数据结构基本保持不变」很重要。它说明这次迁移是在尽量保持原来设计的前提下，用 Rust 重新表达它。
这件事真正有价值的部分，是 Bun 团队希望拿到 Rust 编译器和工具链对内存问题的辅助。作者也说了，这类内存 bug 过去几年消耗了团队大量开发和调试时间。
AI 写代码越快，静态约束就越重要。如果没有编译器、类型系统、测试和规则文档夹住它，AI 只是把错误生成得更快。反过来，如果一个项目有清晰的边界、比较完整的测试、可机器读取的规范，AI 就有机会变成高吞吐的工程劳动力。
我觉得这件事更像是一个信号：未来的软件开发会变成三层。
第一层是 AI 负责吞吐。生成草稿、批量迁移、扫明显问题、跑自动验证。
第二层是工具负责约束。编译器、类型系统、lint、测试、CI、benchmark，把问题尽量提前暴露。
第三层是人负责判断。哪些结果可信，哪些地方必须手工看，哪些行为不能改，哪些风险可以接受，哪些问题必须阻断发布。
开发者不会消失，但位置会变。过去我们常说「程序员写代码」。以后更准确的说法可能是：程序员设计一个能让 AI 安全工作、能让错误尽早暴露的工程系统。
现在很多社区都开始讨论这件事，然而这些讨论里，低质量的部分很多。比如「Zig 完了」「Rust 赢麻了」「AI 写的都是垃圾」。这类说法很适合吵架，不太适合帮助我们理解发生了什么。
真正值得看的问题是：
-
• 这么大的自动迁移，怎么 review？
-
• 原来的 Zig 语义，Rust 版本有没有真的表达出来？
-
• 测试通过以后，还需要多少 canary 覆盖？
-
• 平台差异、性能路径、FFI 边界，会不会在真实项目里暴露问题？
-
• 如果后续有 bug，团队能不能快速定位和修复？
这些问题比语言站队重要。
最受开发者关注的是性能。官方说 benchmark 从持平到更快，这当然是好消息。但具体到你的项目，还是要用自己的真实工作负载测。冷启动、安装依赖、构建、热更新、服务端请求路径，哪个关键测哪个。
我看 Bun 这次迁移，最大的感受是：AI 会改变软件开发里的很多流程和假设。
以前，一个项目太大，那么就很难重写。现在，如果有足够清楚的规则、测试和工具，AI 可能先把第一版迁移成本降下来。它不保证成功，但它让「试一试」的成本变低了。
这会改变团队做技术决策的方式。很多过去因为人力不够而长期拖着的问题，可能会被重新评估。团队会更愿意问：如果 AI 能先生成 70% 的可审查草稿，我们是不是可以做这次迁移？
但最后还是那句话：AI 不会替你承担生产责任。它可以写代码，可以翻译代码，可以帮你跑一轮 review。但架构边界、发布节奏、兼容性判断、线上问题的责任，仍然在人这边。
Bun 用 Rust 重写完成这件事，最有意思的地方就在这里。它是一次很公开的工程实验：当 AI 能参与大型代码迁移以后，软件开发会变成什么样。
资料来源
-
• GitHub PR：oven-sh/bun#30412 - Rewrite Bun in Rust
-
• 早期 porting guide 提交：46d3bc29 - docs/PORTING.md
-
• GitHub 合并提交：23427dbc
-
• Deno 背景：Deno was initially written in Go, later replaced with Rust
-
• HN 讨论：Bun implementation is being ported from Zig to Rust
-
• Ziggit 讨论：Bun is being ported from Zig to Rust