Claude Code 如何将 Bun 重写为 Rust：大规模代码迁移六步指南

引言

过去，大型编程语言迁移是工程团队会推迟数年的项目类型。这类迁移成本高昂、破坏性强且风险巨大。一家公司可能花费几个季度的时间同时维护两个实现版本，最终得到的替代品却与原版行为不一致。

Claude Code正在改变这一局面。

Anthropic最近公布了其利用AI代理进行大规模代码迁移的流程。最引人注目的案例是Bun的创建者Jarred Sumner将Bun的核心从Zig迁移到Rust。在不到两周的时间里，Claude Code工作流生成了超过一百万行代码，而Bun现有的测试套件在合并前就已通过持续集成测试。

这个项目并非通过让模型"用Rust重写Bun"并等待完美答案完成的。它依赖于一套精心设计的系统，包括规则手册、依赖映射、机械队列、对抗性审查者、编译器、冒烟测试和行为一致性检查。

核心教训很直接：对于如此大规模的迁移，开发者不应将大部分时间花在修复单个文件上。他们应该改进生成、审查和验证这些文件的流程。

Bun创建者利用AI重写了超过一百万行代码

Jarred Sumner最初用Zig构建了Bun。这种语言让独立开发者既能获得底层控制权和类似C语言的性能，又无需面对大型系统语言生态的全部复杂性。

这一选择帮助Bun在早期快速发展。Sumner曾表示，他在奥克兰的一个小公寓里，在大约一年的时间内写出了第一个版本，那时还没有现代编码模型。

到2026年，Bun已成为广泛使用的JavaScript和TypeScript运行时、包管理器、测试运行器和打包工具。其命令行工具每月获得数千万次下载，包括Claude Code在内的产品都严重依赖Bun。

增长也让旧的工程权衡变得难以忽视。

Bun将垃圾回收的JavaScript引擎与手动管理的本地内存结合在一起。在Zig中，开发者必须明确推理分配、清理、错误路径和对象生命周期。Bun的团队在消毒器、模糊测试、安全检查构建和内存泄漏测试上投入了大量精力，但释放后使用错误、双重释放、泄漏和生命周期错误仍然出现。

Rust提供了不同的基础。其所有权系统、借用检查器和自动清理可以将许多运行时内存问题转化为编译时错误。

从历史上看，这一好处并不足以证明完全重写是合理的。Bun包含数十万行Zig代码，外加大量的原生集成。传统的重写可能消耗一个小型工程团队一年或更长时间，同时还会拖慢功能开发和安全修复。

Claude Code让完全机械迁移变得可行。

11天从Zig到Rust

Sumner使用了Claude Fable 5的预发布版本和Claude Code动态工作流来执行迁移。

主要的编写和审查

该流程持续运行了11天。约50个动态工作流处理了不同阶段，包括：

• 创建Zig到Rust的移植指南
• 映射内存生命周期
• 将.zig文件转换为.rs文件
• 审查每个生成的文件
• 修复编译器错误
• 恢复单个Bun命令
• 运行完整测试套件
• 重构并清理生成的代码

在峰值吞吐量下，工作流每分钟产出约1300行代码。每个生成的代码单元需经过两个独立对抗性审查者检查，随后由修复器应用确认的更改。

最终拉取请求在超过2000个更改文件中添加了超过一百万行代码。

合并前，Bun现有的测试套件在CI中通过。合并后出现了19个回归问题，Anthropic报告称这些问题随后全部得到修复。Rust移植版已于2026年6月随Claude Code一同发布。

这一结果并非证明最初生成的一百万行代码是正确的。Sumner明确指出，最早的翻译输出无法运行。成功的关键在于反馈系统，它能逐步将无法运行的输出转变为已编译、经过测试、行为兼容的代码。

迁移成本约16.5万美元（按API价格计算）

Bun的迁移消耗了大约：

• 59亿未缓存输入令牌
• 6.9亿输出令牌
• 按API定价约16.5万美元

这是一笔不小的金额，但仍远低于传统上需要多名全职工程师耗时数年的迁移成本。

