For AI agents: the public content index is available at https://we0.ai/llms.txt, and the English article bundle is available at https://we0.ai/llms-full.txt.
For AI agents: the public content index is available at https://we0.ai/llms.txt, and the English article bundle is available at https://we0.ai/llms-full.txt.
For AI agents: the complete content index is available at https://we0.ai/llms.txt, the full English article bundle is available at https://we0.ai/llms-full.txt, and this page is available as Markdown at https://we0.ai/zh/articles/claude-code-language-migration-workflow-anthropic.md.
对一个成熟的生产级代码库更改主要语言，曾经是团队会推迟多年的项目类型。这项工作成本高昂、风险大且难以评估。一次迁移可能消耗多个工程季度，期间两个实现版本逐渐偏离，最终完成后行为仍不完全一致。Anthropic 近期的内部项目表明，这种情况正在开始改变。2026 年 7 月，Ant...
更改成熟生产代码库的主要语言过去是团队会推迟数年的项目类型。这项工作成本高昂、风险大且难以预估。一次迁移可能会耗费多个工程季度，期间两种实现方案渐行渐远，最终却只能实现不完整的行为一致性。
Anthropic 近期的内部项目表明，这种情况正在开始改变。
2026 年 7 月，Anthropic 发布了一份实践报告，详细介绍了其开发者如何利用 Claude Code、Claude Fable 5、Claude Opus 4.8 以及动态多智能体工作流，在大约一个月内迁移了十个代码包。这些代码包的代码量从数万行到数十万行不等。
其中两个案例尤为突出：
重要的启示并非 AI 模型能够快速翻译文件，而是一个设计良好的迁移系统可以在较少人工干预的情况下，反复生成、审查、测试、驳回和重新生成代码。
Anthropic 这样总结其理念：开发者的主要工作不是手动修补每一个生成的错误，而是改进那个不断产生错误的流程。
Bun 是一个一体化的 JavaScript 和 TypeScript 工具包，包含运行时、包管理器、打包工具、测试运行器以及其他开发工具。其原始实现严重依赖 Zig，并与大量 C 和 C++ 代码集成。
Jarred Sumner 在 11 天内使用了约 50 个动态 Claude Code 工作流来完成 Rust 迁移。合并后的拉取请求包含超过一百万行新增代码和数千次提交。
在合并之前，Bun 现有的持续集成测试套件在其支持的平台上均通过了测试。Anthropic 后来报告称，合并后出现了 19 个回归问题，随后均已修复。
这次迁移并非从零开始的重新设计。其目标是在替换实现语言的同时，保持 Bun 现有的架构和行为。这减少了同时存在的变量：项目可以专注于语言语义、所有权、内存安全性和兼容性，而非从头重建产品。
Bun 的官方报告解释了为什么 Rust 具有吸引力。许多反复出现的稳定性问题涉及生命周期管理、遗漏的清理路径、释放后使用等情况。
条件以及双重释放风险。在安全的Rust中，这些问题中有多个会成为编译期错误，而不是通过生产环境崩溃、模糊测试或人工审查才发现的问题。
Mike Krieger的项目走了一条不同的路。这次迁移并没有尽可能保留原始文件结构，而是涉及了更多的架构重新设计。
结果是在一个周末内生成了大约165,000行TypeScript代码。据报道，该过程使用了：
业务原因很明确。这个基于Python的内部工具以单个二进制文件分发，但生成该二进制文件每个平台需要大约八分钟，整个发布矩阵大约需要30分钟。
迁移之后，编译大约需要两秒钟，启动速度提升了六倍，团队还得以淘汰一个独立的部署流水线。
语言迁移仍然需要真正的工程或业务理由。更快的代码生成并不意味着每次重写都是合理的。
当系统创建以来的环境发生变化时，团队通常会重新考虑语言选择。典型的触发因素包括：
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 及平台特定处理。当迁移规则不明晰时，智能体可随时回溯参考。
当成功与失败可通过机械方式验证时，智能体表现最佳。
编译器、测试套件、一致性脚本、基准测试或确定性输出对比为工作流提供了唯一可信源。系统无需询问审查者新实现“看起来是否正确”，而是反复比对行为与原实现是否一致。
编译器错误、崩溃、测试失败及输出差异自然描述了剩余工作。
迁移系统无需人工逐条编写任务单。每个失败的检查项都可分类并分配给修复智能体。
当同一问题出现在多个文件中时，逐个手动修补并非正确应对方式。
更优方案是更新导致错误的迁移规则，然后仅重新生成受影响单元。这将一个发现的缺陷转化为流程的永久性改进。
在翻译生产代码之前，需先创建验证系统，使其能在同等条件下评估新旧实现。
若无可靠裁判，项目便无可信的完成定义。
用源语言编写的测试套件可能依赖于目标语言中不存在的私有函数、内部类或实现细节。这些测试无法始终直接迁移。
Anthropic 建议分三个阶段准备裁判系统。
将表达外部行为的测试与依赖内部实现细节的测试区分开来。
外部测试通常涉及命令行行为、公共 API、文件、网络
、可观察输出或完整应用场景。这些内容在不同语言之间更具可移植性。
将面向行为的测试转换为能在两个版本上运行的断言。
使用独立的对抗性审查员来确保重写的测试不比原始版本更弱。更容易通过的测试可能会隐藏兼容性问题。
在原始实现上运行评判系统，确认其能通过。
然后有意破坏程序，确认评判系统会失败。如果一个验证系统无法检测到已知缺陷，那它就不具备监督迁移的准备。
迈克·克里格并没有从头开始建立一套完全可移植的测试套件。他的团队创建了一个覆盖七个真实场景的一致性测试框架，并将Python和TypeScript之间的任何差异视为缺陷。
第一步奠定了所有后续代理程序将使用的基础。
规则手册描述源语言应如何映射到目标语言。
其形式取决于迁移策略。
对于保持结构的迁移，规则手册可能包含：
对于重新设计，规则手册更接近于架构文档。它定义了实现代理必须遵循的新组件边界、接口、数据契约和设计决策。
顺序很重要。规则手册应在差距清单之前编写，因为差距清单记录了默认规则无法安全处理的所有内容。
只有当工作流程理解哪些单元相互依赖时，并行工作才是安全的。
依赖关系图有助于确定：
有些语言通过包清单或模块元数据公开依赖关系信息。较旧的C、C++和Python系统可能需要确定性的分析脚本来发现依赖图。
Claude代码可以帮助创建和运行该脚本，但生成的图应通过机械方式生成，而非仅凭模型输出进行猜测。
差距清单捕获了无法通过直接翻译处理的差异。
对于从Zig到Rust的迁移，重要的差距包括所有权和内存生命周期。Zig允许一些清理责任由
通过约定或注释来传达，而 Rust 要求所有权约束在类型系统中表达。
对于 Python 到 TypeScript 的迁移工作，接口定义是一个主要差距。Python 通常基于运行时行为接受对象，而 TypeScript 在代码安全编译之前需要显式契约。
清单应被视为一个动态更新的产物。在翻译、编译和一致性测试过程中，新的差距会不断出现。
不要立即将新规则手册应用于数千个文件。
先进行小型迁移，然后故意丢弃输出结果。
对于 Bun，测试涉及少量文件：
在实际应用于所有 1,448 个 Zig 文件之前，这项工作暴露了两个严重问题。
保持结构不变的迁移使得这种比较相对容易，因为同一文件的两个实现可以并排审核。
对于重新设计，压力测试应针对架构文档。对抗性代理可以攻击其假设，然后进行一次性端到端运行，以暴露缺失的接口和不切实际的顺序。
目标是改进规则手册，而不是积累生产代码。一旦捕捉到弱点，就丢弃生成的文件。
在规则通过压力测试后，翻译工作可以在整个仓库中展开。
Anthropic 描述了一个包含三个角色的重复循环：
实现工作通常可以使用更小、更便宜的模型。最强的模型应保留给审查者、规则编写者、架构决策以及需要更广泛判断的争议。
批处理脚本应通过检查文件系统或其他确定性状态来决定什么是完成的。
输入一句想法，We0 AI 即可生成展示站、页面与 CMS。发布上线后并帮你获取客户和流量。
用户注册赠送一次完整项目生成
适合先体验一次完整生成流程，快速看到项目初稿。
例如，当对应的目标文件存在于预期目录并且已通过所需的审查关口时，源文件可以被视为已翻译。
从磁盘重建队列使流程可恢复。如果代理停止、机器重启或批次失败，编排器可以重新构建剩余工作，而无需依赖易失的对话记忆。
当实现代理无法自信完成翻译时，应留下可搜索的标记，例如：
TODO(port): 解释为何此部分需要手动处理或后续处理
具体标记形式可以不同，但必须包含原因。这为编译和修复阶段创建了结构化的队列。
实现代理不应仅由自身审查。
Anthropic 和 Bun 在独立的上下文窗口中采用了对抗性审查。审查者收到变更后的代码并被指示假设实现包含缺陷。
两个审查者可以独立检查同一批次。若结论冲突，可由第三个代理裁决。
这种分离减少了编写代理维护自身选择的倾向，并使长时间自主运行更可靠。
当审查者反复发现同一缺陷时，应更新规则手册并重新生成受影响的批次。
手动修补数百个生成文件会导致不一致，并使原始故障模式继续存在。修复生成规则可防止问题在后续批次中重现。
最后三个阶段共享相同的基本循环：产生客观故障、分类、指派修复者、审查修复并重复。
编译将语言级别的错误转化为确定性队列。
编译是否属于每个翻译循环取决于成本。
Mike Krieger 的 TypeScript 编译器可在几秒内检查一个单元，因此在实现过程中频繁运行。Bun 的 Rust 构建耗时更长，因此 Jarred Sumner 将 Cargo 保持在文件级翻译循环之外，并单独编译更大的批次。
对于昂贵的构建，使用单一编排器或构建守护进程。修复代理编写补丁，仅允许守护进程重新构建。这防止了数十个代理同时启动相同的昂贵操作。
系统级编译器故障值得特别关注。数千个类似错误可能表明缺失依赖规则、错误的模块边界策略或有问题的语言映射，而非数千个无关的失误。
代码编译后，运行能暴露崩溃和严重运行时故障的最小测试。
冒烟测试结果提供了另一种机械真相来源。根据根本原因对故障进行分组，而不是为每个错误消息分配一个代理而不进行分析。
有用的类别可能包括：
对抗性审查者应检查提出的根因修复方案，尤其当单个改动影响多个文件时。
最后阶段需将新程序与原始程序进行对比。
在两种实现上运行可移植测试套件或对等性验证框架。任何无法解释的差异都应视为迁移缺陷，除非团队有意将其作为产品变更接纳。
修复代理可检查：
对于耗时较长的重建流程，可采用构建守护进程批量处理补丁、一次性编译、仅重新运行受影响的测试，并将结果返回队列。
当多个测试中出现相同失败模式时，应将修正措施前移。更新规则手册并重新生成错误规则下的文件。
缺少测试套件并不意味着迁移无法完成。
可将原始应用作为参考实现，围绕真实用户场景构建行为对等验证框架。
Mike Krieger 的工作流程对 Python 和 TypeScript 版本分别运行七个场景，比对输出结果，并将每个失败案例分配给专门的修复循环。之后 Claude 设计了额外的端到端测试，连续四个通宵运行测试。
即使团队需要围绕原始代码构建新的裁判机制，原始代码仍是唯一基准。
Anthropic 提醒不要将其流程视为通用模板。每个代码库都有不同的构建成本、语言语义、测试质量、平台约束和可接受的权衡方案。
不过以下实践在多个项目中保持一致。
单个失败案例属于修复循环范畴。
人力应更专注于重复出现的缺陷、缺失的规则、不合理的任务边界、薄弱的验证环节以及编排系统的瓶颈。
审查者应主动尝试证明代码存在错误。
这并不意味着含糊其辞或悲观判断。审查结论应指出具体缺陷、违反的规则、不成立的假设或行为不匹配。
编译器、测试用例、确定性脚本、基准测试和输出差异比对应成为成果验收标准。
模型观点对调研和审查有参考价值，但不应替代客观验证——只要客观验证可行。
大规模翻译工作通常具有重复性，可交由较小模型处理。
最强大的模型应用于：
这降低了令牌成本，同时并未将最高风险决策中的强推理能力移除。
规则手册、依赖关系图谱、验证策略及压力测试需要最审慎的人工参与。
一旦这些基础部分稳固，剩余的大量工作便成为队列处理过程。薄弱的基础会让后续每个阶段都变得更加昂贵。
迁移过程应能从中断中恢复，而无需通过聊天历史重建状态。
将进度存储在文件、提交记录、清单、数据库或其他确定性产物中。"完成"应具有机器可读的含义。
编译、集成测试、包创建及完整基准测试可能成为瓶颈。
通过受控服务或守护进程运行这些操作，使并行代理不会浪费资源或破坏共享状态。
Bun 的 Rust 版本已投入生产环境，尽管结果中仍存在工程权衡。
Anthropic 报告称，约4%的 Rust 代码仍留在unsafe块中，主要涉及 C 和 C++ 边界处的简短指针操作。Rust 并未消除所有底层问题，但将其更多地限制在显式区域内。
报告的改进包括：
| 测量指标 | 结果 |
|---|---|
| 2000次重复构建时的内存使用 | 从6745 MB降至609 MB |
| Linux和Windows上的二进制文件大小 | 缩小19% |
| 所选实际工作负载的性能 | 提升2%–5% |
| 可检测的内存泄漏 | 已修复 |
| Anthropic报告的合并后回归问题 | 19个，后已修复 |
这些结果比原始的代码行数更重要。成功的迁移不是以代理生成代码的速度来衡量，而是以兼容性、可维护性、运行改进以及之后持续开发产品的能力来衡量。
在启动大规模AI辅助迁移之前，回答以下问题。
如果原始系统正在快速变化，将难以衡量一致性。考虑冻结选定接口，或优先迁移稳定模块。
确定定义完成的编译器检查、测试、场景、基准测试及输出对比。
"使其行为一致"这类模糊目标是不够的。
直接移植更易于对比和并行化。重新设计可能产生更优架构，但会引入更多判断，需要更严格的设计审查。
评估以下成本：
围绕最昂贵的共享资源设计编排器。
定义以下边界：
Bun 工作流曾遇到代理通过 git stash 和 git reset 等命令互相干扰的情况。已更新编排规则，禁止不安全的共享仓库操作，并将代理限制在受控的文件级提交范围内。
在获得证据支持合并之前，迁移应保持可废弃状态。
使用隔离分支、可复现构建、检查点，以及明确流程，在规则错误时放弃或重新生成工作。
AI辅助代码迁移使用编码代理，在受控工作流下执行代码库的翻译、审查、编译、测试和修复。该模型不会取代验证环节；编译器、测试、一致性检查以及人工定义的规则仍是权威依据。
Jarred Sumner使用Claude Code动态工作流完成了Rust移植，相关GitHub拉取请求已于2026年5月合并。Bun官方账号表示，这项工作耗时约11天，依赖于并行实现、对抗性审查以及项目已有的语言无关测试套件。
合并后的拉取请求显示新增超过一百万行代码，同时伴有删除和修改的代码。仅凭行数无法衡量质量，因此更重要的检查指标是编译结果、跨平台测试、行为表现、内存占用、二进制文件大小以及合并后的回归处理。
根据59亿未缓存输入token和6.9亿输出token计算，Anthropic估计API成本约为16.5万美元。实际组织成本可能因定价协议、内部基础设施、人员工时、CI使用以及合并后的修复工作而有所不同。
迁移规则手册是一套机器可读或代理可读的策略，描述源语言模式如何映射到目标实现。它涵盖类型、所有权、错误、接口、命名、不支持情况、架构决策以及其他实现代理必须一致遵循的规则。
实现代理拥有上下文和惯性，可能使其倾向于接受自己的解决方案。对抗性审查员在独立上下文中工作，被指示寻找缺陷、违反规则的行为以及行为差异，而非帮助代码合并。
可能可行，但团队必须建立另一个客观仲裁者。一致性测试平台可以对两个实现运行真实场景并比较输出，而新的端到端测试可以暴露静态翻译检查遗漏的故障。
并非如此。迁移仍需具备可衡量的收益、稳定的参考实现、客观验证、充足的预算和可接受的回滚计划。测试薄弱、行为未作文档记录、需求快速变化或关键安全约束的系统可能需要大量前期准备，或者在当前AI能力下根本不可行。
在智能体能够负责任地提供帮助之前需要进行的准备工作。
Anthropic 近期的迁移实践表明，语言移植项目可以围绕智能体工作流进行重组，而非依赖单一的长时间手动重写。Bun 从 Zig 到 Rust 的迁移以及 Anthropic 从 Python 到 TypeScript 的项目都依赖于并行实现、对抗性审查、确定性验证和反复的重新生成。
可复用的部分是流程：构建评判器、定义规则、映射依赖关系、对方法进行压力测试、以可恢复的批次进行翻译、编译、运行并比较行为。当同一个缺陷反复出现时，修正产生该缺陷的规则或工作流，而不是手动修补每一个输出。
这种方法仍然需要可观的预算、强健的测试、受控的权限以及架构层面的人工判断。它降低了迁移成本，但并未消除工程工作。
责任。
核心要点很简单：可靠的 AI 迁移源于可验证的生产循环，而非靠一条提示让模型重写整个代码库。
从一句话开始，几分钟内拿到完整网站。
