Claude Code 用着用着，它就变笨了。
一开始反应贼快，眼明手快的。但聊到后面，越改越离谱，活像一个喝了两杯的同事：道歉、改错、再道歉、再改错。你在那头抓狂，它在循环里出不来。
你心里嘀咕：是它今天状态不好？还是我哪句话没说清楚？
（说实话，我也这样想过一百次。）
直到我看到这周 Anthropic 的 Thariq Shihipar（Claude Code 团队的人）发了一篇博客。
他说，都不是...
是你 session（一次完整的对话）里的上下文烂了。
他们给这个现象起了个名字，叫 Context Rot（上下文腐烂）。
腐烂是重力，不是 bug。
啥意思？我的理解是：它不是 Claude 哪里坏了可以修的故障，而是只要对话还在继续，就必然在发生的事。
这篇博客表面上是介绍一个新命令 /usage。但它真正想告诉你的，其实是另一件事：
100 万 token 的窗口，不会让你更省心。它让你每聊一轮，都得多做一个判断。
窗口能装下是一回事，能不能用好...是另一回事。
01 腐烂这件事，是物理规律
咱们先把"上下文"是啥弄明白。
说白了，上下文就是 Claude 一次能"记住"的东西的总量。你讲的话、它回的话、它读过的文件、它调工具跑出来的结果...全部往这一块里塞。
你可以想象成，这是 Claude 脑子里的一张桌子。
Claude Code 现在这张桌子是 100 万 token 的大小，换算成中文差不多 60 到 70 万字，三本长篇小说那么多。
听起来很爽对吧？
但实际情况是...
"Context rot is the observation that model performance degrades as context grows because attention gets spread across more tokens, and older, irrelevant content starts to distract from the current task."
上下文越长，模型性能会下降。注意力被分摊到更多 token 上，旧的无关内容开始干扰当前任务。
你注意哈，这句话说的是性能下降，不是崩溃。是慢慢滑下去，不是一下子摔下来。
这个差别很关键。因为滑下去你察觉不到，摔下来你立马知道。
为啥会腐烂
Anthropic 打了个生活类比：
"Like humans, who have limited working memory capacity, LLMs have an 'attention budget' that they draw on when parsing large volumes of context."
我翻译一下：
桌子大，不代表你能摊下更多东西还找得到。反而越大越考验你，你得记住每个角落放的是啥。你多摊一叠纸，找一个之前的笔记本就要多花 3 秒。
模型的注意力也是这么回事，每多一个 token，就分走一点点。
（这部分我看完挺受启发的。因为我一直以为窗口越大越好。结果不是这么回事。）
架构层面的原因更冷一点：Transformer（大模型的基础架构）里，每个 token 都要跟窗口里其他所有 token 两两算一次关系。关系总数，是 token 数的平方。
一万亿。不是我打错字。
训练数据层面还有一层原因：模型见过的短对话、短代码段，远比长的多。短是主流，长是补丁。所以上下文长到一定程度性能塌，不是 bug，是架构本身骨头上的病。
不是 Anthropic 一家这么说
ChromaDB 在 2025 年 7 月发过一份技术报告，这是 Anthropic 官方 context engineering 文章唯一明确引用的外部研究，分量可以说很重了。
他们测了业界最顶尖的 18 个模型（业内叫 SOTA），覆盖 Claude、GPT、Gemini、Qwen 四大家族。
几个反直觉的发现：
ChromaDB 的结论被 Anthropic 拿去当立论基础：
"Whether relevant information is present in a model's context is not all that matters; what matters more is how that information is presented."
关键信息在不在 context 里不重要，关键是怎么呈现。
Hacker News 上有人补了句狠话（用户 lukev）：
"the context rot problem gets much worse for these more complex tasks... exponentially so for each logical 'hop' which is required to answer successfully."
每多一步推理，context rot 的惩罚就指数级叠加。
翻译成人话就是，任务每多要一步推理，错误率不是线性加，是翻倍往上堆。
02 你写文章的也跑不掉
Thariq 原文没明说这一层。但把 Anthropic 那篇 context engineering（上下文工程）深度文和 HN 讨论拼起来，就能看出来：
写代码这件事，是 context rot 最严重的应用场景。
但...你要是写文章的别高兴太早，你一样跑不掉，只是温度低一点而已。让 Claude 读一堆素材、反复改一篇长文、来回比较两个措辞版本...一样会让它越聊越笨。
下面三个原因我拿写代码的场景讲，但道理对所有长任务都通用。
第一，工具输出是大头。
程序员每调用一次 grep -r（在代码库里搜关键字）、ls -la（列目录）、跑一次测试...都会往 context 里倒几千 token 的原始输出。
但绝大多数原始输出，后面根本用不到第二次。Anthropic 原话说得好：
"once a tool has been called deep in the message history, why would the agent need to see the raw result again?"
工具已经在历史消息里调用完了，为啥还要再看一次原始结果？
第二，编程任务天然需要多步推理。
读文件 → 理解结构 → 定位 bug → 推断原因 → 写 fix → 验证。每多一步，准确率都要打一次折扣。按 lukev 那句"每多一步折扣翻倍"来算...五步下来，比单步的准确率掉得不是一点半点。
第三（也是最狠的），旧尝试会污染新判断。
debug 失败的路径如果还留在 context 里，模型倾向于复用那些已经被证明错了的框架。HN 用户 posnet 说得很准：
"Claude Code with Opus or Sonnet gets worse the more compactions happen... clearing the context and asking it to re-read the relevant files gives better results."
翻译：Claude Code 的 Opus 或 Sonnet，compact 次数越多越差，清空 context 让它重新读文件，反而结果更好。
好，这段看完你肯定有画面了。
你见过 Claude 一遍一遍道歉，然后继续犯一模一样的错吗？
你见过它明明读过了文件，却像从来没读过一样问你文件路径吗？
你见过它上一轮还清晰无比，下一轮突然开始绕圈吗？
那不是它变蠢了。
是失败的尝试在污染它的判断。
上下文里堆的垃圾越多，它越听不清你真正在说什么。
所以 Thariq 这篇博客，才要把 session 管理单独拎出来讲。这不是一个功能介绍，这是一次认知调整。
03 好，那咱能怎么办？五条路摆你面前
每次 Claude 说完话，你以为你只有两个选项：继续聊，或者关了重来。
其实不是。
Thariq 在文章里抛出了真正的主角。他说，你面前有五条路。
/rewind | ||
/clear | ||
/compact | ||
Thariq 还给了一张官方决策表：
/compact <hint> | ||
/clear | ||
这五个选项听起来像五个功能按钮。但你琢磨一下...
它们其实是你对"现在上下文应该长啥样"的五种判断。
每一轮你都在做这个判断。
只是以前...没人问你。
好，下面咱就按表格顺序，一条一条拆开聊。从最常被你无意识用掉的那一条开始，Continue。
五条路之 01：Continue，看起来免费其实不免费
Thariq 原文里没单独讲这条路，因为它是默认行为，你不做任何选择的时候用的就是它。
但对每一个用 Claude Code 的人来说，这条路是钱包问题。
Claude 定价（Sonnet 4，公开价格。MTok = 每百万 token）：
这里有一点你必须搞清楚：
每发一条新消息，整个历史的 token 量都要重新当 input 计费一次。（除非命中提示词缓存。）
我帮你算一下账。
光这一条消息的 input 就 3 刀。
一个不停 Continue 的 session，边际成本是随长度平方级增长的。你聊得越长，每条越贵。
窗口从 20 万涨到 100 万听起来是好消息。但你真看定价表才发现，超过 20 万那一档，输入价从 3 刀涨到 6 刀，输出从 15 刀涨到 22.5 刀。整整翻倍。
你付双倍的钱。
买到的不是双倍的智力。
是双倍的腐烂距离。
那能救多少呢？
所以...主动 /compact <hint> 是买保险。花 30 秒写个 hint，省 2 小时的回滚。
这笔账你算得过来。
Continue 不是免费的默认。它是五条路里最贵的一条，只是你感觉不到而已。
五条路之 02：Rewind，比"纠正"聪明的那一秒
这一条，可能是整篇博客里最容易被略过的一个动作。我当初就是这样，我知道有 Rewind 这个功能，但几乎没用过。
场景是这样：你让 Claude 读了五个文件，它给出一个不对的方案。
你第一反应会是啥？
我的本能是打一句"这样不行，换个路子"。
Thariq 说...这个本能是错的。
正确的动作应该是双击 ESC。回到它刚读完文件的那一刻，用你新学到的东西重新提问：
"Don't use approach A, the foo module doesn't expose that—go straight to B."
别用方案 A，foo 模块不暴露那个接口，直接走 B。
区别在哪呢？
前一种，Claude 的失败尝试还留在上下文里。后面每一轮，它都在被那段失败污染着判断。
后一种，那段失败就像没发生过一样。干净。
（说实话，这个洞察让我重新审视了我自己过去几十个小时的对话。有多少次 debug 陷入死循环，其实不是因为 bug 真那么难，而是因为 Claude 被自己之前的失败给绕进去了。）
写文章的人也能用
你是写文章的？来，给你一个更直观的版本。
Rewind 就像"回到某个存档点重开"。你在 Word 里存了 v1.docx、v2.docx、v3.docx，写到 v4 发现跑偏了，回到 v2 继续写。把那些跑偏的尝试像没发生过一样丢掉，回到还干净的地方。
这就是 Rewind。
程序员的版本
对写代码的人来说，这玩意儿本质上就是 Git reset + 手动 rebase：
git commit --amend 把失败补丁堆在一起git reset --soft HEAD~3 然后重写 commit message/clear = git checkout -b new-branch 换 branchgit worktree 另起一条并行分支写代码的人对 git reset 有肌肉记忆。知道"回到某个干净的状态再往前走"是更好的做法。Rewind 就是把这个习惯搬到对话上。
彩蛋：给过去的自己写便条
Thariq 还提了一个挺妙的小技巧：
"You can also use 'summarize from here' or the /rewind slash command to have Claude summarize its learnings and create a handoff message, kind of like a message to the previous iteration of Claude from its future self."
就是...让 Claude 在你 Rewind 之前，先写一张"便条"。把刚才尝试了啥、为啥失败、学到了啥，总结下来，递给回退之后的那个自己。
未来的你，给过去的你写字条。
这个画面我真的很喜欢。
特别适合长 debug。你花两小时搞明白一个 bug 为啥出现、哪些方向被证伪、正确方向是啥...这些认知埋在几百轮对话里。Rewind + handoff 相当于只把这些认知摘出来带走，剩下几百轮的垃圾对话全扔了。
五条路之 03：Clear，换个干净桌子
Clear 是五条路里最简单的一条。
你直接敲 /clear，Claude 就把之前说过的一切全忘掉。然后你手写一份简报，把必要的信息重新带进去。
看起来是"粗暴重来"对吧？
但它有一个 Compact 永远比不了的优势，无损。
Claude 自动压缩（compact）会漏东西，因为它是在模型最笨的时候做决定（下一节细讲）。但 Clear 不会漏。因为是你亲自写简报。你说啥带啥，你不说的就不带。
啥时候该 Clear？
Clear 的成本是你得动脑子写简报。Compact 是让 AI 替你写，你省事。
Clear 无损但累人。Compact 省事但有损。
（说实话，我一开始也嫌 Clear 麻烦。后来被 autocompact 坑过几次，就开始养成每天至少主动 Clear 一两次的习惯。花那 30 秒手写简报，比花两小时回滚代码强。）
这两条的具体对比，下一节讲 Compact 时会有一张对比表。
五条路之 04：坏 Compact，发生在 Claude 最笨的那一刻
（这一条我要你特别留意，因为里面有一个我真的没想到的点。）
Thariq 扔出了一句很反直觉的话：
"Due to context rot, the model is at its least intelligent point when compacting."
因为 context rot，模型在做 compact 的那一刻，恰恰是它最笨的时候。
这句话...值得你停下来读三遍。
生活类比：让醉酒的人做战略
你喝了 8 个小时酒，意识已经模糊了。这时候让你对护士说"等会出院记得带 X、Y、Z"，你说出来的清单，十有八九会漏掉关键项。
autocompact（上下文太满时系统自动触发的 compact）就是在模型这种状态下被触发的。
上下文快满了（大约 83.5% 容量，~830K token），腐烂得最严重，判断力在最差的时刻...却要做最重要的决策："这一堆里哪些该留哪些该扔？"
你让喝醉的人规划行李，能不翻车才怪。
典型的翻车场景
Thariq 给的原话例子：
想象你跟 Claude 调试了一个复杂 bug，来回折腾了 50 轮。上下文快满了，系统自动触发 compact，把这段调试过程总结成一段摘要。
然后你接着说："顺便把 bar.ts 里那个其他 warning 也修了。"
Claude 回你："哪个 warning？"
因为刚才那次 compact 是以"调试当前这个 bug"为中心做的总结。那个"其他 warning"跟主线不相关，被当成冗余信息扔掉了。
写文章的场景一样翻车。
你跟 Claude 打磨一篇稿子 50 轮，上下文快满，autocompact 触发。你接着说："顺便把开头第三段那个'仪式感'改成'郑重感'。"Claude 回你："哪个'仪式感'？" 因为那个词早期提过一次就没再说，不是主线话题，被当成冗余扔了。
但...这还不是最糟的。
真正让人后背发凉的，是下一层。
autocompact 不会崩溃。它只是悄悄变差。
你收不到报错。你收到的是一份看起来"还不错"、但关键信息已经丢了的摘要。你要花好几个小时才会反应过来："诶？它怎么越改越离谱？"
（我经历过这个，真的很挫败。因为你找不到"它是哪个瞬间变笨的"，它是一点一点烂掉的。）
/compact <hint> 是保命符
（hint 就是你给 Claude 的一句话提示，告诉它这次压缩该留什么。）
Thariq 说：
"With one million context, you have more time to /compact proactively with a description of what you want to do."
有了 100 万 context，你就有时间主动 /compact，并且告诉它你接下来想干啥。
用法模板（直接照抄）：
Thariq 原文的示例：
你想啊，这就像你请同事写会议纪要：
"帮我写一下"，对方按自己理解来，重要细节一笔带过。
"重点讲 auth refactor 那块，测试调试的琐事不用带"，就多一句话，对齐度差一个量级。
不写 hint = 放弃方向盘，让自动驾驶在你最累的时候做决策。
/compact vs /clear 到底该用哪个？
上一节我说 Clear 无损但累人、Compact 省事但有损。具体对比：
| 有损 | 无损 | |
简单说就是...
只有当你觉得"当前 session 里确实有我下一步会用的东西，只是摘要版的就够了"，才用 Compact。
如果你的"下一步需要"能被你自己一句话写清楚，直接 Clear。
主动 Compact 的黄金窗口
/compact 黄金区，头脑最清醒，摘要质量最高 | |
/compact 还是 /clear，再晚就被动了 | |
Anthropic CPO Jon Bell 给过一个数字：1M 窗口上线后，compaction events 下降了 15%。
这个数字挺有意思。不是因为大家更少管 context 了，而是...很多原本要 compact 的任务，在新窗口下根本跑得完了。
所以 1M 的真正红利不是"装更多"，是给你更长的清醒时间，去做主动决策。
五条路之 05：Subagent，派个分身干脏活
五条路里，Subagent 是最被低估的。对经常跑长任务的人来说，这玩意儿可能是最重要的。
Thariq 的原话：
"When Claude spawns a subagent via the Agent tool, that subagent gets its own fresh context window. It can do as much work as it needs to, and then synthesize its results so only the final report comes back to the parent."
公司分部的比方
你把主对话想成是总部。
总部派一个分部去做一件事，比如"读完这个陌生代码库，总结它是怎么实现登录流程的"。
分部拿到任务之后，自己开一个全新的上下文窗口（就像开了一个独立办公室）。它读几十个文件、调工具、反复试错...这些过程完全不占总部的桌面。
分部干完活，只把结论交回总部。一份两段话的总结。
中间那些"读了哪些文件、试了哪些思路、哪个方法失败了"，都留在分部自己的上下文里，被丢掉也不影响。
量化一下：能省多少
官方 subagents 博客的数字：
"Each subagent might explore extensively, using tens of thousands of tokens or more, but returns only a condensed, distilled summary of its work (often 1,000-2,000 tokens)."
压缩比 10-50 倍。
如果是一条跑一整天的长任务...这个节省是成倍数量级的。
Anthropic 自己用的判断标准
这句话可以背下来：
"The mental test we use at Anthropic: will I need this tool output again, or just the conclusion?"
我们在 Anthropic 用的心智测试是：我以后还会用到这个工具输出吗，还是只需要结论？
三个可以直接照抄的 prompt 模板
1. 验证型
"Spin up a subagent to verify the result of this work based on the following spec file"
起一个 subagent，按这份 spec 文件验证一下刚才那个活的结果。
2. 跨代码库学习型
"Spin off a subagent to read through this other codebase and summarize how it implemented the auth flow, then implement it yourself in the same way"
派一个 subagent 去读 [另一个代码库]，总结他们是怎么实现 auth flow 的，然后你照着同样方式实现一遍。
3. 写文档型
"Spin off a subagent to write the docs on this feature based on my git changes"
派一个 subagent 根据我的 git 变更，给这个 feature 写文档。
写文章的人也能用
把思路套到你自己的场景：
中间翻了哪些资料、走过哪些弯路，subagent 自己消化，你的主对话拿到的是精炼的结论。
有个反直觉的点：默认它不会自动派
Thariq 原话：
"While Claude Code will automatically call subagents, you may want to tell it to explicitly do this."
Claude 默认不会主动为每件小事都开子 agent。因为启动子 agent 本身是有延迟和成本的。
所以...显式要求是常见操作。别以为"它应该自己知道"，很多时候它真的不知道。
04 聊了这么多，其实是一个范式在变
你有没有发现，这篇博客背后其实在讲一件更大的事？
过去一年，我们聊"用 AI 干活"（不管是写代码、写文章，还是做研究），焦点都在一个词上，prompt engineering。怎么问？问什么？写什么 system prompt？
那个阶段里，每一次对话都是相对独立的"一问一答"。
但从 agentic coding（让 AI 自己跑代码）开始...单位变了。
你不再是问一个问题得一个答案。你是开一个 session，在里面干几个小时，甚至几天的工作。
session 变成了工作的基本单位。
Karpathy 在 2025 年 6 月发过一条挺出名的推文，给这个新阶段起了名字：
"+1 for 'context engineering' over 'prompt engineering'. People associate prompts with short task descriptions you'd give an LLM in your day-to-day use. When in every industrial-strength LLM app, context engineering is the delicate art and science of filling the context window with just the right information for the next step."
我翻译一下：
我投"context engineering"这个词，不投"prompt engineering"。人们一说 prompt 就想到日常丢给 LLM 的一句话。但任何工业级 LLM 应用里，context engineering 才是那门精细的艺术+科学，给下一步填进窗口里刚刚好的信息。
两种范式摆在一起，差别就一目了然：
prompt engineering 时代，比的是"怎么说清楚"。
context engineering 时代，比的是"怎么保持清醒"。
这是两种完全不同的能力。
前一种靠语言、结构、举例，更像写作能力。
后一种靠判断、节奏、取舍，更像项目管理能力。
（这让我想起一个事。我观察身边用 Claude Code 效率差别很大的人，差距不在提示词写得多漂亮，而在他们懂什么时候"停下来"。）
05 /usage 这个命令，其实是一面镜子
回头看一下 Thariq 博客的开头。
/usage 只是一个帮你理解 Claude Code 用量的命令。但读完整篇，你会发现一件事...
它和这篇博客一起发布，绝对不是巧合。
Anthropic 团队做过一批用户访谈。发现一个挺扎心的事：
同一个 Claude Code，同一个模型版本，不同用户用出来的效果，可以差出十倍。
差距不在 prompt 写得好不好，不在用了多 fancy 的 subagent。而在一件听起来朴素到不行的事...
你会不会管 session。
有的人从早到晚一个 session 用到底；有的人每条指令都开一个新窗口；有的人在 /compact 和 /clear 之间纠结半天。
同一个工具，用法差异大到像在用不同的产品。
但问题是...你之前其实根本不知道自己用得对不对。因为你看不到状态。
你不查 token 消耗，就没法做 context 管理的决策。你不知道 session 到几成满了，也不知道哪类操作最费。
所以 /usage 不是一个功能。
它是一面镜子。让你第一次看见自己 session 的真实状态。
就像健身戴心率表。不戴也能练，凭感觉来。戴了才知道"我刚才那组是真的在无氧区"还是"其实还没到"。
所以 /usage 发出来，不是多了一个功能而已。它是 Anthropic 在承认一件事：
100 万 token 的窗口，不会让你更省心。反而让你每一轮都得做更多判断。
他们能做的，就是把看不见的状态变成你能看见的数字。剩下的选择，留给你。
这是 context engineering 时代最诚实的产品姿态...
不许诺魔法，只给仪表盘。
06 最后，一个可以贴桌子上的三秒自检
我把上面所有内容压缩成了一个...你每次 Claude 回完话都可以走一遍的三秒自检：
第一问：前面这堆上下文，还和我接下来要做的事相关吗？
/clear，开新 session，自己手写简报第二问：我要的是中间过程，还是只要最终结论？
（写代码场景：我要 Claude 搜代码库的每一条记录，还是只要它告诉我"这个函数在哪几处被调用"？）
（写作场景：我要 Claude 读 PDF 时每段都反馈，还是只要它总结出三条要点？）
第三问：有没有一条路，是我应该回去重走、而不是往前继续走的？
/rewind 到岔路点再加一条观察项：跑 /usage 看看窗口占用到哪了。接近 50% 还在同一任务，提前 /compact 比让 autocompact 触发要好。
三个问题答完...五个动作自己会冒出答案。
07 真正的能力差距，其实已经从模型转移到了人身上
Thariq 这篇文章，表面讲的是五个命令的使用技巧。
本质上...是一份工程范式迁移通知。
我读完最大的感受是：如果你还在用 200K 时代的 prompt 思维，来用 1M 时代的 Claude Code，你会发现工具越强，你反而越累。
不是模型退步了。是工具跑在你前面了。
会管 session 的，一个 session 顶别人十个。
不会管的，无论模型多强，最后都会被 context rot 磨成平庸的产出。
这个转变只会越来越明显。
等未来窗口从 1M 涨到 10M，那些还在无脑 Continue 的人，会发现自己在用越来越贵的 token，换越来越差的答案。
而今天就开始练习"每一轮做一次决策"的人，手里握的不是一个技巧，是一整套随工具升级自动放大的复利。
所以...
今天就挑一个正在开着的 session。下次 Claude 回完话，别急着继续。停三秒。
在五个动作里选一个：Continue / Rewind / Clear / Compact / Subagent。
选完再出手。
这一下停顿，就是区别。
参考链接
[1] https://claude.com/blog/using-claude-code-session-management-and-1m-context
[2]https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
[3] https://research.trychroma.com/context-rot
— END —
加入XiaoHu.ai 日报社群 每天获取最新的AI信息
____________
End.