Anthropic估计，此前百万行级别的迁移可能需要四年的时间，耗费约300万至400万美元的工程资源。AI改变了业务逻辑，因为迁移不再需要解决生存危机才能证明其成本合理性。

持久的内存错误、老化的语言生态系统、昂贵的构建过程或反复出现的维护瓶颈，现在都可能足以让迁移值得评估。

不过，比较仍需谨慎。令牌成本并非项目总成本。团队还需要人工规划、基础设施、测试、代码审查、安全工作和合并后的维护。

Bun为何从Zig迁移至Rust

此次迁移主要出于可靠性考量，而非原始速度。

Bun在Zig中已经表现出色。问题在于如何安全地协调手动管理的原生内存与垃圾回收的JavaScript运行时。

常见的故障类别包括：

• 释放后使用错误
• 双重释放错误
• 异常路径上的内存泄漏
• 由重入回调导致的无效指针
• 被跳过的清理代码
• 难以一致实施的生命周期假设

在安全的Rust中，许多

这些错误无法通过编译。值具有明确的所有权，资源清理与对象生命周期绑定，编译器在程序运行前就会检查引用。

此次迁移的目标是保留 Bun 现有的架构、数据结构、行为和性能。它有意更接近机械式移植，而非彻底重新设计。

这一决策至关重要。如果同时重新设计系统并更换语言，行为对比将变得异常困难。

第二个案例：16.5万行 Python 代码转为 TypeScript

Jarred Sumner 并非唯一使用 Claude Code 进行重大迁移的 Anthropic 工程师。

Anthropic Labs 联合负责人、Instagram 联合创始人 Mike Krieger 在一个周末内将内部 Python 代码库迁移成了约 16.5 万行 TypeScript 代码。

主要迁移过程消耗约 2700 万 token，涉及：

• 数百个智能代理
• 八个阶段关卡
• 三轮对抗性审查
• 最终一致性检查
• 逐命令与 Python 版本进行输出对比
• AI 生成的端到端测试

原本的工具需要以单一二进制文件形式交付。使用 Python 工具链时，每个平台编译约需八分钟，完整的构建矩阵使每次发布延迟约 30 分钟。

TypeScript 迁移完成后：

• 编译时间缩短至约两秒
• 二进制文件启动速度提升约六倍
• 可淘汰独立的部署管道

Krieger 并未依赖现有的全面跨语言测试套件。相反，Claude 创建了一个覆盖七个真实场景的一致性测试框架，然后对比新旧实现的输出结果。

Claude 还设计了额外的端到端测试，并连续四个晚上运行这些测试，修复失败案例后重复此过程。这发现了原始场景未曾预料的细微行为差异。

为何大型代码迁移适合 AI 智能代理

大型迁移之所以令人生畏，是因为它们涉及海量重复性变更。而正是这些特征，使它们适合采用智能代理工作流。

工作可并行化

大型代码库通常可拆分为文件、包、crate、模块或依赖组。独立的智能代理可同时处理相互独立的单元。

依赖关系图决定了哪些单元可以并行推进，哪些必须等待。

现有代码即为规范

原始实现已包含所需的行为、边界情况、数据结构和集成细节。

模型无需创造产品功能，其任务是在新语言或框架中保留现有系统。

测试提供客观评判

当智能代理能机械地评估自身输出时，其工作效果更佳。

编译器、测试套件、输出差异对比、基准测试或一致性测试框架能为系统提供具体信号。智能代理可据此持续改进，无需人工评判每次中间尝试。

任务队列可自动生成

编译错误成为下一个任务，失败的测试成为下一个任务，程序崩溃也成为下一个任务。

这便将

大量迁移任务进入一个可反复缩减的队列。

重复失败可推动规则改进

当审查员在多个文件中发现同一问题时，最佳解决方案并非手动逐一修补每个文件。

应当更新规则手册并重新生成受影响的批次。这可以防止相同错误在后续工作中再次出现。

核心原则：修复流程，而非单个文件

Anthropic 流程中最重要的理念是：将生成的代码视为系统输出的产物。

假设200个翻译后的文件包含相同的所有权错误。手动修复这些文件或许能解决可见错误，但工作流程仍可能再次产生同样的错误。

更有效的方法是：

