如果你在 Claude Code 里连续做过一个超过两小时的重构任务大概率遇到过这样的场景它忽然开始重复问你刚才已经回答过的问题或者对一个刚讨论完的实现细节“失忆”了。别急着骂模型变笨多数情况下这是Claude Code 的上下文压缩机制在起作用。你正在经历的是它为了在有限的上下文窗口里继续为你干活对你之前的对话做了一次“减法”。这篇文章想把这个机制彻底讲透窗口里到底发生了什么、自动压缩和手动压缩的区别、哪些内容会被保留哪些会被丢掉以及更重要的——如何在真实开发里利用好压缩而不是被它坑。如果你已经在用 Claude Code 写代码或者正准备上手这篇文章能帮你省下不少和“失忆”较劲的时间。1. 为什么会有上下文压缩窗口里的稀缺资源1.1 上下文窗口是什么编码场景里它被什么吃掉先回到最基础的概念。大语言模型有一个“上下文窗口”你可以把它粗看成模型一次能“读进去”的信息总量单位是 token词块。Claude 系列的窗口容量虽然不小但它是有限的。Claude Code 作为一个终端里的编程助手每个会话就是在这个窗口里工作的——窗口里装着系统提示、工具定义、你发的指令、它读过的文件内容、跑过的命令输出、以及你们之间一来一回的全部对话。问题在于编码场景对上下文的消耗快得惊人。我举个例子你就明白了你让 Claude Code 修一个 bug它大概率会先读一遍相关文件3000 行的文件读进去几万个 token 就没了接着它要跑测试测试输出几百行又读进来测试失败它又去读报错堆栈和日志然后改代码、再跑、再看输出……就这么三五个来回一个以为自己还很“新鲜”的会话实际已经消耗了海量空间。这就是为什么长会话到了后期模型会变得迟钝、开始问重复问题——不是它能力衰退是窗口里的有效信息密度下降了。上下文压缩机制本质上就是在回答一个很现实的问题当窗口快满的时候应该怎么办1.2 压缩的本质不是把窗口变大而是把内容重新组织一个最粗暴的解法是直接把旧对话删掉。但用过就知道这不可行。想象一下你让 Claude Code 做的是一个三步任务先调研接口现状再重构实现最后补测试。如果你把第一步的对话直接删掉模型就忘了为什么要做这一步如果你把第二步的工具输出删掉它不知道结果是什么第三步根本没法接。所以说粗暴截断会直接切断任务的因果链。Claude Code 实际采用的方案是“摘要化压缩”或者说“会议纪要化”。它会在接近窗口上限时让模型自己回顾一遍整个对话把两个小时的讨论浓缩成几条要点把详细的过程降级成“方向的纪要”然后用这份纪要替代原始对话。这个思路很像开会两个小时的头脑风暴最后留下的是一页会议记录散会之后没人能复述每一句话但关键决议都在。这个设计背后的逻辑很清晰压缩追求的不是“无损”而是在有限空间里保留最高的信息回报率。任务的高层目标、关键约束、已经完成的动作、待办事项这些是“必须记住”的而某一轮工具输出里那些零碎的中间状态属于可以牺牲的细节。2. 压缩机制的全貌自动、手动与会话恢复2.1 自动压缩触发条件与默认行为Claude Code 默认开启自动压缩。机制上它在每次发起 API 请求前会判断当前对话是否即将触及上下文窗口的上限一旦判断接近限度就会先对已有对话执行一次压缩再带着压缩后的摘要继续执行你的新指令。你在界面上看到的现象通常是某个请求发出后终端里会出现一行类似Compacting conversation...的提示然后才继续输出结果。这里有个值得注意的细节自动压缩是被动触发的它发生在“快满了”的时候。虽然比“满了再说”优雅得多但它的时机并不一定符合你的任务节奏。你正在集中讨论一个细节或者刚贴了一段关键报错压缩突然发生了摘要大概率不会把所有细节都留住。配置方面设置项里有个autoCompactEnabled之类的开关默认是打开的不同版本的位置和写法略有差异。如果你在跑一些需要稳定输出的长任务可以考虑把它关掉改成手动掌控压缩时机。我要提醒一句关闭自动压缩不代表窗口会变大它只是把“什么时候压缩”的决定权还给你。2.2 手动压缩/compact 与相关命令除了自动触发你还可以在输入框里直接敲/compact来手动触发对话压缩。这个命令的作用是立刻对当前会话做一次摘要化处理把冗长的历史折叠成要点给后续对话腾出空间。那什么时候该主动压缩而不是等自动压缩我的经验是在一个逻辑节点的末尾而不是任务进行到一半的时候。比如一个子任务完成了、结论已经清楚了、接下来要换一个新方向这时候就是压缩的好时机。反之如果你正在一步步排查一个问题每一步结论都是下一步的输入这时候压缩就有风险——摘要可能丢掉你刚发现的中间线索。还有一个实用技巧手动压缩之前先把当前的关键结论写进一个文件。别怕多花一分钟这一分钟能在压缩后省下十分钟的“找回记忆”时间。压缩完成后我建议你立刻发一句“根据我们目前的进度下一步是什么”看看它能不能准确回答。这个动作能快速验证压缩后的会话是否还“在线”。2.3 会话恢复与压缩的联动Claude Code 支持用--resume或--continue恢复之前的会话这个功能很方便但很多人忽略了一个联动效应恢复一个已经很大的会话时系统同样面临着上下文窗口的压力。如果一个会话在保存前就已经非常庞大恢复后很可能立刻触发压缩你看到的“现场”其实是“摘要化的现场”不是完整的原始现场。我踩过这个坑。有一回我恢复一个隔天的大会话想着接着昨天的思路继续结果它把昨天的详细探索过程浓缩成了三行摘要我当时没意识到顺着它的话往下聊结果整个方向都跑偏了。后面才反应过来我不该依赖会话恢复来“回到现场”而应该在保存会话之前就把重要进展同步到文档或代码提交里。所以这里送出一条核心经验不要让 Claude Code 的会话成为唯一的信息载体。文件、README、CLAUDE.md、commit 信息这些才是跨会话的“长期记忆”会话本身只是工作台工作台再好一天结束也要收拾东西。3. 压缩时保留什么、丢掉什么记忆的取舍逻辑3.1 对话中的内容优先级排序压缩不是均匀地“缩水”它有自己的优先级。我根据大量使用经验把会话里的内容类型和它们在压缩中的待遇整理成了下面这张表看完你基本就能预判“什么会被记住、什么会丢”内容类型压缩中的待遇原因用户指令与约束条件高保真保留这是任务的“北极星”丢了就彻底跑偏工具执行结果ls、grep、日志等高度压缩、甚至丢弃多数属于过程噪音信息回报率低被读入的文件内容部分保留关键结构可能留下具体实现细节容易被摘要化模型自己的推理过程与中间解释压缩成结论过程性的“思路草稿”会被折叠成一句话错误信息与异常堆栈关键错误保留零散日志丢弃主要报错影响后续方向次要日志不值得占空间这张表的实际含义是如果你希望某条信息在压缩后依然存在就得让它进入“高优先级”区域。怎么进两个办法一是把它变成用户的明确指令或约束二是在压缩前把它写进文件。单纯地让它在对话里“出现过”在压缩眼中约等于“没说过”。3.2 摘要化的过程分层提炼实际的摘要化处理看起来像是一个分层提炼的过程。第一层保留任务的高层目标和当前状态比如“正在修复 userService 中 getUser 的空指针问题”第二层把具体执行流程浓缩成纪要比如“已分析堆栈、修改了服务层代码、补了两个测试用例”第三层把过程中的噪音直接丢弃比如某次命令的完整输出、某个临时的探索分支。我举一个真实的例子。一次会话里我让 Claude Code 修复一个单元测试原始对话里包含了完整的测试失败输出、代码修改 diff、再次运行测试成功的日志。压缩之后这段历史变成了类似“修复了userService.ts中getUser的空指针问题涉及文件src/services/userService.ts、tests/userService.spec.ts已通过测试。”读起来还是很清晰的对吧但请注意如果你之后追问“那次空指针的触发条件具体是什么”它就答不上来了——细节已经没了。这就是压缩的真相它保留了“发生了什么”但丢掉了“怎么发生的”。对于大部分后续开发前者够了但如果你需要在同一个会话里深入挖掘过程细节就必须在压缩前主动把关键细节外置。3.3 压缩的副作用与“失忆”场景压缩最常见的副作用是丢掉“过程性信息”。我在前面说过这些信息指那些你在对话里发现、但还没写进任何文件的内容。举个例子。你让 Claude Code 排查一个诡异的内存问题它经过好几轮探索发现了一个隐藏的依赖关系——A 模块之所以内存暴涨是因为 B 模块在某个路径下没有释放引用。这个结论本身很重要但发现它的过程更长。如果你不把这个结论写进文件只是继续聊下去一旦压缩发生摘要里很可能只留下“排查了内存问题定位到 B 模块存在引用未释放”至于那个具体的触发路径、A 模块里的哪一行代码是关键——可能就丢了。还有一个容易被忽略的副作用摘要偏移。压缩是由模型生成的既然是生成就可能存在理解偏差。原始对话里你表达得很精确的某句话经过摘要转述后可能带上一点“概括性”的味道方向虽然大致不差但细节已经失真了。所以我不建议在压缩后的会话里继续处理对精度要求极高的事务比如精确的接口参数对齐、复杂的正则表达式调整——这些场景宁可开新会话把上下文从头理一遍。4. 在实操中利用好压缩上下文管理实战4.1 把“短期对话”和“长期记忆”分开真正高效使用 Claude Code 的人一定不会把所有信息都放在对话里。他们会把“长期记忆”外置到项目的CLAUDE.md文件里让对话只承担“当前工作台”的角色。CLAUDE.md是 Claude Code 会在会话开始时自动加载的项目说明文件相当于一个“新同事入职手册”。你可以把项目约定、技术栈、目录结构、代码风格、常用命令、已知的坑都写进去。每次新会话启动这些内容都会被自动载入这意味着即使你的对话被压缩得只剩摘要模型依然能从CLAUDE.md里拿到项目级的关键信息不至于“失忆”得太彻底。一个比较实际的CLAUDE.md片段大概长这样# 项目约定 ## 技术栈 - 后端Python 3.11 FastAPI - 数据库PostgreSQL 15使用 SQLAlchemy 2.0 ## 目录结构 - src/api/ 存放 API 路由 - src/services/ 存放业务逻辑 - tests/ 存放单元测试 ## 常用命令 - 启动开发服务器poetry run uvicorn src.main:app --reload - 运行测试poetry run pytest ## 已知问题 - src/services/billing.py 中历史遗留的时区问题不要在未开会讨论前修改把长期信息写进文件短期信息留在对话里这个习惯能极大提升 Claude Code 的稳定性。压缩只是“短期记忆的刷新”它的破坏力之所以大是因为很多人依赖了对话来保存长期信息。4.2 小步快跑用子任务和会话切分对抗压缩我在实践中发现最有效的上下文管理策略不是“省着用”而是“快速用完就换”。具体来说就是小步快跑一个会话只做一个模糊目标。一个典型的长任务比如“给整个模块加上完整的错误处理”可以切成几个子任务先梳理模块的异常路径再逐个接口加错误处理最后统一跑测试。每个子任务单独开一个会话完成一个、验收一个、写进文档一个然后关掉。这样每个会话的体积都被控制在一定范围内上下文压缩的压力也小很多。另外Claude Code 支持子代理subagents子代理有自己相对独立的上下文空间。你可以让子代理去做那些“脏活、杂活”——比如搜索文件、批量浏览代码、跑一些探索性命令——然后只把结论带回主会话。这相当于给主会话的上下文加了一层“隔离”避免无关内容污染主线推理。我见过不少人在一个会话里一口气干六个小时做到后面模型开始犯迷糊、反复横跳。问题不在模型在窗口里的信息早就是一锅粥了。正确的姿势是每个里程碑完成就主动检查一下/context的上下文占用情况该收尾就收尾该开新会话就开新会话。4.3 主动压缩的正确时机即使你养成了切分会话的好习惯有些任务仍然不可避免地会变长这时候就需要主动压缩了。下面这几个时机是我实测下来比较合适的切换子任务之前。当前任务的结论已经写入文件下一个任务需要新的上下文空间此时压缩可以干净利落地切场。大量工具输出之后。如果你的对话里积压了很多命令输出、日志、测试结果这些信息价值密度很低压缩它们是最划算的。让模型做重要决策之前。压缩后模型的状态会比较“清醒”如果接下来有一个架构性的决策要讨论先压缩再讨论效果会好很多。准备恢复一个重要会话之前。先手动压缩一次能避免恢复后被动触发压缩让你掌握主动权。压缩完之后记得做一次“现场验证”也就是我之前说的问一句“根据我们目前的进度下一步是什么”。这道“面试题”看起来简单但能快速暴露摘要是否保留了你真正需要的信息。如果答偏了别犹豫补充上下文或者开新会话。4.4 面向压缩的输出习惯最后一个技巧是从源头减少上下文污染。很多人在终端里操作时习惯让命令的输出直接打在终端上。但在 Claude Code 里这样做意味着所有输出都会进入对话上下文。几个来回后大量低价值信息就堆积起来了。更聪明的做法是让输出走文件而不是走对话。比如让测试结果写入test-output.log然后让 Claude Code 去读文件里的内容而不是直接看终端输出让 AI 每完成一个阶段就把结论写进一个.md文档而不是只靠对话里的推理。这相当于“数据降维”把冗长的原始数据先折叠成结构化的结论再喂给主会话。还有一个习惯可以刻意培养主动让 AI 把阶段性成果写成文档或 commit message。这听起来像是在给项目做“文档管理”其实是纯粹的“上下文管理”。因为一旦成果外置对话里的历史就变成了“可丢弃的草稿”压缩时丢了也不可惜。5. 常见问题与使用经验速查5.1 症状与对策表最后整理一份我在日常使用中常见的“压缩病”和对策遇到类似情况直接来查症状可能原因对策压缩后模型忘了具体的报错信息报错内容属于过程性信息被摘要化处理把关键报错截图或存成文件作为约束条件重新粘贴给模型自动压缩频繁打断工作流单次会话积累太快大量工具输出挤占窗口对任务做更细的切分让输出走文件关闭自动压缩、手动掌控时机resume 后状态不对、方向跑偏恢复大会话后触发了压缩摘要丢失关键细节保存会话前把关键进展写进文件优先用新会话配合 CLAUDE.md 重建上下文压缩后方向偏了、答非所问摘要丢失了关键约束或任务目标将任务目标写进当前计划文件顶部压缩后立即用“下一步是什么”做验证模型开始重复问同样的问题上下文质量已下降到有效信息不足检查/context考虑手动压缩或在结论外置后开新会话这张表还能当一张“健康检查表”。如果你发现自己的 Claude Code 会话开始出现这些信号就该干预了。5.2 几个值得警惕的信号除了症状表里的硬性问题还有一些更微妙的信号值得你在长会话中留意第一个信号是模型开始重复提问。如果它开始问“你希望用哪种方式实现”“这个需求是面向哪个场景的”这类已经讨论过的问题别怀疑是它“性格变了”多半是上下文里的原始信息已经失效了。第二个信号是回答变得“泛泛的”。压缩后的模型如果能靠摘要正常工作回答会很顺畅但如果摘要质量不好它就只能用非常通用的口吻回应不再引用具体的文件名、行号、变量名。这时候你就要警惕它可能已经丢了“现场感”。第三个信号是工具调用开始变保守。上下文不足时模型有时会倾向少调用工具、少读文件因为每个工具的输入输出都要再占空间。它开始“偷懒”不是不负责是不敢再往窗口里塞东西了。这些信号出现时我的标准动作是停下手头的活检查一下/context的占用情况把关键结论外置然后决定是压缩还是开新会话。5.3 我的实操心得说实话我第一次搞懂压缩机制时最大的感受是这东西并不难理解但很少被系统性地讲清楚。很多人用 Claude Code 觉得“越用越笨”其实是把自己的使用习惯问题归咎到了模型身上。我现在的节奏是每个功能做出来先写文档再开新会话。我不会试图在同一个会话里完成一个项目从调研到上线的一整个过程而是把它拆成一个个里程碑每个里程碑之间用文件和CLAUDE.md交接。上下文管理不是“省着用”而是“让每一段话都花在刀刃上”。还有一个很个人化的小建议我会在项目的CLAUDE.md里专门留一个“近期进展”区块每次会话结束把这次会话的结论写进去。这样即使压缩把会话的记忆抹得一干二净下一次会话也能从文件里无缝接上。这套流程跑顺了之后Claude Code 的稳定性肉眼可见地上了一个台阶——它不再是一个“时灵时不灵”的黑箱而是一个可控、可管理、有节奏感的开发工具。压缩机制本身是一种取舍它换来的空间让你能继续干活代价则是记忆的模糊。搞懂它之后你就不再是那个被动的使用者了——你知道什么时候该信任摘要什么时候该换现场也知道最重要的信息永远应该在压缩到来之前写进那些会一直存在的地方。