Anthropic 如何借助 Claude Code 开展大规模代码迁移

引言

更改成熟生产代码库的主要语言过去是团队会推迟数年的项目类型。这项工作成本高昂、风险大且难以预估。一次迁移可能会耗费多个工程季度，期间两种实现方案渐行渐远，最终却只能实现不完整的行为一致性。

Anthropic 近期的内部项目表明，这种情况正在开始改变。

2026 年 7 月，Anthropic 发布了一份实践报告，详细介绍了其开发者如何利用 Claude Code、Claude Fable 5、Claude Opus 4.8 以及动态多智能体工作流，在大约一个月内迁移了十个代码包。这些代码包的代码量从数万行到数十万行不等。

其中两个案例尤为突出：

• Bun 联合创始人 Jarred Sumner 使用 Claude Code 将 Bun 从 Zig 迁移到 Rust，在不到两周的时间内生成了超过一百万行代码。
• Anthropic Labs 联合负责人 Mike Krieger 在一个周末内将一套 Python 代码库转换成了约 16.5 万行 TypeScript 代码。

重要的启示并非 AI 模型能够快速翻译文件，而是一个设计良好的迁移系统可以在较少人工干预的情况下，反复生成、审查、测试、驳回和重新生成代码。

Anthropic 这样总结其理念：开发者的主要工作不是手动修补每一个生成的错误，而是改进那个不断产生错误的流程。

改变成本计算的两项代码迁移

Bun：从 Zig 到 Rust 的超百万行代码迁移

Bun 是一个一体化的 JavaScript 和 TypeScript 工具包，包含运行时、包管理器、打包工具、测试运行器以及其他开发工具。其原始实现严重依赖 Zig，并与大量 C 和 C++ 代码集成。

Jarred Sumner 在 11 天内使用了约 50 个动态 Claude Code 工作流来完成 Rust 迁移。合并后的拉取请求包含超过一百万行新增代码和数千次提交。

在合并之前，Bun 现有的持续集成测试套件在其支持的平台上均通过了测试。Anthropic 后来报告称，合并后出现了 19 个回归问题，随后均已修复。

这次迁移并非从零开始的重新设计。其目标是在替换实现语言的同时，保持 Bun 现有的架构和行为。这减少了同时存在的变量：项目可以专注于语言语义、所有权、内存安全性和兼容性，而非从头重建产品。

Bun 的官方报告解释了为什么 Rust 具有吸引力。许多反复出现的稳定性问题涉及生命周期管理、遗漏的清理路径、释放后使用等情况。

条件以及双重释放风险。在安全的Rust中，这些问题中有多个会成为编译期错误，而不是通过生产环境崩溃、模糊测试或人工审查才发现的问题。

一个周末从Python迁移到TypeScript

Mike Krieger的项目走了一条不同的路。这次迁移并没有尽可能保留原始文件结构，而是涉及了更多的架构重新设计。

结果是在一个周末内生成了大约165,000行TypeScript代码。据报道，该过程使用了：

• 数百个智能体。
• 八个阶段关卡。
• 三轮对抗性评审。
• 一个一致性测试框架，用于比较每个命令的输出与Python实现。

业务原因很明确。这个基于Python的内部工具以单个二进制文件分发，但生成该二进制文件每个平台需要大约八分钟，整个发布矩阵大约需要30分钟。

迁移之后，编译大约需要两秒钟，启动速度提升了六倍，团队还得以淘汰一个独立的部署流水线。

何时值得考虑语言迁移

语言迁移仍然需要真正的工程或业务理由。更快的代码生成并不意味着每次重写都是合理的。

当系统创建以来的环境发生变化时，团队通常会重新考虑语言选择。典型的触发因素包括：

1. 已知的妥协方案已成为反复出现的运营问题。
2. 更新的语言或生态系统现在提供了更好的工具支持。
3. 原始生态系统正在萎缩，或难以招聘到相关人才。
4. 安全或内存安全要求已发生变化。
5. 构建、部署或运行时性能已成为瓶颈。
6. 维护兼容性需要越来越昂贵的变通方案。

