先说一个场景你手下有个迁移活以前要拖两三个月现在有团队说两周搞定你第一反应是不是觉得他们在吹前两天做 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 的项目更狠用了数百个 AgentAgent 就是能自己接任务、自己执行、自己交回结果的 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 这次压缩的是大规模执行的时间。过去一个团队几年不敢碰的迁移现在可能值得重新算账但它仍然不便宜也没有把责任一起外包掉。还是老金想表达那句话啊。作为一个玩过《魔兽世界》的老登来讲其中的哥布林说过这样一句话老金的印象是非常深的“时间就是金钱我的朋友”所以老金非常看好并行制作这件事情但是并行的质量需要严格的保障。时间折叠将会是人类放大自我价值的唯一途径。谢谢你读我的文章。如果觉得不错随手点个赞、在看、转发三连吧如果想第一时间收到推送也可以给我个星标⭐谢谢你看我的文章。开源知识库交流群开源集合都看这https://tffyvtlai4.feishu.cn/wiki/OhQ8wqntFihcI1kWVDlcNdpznFf​