设想这样一个场景：你手头有一个代码迁移任务，以前需要两三个月才能完成；现在有团队声称两周就能搞定，你的第一反应是不是觉得他们在大放厥词？

前两天，开发 Claude 的 Anthropic 公布了一组数据。Bun 是一套 JavaScript 开发工具，他们将底层从 Zig 迁移到了 Rust，整个迁移工作全部交给了 Claude Code。Claude Code 是 Anthropic 推出的 AI 编程助手，常驻在你的代码编辑器和终端里。不到两周时间，它生成了 100 万行代码。另一个项目更令人震撼：仅用一个周末就把 Python 换成了 16.5 万行 TypeScript。

这样的速度摆在面前，很难不让人心动。迁移、重构、批量改稿，是不是也能交给 AI 跑一夜？乍一看，100 万行最引人注目。但再看第二遍时，真正值得关注的，是另一组数字：合并之后冒出了 19 个回归问题。

今天这篇文章，就是要拆解这两组数字背后的真实情况：100 万行是怎么来的，19 个坑又是怎么留下的，最后落到一张你下次让 AI 跑之前必须先填的长任务卡上。读完之后，你会清楚哪些地方可以放心让 AI 执行，哪些地方必须停下来亲自验收。

100 万行怎么来的，19 个坑怎么留下来的

先把官方披露的结果摆出来。Bun 这次迁移在合并前通过了原有测试套件，按理说已经很稳了。结果合并之后还是冒出了 19 个回归问题，最后逐个修复。

时间和金钱是这样的：Anthropic 按 API 价格（即按照模型调用量计算费用）估算，整个过程大约花了 16.5 万美元，消耗了 59 亿未缓存输入 Token 和 6.9 亿输出 Token。Token 可以理解为模型处理文字和代码时的计费单位，59 亿这个数字直接说明——这种规模确实不便宜。

下面是 Anthropic 原文放出的真实 PR 截图，PR 就是代码准备合并时使用的审查页面。上面可以看到 100 多万行新增、6755 次提交、2188 个改动文件。Bun 仓库中的真实页面也与这个数字吻合，至少说明这不是只写在发布稿里的概念图。

100 万行和 19 个回归同时出现，你绝不能只看一面。AI 确实大幅提升了执行规模，但测试覆盖率、新旧行为是否一致、边界场景能否通过——这些仍然需要依靠人和测试层层兜底。

另一个 Python 迁 TypeScript 的项目更加激进：使用了数百个 Agent（Agent 就是能自主接任务、执行并返回结果的 AI 助手）、8 个阶段检查点、3 轮对抗式审查，最后还把每条命令的执行结果与旧版本逐项对比。在这种规模下，团队减少的不是 AI 干活的数量，而是多了规则制定、检查设计以及最终验收拍板的责任。

所以，Anthropic 这套方法值得关注的不是它跑得有多快，而是它把规则、检查、对比、恢复这些容易出问题的环节承接在了哪里。Claude Code 融入你的代码、终端和测试环境，旧代码可以作为参考，编译器和测试持续给出对错信号。这种任务特别适合：有旧东西可对比、有规则可校验、有失败清单可追溯。

但反过来，那些目标模糊、无人能判定对错的项目，Agent 越多就越糟糕——它只会更快地堆出一批没人敢收的结果。

四样东西，决定长任务敢不敢放手

Anthropic 原文给出了一张六阶段总图，全英文，我们把它翻译成普通人能用的版本。它从建规则、试航、全量迁移，走到编译、运行、行为对齐，每一步都有队列、审查、暂停判断的标准。

但你不必照搬六阶段，先把四样东西写进文件就够了：规则书、裁判、任务账本、断点。这四样不是凭空捏造的，而是把 Anthropic 那张图压缩到普通团队能落地的最小版本。普通团队不需要先模仿几百个 Agent 的阵仗，先把这四样写清楚，长任务才有机会从一段聊天变成可恢复、可检查的生产过程。

规则书：先写清楚，再动手。迁移开始前，团队先明确两种语言如何对应：哪些地方可以直接翻译，哪些地方必须重新设计，依赖关系也要先画出来。他们没有写完规则就全量开跑，而是先拿少量文件做试航。试写出来的代码最后直接扔掉，目的就是把规则里没考虑到的坑先炸出来。

怎么判断规则书是否可用？换一个 Agent 按照同一条规则处理同类文件，结果仍然一致。如果同一个错误在多个文件里反复出现，不要逐个补代码，而是先回去修改产生这条错误的规则。先损失几份样稿，能少报废几百份成品。

裁判：什么算对，提前定好。裁判可以是测试、编译器、前后版本结果对比，也可以是一组真实业务场景。它需要同时检查旧代码和新代码，并且要拿故意改坏的版本试一次。原版能通过、坏版会失败，这个裁判才算开始可信。

