如果我说，有一个百万行级别的开源项目，被 AI 在 11 天内用另一种语言完全重写，API 成本只要 16.5 万美元——你大概率会觉得这是夸大其词。
但如果我说，这同一个项目的创始人，正在被原语言社区公开批评代码质量，而新代码里留下了 2.7 万行连 Rust 编译器都保护不了的 "unsafe" 代码块——你可能会觉得这事没那么简单。
两句话都是真的。
它们指向同一个问题：当 AI 能在一周半内完成人类需要一年的工程时，我们该感到兴奋，还是不安？
答案是：都有。
一、"Claude，把 Bun 用 Rust 重写一遍"
时间回到 2021 年 4 月。程序员 Jarred Sumner 在 Hacker News 上看到了一页纸——Zig 语言参考手册。他被 Zig 的精简和底层控制力深深吸引，决定用它构建一个野心的产物：一个从头开始写的 JavaScript/TypeScript 运行时，要快过 Node.js。
这个项目叫 Bun。
五年后，Bun 的 CLI 每月下载量超过 2200 万。Claude Code、OpenCode 等工具选择它作为运行时，Vercel、Railway、DigitalOcean 原生支持它。Bun 从一个公寓里的个人项目，长成了 JavaScript 生态里不可忽视的存在。
但五年来，有一件事始终在侵蚀 Jarred 的睡眠质量。
Bun 是用 Zig 写的。Zig 像 C 一样，不帮你管理内存。Bun 要处理的场景——JavaScript 引擎的垃圾回收 + 底层 I/O 的手动内存管理——刚好落在了 Zig 最薄弱的环节。结果是一长串 Bug 列表：use-after-free、double-free、错误路径忘记释放内存、竞态条件崩溃……
Jarred 在他的博客里列了一张单子，光是 Bun v1.3.14 一个版本修复的严重内存安全漏洞，就超过了十项。他写道："我已经厌倦了每天睡前为 Bun 的崩溃而焦虑。"
传统方案是加一个严格的内存管理风格指南，但风格指南靠 Code Review 执行，而 Code Review 的执行力取决于人的注意力。
另一个方案是重写。但传统经验告诉我们：重写是个糟糕的主意。项目规模越大，重写的风险越高。5000 多行代码的项目改语言，一个团队至少花一年。这一年里不做新功能、不修 Bug、不应对安全漏洞——对一款每月 2200 万下载量的产品来说，不可行。
但 Jarred 有一个别人没有的优势：他所在的 Anthropic，刚刚做出了当时最强的编程模型 Claude Fable 5。
他也有一款刚刚升级的工具：Claude Code 的动态工作流（Dynamic Workflows），支持多步骤的自主任务编排。
2026 年 5 月，Jarred 做了一个决定：花一周时间测试，看看 AI 能不能把 Bun 用 Rust 重写。
他原以为不会成功。
几天后，测试通过率开始飙升。
二、机器翻译式的重写
Jarred 选择的策略，某种程度上是反常识的。
他没有让 AI 做架构重构——没有"把 Zig 的优势翻译成 Rust 的最佳实践"。他让 AI 做的事情，本质上是一次"机器翻译"：把 Zig 代码逐行映射到 Rust，保持相同的架构、相同的逻辑结构、相同的行为。
这是一个极其务实的决定。
原因很直接：Bun 的测试套件是用 TypeScript 写的——它不依赖运行时的编程语言。只要测试通过了，就证明新代码的行为和旧代码一致。而保持架构不变，意味着"行为保持不变"的概率最大。
结果令人震惊：11 天，约 100 万行 Rust 代码（包含自动生成的绑定代码），API 费用约 16.5 万美元。
在科技圈看来，这笔账算得让人恐惧。一个正常团队用 Rust 重写 Bun 的规模，保守估计需要一年的时间和数百万美元的工程师薪酬。AI 把这两项分别压缩到了 1/30 和 1/10。
Jarred 本人也承认，如果没有 AI，这根本不会发生。"语言选择曾经是一条单行道。"
但"机器翻译式重写"有一个致命弱点。
三、2.7 万行 unsafe 与信任赤字
新代码库里留下了约 2.7 万行 unsafe Rust 代码。
在 Rust 里，"unsafe" 是一个特殊的关键字——它告诉编译器："我知道这段代码可能违背 Rust 的安全保证，但我确认它是正确的。" unsafe 本身不是问题，但 2.7 万行 unsafe，意味着有 2.7 万行代码绕过了 Rust 最重要的安全网。
这笔庞大的 unsafe 代码，来自"逐行翻译"的策略本身。Zig 的很多底层操作（指针运算、内存分配）在 Rust 里需要 unsafe 来等价表达。AI 忠实地把它们翻译了过来，但没有做架构层面的重构来减少 unsafe 的使用。
Zig 创始人 Andrew Kelley 在看到这组数据后，公开发表了一篇措辞严厉的博文。
他的核心论点有三层：
第一层：Bun 的 Bug 问题，根子不在语言，在工程习惯。Kelley 说，Zig 团队一直在检查使用者的代码库，而他们对 Bun 的代码库感到"极度恐惧"——"在 AI 时代来临之前，Jarred 就已经在写垃圾代码了。黑客式的补丁摞补丁，滥用断言，从不花时间消除技术债。"
第二层：测试覆盖率的悖论。"Bun 官方声称 100 万行未经过人类审查的 AI 代码因为有测试用例所以是安全的，"Kelley 反问道，"如果测试用例真的这么完备，为什么 Zig 版本的时候没能抓出那些烦人的 Bug？"
第三层：AI 降低了工程门槛，但没有降低责任。在 Kelley 看来，AI 让一个糟糕的工程师能更快地写出更多糟糕的代码。这不是 AI 的问题，是管理问题。但 AI 的存在放大了这个问题的规模——一个人用 AI 在 11 天内可以创造的技术债，可能是一个团队需要几年才能还清的。
四、一个工程判断框架：三层信任何时成立
这个故事让我想到一个可以复用的框架：AI 代码的三层信任模型。
第一层：行为信任。"它能通过测试吗？"
这是最浅层的信任。Bun 的测试套件通过了，所以新代码"能用"。这一层是 AI 代码最容易满足的——测试不依赖于代码用什么语言写的。
第二层：维护信任。"未来的开发者能看懂并修改它吗？"
2.7 万行 unsafe 对这个问题的回答是"存疑"。维持现状不变时没问题，但当需要新增功能、修复边缘情况时，开发者面对的是一个"机器翻译"过的、架构非人类直觉的代码库。认知成本不会消失——它只是在今天被转移到了明天。
第三层：归属信任。"如果出了问题，谁来负责？"
这是最深、也最容易被忽略的层。传统软件工程中，每一行代码都有一个"作者"——你写的代码你负责。但在 AI 生成的百万行代码里，"作者"是模糊的。AI 建议的代码片段的 bug 由开发者负责，那 AI 在 11 天内自主生成的百万行代码呢？
Kelley 的愤怒，本质上是第三层信任的崩溃——他不相信任何人对这 100 万行 AI 代码负责。
这套框架不只适用于 Bun。任何正在评估"是否让 AI 写更多代码"的团队，都可以用它来给自己做检查：你停留在哪一层？
五、所以，该怎么做？
如果你是技术决策者——不要只问"AI 写代码能不能通过测试"。追问一句"如果我们团队里最厉害的工程师下个月离职，接手的人能立刻理解这段 AI 代码吗？"
如果你是开发者——"审查 AI 生成的代码"正在成为一项核心技能。不是读一遍看有没有 bug，而是理解它的架构决策、重构意图、以及对未来维护者的友好度。
如果你是开源社区维护者——AI 生成的大规模贡献正在成为新常态。你的社区需要明确的政策：什么级别的 AI 生成代码可以直接合入，什么级别需要人工审查。
最后，回到 Bun 这件事本身。
Jarred 公开承认 Zig 让 Bun 成为了可能，并始终对 Zig 社区保持着诚恳的感谢。这 11 天的重写，未来能不能变成真正可持续的工程，没人知道答案。
但有一点是确定的：AI 跨过的那道槛，不是"能不能写百万行代码"的技术槛——而是"人类是否准备好和 AI 生成的代码共存"的心理槛。
迈过这道槛需要多久，可能比 11 天要长得多。
来源：Bun 官方博客、Andrew Kelley 博文、机器之心/36氪报道