Claude Code工程师自曝：100万token上下文窗口是一把双刃剑，上下文腐化，每一步都是一个分叉点，曝内部最佳实践：用回溯代替纠错

最近，Claude Code 团队工程师 Thariq Shihipar又在X上发文了，上个月他写的Skill深度经验分享贴在社交平台爆火，这周他又发了一篇Claude的100万toke上下文窗口使用技巧的文章，平台阅读量已超过200万。

在这篇文章中，他提出了一些少有人知的对话窗口的使用技巧。

比如每次对话结束后，是有多个选择的：除了继续对话，还可以用回溯、清除、压缩，或者拉子Agent帮忙。再比如

回溯通常是纠错的更好方法，可以用 /rewind 来“时光倒流”，重启正确轨道。

还有给上下文减负有2种方式：/compact是让模型自己挑重点，可能会丢失关键细节，而/clear是自己写下重点内容，是可控的压缩。另外，复杂任务应该拆给独立子Agent，它们只返回结果，让上下文窗口空间更大、更干净。

X上有人说：“这才是Anthropic今年最有价值的更新啊，没有之一!!”

还有人评论：“Thariq 发布了一份关于许多人低估的主题的必备指南：Context管理。”

以下为 Thariq 撰写的全部内容：

100万 token 的上下文窗口是一把双刃剑

在我最近与 Claude Code 用户的交流中，一个主题被反复提及：100万 token 的上下文窗口是一把双刃剑。

它让 Claude Code 能够自主运行更长时间并更可靠地处理任务，但如果你不刻意管理会话，它也会为“上下文污染”打开大门。

会话管理比以往任何时候都重要，而且大家似乎对此有很多疑问。你应该在一个终端里保持一个会话，还是两个？每次提问都要重新开始吗？什么时候该使用 compact（压缩）、rewind（回溯）或 subagents（子代理）？是什么导致了糟糕的压缩效果？

这里有惊人数量的细节可以真正塑造你使用 Claude Code 的体验，而其中几乎所有细节都源于对上下文窗口的管理。

上下文、压缩与上下文腐化（Context Rot）

上下文窗口是模型在生成下一次回复时能同时“看到”的一切。它包括你的系统提示词、到目前为止的对话、每一个工具调用及其输出，以及每一份被读取的文件。Claude Code 拥有 100 万 token 的上下文窗口。

不幸的是，使用上下文是有细微代价的，这通常被称为上下文腐化。上下文腐化是指这样一种观察：随着上下文的增长，模型性能会下降，因为注意力被分散到了更多的 token 上，且陈旧、无关的内容开始干扰当前任务。对于我们的 100 万上下文模型，我们观察到在 30 万到 40 万 token 左右会出现一定程度的上下文腐化，但这高度依赖于任务，并非死板的定律。

上下文窗口是一个硬性截止线，因此当你接近窗口末尾时，你需要将一直在处理的任务总结成较短的描述，并在新的上下文窗口中继续工作，我们称之为压缩。你也可以手动触发压缩。

每一步都是一个分叉点

假设你刚让 Claude 做完某件事，它完成了，现在你的上下文中已经有了一些信息（工具调用、工具输出、你的指令），对于下一步该做什么，你拥有多得令人惊讶的选择：

• Continue（继续）：在同一个会话中发送另一条消息。

• /rewind (esc esc)（回溯）：跳回到之前的某条消息，并从那里重新尝试。

• /clear（清除）：开始一个新会话，通常带着你从刚才所学中提炼出的简要说明。

• Compact（压缩）：总结到目前为止的会话，并在总结的基础上继续。

• Subagents（子代理）：将下一块工作委托给一个拥有干净上下文的代理，仅将其结果传回。

虽然最自然的方式是直接继续，但其他四个选项的存在是为了帮助管理你的上下文。

何时开始新会话

新的 100 万上下文窗口意味着你现在可以更可靠地完成更长的任务，例如让它从头开始构建一个全栈应用。但仅仅因为你的模型还没用完上下文，并不意味着你不应该开始新会话。

