1. 撞墙那一刻5小时配额到底卡在哪第一次被 Claude Code 的配额墙弹脸是在一个周四凌晨两点。当时我正在重构一个老项目的鉴权模块上下文已经堆到 8 万多 tokenCLI 里连续跑了十几轮工具调用突然终端返回一行冷冰冰的提示大意是本周期内的用量已达上限请等待重置。那一刻我的第一反应不是骂人而是意识到一个更本质的问题我把 Claude Code 当成了一个无限续杯的对话窗口但它其实是一个有明确预算约束的工程执行器。这个认知差是绝大多数人第一次撞墙的根源。Claude Code 的计费与配额模型和网页版聊天窗口完全不是一回事。网页版你发一条消息消耗一次而 Claude Code 在 CLI 里执行一个任务背后可能是几十次模型往返——读文件、改文件、跑测试、看报错、再改、再跑。每一次工具调用tool use都是一次独立的模型请求都会计入你的用量。所以你在终端里感觉我只问了一个问题实际上模型可能已经替你干了三十件事。提示判断自己是不是重度消耗型用户看一个指标就够了——单次任务里工具调用轮次是否经常超过 15 轮。超过你就是在高速烧配额。我后来复盘那次撞墙发现真正的浪费点有三个。第一上下文没有做裁剪把整个大文件反复塞进每一轮请求token 消耗呈线性甚至平方级增长。第二任务粒度过粗我让它重构整个鉴权模块而不是先改 token 校验函数跑通测试再继续。第三没有断点意识一旦中断前面所有上下文全部丢失重来一遍等于把配额再烧一遍。所以这篇东西的核心不是教你如何绕过配额——那是没意义的配额就是配额。我要讲的是当配额墙必然出现时怎么让工作流具备断点续传能力把一次长任务拆成多个可恢复的短任务让每一次中断都不浪费。这套思路我称之为三板斧后面会一层层拆开讲。它适合所有把 Claude Code 当生产力工具、而不是玩具的人尤其是那些在 CLI 里跑真实项目、动辄几小时连续作业的开发者。2. 三板斧总览把一次性长跑改成可存档的接力赛在讲具体操作之前先把整体设计思路说清楚。很多人一遇到配额问题第一反应是去找更省 token 的模型或者更聪明的提示词这属于战术层面的小修小补。真正管用的是在架构层面把工作流改造成可中断、可恢复、可验证的形态。我的三板斧本质上是三个层次的防御第一板斧任务切片与状态外置。把一个大任务拆成若干个原子步骤每一步的输入、输出、结论都写到磁盘上的结构化文件里而不是只存在对话上下文里。这样即使会话断了状态还在。第二板斧上下文预算管理。给每一轮请求设定 token 预算上限主动裁剪历史只保留当前步骤必需的信息。这是省配额的关键也是让断点续传真正可行的前提。第三板斧断点续传协议。定义一套从哪里断、从哪里续的约定包括进度文件格式、恢复时的上下文重建规则、以及幂等性保证——确保重复执行某一步不会产生副作用。这三者是有依赖关系的。没有任务切片就没有断点可续没有上下文预算管理切片之后每一片还是太贵没有续传协议切片了也不知道怎么接回去。所以顺序不能乱。我用一个生活化的类比帮你理解这就像装修房子。一次性长跑相当于请一个师傅从毛坯干到精装中间不许停师傅一旦有事走了前面砌的墙、铺的线全得重来。而三板斧相当于把装修拆成水电、泥瓦、木工、油漆四个阶段每个阶段结束拍照片、写验收单师傅换人了下一个师傅拿着验收单接着干。配额墙就是那个师傅必须休息的强制中断而三板斧让你在师傅休息时工地状态是完整保存的。注意三板斧不是让你少用 Claude Code而是让你用得更有结构。省下来的配额最终是为了让你能跑更复杂、更有价值的任务而不是为了省而省。下面我逐板斧拆解每一板斧都会给出可直接抄作业的文件结构、提示词模板和实操命令。2.1 为什么状态外置是断点续传的地基先讲一个反直觉的点Claude Code 的会话上下文本质上是一种易失性存储。会话一断上下文就没了。你可能会说不是有 --continue 或者会话恢复吗对但那恢复的是对话历史不是任务状态。对话历史里混杂着大量已经完成的、无关的、甚至错误的中间过程恢复回来反而拖累后续判断。真正可靠的状态必须外置到文件系统。我习惯在项目根目录建一个.claude-workflow/目录里面放三类文件.claude-workflow/ ├── plan.md # 任务总计划拆解后的步骤清单 ├── progress.json # 进度状态记录每一步的完成情况 ├── context/ # 每一步的上下文快照 │ ├── step-01.md │ ├── step-02.md │ └── ... └── artifacts/ # 每一步产出的实际文件代码、报告等plan.md是给人看的也是给模型看的它定义了我们要做几件事、顺序是什么。progress.json是机器可读的进度账本格式大概长这样{ task: 重构鉴权模块, steps: [ {id: 1, name: 梳理现有鉴权逻辑, status: done, artifact: context/step-01.md}, {id: 2, name: 改写 token 校验函数, status: done, artifact: context/step-02.md}, {id: 3, name: 补充单元测试, status: in_progress, artifact: null}, {id: 4, name: 跑通集成测试, status: pending, artifact: null} ] }这个文件的价值在于任何时候你重新打开 Claude Code第一件事就是让它读 progress.json它立刻知道我干到哪了、下一步该干嘛。不需要你重新解释背景不需要它重新理解需求。这就是断点续传的地基。我实测下来这套结构让我的恢复成本从原来的重新解释五分钟降到读一个文件三秒钟。别小看这几分钟配额墙往往出现在你状态最好的时候恢复成本越低你越不容易因为烦躁而放弃整个任务。2.2 上下文预算给每一轮请求装一个油表第二板斧是省配额的核心。Claude Code 烧 token 的大头从来不是你的提问而是它自动塞进去的上下文——项目文件树、相关文件内容、历史对话、工具调用结果。这些加起来轻松就能到几万 token。我的做法是给每一轮请求设一个预算上限并在提示词里显式约束。具体来说在每一步开始前我会在context/step-XX.md里只放三类信息本步骤的目标一句话不超过 50 字本步骤必需的输入只放相关文件的关键片段不放整个文件上一步的结论从 progress.json 里摘出来不放原始对话然后提示词模板大概是这样你正在执行一个多步骤任务的第 N 步。 当前步骤目标{目标} 必需输入{关键片段} 上一步结论{结论} 约束 - 只处理当前步骤不要提前做后续步骤 - 不要读取与本步骤无关的文件 - 完成后把结论写入 context/step-N.md并更新 progress.json这个模板的关键在于不要读取无关文件这一条。Claude Code 默认会主动探索项目结构这在探索阶段是优点在执行阶段就是烧钱。你明确告诉它别乱看它就会老实很多。提示如果你发现某一轮请求的 token 消耗异常高八成是模型偷偷读了某个大文件。养成习惯每完成一步就cat progress.json看一眼心里有数。2.3 断点续传协议定义怎么接回去第三板斧是把前两板斧串起来的协议。它要回答三个问题从哪里断的、续的时候需要什么、怎么保证不重复劳动。我的协议很简单就三条规则规则一每步结束必须落盘。不管是成功还是失败都要更新 progress.json把当前步骤标记为 done 或 failed并写明原因。失败也是一种状态比不知道干到哪了强一万倍。规则二恢复时先读账本再干活。重新进入会话第一句永远是读 .claude-workflow/progress.json告诉我下一步该做什么。让模型自己判断而不是你替它判断。规则三每步操作必须幂等。也就是说同一步骤重复执行两次结果应该一样。比如改写函数这种操作如果第一次已经改好了第二次执行应该检测到已经是目标状态然后跳过而不是再改一遍改出问题。规则三最容易被忽略但它是断点续传的安全带。我踩过的坑是某一步是在文件末尾追加一段配置结果恢复时重复执行配置被追加了两次程序直接报错。后来我把所有追加类操作都改成了检测-替换模式问题就没了。3. 实操全流程从任务拆解到优雅续传的完整走一遍光讲原理没意思我拿一个真实场景带你走一遍。场景是给一个已有的 Node.js 项目补充完整的日志系统涉及梳理现状、设计日志格式、改造多个模块、补测试、跑验证。这个任务如果一次性跑大概率会在改造到一半时撞配额墙。用三板斧我们把它变成可续传的接力赛。3.1 第一步任务拆解与计划落盘我不会一上来就让 Claude Code 干活而是先让它只做计划不写代码。提示词是这样的我要给当前项目补充日志系统。请你先不要写任何代码 只做一件事把整个任务拆解成 5-8 个原子步骤 每个步骤必须满足 - 可以在一次会话内完成 - 有明确的输入和输出 - 输出可以落盘为文件 把拆解结果写入 .claude-workflow/plan.md 并初始化 .claude-workflow/progress.json。这一步本身消耗很少但它产出的 plan.md 是整个工作流的骨架。我实测下来让模型先做计划再执行比直接执行省 30% 以上的配额因为它在执行时不会边想边做反复横跳。拆解出来的计划大概是这样步骤名称输入输出1梳理现有日志相关代码项目源码context/step-01.md2设计日志格式与级别规范step-01 结论context/step-02.md3实现日志核心模块step-02 结论artifacts/logger.js4改造模块 A 接入日志logger.js修改后的模块 A5改造模块 B 接入日志logger.js修改后的模块 B6补充单元测试logger.jsartifacts/logger.test.js7跑通全部测试并修复全部产物测试报告注意步骤 4 和 5 是分开的。很多人会把改造所有模块合成一步结果就是一步烧掉大半配额。拆开之后即使步骤 4 之后撞墙步骤 5 还能在下一个周期继续前面的成果不浪费。3.2 第二步逐步执行与状态落盘计划落盘后进入执行阶段。每一步我都用同一套启动指令读取 .claude-workflow/progress.json 找到第一个 status 不是 done 的步骤 只执行那一步。 完成后更新 progress.json 并把本步骤的结论写入对应的 context 文件。这套指令的好处是完全幂等。不管我什么时候重新进来它都会自动找到下一个该干的活不需要我记住进度。我甚至可以在脚本里写一个循环让它自动一步步跑直到撞墙为止。执行过程中我会盯着两个信号。一个是 token 消耗速度如果某一步明显比预期贵我会中断它检查是不是上下文没裁剪干净。另一个是 progress.json 的更新频率如果连续几步都没更新说明模型卡住了需要人工介入。注意不要迷信全自动。断点续传的价值在于可恢复不在于无人值守。该盯的时候还是要盯尤其是改造类操作改错了文件比不改还麻烦。3.3 第三步撞墙后的恢复演练假设执行到步骤 5 时撞墙了。这时候 progress.json 里步骤 1-4 是 done步骤 5 是 in_progress 或 pending。等配额重置后我重新打开 Claude Code第一句话就是读取 .claude-workflow/progress.json 和 plan.md 告诉我当前进度以及下一步该做什么。 先不要执行只汇报。它会汇报步骤 1-4 已完成步骤 5 改造模块 B 尚未开始建议从步骤 5 继续。 确认无误后我再发执行指令。整个过程不到一分钟状态完全恢复。这里有个细节恢复时不要让它读原始对话历史。原始历史里可能有大量已经过时的中间状态读进来反而干扰判断。只读 progress.json 和 plan.md干净利落。这也是为什么我坚持把状态外置——外置的状态是提炼过的比原始对话精炼得多。3.4 第四步验证与收尾所有步骤 done 之后最后一步是验证。我会让模型读 progress.json确认所有步骤状态然后跑一遍完整测试。如果测试通过整个任务闭环如果不通过把失败信息写入一个新的步骤追加到 plan.md 里继续用同样的流程处理。这套流程跑顺之后我最大的感受是配额墙从一个灾难变成了一个节奏点。以前撞墙我会烦躁现在撞墙我就当是强制休息反正状态都在磁盘上休息完接着干一点不慌。4. 常见问题与排查技巧实录这套工作流我用了几个月踩过的坑不少整理成一张速查表你遇到问题时可以直接对照。现象可能原因排查与解决恢复后模型重复执行已完成的步骤progress.json 没更新或格式错误检查 json 是否合法确认每步结束都落盘某一步 token 消耗异常高上下文未裁剪模型读了无关大文件在提示词里显式约束只读必需文件重复执行导致文件被改坏操作不幂等如重复追加把追加类操作改成检测-替换模式恢复后模型理解错任务读了过时的原始对话历史恢复时只读 progress.json 和 plan.md步骤拆得太粗一步跑不完拆解时没考虑单次会话容量重新拆解每步控制在 10 轮工具调用内步骤拆得太细管理成本高过度拆解合并无独立产出的步骤保持 5-8 步为宜除了表格里的再分享几个独家心得。心得一给每一步设一个验收标准。在 plan.md 里每个步骤除了写目标还要写怎么算完成。比如步骤 3 的验收标准是logger.js 能被 require 且导出的函数有 4 个。有了验收标准模型自己就能判断该不该进入下一步减少你的介入。心得二失败步骤要记录失败原因不要直接删掉。我一开始失败就把步骤标记回 pending结果恢复时模型又用同样的方式失败一次。后来我改成记录failReason: ...恢复时模型会先读失败原因换个思路再试成功率高很多。心得三定期归档 context 目录。跑多了之后 context 目录会堆很多文件虽然不影响功能但会让模型在探索时多读文件。我习惯每完成一个大任务就把 context 归档到context/archive/保持工作目录干净。心得四配额重置时间要记在日历上。不同套餐的重置周期不一样我习惯把重置时间设个提醒这样撞墙后知道大概等多久心里有预期不会干等。5. 把三板斧用成肌肉记忆写到这里其实核心就一句话Claude Code 的配额墙不可怕可怕的是你的工作流没有断点。三板斧——任务切片与状态外置、上下文预算管理、断点续传协议——本质上是在给你的工作流加一层存档系统。有了存档中断就只是暂停不是重来。我现在跑任何超过半小时的 Claude Code 任务都会先花两分钟做计划落盘。这两分钟看起来是额外开销但它换来的是随时可中断、随时可恢复的自由。实测下来同样的任务用三板斧的总配额消耗反而更低因为模型不再反复重读无关上下文也不再因为中断而重做已完成的部分。最后分享一个小技巧如果你经常在同一个项目上跑 Claude Code可以把.claude-workflow/目录加进.gitignore但把plan.md单独提交到版本库。这样团队里其他人也能看到任务拆解思路而进度和上下文快照属于个人工作状态不必共享。这个习惯让我在协作项目里也能放心用这套工作流不会污染主仓库。这套东西没有什么高深技术就是把工程化思维用在了 AI 工作流上。你把它用成肌肉记忆之后配额墙就真的只是一堵墙翻过去就是了。