Claude Code 上下文管理的 6 个动作，和它们背后的账本
公众号名称：AI 方寸山
作者名称：问答
发布时间：2026-04-17 08:41
前几天算了一笔账，把自己吓一跳。
同样做一个中型重构，我一个会话从头开到尾，和另一种「做完一步 /clear 一次」的干法，后者花的钱差不多是前者的 3 倍。
活是一样的活。钱差这么多。
大部分人用 Claude Code 只有两招，一个窗口开到死，或者一遇到不顺就 /clear 开新的。
两种都在烧钱，而且烧得你毫无察觉。
官方其实在每一轮结束的时候，给了你 6 条路可以选。选哪一条，背后有一套账。这篇讲清楚这 6 条路和这套账，看完就能让 Token 开源节流。
6 大指令
讲指令之前，先给你一个底层直觉，不然后面每个指令你都记不住为啥这么用。
大模型没有记忆。你每发一条消息，它都要把从会话开头到现在的所有东西，一字不漏地重读一遍。聊到第 20 轮，一条新消息可能要带着 10 万 token 的「旧行李」走一遍。
救你的是缓存。模型读过的前缀会留一份「阅读笔记」，下次遇到一模一样的开头，直接拿笔记用，成本只有重算的十分之一。
所以接下来 6 个指令，本质上都在回答同一个问题：这一步操作，是让缓存继续活着，还是让它作废重建？
完整的机制后面会拆，先记住这一句，再往下读。
一、/context，先看一眼油表
每次打开一个新会话，我第一件事就是敲 /context。
它会告诉你当前上下文都被什么占着，plugin 多少 token、skill 多少、CLAUDE.md 多少、memory 多少，一眼就看清。
这个习惯，在装了一堆 skill 和 MCP 之后尤其重要。我自己有过一次，一个字没说，打开会话先看一眼 /context，已经吃掉三万 token 了。我连它在加载啥都还没搞清楚。
油表先看一眼，后面每一步的判断才有依据。不然你是在瞎开。
二、/resume，缓存还热的时候，继续聊最便宜
/resume（或者 claude —resume ）用来恢复之前的会话。
但这个指令真正值得讲的，不是怎么用它，是什么时候用它。
只要任务没变、距离上一条消息不到一小时，继续聊几乎永远是最划算的选择。 上下文连着、缓存是热的、Claude 当前的「状态」也是最聪明的那一个。
听着有点反直觉对吧。很多人直觉上会觉得聊得越久越费钱，干脆每次都重开。我之前也这么干过，后来算了笔账才发现完全反了。
给你一个体感。一个活跃会话里，每轮新消息真正全价付费的，可能只有最后那几百 token，前面几万 token 的上下文都躺在缓存里，按十分之一的价走。而每次 /clear 重开，光是系统提示、工具定义、CLAUDE.md 这些「基础设施」就要全价重读一遍，大约 5 万 token。
一次 /clear 的沉没成本，够你在老会话里继续聊小半天。
完整的账下面 Prompt Cache 那节拆给你看，这里先记住结论，只要缓存还热，继续聊是默认选项。
三、/rewind，我现在最常用的纠错神器
双击 Esc，或者敲 /rewind，可以跳回到过去任意一条消息，后面所有内容直接扔，其实就是回滚。
这个指令，现在几乎是我每天用得最频繁的一个。
用一个场景你就懂。
Claude 读完了 5 个文件、尝试了方案 A，跑出来发现不行。这时候你的第一反应大概是，打字过去说，「刚才不对，换 B 试试」。
先别。
更好的操作是先 rewind 回到「文件读完、但还没试方案 A」的那一刻，然后带着新的认知重新下一次 prompt。
比如这样说，「别用 A，foo module 没暴露那个接口，直接上 B。」
干净、精准。前面那 5 个文件的读取还在缓存里，几千 token 没白花。失败的方案 A 和它搞出来的那一堆脏上下文，全部消失，不会再继续污染 Claude 的注意力。
再进阶一点。rewind 之前，可以先让 Claude 「summarize from here」做一次自我总结。
这份总结就是过去那个 Claude 留给未来那个 Claude 的一封信，「我试过这个方案，没成，原因是 X」。然后再 rewind，把这封信作为下一次 prompt 的开头。
这比打字「刚才不对」有效十倍。
我是真的觉得，会不会用 rewind，基本上就能看出一个人用 Claude Code 的功力。
四、/clear，彻底重开，自己写一份 brief
/clear 不是「随手点一下清屏」。
它的正确用法是，你自己手动写一段精炼的 brief，放在新会话的第一条消息里。
比如这种程度。
「我们在重构 auth middleware，约束是 X，关键文件是 A 和 B，已经排除方案 Y。」
brief 越具体越好，上下文最干净，Claude 也最聚焦。
但代价也很明显，相当于从零重建整个缓存。5 万 token 的基础设施每一次都要从头读一遍，全价。所以 /clear 应该是有条件触发的操作，而不是默认动作。
这块需要注意一下，我观察身边很多人的习惯，做完一个小任务就 /clear，觉得这样「轻装上阵」能省钱。
恰恰相反。
为什么恰恰相反，下面讲缓存的时候会展开。
五、/compact，让它自己总结，带路线图压缩
/compact 的默认行为是，让 Claude 自己总结到目前为止的整个对话，然后用这份总结替换旧上下文，继续往下聊。
这是一种 lossy 压缩。你在赌 Claude 能挑出真正重要的东西。
进阶玩法是带参数。比如这样。
/compact focus on the auth refactor, drop the test debugging
明确告诉它保留什么、丢弃什么，结果比默认模式可控得多。
有个坑必须讲，compact 本身会让当前缓存失效。 所以最好是在「任务阶段性完成、缓存还热」的时候主动 compact，而不是等自动压缩在你最没脑子的那一刻（Claude 自己也最没脑子的那一刻）被动触发。
Anthropic 自己也提过一个典型的失败场景。一个长调试会话结束、自动压缩触发了，然后你下一条消息是「来修那个 bar.ts 里的警告」。
但那个警告，早就在压缩的时候被当成次要信息给砍掉了。
主动压缩，比被动压缩稳得多。
六、subagents，把只要结论不要过程的脏活外包出去
严格说，subagent 不算斜杠指令，是个结构化的做法。但它和前面五个是一套思路里的事，不讲完就不完整，所以也放进来。
subagents（子代理）是一种结构性的上下文隔离。
使用场景很好识别，我确定这段工作会产生大量中间输出，但我只要最后那个结论。
像这几种情况就很典型。
「Spin up a subagent to verify this against the spec file」
「Spin off a subagent to write docs based on my git changes」
「Spin off a subagent to read through that other codebase and summarize how they implemented the auth flow」
子代理有自己独立的上下文窗口，干完活之后只把一份精炼报告拉回主会话。主会话保持极致干净。
但这块也有个代价要注意，子代理的缓存窗口只有 5 分钟，主会话是 1 小时。 子代理赢在「隔离噪音」，不赢在「省缓存」。
所以别把 subagent 当成省钱工具用。它是清洁工具。
Prompt Cache
好了，六个指令讲完。
但说到这里你可能已经发现一个不对劲的地方，我每一条都在说「什么时候便宜」「什么时候贵」「缓存什么时候失效」。
这不是巧合。
这 6 个指令只是操作选项，真正决定「你该走哪条路」的，是藏在指令底下的一套机制，叫 Prompt Cache，提示词缓存。
你发给大模型的东西，长什么样
前面说过模型没记忆，每轮都重读。这里把它拆开看一眼，你才知道重读的到底是什么。
Claude Code 里你每次发过去的东西，其实是三部分拼出来的。
一个是固定部分，系统指令、工具定义、CLAUDE.md 里的项目规则。
一个是对话历史，前面所有的轮次。
一个是新消息，你刚敲的那一句话。
前两部分在同一个会话里几乎不变，但模型每发一次请求都要重读一遍。聊到第 20 轮，一条新消息可能要带着 10 万 token 的「旧行李」走一遍。
这才是你额度烧得飞快的真正原因。
缓存就是一份「阅读笔记」，命中省 90%
为了解决上面的问题（厂商也要降成本的），缓存机制就出现了。其实这个和网络请求的CDN缓存类似。
模型读完一段输入后，会生成一组中间计算结果，相当于一份「阅读笔记」。下次遇到相同的前缀，直接拿笔记用，跳过重复计算。
读缓存的成本，只有重新计算的十分之一。
但缓存有两个前提，必须一起满足。
第一，它只认前缀。必须从头开始、一字不差地匹配。
打个比方，你在作文纸上写文章，前 3 页一字不动，第 4 页改了一个字，前 3 页依然能用缓存。但如果你在第 1 页就改了一个字呢？整张纸作废，从头重写。
所以 Claude Code 的输入布局是有讲究的。不变的东西（系统提示、工具定义、CLAUDE.md）永远排在最前，对话历史在中间，新消息放最后。每一轮你只在「尾巴」加东西，前面一大段天然都能命中缓存。
第二，缓存有寿命。主智能体的缓存窗口是 1 小时，子代理只有 5 分钟。每次命中会刷新计时器，只要你保持交互频率，缓存可以一直活着。但你要是停下来喝杯咖啡超过一小时回来，大概率已经全部过期了。
理解了这两条，再回头看前面那 6 个指令，你会发现很多我们习以为常的操作，其实都是反的。
三件我一直做反了的事
有三件反直觉的事，我自己刚开始也一直做错。
第一件，频繁 /clear 不是省钱，是烧钱。
我非常理解这种感觉，上下文越短应该越省钱，所以做完一步就 /clear 一下，轻装上阵。
但算一笔账你就发现不对。
每次新会话启动，系统提示、工具定义、CLAUDE.md、项目配置全部要重新加载。这些「基础设施」加起来大约 5 万 token。频繁 /clear 等于反复为这些不变的内容付全价。
而在活跃会话里，这 5 万 token 一直躺在缓存里，每次只付十分之一。
一句话，闲置超过一小时才建议重开；活跃工作中，继续聊才是最省的默认策略。
第二件，一次做对，比来回改三轮便宜。
关掉 extended thinking 确实能在单次请求里省 token。听着像是优化对吧。
但对一个复杂重构任务，开着 thinking 一次搞定，和关掉之后来回改三轮，后者更贵的概率非常大。
为啥？因为每多一轮对话，整个上下文都要重新发一次。三轮累积下来的传输成本，远远超过一次深度思考多花的那一点 token。
简单任务反过来，/effort 调低，或者 /config 里把 thinking 关掉，省钱立竿见影。
思考是一次性开销，上下文传输是每轮都要付的开销。
第三件，长内容给路径，别往对话里贴。
不要把一万行日志复制粘贴进对话，让 Claude 自己去里面找错误。
直接把日志文件的路径发给它。
它会用 grep、用 Read 这类工具，只把真正相关的那几行拉进上下文。
最便宜的 token，永远是那些根本没进上下文的 token。
别纠结了，这张表替你做决定
讲到这里，我自己攒了一张「继续聊还是开新会话」的决策表。说真的，这张表我自己用了很久，每次犹豫的时候拿出来对一下就能做决定。
满足下面任一条件，继续当前会话。
- 任务没变。还在调同一个 bug、写同一个模块、围绕同一组文件工作。
- 距离上一条消息不到 1 小时。缓存还活着，前面积累的上下文几乎不花钱。
- 上下文里的内容还在有用。之前读过的文件、讨论过的方案，模型还在用它们。
满足下面任一条件，果断开新会话。
- 任务换了。刚写完认证要去做支付，两件事的上下文完全不同。老会话里堆的代码和调试记录，每一条请求都在为无关内容付钱。
- 闲置超过 1 小时。缓存大概率已经过期，继续聊等于触发全量重建，不如从干净状态开始。
- 上下文被噪音塞满。试了十几种方案、读了一堆无关文件。就算缓存命中，模型也要在噪音里找信号，输出质量明显下滑。
一句话总结，缓存还热、任务没换，继续聊；缓存过期、任务切换、噪音太多，果断重开。
两条小事
顺着上面的再聊聊，有两条经常被忽略的小事。
别在会话中间切模型。缓存是按模型隔离的，你在 Opus 上积累了 10 万 token 的缓存，切到 Sonnet 问个简单问题，Sonnet 要从零建自己的缓存。这种时候让 Opus 直接回答，反而比切到「更便宜」的 Sonnet 花得少。需要轻量模型的场景，用 subagent，不要切主模型。
除非你切换的模型很便宜。我经常是 Opus 和 GLM/Kimi 混用，用 Opus 整出个方案和框架，然后 /exit 退出并切换模型配置到 GLM，然后 —resume 继续刚才的会话，因为国产模型便宜啊，这样用感觉也没啥问题。
精简你的 CLAUDE.md。它的内容会被注入到每一次请求里。官方建议控制在 200 行以内，只保留真正长期有效的规则。代码审查流程、迁移步骤这类「只在特定时刻需要」的东西，挪到 skill 里，按需加载就好。实在不知道咋写，就去 github 上找找，有很多，多试试体验效果，改一改，就找到感觉了。
用得越久越会发现，Claude Code 真正拉开差距的地方，不是谁记住了更多指令，也不是谁的 CLAUDE.md 写得更花哨。
是谁知道什么时候该继续、什么时候该回退、什么时候该压缩、什么时候该彻底重开。
这像一个老派的剪辑师坐在工作台前面干活。所有素材都在，但真正决定一支片子好不好的，从来不是你拍了多少，是你扔掉了多少。
留下的每一帧，都得为接下来的推进服务。
所以我始终觉得，Claude Code 真的不是一个聊天框。
它更像一张剪辑台。
谢谢你看我的文章，我们，下次再见。
Original 问答 AI 方寸山