如果你还在拿AI自动补全几行代码就觉得"AI编程不过如此"，那最近Anthropic公布的一组数据，可能会让你重新理解什么叫"人机协作"。
Bun的创始人Jarred Sumner，用Claude Code在不到两周的时间里，把Bun从Zig语言迁移到了Rust——整整100万行代码。合并前，Bun全部现有测试用例在CI里100%通过。合并后冒出19个回归问题，如今也全部修完。Rust版已经在6月随Claude Code悄悄上线。
这不是一个"让AI写几行代码"的故事，而是一次工业级的代码搬迁。
从300万美元到16万，从4年到2周
这组数字背后的对比，才是真正让人坐不住的地方。
这次迁移烧掉了59亿输入token、6.9亿输出token，按API定价算，约16.5万美元。听着不便宜？对比一下传统方式：同样的项目，过去需要一支工程师团队干上4年，成本在300到400万美元之间。16万对300万，两周对4年——这个差距，已经不是在"降本增效"，而是在改写整个软件工程的成本模型。
但烧钱只是表面。真正的价值在迁移之后：内存占用从6745MB暴跌到609MB，二进制体积缩小19%，实际负载下性能提升2%到5%，所有可检测的内存泄漏全部修复。
Anthropic Labs联合负责人Mike Krieger（Instagram联合创始人）的案例同样震撼。他用一个周末，把一套Python代码库迁成16.5万行TypeScript，编译时间从8分钟压到2秒，二进制启动速度提升6倍。他的团队还因此砍掉了一整条独立部署管线。
核心不是「AI替人写代码」，而是「修流程不修代码」
如果只看到"AI两周写了100万行代码"，那你就错过了这件事真正的含金量。
Anthropic从这些案例里提炼出了一个核心洞察：你不是在修代码，你是在修那个产生代码的流程。 这句话值得贴在你工位上。
他们总结出一套"六步框架"，适用于任何语言、任何规模的代码迁移：
第零步：准备一个公正裁判
开工之前，你得有一套能同时评判原代码和新代码的测试标准。用Claude对现有测试进行分类，把对外接口的测试改写成新旧通用的断言，再用对抗性智能体验证裁判本身是否公正。Mike甚至让Claude自己设计了一套端到端测试，连着跑了四个通宵，专抓那些没人预料得到的边角问题。
第一步：立规矩，画依赖图，列缺口清单
写一份规则手册，定义两种语言之间的类型映射、惯用写法转换；画一张依赖关系图，把任务拆成可并行的独立单元；列一份缺口清单，标明规则覆盖不到的地方。顺序很重要——规则手册决定缺口清单的范围，两者要放在一起审计。
第二步：小规模试航
选几个代表性文件做一次迷你迁移。同时跑三个智能体：一个严格按规则手册翻译，一个模仿资深工程师的做法自由发挥，一个对比两者的差异提炼新规则。这一步的目的是在铺开到几千个文件之前，把致命问题揪出来。注意：试航产出的代码全部丢弃——目标是修规则，不是攒进度。
第三步：全员翻译
这是整套框架的核心：建立一个"实现→审查→修复"的多智能体循环。小模型负责机械的翻译工作，大模型负责审查和规则更新。任务队列完全机械化——脚本检查磁盘上哪些文件已经翻译完成，自动分配剩余任务，天然支持断点续跑。审查员发现重复出现的错误时，不修单个文件，而是回溯修规则手册，然后批量重生成。
第四到六步：编译、冒烟测试、逐项比对
这三步共用同一套循环，人工干预越来越少。编译错误交给修复智能体并行处理；冒烟测试的崩溃按根因归类后统一修复；最后用测试套件逐项对比新旧代码库的行为差异。整个过程，对抗性审查负责把关，编译器和测试脚本负责做公正裁判——人的判断只在规则层面介入。
这套框架对普通开发者意味着什么？
你不需要一个100万行的代码库才能用这套方法。哪怕你在做的是一个几千行的Side Project，这套思路同样生效：
先建裁判，再动手。 不管项目大小，动手之前先问自己：我怎么验证改完的代码是对的？如果答案不清晰，那就别开始。
用规则代替直觉。 与其每次对着AI的输出靠感觉判断好坏，不如花时间写一份规则手册——哪怕只有半页纸。规则越清晰，AI的输出越可控。
修流程，不修个案。 当AI反复犯同一类错误时，别手动改代码，改你的prompt、改你的规则、改你的校验脚本。一次投入，百次收益。
大模型审，小模型干。 如果你同时在用多个模型，把高吞吐量的翻译任务交给便宜的模型，把审查和规则迭代留给最强的模型。Jarred和Mike都是这么做的。
Anthropic这组案例的价值，不在于证明"AI能替代程序员"。恰恰相反，它证明了另一件事：当AI工具足够强大时，真正拉开差距的，不再是"谁代码写得快"，而是"谁更会设计流程、制定规则、建立验证体系"。这才是AI编程的下半场。