1. 识别重复失败的模式。
2. 确定是哪条迁移规则导致的。
3. 更新规则手册。
4. 仅重新生成受影响的文件。
5. 重新运行审查和验证循环。

代码之所以改进，是因为生产流程得到了优化。

这类似于普通的软件工程。一个反复出现的生产缺陷应促使改进测试、类型规则、静态检查或流程——而不仅仅是打上另一个孤立的补丁。

前提条件：构建可靠的评判机制

在开始大规模迁移之前，需要定义团队如何证明新实现的正确性。

没有评判机制，就无法确定可靠的完成条件。

评判机制必须在同等条件下评估原始实现和目标实现。现有测试可能依赖于私有函数或特定语言的内部机制，而这些在移植过程中会消失。

Anthropic 推荐三项准备工作：

1. 对现有测试进行分类。 将测试公开行为的测试与依赖内部实现的测试分开。
2. 为可移植性重写测试。 将外部可观察的行为转化为能在两个系统上都运行的断言。
3. 验证评判机制。 确认原始实现能通过测试，然后刻意破坏程序并确认评判机制会失效。

无法检测已知故障的测试套件，不能用作有效的迁移评判机制。

Bun 有一个显著优势：其大部分测试套件是用 TypeScript 而非 Zig 编写的，因此同一套测试可以测试 Rust 实现。

对于没有这一优势的项目，可以使用对等测试工具比较两个版本之间的实际输入和输出。

Anthropic 的六步代码迁移框架

Anthropic 将这些项目中的经验总结为以下六步流程。

图片展示了Anthropic提出的六步代码迁移框架。第一步是创建地图和规则，包括规则书作者、依赖关系映射器、缺口库存等；第二步是压力测试规则，有双译者、差异检查器等；第三步是翻译所有内容，有实现者、审查员等；第四步是编译，有调查构建、并行修复者等；第五步是运行，有烟雾测试、修复者等；第六步是匹配行为，有构建守护进程、修复者等。底部还列出了共享文档、运行基础设施等内容。该图是对上文Anthropic六步代码迁移框架的可视化呈现。

第一步：创建规则手册、依赖关系图和缺口清单

第一阶段创建所有后续代理都将遵循的共享文档。

构建规则手册

规则手册定义了源语言中的概念如何映射到目标语言。

对于保持结构不变的迁移，规则手册可能包含：

• 类型映射
• 错误处理

规则约定

• 命名规则
• 内存与所有权规则
• 标准库替换规范
• 并发模式
• 文件与模块布局
• 外部函数接口规则
• 需人工审查的模式

在重构设计中，规则手册更接近架构文档。

Jarred Sumner通过与Claude对话及人工审查，制定了Bun的移植指南。最终成品长达数百行。

创建依赖映射

仓库必须按依赖顺序进行划分。

确定性脚本可通过检查导入、清单、构建文件及符号关系生成依赖映射。该结果有助于编排器判断哪些文件可独立转换，哪些需协同处理。

编写差距清单

源语言与目标语言遵循不同规则。

对于Zig到Rust的迁移，内存所有权是主要差距。对于Python到TypeScript的迁移，隐式的对象形态与接口必须转化为显式契约。

差距清单需记录单纯翻译无法解决的环节，具体包括：

• 隐藏的源语言假设
• 缺失的目标语言抽象
• 需显式化的运行时行为
• 不受支持的库
• 平台特定代码
• 不安全边界
• 需重新设计或人工决策的领域

规则手册应先于差距清单创建，因为差距清单部分取决于常规规则无法处理的内容。

第二步：压力测试规则

不要立即翻译数千个文件。

先选取少数复杂且具代表性的文件进行小型一次性试运行。目的是在规则缺陷扩散至整个仓库前暴露问题。

在Bun的试运行中：

1. 首个智能体依据规则手册翻译三个文件。
2. 另一智能体以资深Rust工程师视角翻译相同文件。
3. 比对智能体检查差异。
4. 审查人员标记缺失或错误的迁移规则。
5. 翻译文件被废弃。

此阶段的产出是优化后的规则手册——而非生产代码。

对于重构迁移，等效测试是让对抗性审查者攻击设计文档，然后执行一次性端到端运行。

