Claude Code 在聚合站 key 上跑到一半崩了：怎样重建会话而不把整个任务重跑一遍

先分清：崩溃后哪些东西还在，哪些没了

Claude Code 在本地工作时，会把不少东西留在你的机器上，而不是只存在于服务端。崩溃或余额耗尽后，先别急着重跑，先确认以下本地状态：

• 工作目录里的文件改动：Claude Code 已经写入或修改的文件都在磁盘上，这部分不会因为会话断开而丢失。
• 命令执行记录：终端里跑过的命令、输出，通常还在你的 shell 历史或终端滚动缓冲里。
• 项目内的会话日志：Claude Code 会在项目目录下维护会话记录（具体路径随版本变化，可用 ls -a 查看项目根目录下的隐藏目录）。这些日志包含之前的对话轮次，是重建上下文的关键。
• 已确认的计划与决策：你在对话中拍板的方案、排除的选项，如果没被记录，就只存在于你的记忆里，需要自己补回。

不在本地的：模型侧的对话状态、未落盘的推理过程、以及任何没有写进文件或日志的中间结论。这些在会话断开后就没了，必须通过重新发送上下文来恢复。

第一步：确认崩溃原因，避免重建后立刻再崩

重建会话前，先判断是哪种中断：

• 余额耗尽：聚合站返回余额不足或 402 类错误。这时先充值（USDC 到账后即可继续），再重建。
• 网络中断：连接超时或流式中断。通常重试即可，不必大动干戈。
• 上下文超限：请求因 token 过多被拒。这种情况重建时必须主动裁剪历史，而不是原样重发。
• 客户端崩溃：进程被杀或终端关闭。本地日志通常完好，恢复成本最低。

不同原因对应不同的重建策略，混为一谈容易白花钱。

第二步：从本地日志提取最小必要上下文

重建会话的目标是让模型知道「我们在做什么、做到哪了、下一步是什么」，而不是复述全部历史。打开项目下的会话日志，提取以下几类信息：

1. 任务目标：一句话说明最终要完成什么。
2. 已完成的部分：列出已经改动的文件、已通过的测试、已确认的方案。
3. 当前卡点：崩溃时正在做什么，报了什么错。
4. 约束与偏好：之前明确排除的做法、代码风格要求、不能动的文件。

把这些整理成一段结构化的开场消息。相比把几十轮对话原样贴回去，这样能大幅减少输入 token，也就直接减少了按 ×1.3 计费的实际支出。

第三步：用文件系统代替对话历史

Claude Code 的优势是能读写文件。重建时，让文件本身承载状态，比让对话承载状态更省：

• 把当前进度写进一个 PROGRESS.md 或类似文件，内容包括目标、已完成项、待办项、已知问题。
• 新会话开场只需说「读 PROGRESS.md，从待办项继续」，模型自己读取，比你手动粘贴更准确，也避免重复描述。
• 已经改好的代码不用再贴，模型可以直接读源文件。

这样做的好处是：会话可以反复重建，而每次重建的输入成本都很低。对于长任务，这是最划算的习惯。

第四步：分段续跑，而不是整段重跑

如果原任务很大，重建后不要试图一口气跑完。按以下方式切分：

• 先让模型复述它从 PROGRESS.md 和代码里读到的状态，确认理解一致，再继续。这一步很短，成本低，但能避免它在错误前提下大改。
• 把剩余工作拆成若干可验证的小步，每步完成后更新进度文件。
• 每步结束让模型总结「改了什么、验证结果如何」，写回文件。这样即使再次中断，下一次重建的起点也更靠前。

分段续跑的代价是多次请求的固定开销，但相比整段重跑浪费的输入 token，通常更省，尤其在任务已经完成大半时。

第五步：控制重建成本的几个具体做法

• 不要在开场消息里粘贴大段代码：让模型读文件。
• 不要重发已完成的对话轮次：只发结论，不发过程。
• 复用同一把 key：聚合站一个 key 可调多个模型，重建时可以先用成本较低的模型整理上下文、确认状态，再切回原模型继续执行。
• 注意计费方式：用户按官方价 ×1.3 扣费，重建产生的每一次请求都计入。把「确认状态」和「执行改动」分开，能避免在错误理解上反复烧钱。
• 余额留余量：长任务前确认 USDC 余额充足，避免跑到关键步骤时中断。

常见误区

• 把整个对话记录原样贴回：输入 token 暴涨，且模型未必能从中提取重点。
• 不看日志直接重跑：已完成的工作重复做，既费钱又可能覆盖正确的改动。
• 忽略上下文超限：如果是超限导致的中断，原样重建会立刻再次失败，必须先裁剪。
• 不写进度文件：每次都靠记忆重建，中断次数越多，成本越高。

小结

Claude Code 崩溃后，本地文件、命令记录和会话日志都还在，真正丢失的是模型侧的对话状态。重建的核心是把状态从对话转移到文件，用最小必要的开场消息接上，再分段推进。这样既能让任务继续，也能把按 ×1.3 计费的重复输入压到最低。