长会话越用越笨

硬扛着不重开,是长会话里最贵的错误。这页讲清两个降质机制、四个该重开的信号,以及怎么交接才不丢上下文。

一句话结论

做法步骤

1. 理解降质机制一:噪声稀释。官方context window 装着整段会话——每条消息、每个读过的文件、每次命令输出,一次调试就能吃掉几万 token。官方 best practices 把它列为第一约束:上下文越满性能越降。把不相关任务混进同一会话(官方称之为 kitchen sink session)、反复纠错留下的失败尝试,都在稀释真正有效的信息,「重要规则淹没在噪声里」。
2. 理解降质机制二:压缩丢细节。官方接近上限时 auto-compact 自动触发,把对话历史换成一份结构化摘要:保留请求意图、关键决定、改过的文件和重要代码片段,丢掉逐字的工具输出和中间推理。压缩后还有隐性损失:带 paths: 的规则和子目录 CLAUDE.md 要等再次读到匹配文件才回载;调用过的 skill 正文回载有每个 5,000、总计 25,000 token 的上限,超了先丢最旧的。摘要没写进去的细节,之后就真的不在 Claude 脑子里了。
3. 识别该重开的信号。本站观点结合官方建议,出现任何一条就别硬扛:
   • 同一个问题你已经纠正了两次还不对——官方明确:此时上下文已被失败方案污染,应 /clear 并把学到的东西写进新 prompt;
   • Claude 开始违反 CLAUDE.md 里明确写过的规则;
   • 开始重复读已经读过的文件、重复问已经答过的问题;
   • auto-compact 已经触发过,而你正要开始一件全新的事。
4. 交接后重开,而不是裸重开。官方按任务大小选交接方式:
   • 小切换:/clear 前先 /rename 起名,之后随时 /resume 回来(见 D6 · checkpoint / rewind / 会话管理);
   • 大任务:让 Claude 把状态写成文件(spec 或交接文档),新会话读文件接着干。官方的 interview→spec 工作流就是这个模式:spec 定稿后「开一个新会话执行,新会话拥有干净的、聚焦实现的上下文」;
   • 要连续性但想瘦身:/compact 加定向指令(如 /compact focus on the API changes)控制摘要保什么;或用 /rewind 菜单的 Summarize from here / up to here 只压一段、留一段;
   • 顺手小问题:用 /btw 问,答案不进对话历史,不长上下文。
5. 附带收益:省钱。长会话不只变笨,还在按整段上下文计费——每条消息都背着全部历史。省额度的完整做法见 这个月额度怎么烧完的。

可直接抄的 prompt

这个会话已经很长了,我要开新会话继续。请把当前工作状态写成一份
交接文档存到 HANDOFF.md,包含:
1. 任务目标与当前进度(已完成 / 未完成,逐条列出);
2. 改过的文件清单,以及每处改动的原因;
3. 尝试过但失败的方案和失败原因(让新会话不要重蹈覆辙);
4. 下一步的具体计划,以及怎么验证做对了;
5. 新会话需要知道的项目约定或坑。
写完后,给我一条新会话的第一条消息:让它先读 HANDOFF.md 再开工。

来源与最后核实日期

• 官方code.claude.com/docs/en/best-practices.md(性能随 context 填满而降、两次纠错即 /clear、kitchen sink 反模式、interview→spec 后开新会话),抓取于 2026-08-05。
• 官方code.claude.com/docs/en/context-window.md(压缩保什么丢什么、skill/规则回载上限、/context 与 /autocompact),抓取于 2026-08-05。
• 官方code.claude.com/docs/en/sessions.md(/rename、/resume、/clear、/compact、/context 的会话内用法),抓取于 2026-08-05。
• 本站观点「该重开的四个信号」清单与 HANDOFF.md 交接模板为本站基于官方建议的编排。
• 最后核实:2026-08-05 · volatility:low(核心是「上下文管理与交接」方法论,基本不过期;压缩细节等版本相关处以官方文档为准)。