1. 五小时配额墙到底卡在哪先搞清楚断的是什么用 Claude Code 写代码的人迟早会撞上那堵墙。不是网络断不是模型崩而是你正写到一半终端里突然弹出一行提示告诉你当前会话的用量已经到顶接下来要么等要么换。这个等的周期在多数订阅方案里就是五小时起步。很多人第一次遇到这个提示的反应是懵的。明明刚才还在正常跑怎么突然就不行了其实这不是故障是配额机制在起作用。Claude Code 的订阅制方案背后有一套按时间窗口滚动的用量池你在这个窗口里消耗的 token 和请求次数累积到阈值窗口就会关闭直到下一个窗口开启。关键在于这个窗口是滚动的不是每天零点重置所以你以为睡一觉就好了结果第二天早上打开发现还在冷却期这种情况非常常见。我最初的理解也有偏差以为配额是按天算的。后来实际记录了几次触发时间点才发现它更像是一个滑动的时间桶你从第一次发起请求开始计时五小时内累计的用量达到上限就锁死然后从锁死那一刻起再往后推五小时才解锁。这意味着如果你在窗口快结束时疯狂跑任务解锁时间会被推得很靠后体感上就是怎么等都不好。那为什么这个问题值得单独拿出来讲因为 Claude Code 的使用场景和普通聊天不一样。它不是问一句答一句而是会连续执行多轮工具调用读文件、改代码、跑测试、再读结果、再改。一个稍微复杂点的重构任务可能一口气吃掉几十次请求。你让它把这个模块的错误处理统一一下它可能先扫十个文件再逐个修改再跑一遍 lint这一套下来配额消耗速度远超你的预期。所以断点续传这个词在这里的含义和下载文件时的断点续传不完全一样。下载断的是字节流续的是从第 N 个字节继续。而 Claude Code 断的是任务上下文它已经理解了你的项目结构、已经改了一部分文件、已经形成了对剩余工作的判断配额一到这些脑内状态就丢了。下次你重新开一个会话它对你的项目一无所知你得从头解释一遍它得从头扫一遍等于把之前烧掉的配额又烧一遍。这就是核心痛点配额墙本身不可怕可怕的是撞墙之后上下文归零导致重复劳动。真正要解决的不是如何突破配额那既不现实也不合规而是如何在配额恢复后用最小的代价把任务接上。这也是我后来总结出三板斧的出发点——不是对抗配额而是和配额共存把每次撞墙的损失降到最低。下面我会把这三板斧拆开讲每一板都对应一个具体的失效场景也都会给出可以直接抄的操作方式。不管你是刚装好 Claude Code 的新手还是已经跑了一段时间工作流的老用户这套思路都能直接用。2. 第一板斧把任务切成能独立收尾的小块撞墙最难受的情况是你正在做一个大任务比如给整个项目加上参数校验。这种任务天然是长链条的Claude Code 需要先理解现有代码风格再决定校验逻辑放哪一层再逐个文件改最后统一跑测试。链条越长中途被打断的概率越高而且打断后最难恢复。我的做法是在开始之前就把任务切成可独立收尾的小块。注意关键词是可独立收尾不是可独立开始。区别在于一个能独立收尾的小块做完之后项目是处于一个自洽状态的哪怕你在这里停下代码也是能跑的、能提交的。而一个只是能开始的小块做完一半停下项目就处于半吊子状态下次接手的人包括你自己得先搞清楚上次改到哪了。具体怎么切我一般按一个文件一个闭环或者一个函数一个闭环来分。比如要给项目加参数校验我不会一次性让 Claude Code 处理所有文件而是先让它只处理最核心的那个入口文件改完、跑通、确认没问题再进下一个。这样每一轮消耗的配额是可控的而且每一轮结束都是一个干净的提交点。这里有个实操细节切块的时候要顺手写好交接说明。什么叫交接说明就是你在让 Claude Code 开始这一块之前先用一两句话把这一块要做什么、做完的标准是什么、和上一块的关系是什么讲清楚。比如现在处理 user_service.py 的参数校验。目标是给所有对外方法加上入参类型和范围检查风格参考项目里已有的 validator 模块。做完后这个文件应该能通过现有的单元测试。上一块已经处理完 auth_service.py用的是同一套 validator。这段话看起来啰嗦但它有两个作用。第一它逼你自己想清楚这一块到底要干嘛避免让 Claude Code 去猜。第二万一这一块做到一半撞墙了这段话可以直接作为下一轮的开场白Claude Code 一看就知道上下文不用你重新解释整个项目。我实测下来切块之后单轮任务的配额消耗大概能降三到五成。原因很简单任务边界清晰Claude Code 不需要反复试探我是不是该改这个文件这个改动会不会影响别的地方试探本身就是消耗。边界模糊的时候它会读一堆本来不需要读的文件做一堆本来不需要做的确认这些都是白烧的配额。还有一个反直觉的点不要为了省配额而把块切得太碎。我一开始走极端恨不得一个函数一个会话结果发现每次开新会话Claude Code 都要重新建立对项目的基本认知这个冷启动成本是固定的。块切得太碎冷启动次数就多总消耗反而上去了。比较舒服的粒度是一个块大概对应 15 到 30 分钟的工作量或者对应 3 到 8 个文件的改动。这个粒度下单块任务通常能在配额窗口内跑完冷启动的摊销也合理。为了让你更直观地判断自己的切块粒度合不合适我整理了一个对照表切块粒度单块典型耗时冷启动摊销撞墙后恢复成本适用场景单函数级5-10 分钟高频繁冷启动低零散 bug 修复单文件级15-30 分钟中中常规功能开发模块级1-2 小时低高大型重构项目级数小时极低极高不推荐从表里能看出来单文件级是性价比最高的区间。模块级虽然冷启动摊销低但一旦撞墙恢复成本高得吓人因为模块级任务往往涉及跨文件的依赖关系中断后很难说清楚改到哪了。项目级就更不用说了基本等于把配额当无限用撞墙是必然的。切块这件事本质上是在用任务规划的确定性去对冲配额的不确定性。你没法控制配额什么时候到顶但你可以控制自己手上的任务是不是随时可以停、随时可以接。这个思路一旦建立起来后面两板斧才有发挥的空间。3. 第二板斧用状态文件把脑内上下文外化第一板斧解决的是怎么少撞墙但撞墙这件事本身是躲不掉的配额就那么多任务总有超出的时候。所以第二板斧要解决的是撞墙之后怎么快速接上。核心手段就一个把 Claude Code 的脑内上下文外化成项目里的状态文件。什么叫脑内上下文就是 Claude Code 在会话过程中形成的、但没有写进代码的那些理解。比如它判断这个项目的错误处理统一走 exceptions.py 里的自定义异常比如它发现测试文件都放在 tests/ 下且命名规则是 test_xxx.py比如它决定这次重构先不动数据库层只动 service 层。这些东西它记在会话里会话一断就没了。外化的做法很简单在项目根目录建一个 CLAUDE_PROGRESS.md 文件每完成一个块就更新一次。这个文件不需要写得多漂亮但必须包含几类信息当前任务的整体目标是什么已经完成了哪些块每个块改了什么正在进行中的块做到哪一步了下一步计划做什么过程中发现的重要约定或坑比如这个项目的 import 顺序有 lint 规则改文件时要注意我举个真实的例子。之前做一个 API 版本迁移要把 v1 的接口全部迁到 v2 的路径规范下。这个任务涉及二十多个文件肯定跑不完一个配额窗口。我的 CLAUDE_PROGRESS.md 大概长这样# API v2 迁移进度 ## 总目标 把所有 /api/v1/* 路由迁移到 /api/v2/*保持请求/响应结构不变更新所有调用方。 ## 已完成 - [x] routes/user.py — 已迁移测试通过 - [x] routes/order.py — 已迁移测试通过 - [x] routes/product.py — 已迁移测试通过 ## 进行中 - [ ] routes/payment.py — 已改完路由定义调用方还没更新 ## 下一步 - 完成 payment.py 的调用方更新 - 处理 routes/report.py ## 重要约定 - 路由迁移后旧路径要保留一个 deprecated 装饰器不能直接删 - 所有调用方在 services/ 下用 grep 搜 /api/v1/ 能找到 - 测试文件在 tests/routes/ 下命名是 test_模块名.py这个文件的价值在于下次开新会话第一件事就是让 Claude Code 读它。你只需要说一句读一下 CLAUDE_PROGRESS.md然后继续进行中的任务它就能在几秒内恢复到断点前的状态不需要你重新解释项目结构也不需要它重新扫一遍代码。这里有个关键细节状态文件要写得让没有记忆的 Claude Code能看懂。什么意思就是你不能写继续上次那个改动因为新会话不知道上次那个是什么。你得写payment.py 的路由定义已改完但 services/payment_service.py 里还有三处调用旧路径需要更新。信息要具体到文件、具体到动作不能有指代不明的词。我踩过的一个坑是早期我写状态文件太简略就写了个payment 模块改了一半。结果下次会话 Claude Code 读完还是懵它不知道一半是哪一半只能重新把 payment 相关的文件全读一遍等于状态文件白写了。后来我改成具体到行、具体到函数的写法恢复效率立刻上来了。还有一个进阶用法把状态文件和 git commit 绑定。每完成一个块先更新状态文件再一起提交。这样你的 git 历史里就天然带着进度记录万一状态文件本身丢了或者写乱了还能从 commit message 里找回线索。我现在的习惯是 commit message 直接写完成 user.py 迁移进度见 CLAUDE_PROGRESS.md一举两得。状态文件这个做法说白了就是用磁盘的持久化去弥补会话的易失性。Claude Code 的会话是内存态的断了就没了但文件是磁盘态的只要你不删它就在。把该记的东西记到文件里会话断不断就无所谓了。这也是为什么我把它放在第二板斧——它比切块更主动切块是防守状态文件是进攻让你在撞墙后能快速反打。4. 第三板斧把重复性的恢复动作脚本化前两板斧解决的是任务层面的问题怎么切、怎么记。但撞墙恢复这件事本身还有一堆操作层面的重复动作。比如每次开新会话你都要手动让 Claude Code 读状态文件、读项目结构、读最近的 git log这一套下来也是几分钟。次数多了就烦而且容易漏。第三板斧就是把这些重复动作脚本化。注意这里说的脚本不是让你去写什么自动化工具而是用最朴素的方式把恢复会话这件事变成一个可以一键触发的流程。我的做法是写一个resume.sh放在项目根目录内容大概是这样#!/bin/bash # 恢复 Claude Code 会话的启动脚本 echo 当前进度 cat CLAUDE_PROGRESS.md echo echo 最近 5 次提交 git log --oneline -5 echo echo 未提交的改动 git status --short echo echo 恢复提示 echo 把上面的内容贴给 Claude Code然后说继续进行中的任务这个脚本干的事很简单把恢复会话需要的所有信息一次性打印出来。你运行一下复制输出粘给 Claude Code它就有了完整的上下文。整个过程从原来的手动翻文件、手动敲 git 命令、手动组织语言变成跑一个脚本、复制、粘贴省下来的时间不多但省下来的心智负担很可观。为什么心智负担重要因为撞墙本身已经让人烦躁了如果恢复过程还要你动脑子想我该给它看什么很容易就懒得恢复了干脆去干别的任务就烂尾了。脚本化的意义就是把这个门槛降到最低让你顺手就恢复了。这里有个细节值得说脚本的输出格式要适配 Claude Code 的阅读习惯。我试过几种格式最后发现用清晰的分节标题 xxx 效果最好Claude Code 能快速定位到每一块信息。如果只是把文件内容一股脑 cat 出来它有时候会抓不住重点。另外git log 不要打太多5 条足够打多了反而稀释了关键信息。除了 resume.sh我还建议准备一个checkpoint.sh用来在任务进行到关键节点时快速保存状态#!/bin/bash # 快速保存当前进度到状态文件 echo ## 检查点 $(date %Y-%m-%d %H:%M) CLAUDE_PROGRESS.md echo CLAUDE_PROGRESS.md echo 当前状态$1 CLAUDE_PROGRESS.md echo CLAUDE_PROGRESS.md git add -A git commit -m checkpoint: $1用法是./checkpoint.sh payment.py 路由改完调用方待更新。一条命令既更新了状态文件又提交了代码还留了 commit 记录。这个动作我一般在一个块快做完、或者感觉配额快见底的时候执行相当于手动打了个存档。脚本化这件事很多人会觉得就几步操作值得写脚本吗。我的经验是值得而且越早写越好。因为撞墙恢复是个高频动作只要你用 Claude Code 做正经项目一周撞个三五次很正常。每次省两分钟一个月就是几十分钟更重要的是它让恢复这件事从需要下决心变成顺手就做了这个心理转变的价值远大于时间本身。还有一点脚本要跟着项目走不要放在全局。因为不同项目的恢复流程可能不一样有的项目需要额外读配置文件有的项目需要先启动某个服务。把脚本放在项目根目录跟着 git 一起走换台机器 clone 下来就能用这才是最省心的。5. 三板斧怎么配合一个完整的撞墙恢复实录前面三节分别讲了切块、状态文件、脚本化但它们是配合使用的单独拎出来讲容易让人觉得道理都懂就是不知道怎么串起来。所以我用一个真实的撞墙场景把三板斧的配合过程完整走一遍。场景是这样的我要给一个 Flask 项目加一套统一的请求日志中间件。这个任务涉及中间件本身的编写、在 app 工厂里注册、以及给几个关键路由加上额外的日志字段。预估工作量在两小时左右肯定超一个配额窗口。第一步切块。我把任务切成三块第一块写中间件核心逻辑第二块在 app 工厂注册并跑通第三块给关键路由加字段。每块都是可独立收尾的第一块做完中间件文件能单独测试第二块做完整个 app 能跑起来第三块做完日志字段生效。第二步开跑第一块。我先在 CLAUDE_PROGRESS.md 里写好总目标和第一块的说明然后让 Claude Code 开始。第一块比较顺利大概二十分钟做完中间件文件写好了单元测试也过了。这时候我执行./checkpoint.sh 中间件核心逻辑完成测试通过状态文件和代码一起提交。第三步开跑第二块撞墙。第二块要在 app 工厂里注册中间件Claude Code 需要先读 app 工厂的代码理解现有的中间件注册顺序再决定新中间件插在哪。它读了三四个文件改了两处正准备跑测试的时候配额提示弹出来了。这时候第二块处于改完但没验证的状态。第四步撞墙后的即时处理。我没有慌因为状态文件机制就是为这一刻准备的。我手动在 CLAUDE_PROGRESS.md 里把第二块的状态从进行中更新为改完待验证并补了一句app 工厂里已注册但测试还没跑下次先跑 tests/test_app.py。然后执行./checkpoint.sh 第二块改完待验证配额撞墙。整个过程不到一分钟。第五步配额恢复后恢复会话。五小时后实际我等到第二天我打开终端跑./resume.sh把输出复制给 Claude Code说继续进行中的任务先跑测试验证第二块。Claude Code 读完状态文件直接就知道要去跑 tests/test_app.py跑完发现有个中间件顺序问题修掉第二块完成。整个过程它没有重新读 app 工厂的代码因为状态文件里已经说了已注册它只需要验证。第六步继续第三块。第三块顺利跑完整个任务收尾。这个实录里三板斧的分工很清晰切块让任务在第二块结束时有个自然的停顿点状态文件让改完待验证这个中间状态被准确记录脚本让恢复动作变成两条命令。如果没有这三样第二块撞墙后我大概率会忘记改完但没验证这个细节下次恢复时 Claude Code 可能会重新改一遍或者漏掉验证步骤。这里有个经验值得单独拎出来撞墙的那一刻最重要的动作是记录当前状态而不是抢救着多做一点。很多人撞墙后的第一反应是趁还能用赶紧再让它做一步结果往往是做到一半又断了状态更乱。正确的做法是立刻停手把当前状态写清楚然后安心等恢复。记录的成本是一分钟抢救的收益可能为零甚至为负。另外状态文件里的下一步要写得足够具体具体到跑哪个测试文件改哪个函数。我见过有人写继续完成第二块这种写法等于没写因为新会话不知道第二块是什么。要写跑 tests/test_app.py 验证中间件注册如果失败检查 app/init.py 里的注册顺序。信息密度越高恢复越顺。6. 几个容易踩的坑和对应的绕行方式三板斧讲完了但实操中还有一些细节坑不踩一遍很难意识到。我把几个高频的列出来你对照着避开就行。坑一状态文件写成了流水账。有些人把 CLAUDE_PROGRESS.md 当成日记写今天做了什么、明天计划什么写得很长很全。问题是 Claude Code 读的时候会被无关信息干扰抓不住重点。状态文件要的是结构化不是完整。用固定的几个小节总目标、已完成、进行中、下一步、重要约定每个小节里只放关键信息比长篇大论有用得多。坑二切块切在了依赖关系最紧的地方。比如一个任务里 A 文件依赖 B 文件你把 A 和 B 切成了两块结果做完 A 那块B 还没改项目跑不起来。这种切法就违反了可独立收尾的原则。正确的切法是按依赖关系的闭合来切A 和 B 如果互相依赖就放在同一块里哪怕这块大一点。判断标准很简单这块做完项目能不能跑能跑就是切对了。坑三恢复时忘了检查代码状态。状态文件记录的是我以为的状态但代码实际是什么状态得用 git status 确认。我遇到过一次状态文件写着已提交但实际上 checkpoint 脚本执行失败了代码还在工作区没提交。恢复时如果只看状态文件就会误判。所以 resume.sh 里一定要带 git status恢复时先看一眼实际状态再决定怎么接。坑四把配额恢复时间记错了。前面说过配额窗口是滚动的不是固定时间重置。我建议在撞墙时顺手记一下时间比如在状态文件里写撞墙时间14:30预计恢复19:30 之后。这样你心里有数不会频繁去试好了没试一次也是消耗。坑五三板斧只用一板。有人觉得切块就够了不用状态文件有人觉得状态文件就够了不用脚本。实测下来三板斧是互补的切块降低撞墙频率状态文件保证撞墙后可恢复脚本降低恢复门槛。只用一板效果会打折扣。尤其是状态文件和脚本很多人嫌麻烦不写结果撞墙后恢复得磕磕绊绊反而更费时间。坑六状态文件不跟着代码走。有些人把状态文件放在本地某个笔记软件里不放进项目仓库。这样换台机器、或者多人协作时就抓瞎了。状态文件应该和代码在一起跟着 git 走谁 clone 下来都能看到进度。这也是为什么我建议用 checkpoint.sh 把状态文件和代码一起提交。坑七恢复后不更新状态文件。恢复会话、继续任务、任务做完了但状态文件还停留在旧状态。下次再撞墙读到的就是过时信息。所以每完成一个块都要顺手更新状态文件把它当成代码的一部分来维护。我现在已经养成习惯checkpoint.sh 一跑状态文件自动更新不用额外记。这几个坑里我觉得最值得警惕的是坑二和坑五。坑二是切块的方法论问题切错了整个三板斧的基础就不稳坑五是执行问题三板斧缺一板效果就上不去。其他的坑相对好绕注意一下就行。7. 关于配额这件事我的一些真实体会用 Claude Code 做正经项目有一段时间了配额墙撞了不知道多少次三板斧也是在这些碰撞里慢慢磨出来的。最后分享几点体会不算总结就是一些零散的想法。第一配额限制其实逼着我把任务想得更清楚。以前没有配额压力的时候我经常是大概知道要干嘛就开跑让 Claude Code 自己去摸索。现在因为知道配额有限我会在开跑前把任务拆明白、把状态文件写好这个想清楚的过程本身就提升了任务质量。很多时候 Claude Code 跑偏根源是我自己没想清楚配额墙只是把这个问题的代价放大了。第二断点续传的核心不是技术是习惯。三板斧里没有一个是复杂技术切块是规划习惯状态文件是记录习惯脚本是自动化习惯。难的不是学会是坚持。我一开始也觉得写状态文件麻烦撞了几次墙、吃了几次上下文丢失的亏之后才真正养成习惯。现在不写状态文件反而觉得不踏实。第三不要试图和配额对抗。网上有些讨论是怎么绕过配额我的建议是别在这上面花心思。配额是订阅方案的一部分绕过它既不现实也不合适。真正有价值的是在配额框架内把效率做到最高三板斧就是这个思路的产物。接受约束然后在约束里找最优解这比对抗约束务实得多。第四状态文件写多了会变成项目文档。这是个意外收获。我的一些 CLAUDE_PROGRESS.md 写着写着内容已经不只是进度记录了还包含了项目的一些设计决策和约定。后来我干脆把它整理成了项目的 CONTRIBUTING.md新人接手时直接看这个文件就能上手。所以状态文件这件事投入产出比可能比你想的还高。第五三板斧不是终点。随着项目复杂度上升我还在琢磨新的做法比如把状态文件和 CI 结合让每次 push 自动检查状态文件是否更新比如给不同类型的任务准备不同的切块模板。这些还在试等成熟了再分享。但核心思路是不变的用确定性对冲不确定性用外化对抗易失用自动化降低门槛。如果你也在用 Claude Code 做长任务被配额墙卡过不妨从三板斧里挑一板先试起来。我的建议是从状态文件开始因为它见效最快撞一次墙就能体会到差别。等你习惯了记录状态再回头补切块和脚本整个工作流就顺了。