Bun最初使用Zig是有道理的，对于一个在当代编码智能体出现之前独自构建一个非常广泛运行时的创始人来说，这种语言提供了底层控制，帮助Jarred Sumner快速推进。

几年后，Bun已成为一个广泛使用的生产工具，维护面大得多。反复出现的内存相关缺陷的成本增加了，而Claude Code使得机械性移植变得足够可行以进行测试。

因此，这个决定不是“Zig不好而Rust好”，而是Bun当前的规模、运营需求和可用工具已经改变了权衡取舍。

迁移更快，但并非零成本

AI辅助的语言迁移仍然可能成本高昂。

Anthropic报告称，Bun项目大约消耗了：

使用类别	报告数量
未缓存的输入token	59亿
输出token	6.9亿
估计API价格等值	约16.5万美元

Mike Krieger的Python到TypeScript迁移主要部分使用了约2700万个token。

这些数字远低于传统多年迁移的工程成本，但并不微不足道。团队还必须考虑：

• 人工监督。
• 计算和API开销。
• 测试基础设施。
• CI容量。
• 构建机器。
• 合并后的审查和修复。
• 迁移期间的机会成本。
• 目标语言的长期维护。

实施。

成本降低使更多项目在财务上变得可行，但这并未消除对商业案例的需求。

为何大型迁移如此契合 AI 智能体

大型语言迁移具备多项特性，特别适合与协同编码智能体配合使用。

工作可并行化

迁移通常涉及数百或数千个文件、模块、包或库，只要理解其依赖关系，即可独立处理。

智能体可以并行翻译独立单元，而非等待单一中央实施流。挑战从打字速度转向编排、一致性和验证。

旧代码即详细规范

许多软件任务始于不完整的需求。而语言迁移的起点则强大得多：原始实现。

现有源码定义了控制流、数据结构、边界案例、错误行为、公共 API 及平台特定处理。当迁移规则不明晰时，智能体可随时回溯参考。

测试提供客观裁判

当成功与失败可通过机械方式验证时，智能体表现最佳。

编译器、测试套件、一致性脚本、基准测试或确定性输出对比为工作流提供了唯一可信源。系统无需询问审查者新实现“看起来是否正确”，而是反复比对行为与原实现是否一致。

失败自动转化为待办项

编译器错误、崩溃、测试失败及输出差异自然描述了剩余工作。

迁移系统无需人工逐条编写任务单。每个失败的检查项都可分类并分配给修复智能体。

重复错误可上游修复

当同一问题出现在多个文件中时，逐个手动修补并非正确应对方式。

更优方案是更新导致错误的迁移规则，然后仅重新生成受影响单元。这将一个发现的缺陷转化为流程的永久性改进。

前提条件：构建可靠裁判

在翻译生产代码之前，需先创建验证系统，使其能在同等条件下评估新旧实现。

若无可靠裁判，项目便无可信的完成定义。

用源语言编写的测试套件可能依赖于目标语言中不存在的私有函数、内部类或实现细节。这些测试无法始终直接迁移。

Anthropic 建议分三个阶段准备裁判系统。

1. 对现有测试分类

将表达外部行为的测试与依赖内部实现细节的测试区分开来。

外部测试通常涉及命令行行为、公共 API、文件、网络

、可观察输出或完整应用场景。这些内容在不同语言之间更具可移植性。

2. 为可移植性重写测试

将面向行为的测试转换为能在两个版本上运行的断言。

使用独立的对抗性审查员来确保重写的测试不比原始版本更弱。更容易通过的测试可能会隐藏兼容性问题。

3. 验证评判系统本身

在原始实现上运行评判系统，确认其能通过。

然后有意破坏程序，确认评判系统会失败。如果一个验证系统无法检测到已知缺陷，那它就不具备监督迁移的准备。

迈克·克里格并没有从头开始建立一套完全可移植的测试套件。他的团队创建了一个覆盖七个真实场景的一致性测试框架，并将Python和TypeScript之间的任何差异视为缺陷。

