核心要点摘要
- 大规模迁移的首要交付物不是目标语言代码，而是能同时评价新旧实现的 judge 与 parity 样本。
- 规则手册、依赖图、机械队列和可恢复构建环境，决定多智能体并发能否转化为可合并成果。
- 原有 CI 全绿只说明已知测试通过，上线前还要补真实样本回放、耐久性观测和细粒度回滚。
直接说结论：Claude Code 可以把代码翻译和修复速度推到新的量级，但工程团队仍要自己定义验收标准。本文关注怎样把生成、审查、构建和行为对齐接成一条能重复运行的流水线。
2026 年 7 月 16 日，Anthropic 公布了几次大规模代码迁移的实践。其中最醒目的数字，是 Bun 把一套 Zig 实现迁到 Rust：不到两周生成约 100 万行代码，合并前通过原有 CI 测试，合并后仍发现 19 个回归。另一个 Python 到 TypeScript 的项目，在一个周末迁移约 16.5 万行代码，动用了数百个智能体。只看代码产量，很容易把重点放在“模型写得多快”；从工程角度看，更值得复用的是它怎样把迁移变成一条可暂停、可恢复、可否决的流水线。
Judge 必须先于翻译任务存在
大规模迁移的起点不是让模型打开第一个文件，而是先造一个能同时评价新旧实现的 judge。它可以是完整测试套件，也可以是命令输出对比器、协议回放器、编译产物检查器或业务样本裁判。关键要求只有一个：旧代码和新代码接受同一输入，并用同一标准判断结果。
如果项目本来缺少测试，不能因此跳过验证。可以先从高频命令、异常参数、边界数据和生产日志中抽样，做一套最小等价性样本。Python 到 TypeScript 的案例最后使用了命令输出 parity diff，并跑了 7 个真实场景；端到端测试还连续运行了 4 个夜晚。这里的意义不在于“七个场景就够”，而在于验证对象必须落到可比较的输出，而不是代码风格相似或编译通过。
judge 还要独立于翻译智能体。若生成者同时决定哪些差异可以忽略，迁移很容易在不知不觉中改变行为。工程上可以把结果分为三档：完全一致、允许差异、阻断差异。允许差异要有人写明原因，例如日志时间戳、路径分隔符或排序方式；阻断差异则回到修复队列，不允许靠人工口头放行。
规则手册和机械队列比长提示词更重要
Anthropic 总结的流程先做依赖图、差距清单和规则手册，再用一小段“可丢弃迁移”压力测试规则。试跑的产物不保留，暴露出来的规则缺口才是成果。这样可以避免团队在迁移到一半时才发现，某类内存语义、错误处理或平台条件编译从未定义过。
实际执行队列要尽量机械化。每个工作项至少记录源文件、目标文件、依赖状态、实现轮次、审查结论、构建错误和重试次数。工作进程退出后，下一次运行能从队列继续，而不是重新阅读整个仓库再猜进度。编译服务可保持常驻，因为频繁冷启动大型构建环境会浪费大量时间；构建失败也应自动归档为下一轮修复输入。
模型分工不必追求所有任务都用同一档。实现层是大量可并行、可检查的小工作，审查层则要发现跨文件语义偏差和规则漏洞。团队若要比较不同候选模型，可以用 147AI 按任务编号记录实现、复核、失败原因与调用成本，再把通过 judge 的结果作为比较口径，而不是只看生成速度。它解决的是调用与评测记录问题，并不替代 Claude Code 的迁移流程或仓库权限控制。
上线标准不能停在 100% CI
Bun 案例在合并前通过了现有测试，合并后仍出现 19 个回归，这说明“测试全绿”只能证明已覆盖的部分没有报错。迁移还会触碰长期运行内存、平台差异、极端输入、性能退化和未被测试描述的隐含行为。上线门槛因此要包括冒烟测试、行为对比、资源指标和生产观测，而不只是单次 CI。
官方数据也提醒团队别把迁移想成低成本自动化。Bun 迁移使用约 59 亿未缓存输入 token 和 6.9 亿输出 token，按 API 价格估算约 16.5 万美元。结果有明显收益：在 2000 次重复构建测试中，内存从 6745 MB 降到 609 MB，Linux 和 Windows 二进制体积缩小约 19%，部分工作负载快了 2% 到 5%。但这些数字属于具体案例，不能直接写进自己的立项收益表。
更稳妥的上线方式是先跑影子流量或双执行，记录新旧结果分歧，再按模块逐步扩大。回滚单位也要足够小，应能退回某个包或某条命令，而不是只能撤销整次迁移。真正可复制的经验不是“百万行也能自动写”，而是先让验证闭环成立，再让生成速度进入这个闭环。
把六步流程改成可执行的阶段门
一条可执行的迁移流水线至少要回答五个问题：工作项从哪里领取，什么结果算完成，失败后回到哪一步，谁有权批准差异，怎样撤回已经合并的模块。可以把队列设计成下面几类状态，而不是只记录“处理中”和“已完成”。
| 阶段 | 必留证据 | 阻断条件 |
|---|---|---|
| 规则准备 | 规则版本、依赖图、允许差异 | 关键语义没有定义 |
| 翻译实现 | 源提交号、目标文件、模型与轮次 | 依赖未满足或输出不完整 |
| 构建检查 | 平台、命令、错误摘要、产物哈希 | 任一目标平台编译失败 |
| 行为对比 | 样本版本、新旧输出、差异分类 | 出现未批准的行为差异 |
| 灰度上线 | 流量比例、资源指标、回滚点 | 回归或资源指标越过阈值 |
这张表不要求所有项目使用同样的阈值，但要求每一项都能被机器读取。若失败只能靠某位工程师回忆上下文，队列就无法真正恢复；若差异没有批准记录，后续也无法判断它是有意改动还是遗漏回归。
并发扩容应放在阶段门稳定之后。先观察规则变更频率、编译等待时间、judge 队列长度和人工介入比例。任何一项持续上升，都说明瓶颈还没解决，增加工作进程只会制造更多待复核代码。
迁移流水线常见问题
没有完整测试套件，能不能开始？
可以先建设最小 parity harness，从高频命令、生产脱敏样本和高损失异常入手。没有测试不是跳过 judge 的理由，而是先把隐含行为转成可执行样本的理由。
怎样判断应修代码还是修规则？
单个文件的偶发错误通常回到实现任务；多个工作项反复出现同类偏差，应暂停同类队列并修改共享规则。只修每个文件，会让同一种错误在下一批继续复制。
什么时候可以扩大并发？
当规则稳定、构建服务没有形成长队、judge 能及时消费产物，且失败类型不再集中于同一缺口时再扩容。
内容更新时间：2026-07-17
官方来源：Anthropic：How Anthropic runs large-scale code migrations with Claude Code
证据边界：案例数字和流程来自 Anthropic 2026-07-16 官方文章；落地清单与治理方法为基于案例提出的工程建议。
