一篇Claude Code 1M上下文使用技巧与官方文章读后整理

Claude Code 的 1M Context 怎么用：官方文章要点与实战解读

最近阅读了 Anthropic 的一篇官方文章：Using Claude Code: session management and 1M context。说实话，最初看到标题时，我以为重点会围绕 1M 上下文窗口本身——比如到底能容纳多少内容、能否直接把整个项目一次性塞进去。但读完后才发现，文章真正想传达的核心并非“上下文变大了”，而是会话管理才是关键。

其实这一点很容易理解。上下文窗口扩大，确实能让 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

原文里有一句特别实用的话：

“如果任务是新的，那就开一个新会话。”

这句话听着简单，但实际很容易忽略。很多时候，我们会在一个会话里连续切任务：前面还在调接口，后面顺手去改 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

这些东西听起来不复杂，但真到了长任务里，差别会很明显。以前也会把“上下文大”直接理解成“那就一直聊下去”，看完原文之后反而更觉得：大上下文不是让人偷懒的，而是给你更多空间去做取舍。用好它，关键不在于容量，而在于管理。

参考链接

• 原文：Using Claude Code: session management and 1M context