9天、6755次提交、百万行代码：Anthropic如何用Claude Code重构Bun，以及这件事教会我们什么
写在前面
2026年5月14日，一条PR被合并进了Bun的主分支。这条PR包含超过100万行用Rust重写的代码、6755次提交——全部由Anthropic的Claude Code智能体在9天内生成完成。它将Bun的核心运行时从Zig彻底迁移到了Rust，二进制文件体积缩小3-8MB，性能持平甚至略有提升。
这条PR收获了600多个点赞，也收到了400多个点踩。GitHub页面因为涌入太多人而短暂崩溃。
这不是一次普通的技术合并。它可能是人类历史上规模最大的AI辅助代码重写事件，也是JavaScript生态发展二十多年来最具争议的一次基础设施迁移。
本文将深入剖析：为什么Anthropic要在收购Bun之后做这件事？技术层面具体发生了什么？安全审计报告揭示了什么？社区的反应从何而来？以及，作为程序员，我们应该从这件事中学到什么。
一、背景：为什么是Bun，为什么是Zig
1.1 Bun是什么
Bun是一个all-in-one的JavaScript运行时环境，由Jarred Sumner创建。它的定位是Node.js的替代品，同时集成了打包器（bundler）、测试框架（test runner）、包管理器（package manager）等多种工具。简单来说，你可以在Bun上运行JS/TS代码，可以像esbuild一样打包前端资源，也可以像Vitest一样运行测试——全部由同一个二进制文件完成。
Bun的核心竞争力是速度。它使用JavaScriptCore（JSC）引擎（WebKit的JS引擎，与Chrome的V8不同），并大量使用低层优化，在启动时间、执行效率等方面显著优于Node.js。对于那些需要频繁运行脚本、处理大量小型JS任务的开发者来说，Bun的加速效果非常可观。
Bun的GitHub仓库目前有超过9.2万颗星，每周下载量超过700万次，在npm生态中已经成为不可忽视的基础设施。
1.2 为什么选择Zig
Bun最初选择Zig，而非C/C++或Rust，有几个深层原因。
Zig的核心哲学是"没有隐藏控制流"。与C++的隐式内存分配、模板元编程、RAII等复杂机制相比，Zig要求程序员显式管理内存和资源，没有垃圾回收器，也没有隐藏的运行时行为。这种透明性对于系统编程来说是巨大优势——你能100%控制每一字节内存的分配和释放。
对于Bun这样的项目来说，这意味着：可以在不引入完整C++复杂度的情况下，获得与C相近的性能，同时比纯C更容易写出正确的代码。Zig的 comptime（编译时执行）特性也允许在编译期做很多优化，进一步减少运行时开销。
然而，Zig是一门仍在快速演进中的语言，标准库API不稳定，语言特性也在持续迭代。这为长期维护大型项目带来了特有的挑战。
1.3 Anthropic收购Bun：意料之外，却在情理之中
2025年底，Anthropic宣布收购Bun。当时外界普遍认为，Anthropic看中的不仅是Bun作为JavaScript运行时的市场份额，更是一块验证AI编程能力的最佳试验田——让Claude Code在真实的大规模生产级项目上做一次端到端的实战演练。
Jarred Sumner在合并PR后的一条推文中写道："我们已经好几个月没有亲手敲代码了。"这句话迅速在Hacker News上引发热议——它既是AI编程能力的一次展示，也是一记对整个行业敲响的警钟。
二、技术层面：9天里到底发生了什么
2.1 规模与速度
让我们先看一下这次重写的量级：
PR #30412 - Rewrite Bun in Rust
- 变更文件数：2188个
- 新增代码：约100万行
- 删除代码：约4.7万行
- 提交次数：6755次
- 持续时间：约9天
- 生成方式：Claude Code智能体
这个规模是什么概念？Linux内核的某个中等规模子系统的代码量大约在50-100万行。Bun这次一次性迁移了如此体量的代码，且在极短时间内完成，在软件工程史上几乎找不到先例。
2.2 PR #30683：连Zig源码都删了
如果说PR #30412本身还算合理（保留Rust和Zig两套实现并行），那么随后提交的PR #30683就让社区炸了锅：
PR #30683 - Remove .zig source files; rename $zig macros to $rust
Jarred Sumner不仅合入了Rust版本，还计划立即删除所有Zig源码——连过渡期都不要了。这意味着Bun将在一个commit之内，从完全使用Zig变成完全使用Rust，没有任何回退空间。
这个PR目前仍是Open状态，社区已经发起了两个对立的PR：
- PR #30702：Revert "Rewrite Bun in Rust"（撤回Rust重写）
- PR #30706：Clarify that bun now is slop（标注Bun现在是"slop"）
两个PR的标题本身就是这场争议的缩影。
2.3 架构保持不变
尽管语言发生了翻天覆地的变化，但这次重写遵循了一个关键原则：保持相同的架构设计，保持相同的数据结构。
Bun团队发布的迁移指南（Migration Guide）明确要求：尽可能忠实地将Zig代码翻译为Rust——不是重新设计，不是利用Rust的特性重构逻辑，而是逐文件、逐函数地做语言转换。
这是一个务实的选择：对于Bun这样庞大的项目，推倒重来不仅工程量巨大，风险也难以控制。忠实翻译意味着可以在最大程度上复用现有的测试套件和行为验证，降低回归风险。
2.4 不使用async Rust
值得注意的是，新版Bun的Rust实现没有使用async Rust（即async/await、Tokio等异步运行时）。Bun仍然使用自己原有的事件循环机制，只是底层的内存管理和数据结构操作换成了Rust。
这意味着：Rust在这里扮演的角色更多是"更安全的C"——提供内存安全保证，同时保持原有架构的确定性和性能特征，而没有引入Rust异步生态带来的额外复杂性。
三、安全审计报告：69%的unsafe其实不需要unsafe
3.1 数字触目惊心
2026年5月21日，Bun团队主动发布了Rust重写版本的安全审计报告。报告揭示了一个让很多人意外的数字：
Bun Rust代码库中unsafe语法节点数量：13,365个
分布在：774个文件、51个子系统中
作为对比，体量和复杂度相近的Rust项目uv（Python包管理器，同样来自Rust生态），整个项目只有73个unsafe块。
这不是数量级上的小差异，而是相差近200倍。
3.2 unsafe的来源分布
审计报告将这13,365个unsafe节点的来源做了精确分类：
| 来源 | 占比 | 说明 |
|---|---|---|
| Zig时代的ownership惯用法 | 33.9% | Zig的内存管理模式被逐字翻译到Rust后，用unsafe绕过借用检查 |
| FFI边界 | 29.8% | 与JavaScriptCore引擎、C库等的跨语言调用 |
| 事件循环回调的重入问题 | 10.6% | 同线程重入导致的别名化（aliasing）问题 |
| 真正的性能优化 | ~3% | 确实需要绕过Rust安全检查的高性能路径 |
| 其他 | ~23% | 各类特殊场景 |
这里最值得深思的是那个33.9%：Zig的所有权模型和Rust的所有权模型并不完全兼容，迁移过程中，当Zig代码中的逻辑无法通过Rust借用检查器的验证时，最直接的"解法"就是加一个unsafe。这导致大量本可以在Rust中用安全方式表达的逻辑，被翻译成了unsafe实现。
3.3 处置策略：不是所有unsafe都是必要的
审计报告给出了更细致的处置策略分析：
- 46.9% 的unsafe块：无需降速即可安全化（添加Rust标准库替代方案即可）
- 16.3% 的unsafe块：添加一处检查后即可安全化
- 约37% 的unsafe块：需要更复杂的重构才能安全化
也就是说，大约69.4%（9,300个） 的unsafe节点最终有望转换为安全Rust代码。
Bun团队提出了一个八步清理路线图，全部完成后unsafe块将从13,365降至约4,000个。
3.4 发现的声超漏洞
审计过程中发现了5个实际的声超（soundness）漏洞。声超漏洞是指：Rust的类型系统向程序员承诺的安全性，在某些条件下被打破——编译器认为安全的代码，实际上可能导致未定义行为（undefined behavior）。
其中最典型的是RacyCell上的无条件Sync实现：当多个线程可以同时访问同一个可变引用时，Rust的Sync trait保证本应阻止这种访问，但代码中无条件地实现了这个trait，导致Rust的安全承诺被打破。
这些漏洞在被发现时已经在主分支上存在了一段时间，说明AI生成的代码在引入声超漏洞方面，并不比人工编写的代码更罕见。
3.5 与行业基准的对比
审计报告也做了横向对比：
| 项目 | 每千行Rust代码的unsafe数量 |
|---|---|
| Bun（当前，未清理） | 13.7 |
| Bun（目标，清理后） | 4.2 |
| Wasmtime | ~3.8 |
| Ring（密码学库） | ~0.8 |
| Rust标准库 | ~0.3 |
目标4.2这个数字已经接近Wasmtime的水平，这是个合理的目标，但清理工作本身并非简单的"代码格式化"——它需要逐个审计unsafe块的语义，判断是否真的可以安全化。
四、99.8%的测试通过率到底说明了什么
4.1 这个数字本身并不差
新版Bun通过了现有测试套件中**99.8%**的测试用例。对于一次涉及100万行代码的重写来说，这个数字本身就相当惊人——说明迁移的忠实度很高，行为层面几乎没有破坏性变更。
在性能方面，基准测试显示新版与旧版持平甚至略有提升。Linux x64平台的二进制文件体积从约93MB缩小了几MB。对于用户来说，这些指标都是正面的。
4.2 但这个数字无法证明安全性
问题在于：Bun团队将"迁移到Rust"的理由表述为安全性，而99.8%的测试通过率根本无法验证这一属性。
测试套件验证的是行为一致性——新实现与旧实现对外暴露的接口行为是否相同。但这和安全是两码事：
- 行为一致 = 新旧实现对相同输入产生相同输出
- 内存安全 = 新实现不会发生释放后使用、缓冲区溢出、数据竞争等未定义行为
这两个命题之间没有蕴含关系。测试套件可以通过（行为一致），但代码仍然存在内存安全问题。事实上，未定义行为从来不会通过测试失败来暴露自己——它更可能在某个用户报告的边缘场景、某个特定平台配置或某个特定输入组合下才触发。
4.3 一百万行代码，谁来读？
Hacker News讨论中最终聚焦的问题是：一个智能体在9天内生成的100万行代码，到底有没有人真正审核过？
以人类阅读代码的平均速度（高质量代码约50-100行/小时），审核100万行代码需要2万到5万小时——即使10个人全职做，也需要数年。
这与代码生成速度之间存在根本性的不对称：AI生成代码的速度正在指数级增长，而人类审核代码的能力基本是线性的。Bun可能只是迄今为止规模最大、曝光度最高的案例而已——类似的挑战正在整个行业中以不同规模反复上演。
五、社区反应：从技术到文化的多维冲突
5.1 Zig社区的愤怒
这次迁移引发的最直接冲突来自Zig社区。
Zig项目本身对AI生成代码持极端排斥态度。Zig项目明确禁止在代码库中提交AI生成的代码、AI生成的Issue和AI生成的评论。这一立场背后有其逻辑：Zig强调透明性和显式控制，依赖AI"凭空生成"逻辑与该语言的设计哲学根本相悖。
而Bun团队在迁移过程中多次公开表示：自己通过LLM大幅提升了性能，但这些改进无法合并回Zig上游，原因是"我们用LLM写的"。
当这种对立积累到一定程度，就变成了社区PR中的那句"bun now is slop"——不是技术批评，而是情绪表达。
5.2 从GitHub迁移到GitHub的隐喻
2024年底，Zig项目因为GitHub Actions的调度问题，拖家带口离开了GitHub。Andrew Kelley的迁移公告措辞激烈，充满政治色彩。这次"vibe-scheduling"事件被社区戏谑地称为Zig社区对GitHub的一次"Vibe"抗议。
Bun这边被Anthropic收购，而Anthropic又是Claude Code的创造者。这种背景组合——"Rust/AI友好的Anthropic收购了坚持手写代码哲学的Zig项目之一的核心依赖"——在技术之外也蕴含了意识形态的碰撞。
5.3 点赞和点踩各占一半意味着什么
PR #30412的600多点赞和400多踩，恰恰反映了开发者社区的真实分歧：
- 点赞者：看到了AI编程能力的突破性进展，相信Rust+AI的组合能在保证质量的前提下大幅提升开发效率
- 点踩者：担忧在没有充分人工审核的情况下将AI生成的代码用于生产级基础设施，担心unsafe问题被低估，担心"速度优先"的文化正在侵蚀代码安全的底线
这两种视角都有其合理性，争论本身也是有价值的——它迫使整个行业去认真思考：当AI开始介入基础设施级代码时，我们的审核标准和流程应该是什么样的？
六、从安全研究的角度：正确理解Rust的内存安全承诺
6.1 safe Rust vs. unsafe Rust
Rust的安全性建立在safe Rust的约束之上。在unsafe块之外，Rust编译器强制执行所有权（ownership）、借用（borrowing）和生命周期（lifetime）规则，保证不会出现：
- 释放后使用（use-after-free）
- 双重释放（double-free）
- 悬垂指针（dangling pointer）
- 数据竞争（data race）
但unsafe块是一个"出口"：在unsafe中，程序员明确告诉编译器"我知道我在做什么，请不要检查"。在unsafe中，安全性完全由程序员自己保证。
Bun项目中的13,365个unsafe，意味着有同样多的"出口"——在每一个出口处，Rust编译器失去了对内存安全的保障能力。
6.2 unsafe代码的安全性依赖于程序员
验证一个unsafe块是否真正安全，本身就是一件极其困难的事。这不是"会不会用Rust"的问题，而是形式化验证领域的核心难题之一。
Amazon联合Rust基金会成立了专门的社区项目来验证Rust标准库中的unsafe代码——而Rust标准库比Bun代码库小得多，也经过了更严格的审查，且是由Rust专家人工编写的。即便如此，验证工作仍然需要专门的项目来推动。
Rust标准库在过去数年中出现了二十多个与unsafe相关的CVE漏洞，这些代码已经接受了数十年专家级别的审查，问题依然存在。这应该让任何人对"unsafe可以轻松清理"的说法保持警惕。
6.3 大规模AI生成的unsafe：额外的风险
Bun案例的特殊之处在于：这些unsafe代码是由AI生成的，而非人工编写的。这意味着：
- 缺乏人类编写时的直觉保障：人类程序员在写unsafe时，通常对该段代码的语义有完整的心智模型；AI生成的unsafe可能缺少这种深层理解
- 上下文丢失风险：AI在逐文件翻译时，可能丢失了原Zig代码中的某些隐含约束条件
- 累积规模效应：单个unsafe块的风险可能不大，但当规模达到13,365个时，即使每个的危险概率极低，整体风险也变得不可忽视
七、实用主义视角：我们能从中学习什么
7.1 作为程序员，应该如何评估这类项目
Bun的Rust版本目前只发布在canary频道（即每日构建版），尚未进入stable稳定版。这意味着用户目前可以选择是否使用这个新版本。
对于生产环境的决策，这里有一个实用的评估框架：
第一步：识别团队的实际风险暴露
- Bun在你们团队中是否用于长期运行的服务器进程？
- 还是会用完就丢弃的工具脚本？
第二步：考虑内存泄漏历史
- Bun早年以内存泄漏问题著称
- 如果你们的场景是"用完即丢"的工具链（npm脚本、构建工具），
内存安全问题的影响相对有限
- 如果是服务器长期运行，内存问题的风险更高
第三步：关注unsafe清理进度
- Bun团队有八步清理路线图，持续关注其进展
- unsafe数量从13,365降到4,000以下是一个重要里程碑
第四步：等待生产级用户的反馈
- 社区中第一批吃螃蟹的人的经验最有参考价值
7.2 对于AI辅助编程的工程实践
这件事给AI辅助编程领域提供了几个重要的工程原则：
原则一：行为测试和安全性测试是两回事
不要用测试通过率来证明代码安全性。Bun的99.8%测试通过率和13,365个unsafe块之间没有矛盾——它们从不同维度描述了这次迁移，两者是并存的。
原则二：AI生成代码需要不同的审核策略
对AI生成的代码，不能沿用传统的"逐行审核"策略。正确的做法是：
- 先审核架构和设计：代码的整体结构是否合理
- 再审核边界条件：关键路径上的处理是否完整
- 最后关注unsafe块：集中审计所有unsafe，而不是逐行读代码
原则三：迁移指南应该包含安全约束
Bun的迁移指南要求"忠实翻译"，但没有规定"禁止使用unsafe"或"禁止绕过借用检查器"。如果当时有这样的约束，AI模型会寻找真正符合Rust惯用法的实现方式——即使这意味着需要更复杂的重构。
原则四：AI是工具，责任感在工程师
"AI写的代码出了问题，谁来负责？"这个问题没有标准答案。但至少在当前阶段，答案是"使用AI的人"。Jarred Sumner说过"我们好几个月没有亲手敲代码了"，但最终为这个决定负责的，仍然是他和Bun团队。
7.3 Rust正在成为AI时代的基础设施工具
值得注意的是，Bun并不是孤例。过去一年里，多个顶级项目都在向Rust迁移或已经在使用Rust：
- Codex CLI（OpenAI的编程Agent CLI）：从TypeScript/Node.js迁移到Rust，核心是90+个Rust crate的workspace
- LiteLLM：迁移到Rust实现，吞吐量提升15倍
- Chromium：采用Rust编写的PNG解码库
- NVIDIA OSMO：评估RustFS作为MinIO的替代存储方案
这些选择的共同逻辑是：Rust提供的内存安全保证，对于基础设施级项目来说是难以拒绝的价值。当你的代码每天处理数百万用户的请求时，一个内存bug可能导致的安全漏洞远超性能优化的收益。
Bun案例的特殊之处不在于"用了Rust"，而在于"用AI大规模生成Rust代码"。这两件事的结合方式，才是真正值得整个行业深入思考的命题。
八、展望：Bun的下一步与行业启示
8.1 清理unsafe的工程挑战
从技术路线图来看，Bun的Rust版本还有很长的路要走：
当前状态：
- 13,365个unsafe块
- 5个已发现的声超漏洞（已修复）
- 每千行13.7个unsafe
目标状态：
- ~4,000个unsafe块
- 每千行4.2个unsafe（接近Wasmtime水平）
挑战：
- 清理unsafe不是简单的代码格式化，需要逐块语义审计
- 有些unsafe的清理可能需要重构整个模块的设计
- 学术界目前最好的方法也只是半自动化分析工具
- 这是一个可能持续数年的工程，而非几个PR能解决
8.2 AI编程的下一阶段
Bun案例揭示了一个深刻的问题：AI生成代码的能力正在指数级增长，而人类审核代码的能力基本保持不变。这个不对称性是整个行业必须面对的结构性挑战。
可能的解决方向：
- 形式化验证工具的进步：如果能自动化验证unsafe代码的安全性，这个不对称性可以被弥合
- AI辅助审计：用AI来审核AI生成的代码——虽然有"用同一来源的智能体验证"的哲学问题，但实践上可能是当前最可行的路径
- 更严格的迁移规范：明确规定AI辅助迁移必须满足的安全约束条件，而不是放任"忠实翻译"
- 行业标准和最佳实践：类似航空业对飞行软件的安全标准，基础设施级项目可能需要建立AI辅助代码的审核标准和认证流程
8.3 对程序员茄子的读者说的话
作为程序员，我们应该如何面对这个趋势？
首先，不要恐慌，也不要盲目拥抱。Bun的案例告诉我们：AI可以完成大规模代码迁移，但迁移的质量取决于约束条件、审核流程和工程决策，而不是AI本身。
其次，理解工具的边界比使用工具更重要。知道Rust的内存安全承诺在什么条件下成立，知道测试通过率和代码安全性是两回事，知道AI生成的代码需要不同方式的审核——这些知识比会写prompt更有价值。
最后，持续关注这个领域的进展。AI编程的发展速度远超任何人的预期。Bun不会是最后一个"AI生成百万行代码"的项目，也不会是最后一个引发争议的项目。保持学习、保持批判性思考，才是在这个时代保持竞争力的方式。
附录：关键数据汇总
| 指标 | 数值 |
|---|---|
| 重写耗时 | 9天 |
| 总提交数 | 6,755次 |
| 变更文件数 | 2,188个 |
| 新增代码量 | ~100万行 |
| 删除代码量 | ~4.7万行 |
| unsafe块数量 | 13,365个 |
| unsafe来源-Zig惯用法 | 33.9% |
| unsafe来源-FFI边界 | 29.8% |
| unsafe来源-事件循环重入 | 10.6% |
| unsafe来源-性能优化 | ~3% |
| 可安全化的unsafe | ~69.4% |
| 当前每千行unsafe数 | 13.7 |
| 目标每千行unsafe数 | 4.2 |
| 测试通过率 | 99.8% |
| Linux x64二进制缩减 | 3-8 MB |
| 发现的声超漏洞 | 5个（已修复） |
本文参考了Bun官方PR #30412、PR #30683、安全审计报告（2026年5月21日）、Elecmonkey技术博客、DevPress专题报道、Hacker News讨论（#30412，708分热度）等多个来源。如有疏漏，欢迎指正。