如果原版和坏版都能通过，先别怪 Agent，是裁判自己失灵了。很多人给 AI 的完成标准只有“能运行”——这太宽松了。能启动不等于行为一致，原有测试全绿也不代表没有漏掉测试从未覆盖的地方。

任务账本：下一步从哪里来，别记在脑子里。官方案例中的队列非常机械：目标文件还没出现，它就在待办里；编译器报错，报错会变成下一张任务卡；测试失败，失败项自动进入修复队列。

成功信号应该是待办能从文件、编译错误和测试结果中重新计算出来，不需要某个人记得还剩多少。如果下一步只存在于聊天记录里，先别让 AI 跑一夜。聊天会压缩，Agent 会换会话，人的记忆也会断——断在哪个环节都没人知道。

断点：靠文件接住，不靠人回忆。队列每次从磁盘上的真实状态重新生成，已经存在的文件算完成，没出现的继续排队。会话停了、电脑重启了、Agent 换了，只要重新读取状态就知道下一张卡是什么——这才叫可恢复。

判断断点合格不合格也简单。关掉当前会话，让另一个人只看留下的文件。如果他能说出做完了什么、下一步是什么、哪里还卡着，断点就能用。如果还得靠原来那个人回忆现场，任务就没有真正落盘。

Meta_Kim 项目也这样设计

讲到这里你可能会问：这套方法压缩成四件套，自己在项目里也用吗？是的。

Meta_Kim 是作者自己的 GitHub 开源项目，放在 Claude Code、Codex 这些执行工具之上，专门管理目标、证据、审查、恢复这四件事。Claude Code 和 Codex 是默认正式支持路径，OpenClaw 和 Cursor 目前属于需要额外选择和验证的兼容路径，项目只做了通用兼容性设计，并未实际测试这两个平台。

项目把一条长任务拆成 8 段：先把真实目标和成功标准说清楚，再找证据、选做法、执行、审查、复查这一轮审查是否足够严格、拿新证据验证，最后决定这次教训要不要写回长期规则。流程名字看着多，说穿了就一句话——先说明白，再动手，做完拿证据，踩过的坑别让下一轮重来。

项目会把当前阶段、已经完成的阶段、下一步、阻塞原因写进状态文件。上下文需要压缩时，续跑包还会记录从哪里恢复、哪些检查已经做过、验证是否还在等。这个设计与 Claude Code 迁移中“从磁盘重建队列”是一回事——记忆不可靠，就把能恢复现场的证据留下来。

在验证规范里还写过一条看似很基础的要求：不能只说“我测过了”。谁测的、测了什么、跑的哪条命令、结果放在哪、失败以后怎么办，这几样必须对得上。命令退出码是 0，只能证明命令没报错，不能自动证明用户原来的目标已经完成。

工具不一样，原理是一样的：容易忘的交给文件，容易争的交给裁判，最终的取舍还是留给人。

最后一段是回写。反复出现、能写成预防规则、还能补一条回归测试的教训，才值得进入长期规则。只在这一次任务里有用，就留在本次记录里。一次失败被解决掉不算学会，能让下一批不再犯，才算把问题修到了上游。

先填这张卡，再决定要不要扩 Agent

你不用一上来搭 8 个阶段，也不用真的叫来 200 个 Agent。下次准备把迁移、重构、批量改稿、资料整理这种长任务交给 AI，先把下面这张卡填完。

如果你想进行最小测试，可以使用下面这段提示词，把它填写明白，就能获得一个非常合理的工作流程。

长任务卡

目标：这次到底要改变什么
完成标准：看到什么证据才算结束

规则书：哪些做法固定，哪些情况必须停下来问
裁判：用测试、对比、样例还是人工检查判定对错
任务账本：什么东西能自动变成下一张待办
断点：会话中断后，靠哪个文件或状态继续

小规模试航：先拿哪 3 个样本把规则里的坑炸出来
成功信号：原版能过、坏版会失败、重开后知道下一步
失败先查：完成标准、裁判、任务账本还是断点
重复错误处理：改当前结果，还是回去改产生它的规则
停止条件：出现什么情况立刻暂停，不继续消耗
最终验收人：谁为点通过负责

填不出完成标准，先别扩 Agent。裁判没拿坏样本测过，先别相信它。任务账本只在聊天里，先别让 AI 跑一夜。断点说不清，先把任务缩到一次会话能收住。

老实讲，Claude Code 这次压缩的是大规模执行的时间。过去一个团队几年不敢碰的迁移，现在可能值得重新评估，但它仍然不便宜，也没有把责任一起外包掉。

最后，不妨用一句话总结。作为一个玩过《魔兽世界》的老玩家，哥布林说过这样一句话，印象非常深：“时间就是金钱，我的朋友！”

所以，非常看好并行制作这件事情，但是并行的质量需要严格的保障。

时间折叠将会是人类放大自我价值的唯一途径。