第三步：全面翻译

一旦规则通过试运行验证，仓库即可通过并行队列处理。

典型单元配置包括：

• 一名实施者
• 两名独立对抗性审查者
• 一名修复者
• 机械队列
• 共享规则手册
• 共享差距清单

队列需支持断点续传。应能通过检查文件或记录产物（而非依赖单个智能体记忆）来判断工作完成状态。

智能体应始终一致地标记未完成的工作，例如：

TODO(移植): 解释为何此部分无法安全翻译

无需对每个单元使用最昂贵的模型。较低配置的模型可处理高容量翻译，而更强模型可保留给审查者、架构决策及规则修改。

第四步：编译

首次完整构建会将编译器错误转化为结构化工作队列。

根据构建成本的不同，

编译器可以在每个代理循环内部运行，也可以通过单独编排器运行。

对于Bun项目而言，编译整个工作区的成本较高，因此在文件翻译过程中，Claude代理不会随意执行cargo命令。取而代之的流程是：

1. 编排器运行编译器。
2. 错误信息写入共享列表。
3. 按模块或根本原因对列表进行分类。
4. 修复代理并行处理各组错误。
5. 审查员检查修复结果。
6. 编排器重新构建项目。

这可以防止数十个代理同时启动同样高成本的构建。

系统性编译器错误应更新规则。例如，目标语言可能拒绝源编译器以懒加载方式容忍的循环依赖。这是流程层面的问题，而不仅仅是孤立文件错误的简单集合。

第五步：运行程序

编译成功仅证明目标语言能接受代码。

下一阶段通过基本执行和冒烟测试来发现崩溃、初始化失败、资源缺失、无效假设和集成故障。

失败案例仍应按原因分类。

如果40个冒烟测试因同一个错误的初始化模式而失败，应修复迁移规则并重新生成受影响的代码，而非分配40个独立的修补方案。

第六步：匹配原始行为

最终关卡是行为一致性。

同时运行两个代码库的便携测试套件、一致性验证工具、输出对比和相关基准测试。

针对每个失败案例：

1. 为修复代理提供失败证据及两种实现方案。
2. 要求修复代理识别行为差异。
3. 由对抗性审查员检查拟议的修改方案。
4. 通过单一构建流程批量处理高成本构建。
5. 重新运行受影响的测试。
6. 将反复出现的失败升级为规则变更。

原代码库始终是事实基准，除非项目明确意图改变行为。

缺乏测试套件不能跳过此步骤。团队可借助Claude基于真实场景创建外部一致性验证工具，并通过刻意破坏的行为对验证工具进行有效性确认。

Anthropic迁移工具包快速入门

Anthropic发布了公开入门工具包，包含基于迁移流程的通用提示语、模板和脚本。

该仓库是参考材料而非完全托管式的迁移产品。其提示语为重构模板，并非Bun项目的确切流程记录。

1. 安装Claude Code

在macOS或Linux系统：

curl -fsSL https://claude.ai/install.sh | bash

在Windows PowerShell系统：

irm https://claude.ai/install.ps1 | iex

执行远程安装脚本前，请先审查脚本内容及贵组织的安全策略。

2. 克隆迁移工具包

在待迁移的仓库中执行：

git clone https://github.com/anthropics/code-migration-kit-with-claude-code.git ./migration-kit

3. 添加迁移技能

此可选步骤将迁移技能复制到本地Claude Code技能目录：

cp -r migration-kit/skill ~/.claude/skills/code-migration

按照说明更新已安装的SKILL.md中的工具包路径。

仓库。

4. 运行可行性评估

首先使用工具包的只读可行性提示：

prompts/00-feasibility.md

结果应回答三个问题：

• 该项目是否应该迁移？
• 迁移是保持结构不变还是重新设计？
• 原始实现和目标实现能否得到公平评判？

"不迁移"是一个有效的结果。

5. 准备评判工具和安全规则

在展开翻译之前：

• 构建或验证跨语言评判工具。
• 将推荐的 Claude 设置复制到目标仓库中。
• 在适当情况下禁止破坏性或高成本命令。
• 确认源仓库有可恢复的备份。
• 使用隔离分支、受控工作树和最小权限凭证。

