Bun 1.4 的 Rust 重写：15800 个 AI 提交，到底换来了什么
Bun 1.4 的 Rust 重写：15800 个 AI 提交，到底换来了什么
Bun 换 Rust 重写，这事的走向越来越不对劲了。
先别管"重写后性能倒退"这个说法有没有硬 benchmark——它更可能是表象。真正值得看的，是这次重写是谁写的。
790 个人类提交，15800 个机器人提交
长期用 Bun 的开发者 tipiirai 在博客里拉了一组 GitHub 数据。过去一个月，Bun 的提交里：
- 15800 个来自 robobun（AI agent）
- 1600 个来自 autofix-ci（AI 修复 bot）
- 790 个来自 Jarred（那个真人类作者）
人类写的代码，占比不到 4%。
更刺眼的是 Jarred 自己发的一条推文，tipiirai 原文引用了它："六个月前，Bun 的 PR 大多是人在提示 Claude；现在，大多是 Claude 在提示 Claude。"
翻译一下：以前是人指挥 AI 写代码，现在是 AI 指挥 AI 写代码，人站在旁边看。
5000 个 open PR，是新的技术债
Bun 现在的 open pull request 超过 5000 个。对比一下：React 441 个，OpenClaw 2200 个。GitHub 官方建议单一分支的 open PR 别超过 1000，否则 mergeability 检查会开始超时。
代码的产出速度，已经远远超过 review 和 merge 的速度。AI 能把代码写出来，但没人能把它读明白、审明白、合明白。
技术债的形式变了。以前是"代码写得烂"，现在是"代码写得快，快到你来不及看"。
内存安全这个理由，也没兑现
当初说重写是为了内存安全——Zig 手动内存管理容易出问题，换 Rust 靠编译器兜底。但 tipiirai 指出，Rust 代码里的 unsafe 块数量，让这个理由站不住脚。
Zig 作者 Andrew Kelley 的话更狠。他在文章里说，Bun 的代码库让他"越来越惊骇"："hack 叠 hack，滥用断言。Jarred 早在接触 LLM 之前，写的就已经是 slop 了。"
我的看法：如果重写前是 slop，那让 AI 更快地写更多 slop，只是把问题规模化，不是解决问题。
这场重写，是 AI 写代码最大的一次公开实验
tipiirai 说了一句很准的话：这次重写，是"AI agent 能不能接管一个生产代码库"最受关注的真实测试。人在旁边主要做指挥，不一行行读代码。
Anthropic 的名声也押在上面。成，就是 agentic coding 的最佳广告；败，就是反方向的信号。
所以这事的严重程度，超过"Bun 要不要升级"。它在替整个行业回答一个问题：AI 的 commit 数量，能不能等价于代码质量？
目前 Bun 给出的答案，是"不能"。而且代价不便宜：三个月没有 stable 发布，是 2022 年以来最长的一次间隔；社区里"tomorrow 到了吗"已经成了梗。
你今天可以做的事
不用急着弃用 Bun，更不用急着看衰 AI 写代码。但如果你团队也在让 AI 重写或大规模生成代码，先问三个问题：
- 你重写是为了什么？性能就先把基线量清楚，别拿"内存安全"当遮羞布。
- 谁在 review？AI 一天能吐几百个 commit，你的人一天能审几个？缺口就是技术债。
- 敢不敢让 AI 碰安全关键的路径？unsafe 块、注入点、权限边界——这些地方 AI 写爽了，出事了它不负责。
结论一句话：AI 把"写代码"变得便宜了，但把"读懂代码"变得更贵了。别让前者掩盖后者。
✨ 本文由 DeepSeek 生成初稿，Claude 审核润色。
来源：