六步Claude代码迁移流程

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

第一步奠定了所有后续代理程序将使用的基础。

首先构建规则手册

规则手册描述源语言应如何映射到目标语言。

其形式取决于迁移策略。

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

• 类型映射。
• 错误处理映射。
• 所有权规则。
• 命名约定。
• 标准库替代方案。
• 外部函数接口模式。
• 异步操作规则。
• 不支持构造的指令。

对于重新设计，规则手册更接近于架构文档。它定义了实现代理必须遵循的新组件边界、接口、数据契约和设计决策。

顺序很重要。规则手册应在差距清单之前编写，因为差距清单记录了默认规则无法安全处理的所有内容。

映射依赖关系

只有当工作流程理解哪些单元相互依赖时，并行工作才是安全的。

依赖关系图有助于确定：

• 哪些模块应首先迁移。
• 哪些文件属于同一批次。
• 哪些接口必须在下游工作开始前稳定下来。
• 哪些循环需要特殊处理。
• 哪些并行代理可能产生冲突。

有些语言通过包清单或模块元数据公开依赖关系信息。较旧的C、C++和Python系统可能需要确定性的分析脚本来发现依赖图。

Claude代码可以帮助创建和运行该脚本，但生成的图应通过机械方式生成，而非仅凭模型输出进行猜测。

记录语言和架构差距

差距清单捕获了无法通过直接翻译处理的差异。

对于从Zig到Rust的迁移，重要的差距包括所有权和内存生命周期。Zig允许一些清理责任由

通过约定或注释来传达，而 Rust 要求所有权约束在类型系统中表达。

对于 Python 到 TypeScript 的迁移工作，接口定义是一个主要差距。Python 通常基于运行时行为接受对象，而 TypeScript 在代码安全编译之前需要显式契约。

清单应被视为一个动态更新的产物。在翻译、编译和一致性测试过程中，新的差距会不断出现。

第 2 步：通过一次性迷你迁移对规则进行压力测试

不要立即将新规则手册应用于数千个文件。

先进行小型迁移，然后故意丢弃输出结果。

对于 Bun，测试涉及少量文件：

1. 一位代理根据规则手册翻译文件。
2. 另一位代理以经验丰富的 Rust 工程师的方式翻译可比较的文件。
3. 第三位代理比较结果并提出更强的规则。
4. 对抗性审查者查找行为或结构性问题。

在实际应用于所有 1,448 个 Zig 文件之前，这项工作暴露了两个严重问题。

保持结构不变的迁移使得这种比较相对容易，因为同一文件的两个实现可以并排审核。

对于重新设计，压力测试应针对架构文档。对抗性代理可以攻击其假设，然后进行一次性端到端运行，以暴露缺失的接口和不切实际的顺序。

目标是改进规则手册，而不是积累生产代码。一旦捕捉到弱点，就丢弃生成的文件。

第 3 步：翻译完整代码库

在规则通过压力测试后，翻译工作可以在整个仓库中展开。

Anthropic 描述了一个包含三个角色的重复循环：

1. 实现者生成翻译后的代码。
2. 对抗性审查者查找缺陷和违反规则的情况。
3. 修复者应用已接受的审查反馈。

实现工作通常可以使用更小、更便宜的模型。最强的模型应保留给审查者、规则编写者、架构决策以及需要更广泛判断的争议。

保持队列的机械性

批处理脚本应通过检查文件系统或其他确定性状态来决定什么是完成的。

例如，当对应的目标文件存在于预期目录并且已通过所需的审查关口时，源文件可以被视为已翻译。

从磁盘重建队列使流程可恢复。如果代理停止、机器重启或批次失败，编排器可以重新构建剩余工作，而无需依赖易失的对话记忆。

明确标记不确定的工作

当实现代理无法自信完成翻译时，应留下可搜索的标记，例如：

TODO(port): 解释为何此部分需要手动处理或后续处理

具体标记形式可以不同，但必须包含原因。这为编译和修复阶段创建了结构化的队列。

使用独立的审查上下文

实现代理不应仅由自身审查。

