The Bun Rust Rewrite: AI Porting, Undefined Behavior, and the 'Vibe-Coding' Debate

Bun 运行时最近宣布使用 agentic AI 用 Rust 重写，这引发了即时的兴奋，但随后很快就迎来了一波技术审查。最近出现的一个 GitHub issue 揭示了新的代码库无法通过基本的 Miri 检查，并且即使在 "safe" Rust 中也会允许发生未定义行为 (Undefined Behavior, UB)。

这种情况已成为开发者社区中更广泛辩论的焦点：通过 AI 驱动的大规模代码库移植是通向更好软件的可行路径，还是向 "vibe-coding"（氛围编码）迈进的一种危险趋势——即为了速度和营销噱头而牺牲严谨性？

The Technical Core: Miri and Undefined Behavior

这场争议的核心在于对 Miri 的使用，它是 Rust 中级中间表示 (MIR) 的解释器。Miri 的设计目的是检测未定义行为 (Undefined Behavior)——即 Rust 语言规范中未定义的行为，这些行为可能导致不可预测的崩溃、安全漏洞或静默数据损坏。

在 Rust 中，语言的 "safe" 子集被保证是不会出现 UB 的。然而，当开发者使用 unsafe 块来执行底层操作时（这在 Bun 这样的运行时中很常见），他们必须承担确保安全不变性得以维持的责任。Bun 仓库中提出的问题表明，AI 生成的移植版本暴露了即使从 safe code 调用也会导致 UB 发生的 API。

正如一位社区成员所注意到的，问题不仅仅在于 UB 的存在，而在于未能正确封装 unsafe code：

"The issue isn't the existence of undefined behavior that miri would catch. The issue is exposing an API that allows undefined behavior from safe code... Temporarily in a porting stage incorrectly marking some unsafe functions as safe isn't a real issue [unless] they made an actual release with the code in this state."

Porting vs. Rewriting: A Crucial Distinction

许多反对意见源于对项目目标的误解。虽然在公开讨论中使用了 "rewrite"（重写）一词，但几位工程师认为这实际上是一个 port（移植）。

在移植 (port) 中，目标是尽可能直接地将一种语言 (Zig) 的逻辑翻译成另一种语言 (Rust)。这通常会导致 "unidiomatic"（非惯用）代码——即看起来像 Zig 代码的 Rust 代码。支持这种方法的论点是，它可以让代码库快速进入更强大的类型系统，为随后迭代改进为惯用且安全的 Rust 代码提供基础。

然而，批评者认为，使用 LLM 进行一对一翻译是低效且危险的。一些人建议，使用确定性的翻译工具 (如 c2rust) 会比 agentic AI 更安全，因为输出结果会具有与输入相同的保证，而不是通过 "vibe-coding" 产生，并可能引入原始 Zig 源码中不存在的新且微妙的 bugs。

The "Vibe-Coding" Controversy

Bun 事件引发了关于 AI 在软件工程中的角色的哲学冲突。一方是那些认为这在开发演进中是一次必要的实验的人。

"It's a throw thing at the wall and see what sticks situation... LLMs will improve... Using LLMs in an agentic way will improve. So what happened here is a mess, but you gotta break a few eggs to make a souffle."

另一方是那些担心行业正在失去对工程严谨性的掌控。在没有经过详尽的人类审查的情况下合并一个百万行 AI 生成的 diff，被一些人视为更大 "AI 泡沫" 的征兆。

"I think the only way to interpret a one million line LLM-generated diff with no proper reviews... is that my company no longer has an interest in understanding, or even looking at, its own code."

Marketing vs. Engineering Reality

除了技术层面，还有对 "flashy announcement"（华丽的发布会）文化的批判。高调的宣传 (例如 "Bun rewritten in Rust in two weeks") 与随后在 GitHub issue 中默默地纠正记录的行为，这种不对称性是公关 (PR) 中的一种已知模式。

批评者认为，重写的速度可能更多是一种营销噱头，而非技术里程碑。然而，支持者指出，只要稳定版本仍然使用 Zig，对用户的风险就是极小的，且 Rust 移植版本作为项目可维护性的长期投资。

Conclusion

Bun 传奇事件为当前 AI 能力的极限提供了一个案例研究。虽然 LLM 可以以惊人的速度生成大量代码，但代码的 verification（验证）仍然是瓶颈。正如社区所观察到的，当代码生产率提高 100 倍时，验证过程的鲁棒性必须成比例地提高，以避免创造出一个由未经验证的逻辑组成的 "monstrosity"（怪兽）。