Claude Code 的 1M Context 怎么用：一篇官方文章的读后整理
最近看了 Anthropic 的一篇官方文章：Using Claude Code: session management and 1M context。一开始我以为这篇会重点讲 1M context 本身，比如到底能塞多少、能不能直接把整个项目一股脑扔进去。结果看完之后发现，文章真正想讲的不是"上下文变大了"，而是会话怎么管。
这点其实挺好理解。上下文窗口变大，确实能让 Claude Code 持续处理更长的任务，但会话一长，里面也会混进越来越多已经没用的信息。任务换了、方案试错过了、日志看完了，这些东西如果一直留在上下文里，后面继续问的时候反而容易把模型带偏。
所以这篇我不打算按原文顺着翻，而是按"日常怎么用"这个角度，把我觉得最值得留下的几个点重新整理一遍。
1. 官方文章到底在提醒什么
原文里反复在讲一件事：Claude Code 现在上下文更大了，能处理更长的工作流，这当然是好事；但会话不是越长越好，长到一定程度之后，注意力会被历史内容分散，效果会慢慢往下掉。
也就是说，1M context 的价值不是"以后都不用管上下文了"，而是给了你更大的操作空间。以前可能稍微做长一点就顶不住，现在能做的事情更多，但前提还是你得知道什么时候继续沿着当前会话走，什么时候应该收一收，甚至直接换一个新 session。
如果只记一句话，我觉得可以记这个：
大上下文让长任务更可行，但不会自动帮你把长任务管好。
2. Claude Code 里这几个动作，最好分清
原文里提到的几个动作，平时其实都能用到：
-
继续在当前 session 里往下做
-
用
/rewind回到前面的某个节点 -
用
/clear重新开始一个会话 -
用
/compact压缩当前上下文 -
把一部分工作交给 subagent
这几个动作看起来都像"继续干活"，但作用不一样。
我自己读完之后的理解是：
-
continue适合同一件事接着做 -
/rewind适合"前面读文件没问题，但后面走偏了" -
/compact适合任务没变，但会话已经变长了 -
/clear适合任务边界已经变了 -
subagent 适合那些中间过程很长、但你最后只关心结论的活
如果平时不刻意区分，最容易出现的情况就是无论什么事都在一个窗口里硬聊。短期看省事，后面会越来越乱。
3. 什么情况下可以继续当前 session
这一点原文讲得比较明确：如果你还在做同一个任务，而且前面的上下文对下一步仍然有帮助，那就没必要重新开。
比如：
-
还在改同一个模块
-
刚实现完一段逻辑，接着补测试或文档
-
前面刚读过的文件、约束、命令输出，下一步还要继续用
这种情况下强行开新会话，反而要重新解释一遍背景，既慢，也容易漏掉刚才已经确认好的信息。
所以问题不在于"会话是不是长"，而在于"前面的内容现在还有没有用"。如果还有用，继续当前 session 是合理的。
4. 什么时候应该开新 session
原文里有一句我觉得特别实用：
当你开始一个新任务时，也应该开始一个新的 session。
这句话听着简单，但实际很容易忽略。很多时候我们会在一个会话里连续切任务，比如前面还在调接口，后面顺手去改 README，再往后又开始查另一个 warning。人自己知道已经换题了，但模型看到的还是一整段连续上下文。
下面这些场景，我会更倾向于直接开新会话：
-
当前任务已经明显结束，后面是另一件事
-
前面试过不少失败方案，会话里混了很多无效尝试
-
你已经开始怀疑模型还在受前面旧结论影响
-
接下来要处理的是另一个子系统，文件和约束都换了一套
新 session 的成本没有想象中高。很多时候只要你在开头写一个简短的交代，把当前目标、涉及文件、关键限制说清楚，效果反而比硬接着聊更稳。
5. 为什么 rewind 常常比"你换个方案再试试"更有用
这一点我觉得是原文里最容易被忽略，但实际特别有用的地方。
假设 Claude 前面已经把相关文件读了，也理解了背景，但后面的实现思路走偏了。这时候最常见的做法是直接补一句：
这个方向不对，换一种方式做。
问题在于，那段错误尝试还在会话里。你虽然口头上纠偏了，但历史上下文没有变干净。
/rewind 的价值就在这里。它不是简单"撤销"，而是把会话回到还没走偏的地方，保留前面已经有用的阅读和分析结果，把后面那段错误路径剪掉。这样重新开始，往往比在错误路径上继续补指令更省事。
如果说得再直白一点：
-
文件已经读对了，方向后来走歪了，用
/rewind -
从头到尾都已经聊乱了，直接新开 session
6. /compact 和 /clear 的差别，最好别混着用
这两个命令特别容易混。
/compact 更像是"把当前会话压缩一下，再接着做"。它适合任务本身没变，但上下文已经很长的情况。你还想延续这条主线，只是不想把所有细枝末节都继续背在身上。
比如原文里提到，你可以给 /compact 一点提示，让它在压缩时保留哪条主线，少带哪些无关内容。这个思路挺实用，因为会话一长，最怕的不是信息少，而是重要信息和不重要信息混在一起。
/clear 就不一样了。它更适合任务已经变了，或者你已经不信任当前上下文的时候。这个时候与其让模型在旧会话基础上"尽量忘掉"，不如你自己重新起一个头，把新的任务背景交代清楚。
我的理解可以简单归成一句：
-
任务没变，但会话太长了，用
/compact -
任务已经换了，或者上下文已经脏了，用
/clear
7. 原文提到的 autocompact，为什么要小心
文章里还提到一个点：自动 compact 并不总是靠谱，尤其是在会话已经很乱的时候。
这个很好理解。自动压缩本质上还是一次"有损整理"。如果会话里已经塞了很多调试日志、失败方案和临时分支，那压缩时就一定会发生取舍。问题是，模型在上下文本来就有点发散的时候，未必总能替你选对"哪些该留、哪些该丢"。
所以我的感受是：与其等它在最后帮你自动兜底，不如在你自己还清楚主线的时候，主动决定要不要 compact。一旦你自己都已经感觉会话开始发涨，通常就该动手了。
8. subagent 最适合干什么
原文对 subagent 的一个判断标准，我觉得很实用：看这段任务的中间过程你后面还要不要反复参考。
如果你只关心结论，不关心过程，那这类任务通常就适合交给 subagent。
比如：
-
扫一遍代码库，找某种模式是不是已经存在
-
对照已有 spec 或需求做检查
-
跑一轮会产生很多中间输出的分析任务
-
补文档、整理说明这类相对独立的事情
这样做的好处不是"更高级"，而是主会话会干净很多。子任务在自己的上下文里折腾，最后把结果带回来，主线不容易被大量中间输出冲散。
9. 我看完之后，觉得最值得记住的三点
第一，别把 1M context 理解成"以后都不用管上下文了"。它解决的是容量问题，不是信息筛选问题。
第二，任务边界要比会话长度更重要。同一个任务，聊长一点没关系；任务一旦换了，旧上下文留得越多，越容易互相干扰。
第三，很多时候不是模型不会做，而是会话里已经混进了太多早该丢掉的东西。这一点在长时间调试、频繁试错的时候特别明显。
10. 总结
如果只从使用层面看，这篇官方文章想讲的其实很朴素：
-
同一个任务，能继续就继续
-
走偏了但前面的阅读还有效，优先考虑
/rewind -
任务没变但会话太长了，可以用
/compact -
任务换了，就别硬接着聊，直接新开
-
中间过程很吵、但你只想拿结论的事，交给 subagent
这些东西听起来不复杂，但真到了长任务里，差别会很明显。以前我也会把"上下文大"直接理解成"那就一直聊下去"，看完原文之后反而更觉得，大上下文不是让人偷懒的，而是给你更多空间去做取舍。