Anthropic 和 Bun 在独立的上下文窗口中采用了对抗性审查。审查者收到变更后的代码并被指示假设实现包含缺陷。

两个审查者可以独立检查同一批次。若结论冲突，可由第三个代理裁决。

这种分离减少了编写代理维护自身选择的倾向，并使长时间自主运行更可靠。

修正生成器，而非每个输出

当审查者反复发现同一缺陷时，应更新规则手册并重新生成受影响的批次。

手动修补数百个生成文件会导致不一致，并使原始故障模式继续存在。修复生成规则可防止问题在后续批次中重现。

步骤 4、5、6：编译、运行和行为匹配

最后三个阶段共享相同的基本循环：产生客观故障、分类、指派修复者、审查修复并重复。

第4步：编译

编译将语言级别的错误转化为确定性队列。

编译是否属于每个翻译循环取决于成本。

Mike Krieger 的 TypeScript 编译器可在几秒内检查一个单元，因此在实现过程中频繁运行。Bun 的 Rust 构建耗时更长，因此 Jarred Sumner 将 Cargo 保持在文件级翻译循环之外，并单独编译更大的批次。

对于昂贵的构建，使用单一编排器或构建守护进程。修复代理编写补丁，仅允许守护进程重新构建。这防止了数十个代理同时启动相同的昂贵操作。

系统级编译器故障值得特别关注。数千个类似错误可能表明缺失依赖规则、错误的模块边界策略或有问题的语言映射，而非数千个无关的失误。

第5步：运行冒烟测试

代码编译后，运行能暴露崩溃和严重运行时故障的最小测试。

冒烟测试结果提供了另一种机械真相来源。根据根本原因对故障进行分组，而不是为每个错误消息分配一个代理而不进行分析。

有用的类别可能包括：

• 初始化失败
• 资源缺失
• 路径处理错误
• 序列化差异
• 内存生命周期缺陷
• 平台特定行为
• 并发假设错误
• 外部函数接口问题

对抗性审查者应检查提出的根因修复方案，尤其当单个改动影响多个文件时。

第六步：匹配原始行为

最后阶段需将新程序与原始程序进行对比。

在两种实现上运行可移植测试套件或对等性验证框架。任何无法解释的差异都应视为迁移缺陷，除非团队有意将其作为产品变更接纳。

修复代理可检查：

• 失败的测试用例
• 原始实现
• 翻译后的实现
• 影响代码的迁移规则
• 先前相关的失败案例

对于耗时较长的重建流程，可采用构建守护进程批量处理补丁、一次性编译、仅重新运行受影响的测试，并将结果返回队列。

当多个测试中出现相同失败模式时，应将修正措施前移。更新规则手册并重新生成错误规则下的文件。

缺乏可移植测试套件的应对方案

缺少测试套件并不意味着迁移无法完成。

可将原始应用作为参考实现，围绕真实用户场景构建行为对等验证框架。

Mike Krieger 的工作流程对 Python 和 TypeScript 版本分别运行七个场景，比对输出结果，并将每个失败案例分配给专门的修复循环。之后 Claude 设计了额外的端到端测试，连续四个通宵运行测试。

即使团队需要围绕原始代码构建新的裁判机制，原始代码仍是唯一基准。

跨项目适用的实践教训

Anthropic 提醒不要将其流程视为通用模板。每个代码库都有不同的构建成本、语言语义、测试质量、平台约束和可接受的权衡方案。

不过以下实践在多个项目中保持一致。

聚焦模式而非个别失败

单个失败案例属于修复循环范畴。

人力应更专注于重复出现的缺陷、缺失的规则、不合理的任务边界、薄弱的验证环节以及编排系统的瓶颈。

采用对抗性审查

审查者应主动尝试证明代码存在错误。

这并不意味着含糊其辞或悲观判断。审查结论应指出具体缺陷、违反的规则、不成立的假设或行为不匹配。

实现验证自动化

编译器、测试用例、确定性脚本、基准测试和输出差异比对应成为成果验收标准。