然后按顺序运行迁移提示，而不是直接跳到大规模翻译。

Bun 早期尝试中出现的问题

Bun 的迁移从一开始就不顺利。

当许多代理开始在一个仓库中工作时，它们的 Git 操作会相互干扰。一个代理运行了 git stash，另一个使用了 git stash pop，还有一个重置了工作树。

Sumner 改变了工作流程，让代理无法自由运行破坏性的 Git 命令。后来他将工作划分为四个工作流分片，每个分片使用独立的工作树，各自协调多个代理。

这个例子突出了一个关键点：代理权限必须与工作流设计相匹配。

拥有广泛 shell 访问权限的编码代理可能：

• 删除或覆盖工作
• 重置未提交的更改
• 重复触发高成本构建
• 修改无关文件
• 通过命令或日志泄露机密
• 干扰其他代理

编排层必须限制命令、定义文件所有权、序列化高成本操作，并使恢复变得简单。

AI 辅助代码迁移的最佳实践

Anthropic 发布的经验教训可以归结为几条实用规则。

不要盲目遵循通用指南

每个代码库都有不同的构建系统、测试覆盖率、运行时行为、部署约束和风险承受能力。

以六步框架为起点，然后让 Claude 根据实际仓库进行调整。

关注模式，而非个别失败

修复代理可以处理个别失败。当人类注意力用于识别重复模式、缺失规则、不安全假设和架构问题时，其价值更高。

让审查具有对抗性

实施代理不应成为其唯一的审查者。

为审查者提供独立的上下文，并告知他们假设生成的代码是错误的。他们的任务是找出代码失败、偏离或违反规则手册的原因。

让验证机械化

使用编译器、测试、代码检查工具、输出差异、基准测试和确定性脚本作为评判工具。

主观的"看起来正确"的审查无法安全地验证百万行级的变更。

为不同角色使用不同模型

高容量的翻译任务可以交给较小或较便宜的模型。最强的模型应负责规则创建、架构、模糊失败和审查。

尽早投入人力

最高价值的人力工作应在大规模生成之前完成：

定义业务案例

• 构建评审机制
• 制定规则手册
• 映射依赖关系
• 审计试点项目
• 设定权限与边界

一旦这些基础环节稳固可靠，剩余的大部分工作就会变成机械化的队列任务。

保持队列可恢复性

需要运行数天的迁移任务必须能够承受崩溃、重启、模型故障以及基础设施中断等突发情况。

完成状态应当基于磁盘上的持久化工件、提交记录、测试结果和队列状态来判定，而非依赖单一的长对话。

Bun 迁移后的成效

Anthropic 报告称，基于 Rust 编写的 Bun 代码已投入生产环境使用。

此次迁移并未消除所有权衡问题。约有 4% 的 Rust 代码仍然存在于 unsafe 块中，主要集中在 C 和 C++ 边界处的小型指针操作。

不过，新实现方案带来了显著的改进：

• 修复了可检测到的内存泄漏问题
• 某项重复构建基准测试的内存占用从 6,745 MB 降至 609 MB
• 在 Linux 和 Windows 平台上，二进制文件体积缩小了 19%
• 跨语言优化使特定工作负载性能提升约 2% 至 5%

这些成果充分说明了迁移的意义所在。目标并非生成大量 AI 编写的代码，而是在保持原有行为的前提下，打造一个更安全、更精简、更易于维护的系统。

AI 迁移的适用场景

当满足以下条件时，大规模迁移适合采用智能体工作流：

• 原始代码库可作为完整规范使用
• 行为可通过外部手段检查
• 能够创建测试或对等场景
• 工作可分解为可重复执行的单元
• 目标语言具有明显优势
• 组织能够容忍大型实验性分支
• 人类专家可审查架构和边界情况
• 工具环境可受限且可审计

而在以下情况下，则可能不太适合：

• 对原始行为理解不充分
• 无法验证正确性
• 项目将迁移与完整产品重新设计混为一谈
• 监管审批要求对每项变更进行人工验证
• 代码包含不能安全暴露的机密或系统
• AI 生成代码合并后团队缺乏所有权

