1. 撞墙那一刻5 小时配额到底卡在哪第一次被 Claude Code 的配额墙拦下来是在一个周四的凌晨。当时我正在重构一个老项目的鉴权模块涉及十几个文件的联动改动CLI 里连续跑了大概四个多小时中间穿插着读文件、改代码、跑测试、再读报错、再改。眼看着最后一个测试用例就要过了终端突然甩出一行提示大意是本轮用量已达上限请稍后再试。那一瞬间的感觉就像打游戏打到 BOSS 剩一丝血突然断网。后来我专门花时间摸清了这套配额机制。Claude Code 的用量限制不是按你发了多少条消息来算的而是按一个滚动的时间窗口来统计你的实际消耗。这个窗口通常是 5 小时窗口内你的 token 消耗、请求次数、以及单次会话的上下文规模都会累加进去。也就是说你如果在一个会话里塞了超长的上下文反复让模型读大文件那消耗速度会比你想象得快得多。这里有个很多人忽略的点配额是跟着账号走的不是跟着终端窗口走的。你开三个终端同时跑消耗是叠加的不会因为我开了新窗口就重置。我一开始就吃过这个亏以为多开几个 tab 能绕过限制结果只是让墙来得更快。那为什么偏偏是 5 小时这个粒度从工程角度看这是一个在用户体验和资源公平之间的折中。窗口太短正常干活的人频繁被打断窗口太长又容易被少数重度用户长时间占满。5 小时差不多是一个完整工作段的长度设计意图是让你在一个工作段内能连续用但别指望 24 小时不间断地压榨。理解了这一点应对思路就清晰了不要去对抗配额而是让工作流具备被打断后能无损接上的能力。这就是我后来总结的三板斧的核心——断点续传。不是续传网络请求而是续传你的工作状态。提示配额窗口的具体数值和重置规则会随官方策略调整别把某个具体数字当成永久真理重点是掌握状态可恢复的方法论。2. 三板斧总览把被打断变成可恢复在讲具体操作之前先把三板斧的整体设计讲清楚不然你照着做会不知道为什么这么做。第一板斧是任务切片与状态落盘。核心思想是不要把一个巨大的任务当成一次会话去跑而是拆成若干个有明确边界的小任务每完成一个就把做到哪了、下一步做什么、当前有哪些关键结论写到一个持久化的文件里。这样即使配额墙来了你重新开一轮读一下这个文件就能接上。第二板斧是上下文瘦身与外部记忆。Claude Code 的消耗大头往往在上下文。你如果每次都把整个项目、整个对话历史喂进去那配额烧得飞快。做法是把需要长期记住的东西从对话上下文里挪出来放到项目里的 Markdown 文件或者专门的笔记文件里让模型按需读取而不是一直挂在上下文里。第三板斧是会话交接协议。这是最容易被忽视但最值钱的一板斧。你要约定一套固定的交接格式让上一轮会话在结束前自动生成一份给下一轮会话看的交接单。下一轮会话开场先读这份交接单就能无缝续上不用你手动复述半天。这三板斧合起来本质上是把会话这个易失性状态转换成文件这个持久化状态。会话可以被配额打断但文件不会。你随时可以基于文件重建一个新的会话继续往下走。我实测下来用了这套方法之后同样一个中型重构任务原来被墙一次就得重新梳理半小时上下文现在重新接上大概两三分钟就能进入状态。省下来的不只是时间更是那种被打断后不想再捡起来的心理成本。2.1 为什么不用多账号轮换这种野路子可能有人会想那我多准备几个账号轮着用不就行了。我不推荐这么干原因有两个。一是这违反服务条款风险你自己承担二是它解决不了根本问题——你的工作状态还是散落在各个会话里账号一换上下文就断了你还是得手动复述。真正的问题不是配额不够而是状态没落盘。把状态落盘这件事做好了单账号也能跑得很顺。2.2 三板斧的适用边界这套方法最适合的是长周期的代码改造、文档撰写、数据分析这类有明确阶段、阶段之间有依赖的任务。如果你只是问几个零散问题那没必要上这套直接问就行。三板斧的价值在于任务足够长、足够复杂长到一定会撞墙复杂到重新梳理成本很高。3. 第一板斧实操任务切片与状态落盘这一板斧落地下来核心就是两个文件一个任务清单一个进度日志。我习惯把它们放在项目根目录下一个叫.claude-work的隐藏目录里跟代码放一起方便版本管理也方便模型读取。3.1 任务清单怎么写才有效任务清单不是简单列个 TODO而是要写成模型能读懂、能判断完成状态的结构。我一般用这样的格式# 任务清单 ## 阶段一鉴权模块重构 - [x] 梳理现有鉴权入口列出所有调用点 - [x] 设计新的 token 校验接口签名 - [ ] 替换 login 路由中的旧校验逻辑 - [ ] 替换 refresh 路由中的旧校验逻辑 - [ ] 补充单元测试 ## 阶段二中间件适配 - [ ] 更新全局中间件对新接口的调用 - [ ] 回归测试关键在于每个条目要足够小、可独立验证。像重构鉴权模块这种条目就是无效的因为它没法判断完成没完成。而替换 login 路由中的旧校验逻辑就很明确做完就是做完没做完就是没做完。我踩过的一个坑是一开始清单写得太粗结果模型每次读清单都要重新理解这个阶段到底包含啥反而浪费上下文。后来我把粒度细化到一个函数、一个文件级别模型读起来就非常快判断也准。3.2 进度日志的写法进度日志记录的是为什么和怎么做的而不是做了什么做了什么清单里已经有了。格式我一般这样# 进度日志 ## 2024-XX-XX 第一轮 - 完成鉴权入口梳理共找到 7 个调用点分布在 routes/ 和 middleware/ 下 - 新接口签名定为 verifyToken(token, options)options 里带 audience 字段 - 注意refresh 路由里有个历史遗留的兼容分支暂时保留别删 - 下一步从 login 路由开始替换 ## 2024-XX-XX 第二轮配额中断后 - 已替换 login 路由测试通过 - 发现 refresh 路由的兼容分支需要特殊处理记录在案 - 下一步替换 refresh 路由这份日志的价值在于它把决策和坑都记下来了。配额中断后重新开会话模型读这份日志就知道之前为什么这么设计、哪里埋了雷不会重复踩坑。注意进度日志要写结论和原因不要写过程流水账。比如我读了 A 文件、又读了 B 文件这种没意义直接写结论A 和 B 的接口不一致需要适配层。3.3 让模型自动维护这两个文件手动维护太累我一般会在会话开始时给模型一个明确的指令让它每完成一个清单条目就自动更新这两个文件。指令大概是这样本项目使用 .claude-work/tasks.md 和 .claude-work/progress.md 管理任务状态。 每完成一个任务条目请 1. 更新 tasks.md 中对应条目的勾选状态 2. 在 progress.md 追加一条记录包含完成了什么、关键决策、遇到的坑、下一步 3. 如果发现新的子任务追加到 tasks.md 对应阶段下把这段指令固化到项目的CLAUDE.md里每次会话自动生效就不用每次重复交代了。4. 第二板斧实操上下文瘦身与外部记忆配额烧得快八成是上下文太肥。这一板斧的目标是让每次请求携带的上下文尽可能精简同时又不丢失关键信息。4.1 识别上下文里的赘肉上下文里的赘肉主要有三类。第一类是重复的历史对话尤其是那种来回确认了好几轮的讨论结论早就定了但历史还挂在那。第二类是大文件的全文你其实只需要其中几个函数但整个文件被读进来了。第三类是已经过时的中间产物比如早期版本的方案草稿早就不用了但还在上下文里。我做过一个粗略的估算一个跑了三小时的会话如果中间读了三四个大文件上下文里可能有超过一半的 token 是其实不需要一直挂着的。把这些清掉同样的配额能多跑不少活。4.2 用外部记忆文件替代长上下文做法是把需要长期记住的信息从对话里挪到文件里。我一般会建这么几个文件文件作用更新时机context/architecture.md项目架构、模块划分、关键约定架构有变动时context/decisions.md重要技术决策及原因每次做决策时context/gotchas.md已知的坑和注意事项每次踩坑后.claude-work/progress.md当前任务进度每完成一个条目会话开始时让模型先读这几个文件建立背景认知然后干活。干完活把新的决策和坑写回文件。这样下一轮会话只需要读这几个精炼的文件而不是重放整个历史对话。4.3 按需读取而不是全量加载Claude Code 有个很好用的能力就是它可以自己决定读哪个文件。你要做的是引导它按需读而不是一上来就把所有文件塞给它。我一般会在指令里写需要了解项目背景时优先读 context/ 目录下的文件。 需要看具体代码时只读相关函数所在的文件不要整目录读。 读大文件前先用 grep 或搜索定位到相关行再读那一段。这个先定位再读的习惯能省下大量 token。我实测过一个两千行的文件如果只读其中相关的五十行消耗能降到原来的十分之一都不到。提示context/目录下的文件要定期清理过时的决策和已解决的坑就删掉别让它无限膨胀否则外部记忆本身又变成了新的上下文负担。4.4 会话开场的最小加载模板我给自己定了一个会话开场的固定动作大概是这样一段话请先读 .claude-work/tasks.md 和 .claude-work/progress.md 了解当前任务进度。然后读 context/decisions.md 和 context/gotchas.md 了解关键决策和已知坑。读完告诉我你理解的当前状态和下一步计划 我确认后再开始干活。这个先复述再干活的步骤很关键。它相当于让模型先做一次状态自检如果它理解错了你在它动手之前就能纠正避免它基于错误理解改一堆代码。5. 第三板斧实操会话交接协议前两板斧解决了状态存哪和上下文怎么瘦的问题第三板斧解决的是怎么把状态交给下一轮会话。这一板斧的核心是一份标准化的交接单。5.1 交接单的标准格式我用的交接单格式是这样的# 会话交接单 ## 本轮完成 - 替换了 login 路由的校验逻辑测试通过 - 更新了 verifyToken 的单元测试 ## 当前状态 - 代码可编译login 相关测试全绿 - refresh 路由尚未替换是下一步重点 ## 关键决策 - verifyToken 的 options 参数用对象而非位置参数方便后续扩展 ## 未解决的坑 - refresh 路由有个兼容分支替换时要保留旧行为 ## 下一步计划 1. 替换 refresh 路由校验逻辑 2. 跑全量回归测试 3. 更新中间件调用 ## 需要下一轮注意 - 别动 middleware/auth.js 里的 fallback 逻辑那是给老客户端用的这份交接单本质上就是给未来的自己或者下一轮会话的模型看的一封信。它把散落在对话里的关键信息压缩成一份结构化的文档。5.2 让模型自动生成交接单手动写交接单也累我一般会在会话快结束、或者感觉快撞墙的时候给模型一个指令请生成本轮的会话交接单保存到 .claude-work/handoff.md 格式参考现有文件。重点写清楚完成了什么、当前状态、 关键决策、未解决的坑、下一步计划、下一轮注意事项。生成完之后我扫一眼补两句它漏掉的就完事了。下一轮会话开场第一件事就是读这份交接单。5.3 交接单和进度日志的区别有人会问这跟进度日志不是重复了吗。其实定位不一样。进度日志是累积的、面向历史的记录整个任务的演进过程交接单是当前的、面向未来的只关心现在在哪、接下来去哪。进度日志可以很长交接单要尽量短最好一屏能看完。我一般让交接单控制在 50 行以内。超过这个长度说明这一轮做的事情太多应该考虑把任务切得更细。5.4 撞墙瞬间的应急动作配额墙来的时候往往很突然你可能正在等模型输出。这时候别慌先做这几件事如果模型已经输出了部分内容先把有用的部分复制到进度日志里手动补一条进度记录写清楚卡在哪了如果来得及让模型生成交接单有时候墙来了还能发一两条消息关掉会话等窗口重置我踩过的最大的坑是撞墙时正在改一个复杂函数改了一半没记录等窗口重置后完全想不起来改到哪了只能从头看 diff。从那以后我养成了一个习惯每完成一个函数级别的改动就立刻更新进度日志不等会话结束。这样即使突然撞墙损失也最小。6. 常见问题与排查技巧实录这套工作流跑了大半年踩过的坑不少整理成一张速查表你遇到问题可以直接对照。问题现象可能原因排查与解决重新开会话后模型完全不记得之前做了什么没读交接单或进度日志开场指令里明确要求先读.claude-work/下的文件配额消耗异常快上下文里有大文件全文或重复历史检查是否整目录读取改用先定位再读模型改代码时改错了地方上下文里的架构认知过时更新context/architecture.md开场先读交接单越写越长单轮任务太大把任务切细单轮只做一到两个清单条目进度日志变成流水账记录方式不对只记结论、决策、坑不记过程模型重复踩同一个坑坑没写进gotchas.md每次踩坑后立刻记录开场必读多个终端同时跑消耗叠加配额跟账号走别多开串行跑用交接单衔接6.1 一个真实的排查案例有段时间我发现明明任务不大配额却掉得飞快。排查下来发现是模型每次读文件都习惯性地把整个src/目录列一遍然后读好几个不相关的文件。原因是我的开场指令里没限制读取范围。后来我在CLAUDE.md里加了一条硬性约束读取代码时禁止列目录后批量读取。 必须先根据任务定位到具体文件再读取该文件的相关部分。加上这条之后同样的任务配额消耗大概降了四成。这个经验告诉我模型的默认行为往往是求全而工程上要的是求准你得主动约束它。6.2 关于续传的一个认知纠正很多人一听断点续传第一反应是能不能让请求自动重试。这个方向是错的。配额墙不是网络抖动重试没用只会浪费。真正的续传是工作状态的续传不是请求的续传。你要做的是让人模型这个组合的工作状态可恢复而不是让单个请求可恢复。想清楚这一点三板斧的逻辑就顺了。6.3 几个提升效率的小技巧第一个技巧是给任务编号。在 tasks.md 里给每个条目加个编号进度日志和交接单里引用编号沟通起来特别快比如完成了 T3卡在 T5。第二个技巧是定期归档。一个任务做完后把.claude-work/下的文件移到archive/目录保持工作目录干净。新任务开新的一套文件别混在一起。第三个技巧是交接单模板化。把交接单的格式固化成一个模板文件每次让模型照着填省得它自由发挥导致格式混乱。7. 把三板斧串成一条流水线单独看三板斧每一板都不复杂但真正省时间的是把它们串成一条流水线。我现在的标准流程是这样的任务开始前先花五分钟把任务拆成清单写进tasks.md。然后开一个会话让它读清单和背景文件确认理解后开始干活。每完成一个条目它自动更新清单和进度日志。感觉快撞墙了让它生成交接单。窗口重置后开新会话先读交接单和进度日志接着干。任务全部完成后归档工作文件。这条流水线跑顺了之后配额墙从一个让人抓狂的障碍变成了一个自然的休息节点。反正每五小时左右本来也该歇歇正好借这个机会让模型生成交接单自己喝杯水回来接着干。我个人的体会是这套方法真正的价值不在于省了多少配额而在于它把长任务这件事变得可控了。以前我不敢接那种要跨好几天的大改造因为中间一断就接不上。现在有了这套状态管理任务再长也不怕反正状态都在文件里随时能捡起来。最后分享一个小习惯我会在context/gotchas.md里专门记一条配额相关的坑比如某次因为整目录读取导致配额提前耗尽。这些坑记下来下次开场模型读到就会主动避开。坑记得越多后面跑得越顺。