Claude Code 1M上下文管理指南：避免越用越慢的五大策略

最近和不少 Claude Code 用户交流，发现一个普遍现象：那个高达100万token的上下文窗口，用好了是神器，用不好反而会成为拖累。

它确实能让 Claude Code 处理更复杂的任务，运行更长的对话。但与此同时，也为“上下文污染”打开了方便之门。如果你不注意管理会话，用久了就会感觉 Claude 开始“犯迷糊”——该记住的东西忘了，不该碰的地方乱改。

如今，会话管理变得前所未有的重要。大家的问题也很集中：终端里该开一个会话还是多个？每次都开新的吗？什么时候该用 compact、rewind 或者子代理？什么情况下压缩会越压越乱？

这些细节看似不起眼，却实实在在地影响着你的使用体验。而核心只有一个：管好你的上下文窗口。

先搞清楚几个概念：上下文、压缩与腐化

上下文窗口，简单来说就是模型在生成下一条回复时所能“看见”的全部内容。这包括了你的系统提示、整个对话历史、所有的工具调用及其输出、以及所有被读取过的文件。Claude Code 的上下文窗口大小是 100 万 token。

使用上下文是有代价的，这个代价被称为“上下文腐化”。随着上下文长度不断增加，模型的注意力被分散到更多的 token 上，其表现就会开始下降。旧的、不相关的内容开始干扰当前的任务。根据实际测试，Claude 的上下文腐化现象大约在 30-40 万 token 时开始显现，但这并非绝对，具体取决于任务类型。

上下文窗口有硬上限。当快到达上限时，你需要将之前的工作总结成一段简短的描述，然后在新的上下文里继续——这个过程就叫压缩。当然，你也可以手动触发压缩。

每个回合结束，都是一个分支点

当 Claude 完成一轮回复、等待你输入时，你实际上有好几种选择：

• 继续 — 在同一个会话里接着发送下一条消息。
• /rewind（按两次 Esc） — 跳回之前的某条消息，从那里重新开始。
• /clear — 开启一个新会话，通常附上你从刚才对话中提炼出的简报。
• 压缩 — 将当前会话总结一下，在总结的基础上继续。
• 子代理 — 把下一步工作交给一个拥有独立上下文的 Agent，最后只把结果带回来。

最自然的选择是“继续”，但其他四个选项都是管理上下文的利器。

什么时候该开启新会话？

100 万上下文窗口意味着你可以更可靠地运行更长的任务，例如让 Claude 从零开始构建一个全栈应用。但这并不意味着在模型触顶之前，你就不该开新会话。

经验法则：任务换了，会话就换。

难点在于“相关任务”的界定——有些上下文可能还有用，但并非全部需要。例如，你刚刚实现了一个新功能，现在要为其编写文档。虽然可以开新会话，但新会话中的 Claude 需要重新读取你刚写的代码，速度更慢、成本更高。既然编写文档对“智能”的要求没那么苛刻，保留上下文所带来的效率提升通常更值得。

学会 Rewind，而不是一味纠正

如果只能培养一个代表良好上下文管理习惯的操作，我会选择 Rewind。

在 Claude Code 中，双击 Esc 键（或输入 /rewind）可以让你跳回任意一条历史消息，并从那里重新开始。此后的消息都会被丢弃，不再占用上下文空间。

Rewind 通常比“口头纠正”更有效。比如，Claude 读取了五个文件，尝试了方案 A 但行不通。你本能的反应可能是输入“这个不行，试试方案 B”。但更好的做法是：使用 rewind 跳回到刚读完文件的那一步，然后基于你学到的新信息重新给出提示：“别用方案 A，foo 模块没有暴露那个接口，直接走方案 B。”

你还可以让 Claude “从这开始总结”，让它将自己的学习和尝试结果总结成一段话，作为给“过去的自己”的交接信息——这就像未来的你写信给过去，说“我试了但是不行，你换个方向吧”。

压缩 vs 开启新会话

当一个会话运行时间过长时，你有两种“减重”方式：/compact 或 /clear（开新会话）。它们感觉相似，但机制完全不同。

压缩是让模型总结迄今为止的全部对话历史，然后用这个总结替换掉原始历史。这个过程存在信息损耗，你是在信任 Claude 的判断力来决定什么重要、什么可以舍弃。好处是省事，Claude 的总结可能比你手动写的更全面，甚至会保留一些你忽略的重要细节和文件。你也可以通过指令来引导压缩的方向：

/compact 重点放在auth重构，测试调试的部分可以丢掉

/clear 则要求你手动撰写一份简报（例如：“我们在重构 auth 中间件，约束条件是 X，重点文件是 A 和 B，已经排除了方案 Y”），然后清空上下文，重新开始。这更费事，但上下文中存放什么内容，完全由你掌控。

什么情况下压缩会“越压越乱”？

进行过多次长会话后，你可能会注意到某些压缩效果特别差。这种情况通常发生在：模型无法预测你接下来的工作方向时。

例如，你刚进行了一段漫长的调试，自动压缩被触发，总结了整个调查过程。然后你的下一条消息是：“去修一下之前在 bar.ts 里看到的那个 warning。” 但由于整个会话都聚焦在调试上，那个 warning 很可能在总结时被丢掉了。

这个问题很棘手，因为上下文腐化在压缩时最为严重——模型注意力最分散、表现最不“灵光”的时候，恰恰要让它做最重要的事。得益于 100 万的上下文容量，你可以更主动地提前进行压缩，并明确告诉它你接下来的意图。

子代理：用全新上下文运行独立任务

子代理 也是一种重要的上下文管理手段，特别适用于你事先知道某部分工作会产生大量中间输出，但最终只需要结论的情况。

当 Claude 通过 Agent 工具启动一个子代理时，这个子代理拥有自己全新的上下文窗口。它可以在其中自由探索和尝试，最终只将一份最终报告返回给父会话。

一个简单的判断标准是：这个工具调用产生的输出，后续还会频繁用到吗？还是说，我们只需要它的最终结论？

虽然 Claude Code 在某些情况下会自动调用子代理，但你也可能希望主动指示它这样做。例如：

• “起一个子代理，验证这个改动是否符合以下规范文件列表。”
• “派一个子代理去阅读那个代码库，总结它如何实现 auth 的，然后你自己参照着实现。”
• “派一个子代理根据我的 git 变更历史，为这个新功能撰写文档。”

总结与实用操作指南

说到底，每次 Claude 结束一个回合、等待你输入新消息时，都是一个决策点。未来 Claude 可能会变得更智能，自行处理这些决策。但在现阶段，这恰恰是你引导 Claude 产出、提升效率的重要手段之一。

用好上下文管理，Claude Code 带给你的生产力提升远不止翻倍。

希望这篇关于 Claude Code 上下文管理的深入探讨，能帮助你在 云栈社区 获得更流畅、更高效的AI编程体验。