模型观点对调研和审查有参考价值，但不应替代客观验证——只要客观验证可行。

避免处处使用最强大模型

大规模翻译工作通常具有重复性，可交由较小模型处理。

最强大的模型应用于：

• 制定规则
• 审查架构
• 发现系统性缺陷
• 解决审查分歧
• 设计验证方案
• 处理困难边界情况

这降低了令牌成本，同时并未将最高风险决策中的强推理能力移除。

前置人工投入

规则手册、依赖关系图谱、验证策略及压力测试需要最审慎的人工参与。

一旦这些基础部分稳固，剩余的大量工作便成为队列处理过程。薄弱的基础会让后续每个阶段都变得更加昂贵。

确保工作流可中断恢复

迁移过程应能从中断中恢复，而无需通过聊天历史重建状态。

将进度存储在文件、提交记录、清单、数据库或其他确定性产物中。"完成"应具有机器可读的含义。

分离昂贵的共享操作

编译、集成测试、包创建及完整基准测试可能成为瓶颈。

通过受控服务或守护进程运行这些操作，使并行代理不会浪费资源或破坏共享状态。

Bun 的 Rust 迁移结果

Bun 的 Rust 版本已投入生产环境，尽管结果中仍存在工程权衡。

Anthropic 报告称，约4%的 Rust 代码仍留在unsafe块中，主要涉及 C 和 C++ 边界处的简短指针操作。Rust 并未消除所有底层问题，但将其更多地限制在显式区域内。

报告的改进包括：

测量指标	结果
2000次重复构建时的内存使用	从6745 MB降至609 MB
Linux和Windows上的二进制文件大小	缩小19%
所选实际工作负载的性能	提升2%–5%
可检测的内存泄漏	已修复
Anthropic报告的合并后回归问题	19个，后已修复

这些结果比原始的代码行数更重要。成功的迁移不是以代理生成代码的速度来衡量，而是以兼容性、可维护性、运行改进以及之后持续开发产品的能力来衡量。

团队启动前应评估的事项

在启动大规模AI辅助迁移之前，回答以下问题。

源实现是否为稳定参考点？

如果原始系统正在快速变化，将难以衡量一致性。考虑冻结选定接口，或优先迁移稳定模块。

能否机械地衡量成功？

确定定义完成的编译器检查、测试、场景、基准测试及输出对比。

"使其行为一致"这类模糊目标是不够的。

迁移是保留结构还是重新设计？

直接移植更易于对比和并行化。重新设计可能产生更优架构，但会引入更多判断，需要更严格的设计审查。

最昂贵的环节是什么？

评估以下成本：

• 模型调用
• 编译
• 测试执行
• CI并发
• 仓库存储
• 完整集成运行
• 人工审查

围绕最昂贵的共享资源设计编排器。

哪些操作需要人工批准？

定义以下边界：

• 破坏性Git命令
• 依赖变化
• 架构变化
• 安全敏感代码
• 生产环境凭据
• 发布操作
• 公共API变更

Bun 工作流曾遇到代理通过 git stash 和 git reset 等命令互相干扰的情况。已更新编排规则，禁止不安全的共享仓库操作，并将代理限制在受控的文件级提交范围内。

什么是回滚策略？

在获得证据支持合并之前，迁移应保持可废弃状态。

使用隔离分支、可复现构建、检查点，以及明确流程，在规则错误时放弃或重新生成工作。

常见问题

什么是AI辅助代码迁移？

AI辅助代码迁移使用编码代理，在受控工作流下执行代码库的翻译、审查、编译、测试和修复。该模型不会取代验证环节；编译器、测试、一致性检查以及人工定义的规则仍是权威依据。

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

Jarred Sumner使用Claude Code动态工作流完成了Rust移植，相关GitHub拉取请求已于2026年5月合并。Bun官方账号表示，这项工作耗时约11天，依赖于并行实现、对抗性审查以及项目已有的语言无关测试套件。

Bun迁移涉及多少行代码变更？

