聚合站上的 Claude Code 撞上上下文窗口上限：把一次大重构拆给多个后端而计划不丢

问题不在模型，在上下文预算

Claude Code 这类编码代理会把对话、读过的文件、工具输出都放进上下文。一次中等规模的重构往往要跨十几个文件，代理为了让模型“看全”，会不断把文件内容读进对话。预算很快被撑爆：要么开始截断、遗忘早期决定，要么被迫在中途丢掉已经形成的计划。

直接换一个上下文更长的后端只能推迟问题，不能解决。因为重构真正的状态是一份“要改哪些文件、每个文件怎么改、哪些先改哪些后改”的计划，而这份计划如果只活在对话里，就会随着上下文被压缩而变得不可靠。

核心思路：计划与执行分离

把一次大重构拆成两层：

• 计划层：一次性产出，说明目标、涉及文件、每个文件的改动意图、依赖顺序和验收方式。这份计划写到磁盘文件里，而不是留在对话里。
• 执行层：按文件拆成独立的小调用，每次只把该文件的相关内容和它对应的那一段计划给模型，改完就结束。

这样单个调用的上下文需求变小且稳定，而总体的计划不随任何一次调用的结束而消失。

让计划落在持久文件里

计划文件是你和代理之间的契约。它至少要回答：

• 重构目标与不做什么（划清边界，避免模型顺手扩大范围）；
• 涉及的文件清单，以及每个文件的改动类型（重命名、抽接口、拆函数、移动逻辑等）；
• 文件间的依赖顺序，哪些改动必须先落地，后续文件才能引用；
• 每个文件改完后的自检方式（能否编译、相关测试是否通过）；
• 进度标记：哪些已完成、哪些待办、哪些期间发现了新情况。

把它写成 markdown 或结构化格式存放在仓库里，代理每次开工先读它，收工再更新它。对话可以丢，文件不会。

一个重要的细节：计划文件要由代理显式维护，而不是靠它“记得”。在每次按文件调用的提示里，要求它先读计划、只做当前文件、改完回写进度。

按文件拆调用

执行阶段每次调用只处理一个文件或一组强关联的小文件。提示里包含：

• 计划文件中与该文件相关的那一段；
• 该文件的当前内容；
• 它需要依赖的、已经改好的接口签名（而不是整个已改文件的全文）；
• 明确的输出形式：完整的替换内容或精确的局部补丁。

这样每次调用的输入规模可控，模型注意力集中在单一改动上，正确率更高，失败时也容易重试而不影响其他文件。

在同一把 key 上分派不同后端

聚合站的价值在这里体现：一把 API key 就能调用 Claude、GPT、DeepSeek、Qwen、GLM、Kimi 等多个后端，不需要为每个后端单独开户、管理多套凭证。

拆分之后，子任务天然可以按特性分派：

• 需要较强推理和长链路改动的文件，交给擅长的后端；
• 机械性重命名、格式统一、样板代码生成，交给更快更省的后端；
• 需要读大段现有代码再判断的，选上下文表现稳定的后端；
• 对同一文件可以让两个后端各出一版，再由计划文件里定义的验收标准择优。

因为调用之间通过计划文件和文件系统解耦，换后端不影响整体流程：每个后端只看到自己那一小段任务，不需要知道整次重构的全貌。

顺序与回滚

按文件拆分后，顺序变得重要。让计划文件显式记录依赖顺序，执行时按顺序推进；每完成一个文件就更新进度并做一次自检。

当某个文件改坏时，回滚粒度是单个文件，而不是整次重构。这让“撞上上下文上限”从一次失败变成一次可恢复的中断。

成本与计费要心里有数

在这类聚合站上，用 key 调用按官方价 ×1.3 扣费；如果你贡献自己的 key，按官方价 ×1.1（优质 ×1.2）返 USDC。拆成多个小调用并不会让单价变化，但因为每次调用的输入更短、更聚焦，浪费在无关上下文上的 token 会明显减少，重试也更便宜。用 Base 上的 USDC 充值、无需 KYC，对小团队做这种多次试验比较方便。

检查清单

• 计划是否写在文件里，而不是只在对话里？
• 每个文件是否有独立的调用与独立的验收？
• 依赖顺序是否显式记录？
• 换后端时，子任务是否仍然自洽？
• 失败时能否只回滚当前文件？

把重构当成“一份计划 + 多次按文件调用”，上下文窗口就不再是天花板，而只是一个需要被管理的预算。