我们的通用经验法则是：当你开始一个新任务时，你也应该开始一个新会话。

一个模糊地带是当你可能想做相关任务，且部分上下文仍有必要、但并非全部必要时。

例如，为你刚刚实现的功能编写文档。虽然你可以开始一个新会话，但 Claude 必须重新读取你刚刚实现的文件，这会更慢且更昂贵。由于编写文档可能不是一个对智力高度敏感的任务，为了避免重新读取相关文件而带来的效率提升，多出的上下文代价可能是值得的。

用回溯代替纠错

如果让我选一个标志着良好上下文管理习惯的行为，那就是回溯。

在 Claude Code 中，双击 Esc（或运行 /rewind）可以让你跳回到之前的任何消息并重新提问。该点之后的消息将从上下文中删除。

回溯通常是纠错的更好方法。例如，Claude 读取了五个文件，尝试了一种方法，但没奏效。你的直觉可能是输入“那没用，试下方法 X”。但更好的做法是回溯到读取文件之后的节点，并结合你学到的东西重新提问：“不要使用方法 A，foo 模块没有暴露那个接口 —— 直接用方法 B。”

你也可以使用“从这里开始总结（summarize from here）”，让 Claude 总结它的心得并创建一个交接消息，这有点像未来的 Claude 给尝试过某事但失败了的过去版本发送的消息。

压缩 vs. 新会话

一旦会话变得很长，你有两种减重的方法：/compact 或 /clear（重新开始）。它们感觉很像，但行为逻辑迥异。

压缩要求模型总结到目前为止的对话，然后用该总结替换历史记录。它是有损的，你是在信任 Claude 来决定什么重要，但你不需要自己写任何东西，而且 Claude 在包含重要的心得或文件时可能会更周全。你也可以通过传递指令来引导它（例如：/compact focus on the auth refactor, drop the test debugging）。

使用 /clear 时，你写下重要的内容（“我们正在重构 auth 中间件，约束是 X，相关文件是 A 和 B，我们已经排除了方法 Y”）并干净地开始。这需要更多的工作，但产生的上下文是你认为相关的。

是什么导致了糟糕的压缩？

如果你运行了很多长时间的会话，你可能已经注意到有时压缩效果会特别差。在这种情况下，我们经常发现，当模型无法预测你的工作方向时，就会发生糟糕的压缩。

例如，在漫长的调试会话后触发了自动压缩（autocompact），总结了调查过程，而你的下一条消息是“现在修复我们在 bar.ts 中看到的另一个警告”。

但因为之前的会话专注于调试，另一个警告可能已经从总结中被删掉了。

这特别困难，因为由于上下文腐化，模型在压缩时处于其智力的最低点。有了 100 万上下文，你有更多时间在描述你想要做什么的同时，主动进行 /compact。

子Agent与新鲜的上下文窗口

子 Agent 是上下文管理的一种形式，适用于当你预先知道一块工作会产生大量你不再需要的中间输出时。

当 Claude 通过 Agent 工具催生一个子代理时，该子代理会获得自己新鲜的上下文窗口。它可以根据需要做尽可能多的工作，然后综合结果，只有最终报告会返回给父进程。

我们使用的心理测试是：我还会需要这个工具的输出吗，还是只需要结论？

虽然 Claude Code 会自动调用子 Agent，但你可能想显式地告诉它这样做。例如，你可能想告诉它：

• “启动一个子 Agent，根据以下规格文件验证这项工作的结果。”

• “派生一个子 Agent 阅读另一个代码库，总结它是如何实现 auth 流程的，然后你自己以同样的方式实现它。”

• “派生一个子 Agent，根据我的 git 变更编写该功能的文档。”

总结

总之，当 Claude 结束了一个回合而你准备发送新消息时，你处在一个决策点。

随着时间的推移，我们期望 Claude 能够自己帮你处理这些，但目前，这是你引导 Claude 输出的方式之一。

文章来自于"51CTO技术栈"，作者 "玉澄"。