AI 迁移200张表的教训：上下文窗口这样用才省

两百多张表，从旧架构迁移到新架构。字段名、类型、外键——全部需要核对。我估计要两天。

实际花了四天。其中大约一天是在等用量限额重置。

我一开始做错了什么

我把整个 schema 一次性倾倒出去，让 AI 生成一张表一张表的迁移计划。前面二十张进展顺利。过了五十张左右，它开始出错——把两张相似的表搞混，或者重复处理已经处理过的表。

当时我以为是模型不够好。不是的。是上下文已经填满了。五十张表的内容都塞在里面，而它还得在那堆噪声里定位到当前处理的那一张。

这是我希望早点明白的一点：用量是按上下文计费的，不是按问题数量。每一次请求都携带完整的对话历史。一场八小时会话中一个一行的问题，其成本可能是全新会话中同样问题的十倍以上。

我改成了十张一批的处理方式。每批完成后：

把进度写入文件（完成了什么、做了哪些决定、遇到了什么坑）

在下一批开始前，把进度文件读回来

错误率下降了。用量也下降了——每批现在携带十张表加上一小段摘要，而不是累积的两百张。

这个「写进度 → 清空 → 重新读取」的循环成了我做批量任务的默认方式。没什么技巧，就是管用。

同一项目中的其他几个习惯

让它做一个可运行的检查，而不是描述。「迁移这张表并运行 schema diff」比「迁移这张表」要好。当它有一个可以执行的检查时，它会自己迭代，而不是停在「看起来完成了」。

把探索工作委托给 subagent。当我需要理解旧 schema 在代码库中实际是怎么被使用时，我让一个 subagent 去读取相关文件并汇报摘要。它的上下文吸收了那些噪声，我的上下文保持干净。

不要一整天保持一个会话开着。我以前会这样。到了第八小时，成本曲线是很残酷的。

没人警告你的那部分

正确地做这件事，成本更高，而不是更低。可运行的验证意味着额外的迭代。Subagent 意味着额外的上下文窗口。一次单独的 review 意味着另外一整个 agent。

所以到了月中你就陷入了一个糟糕的境地：限额快用完了，而你想要砍掉的恰恰是验证步骤。但这恰恰是不应该砍掉的部分。

对我来说真正解决这个问题的是把「这周我需要多少容量」和「我每个月为哪个套餐付费」解耦。这样的迁移是一次三天的峰值——这个月其余时间我远没有达到上限。为三天升级一个套餐是很不划算的，而在批量任务中途等待限额重置意味着之后要重新建立上下文，又是一笔开销。

我一直在用 Asale 来处理峰值任务。它的机制很简单：套餐容量用不完的人把它挂出来，需要的人从中提取。能让这样一个工具对这类工作真正实用而不是仅仅便宜的原因：

在承诺之前你可以看到要付多少——它按每百万 input/output token 明码标价，旁边显示相对于列表价格的百分比，这样就和你已有 API 成本的认知方式一致了

它不绑定单一供应商，所以当我想要用一个第二模型对棘手的迁移做合理性检查时，可以不用同时持有两个订阅就能做到

随时充值，完成批次，停止。没有月度订阅留下后被遗忘

在尝试之前你应该知道的权衡

请求是通过另一个用户的客户端转发的，所以载荷在那一跳是可见的——没有端到端加密。他们在自己的首页上声明了这一点，并指出共享订阅容量可能与上游条款冲突。这把边界定义得足够清晰了：个人项目和开源，可以。公司代码，不行。

客户端在 GitHub 上，搜索 asale。源码是公开的，考虑到请求会经过别人的机器，这是我关心的一点。

我很想知道是否有比进度文件循环更好的批量工作模式。我的方案感觉粗糙，但我还没找到更好的。