Claude Code 的上下文窗口扩展到了 100 万 token，但很多人还在用 20 万时代的老习惯操作。这篇文章来自 Claude Code 团队负责人 Thariq，把 session 管理的核心技巧说清楚了。

什么是 Context Rot（上下文腐烂）

用过 Claude Code 的人都遇到过这种感觉：聊了很长一段时间之后，模型开始变笨——明明之前理解的东西，现在却绕来绕去。

这不是错觉，有个专门的名词叫 Context Rot（上下文腐烂）。

原理很简单：模型的注意力是有限的，上下文越长，注意力就越分散到那些早就过时的内容上——之前试过但失败的方向、已经不相关的调试信息、废弃的讨论。这些内容不会消失，一直占着位置，干扰模型对当前任务的判断。

Claude Code 的上下文窗口是 100 万 token，但「能放」不等于「该放」。窗口越大，context rot 带来的问题就越需要主动管理。

每次回复之后，你有 5 个选择

Claude 完成一轮任务之后，大多数人直接继续发消息。但这个节点实际上有 5 个选项：

• 继续 — 同一 session 接着来
• /rewind（Esc Esc）— 回到某条消息重新开始
• /clear — 清空 session，写一段手动整理的 brief 开新局
• /compact — 让模型总结上下文，压缩后继续
• Subagents — 把下一块工作分给子 Agent，只把结果拿回来

后四个选项都是为了对抗 context rot，只是适用场景不同。

什么时候开新 Session

原则只有一条：新任务，新 session。

100 万 token 让一些大任务变得可行了——比如从零开始搭一个全栈应用、完整重构一个模块。这类任务可以在一个 session 里跑完。

但有个常见误区：任务结束了，紧接着做关联性工作（比如刚写完功能，马上写这个功能的文档），觉得上下文有用就懒得开新 session。

判断标准是：关联任务用不用开新 session，取决于「Claude 需不需要重新读那些文件」。如果上下文里已经有了刚才操作过的文件内容，留着是合理的；如果已经是一堆无关的调试历史，开新 session 更干净。

Rewind：最被低估的功能

会不会用 rewind，是判断一个人 session 管理水平的标志。

场景：Claude 读了五个文件，尝试了某个实现方向，失败了。你的第一反应可能是直接打「这个方法不行，换个思路」。

但更聪明的做法是：esc esc 回到文件读完之后那条消息，带着刚才学到的教训重新 prompt。

别用 A 方案，foo 模块没有暴露那个接口——直接走 B。

效果的区别一目了然：继续纠错会把「失败的尝试」全程保留在上下文里；rewind 把那段历史删掉，拿着干净的上下文重新出发。

还有一个配合用法：先让 Claude「从这里总结一条交接消息」，把有用的信息提炼出来，复制好，然后再 esc esc 回到之前的节点，把那句总结粘贴进 prompt 重来。

Compact vs. 手动 Clear，两种策略

session 时间长了，有两种减负方式，选哪个取决于你愿意花多少精力：

/compact：让模型自己总结对话，用摘要替换历史记录。省力，但是有损压缩——模型决定什么重要，什么被丢掉。可以加指令控制方向，比如 /compact 聚焦 auth 重构，丢掉测试调试的部分。

/clear：你手动写一段 brief，清空 session 重头开始。费力，但结果是你决定的上下文——「我们在重构 auth 中间件，约束是 X，关键文件是 A 和 B，已经排除了方案 Y」。

什么时候 compact 会翻车？一个典型场景：长时间调试之后，autocompact 触发，把调试过程压缩了。但下一条消息是「去修一下 bar.ts 里的那个 warning」——因为 session 重心在调试，那个 warning 可能根本没进摘要。

规律就是：context rot 最严重的时候，恰好也是模型判断力最差的时候，这时候的自动 compact 质量往往不理想。有了 100 万 token，可以更早触发 /compact，主动给它一个方向，别等到被动触发。

Subagents 不是拿来并行的

很多人把 Subagents 理解成「并行干活的工具」，但更清晰的定位是：Subagents 是一种上下文管理策略。

判断标准只有一个问题：这块工作产生的中间过程，我之后还需要吗？还是只需要最终结果？

如果只需要结果，交给 Subagent——它在自己独立的 100 万 token 里折腾，把总结交回来，主 session 的上下文完全不受影响。

几个实际用法：

• "起一个 subagent，根据这个 spec 文件验证一下刚才的实现"
• "起一个 subagent，读一下那个 codebase 里的 auth 实现方式，然后你按同样的方式在这里实现"
• "起一个 subagent，根据 git 变更写这个功能的文档"

本质上是把「只需要结论、不需要过程」的工作隔离出去，保持主 session 的上下文质量。

决策参考

不同情境下怎么选，可以参考以下决策表：

总结

100 万 token 是更大的操作空间，不是「可以不管上下文」的借口。管好上下文，模型就一直好用；任由 context rot 积累，窗口再大也没用。

核心原则：有用留着，没用砍掉。

参考链接：Thariq 原文 https://x.com/trq212/status/2044548257058328723