Claude Code两周100万行背后，藏着19个坑没人提！
图片加载中…
先说一个场景：你手下有个迁移活，以前要拖两三个月；现在有团队说两周搞定，你第一反应是不是觉得他们在吹？
前两天，做 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 这次压缩的是大规模执行的时间。过去一个团队几年不敢碰的迁移，现在可能值得重新算账，但它仍然不便宜，也没有把责任一起外包掉。
还是老金想表达那句话啊。作为一个玩过《魔兽世界》的老登来讲，其中的哥布林说过这样一句话，老金的印象是非常深的：“时间就是金钱，我的朋友！”
所以，老金非常看好并行制作这件事情，但是并行的质量需要严格的保障。
时间折叠将会是人类放大自我价值的唯一途径。