能够快速生成百万行代码，并不代表迁移方案理所当然地合理。

常见问题解答

Claude Code 真的将 Bun 从 Zig 重写为 Rust 了吗？

是的。Jarred Sumner 利用 Claude Code 动态工作流和预发布版 Claude 模型，将 Bun 的核心从 Zig 迁移至 Rust。该过程在不到两周内生成了超过一百万行代码，随后进行了编译、测试、审查以及合并后的修复工作。

Bun 迁移花费了多少成本？

Anthropic 报告显示，大约消耗了 59 亿个未缓存输入 token 和 6.9 亿个输出 token。按 API 定价计算，模型成本估计约为 16.5 万美元，这还不包括人力和基础设施成本。

迁移合并前是否通过了所有测试？

Anthropic 表示，在合并前，Bun 现有的测试套件在 CI 中已通过。合并后发现了 19 个回归问题，这些问题后续均已修复。

Bun 为何从 Zig 迁移到 Rust？

主要目标是提高内存安全性，减少反复出现的生命周期问题，

清理、释放后使用、双重释放及内存泄漏问题。Rust的所有权与类型系统可在编译时捕获其中许多问题。

Claude Code能自动迁移任意代码库吗？

不能。成功迁移需要严谨的评判者、明确的规则、依赖分析、受控权限、可重复队列、对抗性审查及人工监督。某些项目根本不应迁移。

什么是对抗性代码审查？

对抗性审查员在独立环境中接收生成的变更，其职责是查找缺陷而非批准变更。实施者与审查员角色不同，降低了作者维护自身输出的风险。

我需要现有的测试套件吗？

理想情况下应具备完善的现有测试套件，尤其当它能独立于实现语言测试公共行为时。若不具备此条件，团队可构建校验框架，对比新旧系统间真实场景与输出的差异。

Anthropic的迁移工具包就是Bun使用的完整工作流程吗？

不是。Anthropic将该仓库描述为通用化且重构的入门工具包。实际Bun迁移使用了更具体的构件，包括长篇项目规则手册和自定义动态工作流程。

相关工具

• Claude Code：Anthropic的智能编码工具，用于仓库、终端、测试及开发工作流程管理。
• Bun：JavaScript与TypeScript运行时、包管理器、打包器及测试运行器。
• Rust：专注于性能、类型安全与内存安全的系统编程语言。
• Zig：强调显式控制与简洁语言语义的底层编程语言。
• GitHub：用于管理Bun迁移拉取请求及Anthropic迁移工具包的源码控制与协作平台。
• Claude Code现代化插件：Anthropic官方插件，用于评估和现代化遗留系统。

相关链接

• Anthropic大规模代码迁移指南：官方六步流程及两个迁移案例研究。
• 用Rust重写Bun：Jarred Sumner对架构、工作流程、审查、失败与结果的详细记录。
• Bun Rust重写拉取请求：包含大规模Zig到Rust迁移的已合并拉取请求。
• Claude Code迁移工具包：语言迁移的官方提示词、模板、脚本及参考工作流程。
• Claude Code文档：官方安装、配置、安全及工作流程文档。
• 代码现代化插件：用于遗留系统评估与转型的官方Claude Code插件。

行为等价性测试。

• Rust 官方指南：涵盖 Rust 的所有权、借用、类型、并发及应用程序开发的官方文档。

总结

Claude Code 之所以能让 Bun 的迁移成功，并非因为一次性生成了完美的百万行重写代码。项目成功的关键在于团队围绕该模型构建了一套严谨的生产系统：规则手册、依赖映射、缺口清单、试点项目、并行翻译队列、对抗性审查、编译器循环、冒烟测试及行为一致性检查。

同样的方法帮助 Anthropic 在周末内将大型 Python 代码库迁移至 TypeScript。在这两个案例中，客观验证的重要性远超原始生成速度。

AI 能显著降低大规模迁移的成本和周期，但前提是流程可中断恢复、权限受控，且重复出现的缺陷能持续改进生成代码的规则。

真正的突破不在于 AI 能写出百万行代码——而在于精心设计的循环能反复生成、质疑、测试并修正这些代码，直至新系统的行为与旧系统完全一致。