合并后的拉取请求显示新增超过一百万行代码，同时伴有删除和修改的代码。仅凭行数无法衡量质量，因此更重要的检查指标是编译结果、跨平台测试、行为表现、内存占用、二进制文件大小以及合并后的回归处理。

Bun的AI迁移成本是多少？

根据59亿未缓存输入token和6.9亿输出token计算，Anthropic估计API成本约为16.5万美元。实际组织成本可能因定价协议、内部基础设施、人员工时、CI使用以及合并后的修复工作而有所不同。

什么是迁移规则手册？

迁移规则手册是一套机器可读或代理可读的策略，描述源语言模式如何映射到目标实现。它涵盖类型、所有权、错误、接口、命名、不支持情况、架构决策以及其他实现代理必须一致遵循的规则。

为什么要使用对抗性审查员？

实现代理拥有上下文和惯性，可能使其倾向于接受自己的解决方案。对抗性审查员在独立上下文中工作，被指示寻找缺陷、违反规则的行为以及行为差异，而非帮助代码合并。

如果没有现有测试套件，这种方法还能起作用吗？

可能可行，但团队必须建立另一个客观仲裁者。一致性测试平台可以对两个实现运行真实场景并比较输出，而新的端到端测试可以暴露静态翻译检查遗漏的故障。

每个遗留代码库现在都适合AI迁移吗？

并非如此。迁移仍需具备可衡量的收益、稳定的参考实现、客观验证、充足的预算和可接受的回滚计划。测试薄弱、行为未作文档记录、需求快速变化或关键安全约束的系统可能需要大量前期准备，或者在当前AI能力下根本不可行。

在智能体能够负责任地提供帮助之前需要进行的准备工作。

相关工具

• Claude Code：Anthropic 的智能体编码工具，用于理解代码仓库、编辑文件、运行命令以及协调开发工作。
• Anthropic 代码迁移工具包：用于构建语言迁移工作流的官方提示词、模板和脚本。
• Claude Code 现代化插件：专注于框架升级和遗留系统现代化（而非完整语言移植）的官方插件。
• Bun：Anthropic 百万行代码从 Zig 迁移到 Rust 案例研究中使用的 JavaScript 和 TypeScript 工具集。
• Rust：Bun 新实现所选择的内存安全型系统语言。
• Zig：Bun 在迁移至 Rust 之前使用的系统编程语言。
• TypeScript：Anthropic 的 Python 迁移示例中使用的带类型 JavaScript 语言。

相关链接

• Anthropic 大规模代码迁移指南：官方的六步方法论及两个 Anthropic 迁移案例研究。
• 将 Bun 重写为 Rust：Jarred Sumner 对迁移动机、编排循环、审查过程和结果的详细技术说明。
• Bun Rust 重写拉取请求：包含大规模 Rust 迁移的已合并公开拉取请求。
• 与 Claude Code 一起使用的代码迁移工具包：基于迁移过程提炼的通用入门工具包。
• 动态工作流介绍：Anthropic 对 Claude Code 中长时运行、自适应多智能体工作流的解释。
• Claude Code 文档：官方安装、工作流、配置和使用文档。
• Claude Code 最佳实践：关于代码仓库上下文、并行会话、验证和智能体工作流的实操指南。

总结

Anthropic 近期的迁移实践表明，语言移植项目可以围绕智能体工作流进行重组，而非依赖单一的长时间手动重写。Bun 从 Zig 到 Rust 的迁移以及 Anthropic 从 Python 到 TypeScript 的项目都依赖于并行实现、对抗性审查、确定性验证和反复的重新生成。

可复用的部分是流程：构建评判器、定义规则、映射依赖关系、对方法进行压力测试、以可恢复的批次进行翻译、编译、运行并比较行为。当同一个缺陷反复出现时，修正产生该缺陷的规则或工作流，而不是手动修补每一个输出。

这种方法仍然需要可观的预算、强健的测试、受控的权限以及架构层面的人工判断。它降低了迁移成本，但并未消除工程工作。

责任。

核心要点很简单：可靠的 AI 迁移源于可验证的生产循环，而非靠一条提示让模型重写整个代码库。