Claude Code 卡顿变慢？几个 Session 管理的实战技巧帮你续命

最近在啃一个有点年代的 Vue 老项目，Claude Code 确实是把好手，但用着用着就发现不对劲了，尤其是连续工作半小时后，那响应速度肉眼可见地变慢。

打开终端一看好家伙，上下文窗口都要被撑爆了。毕竟是在改代码，不是闲聊，每一个文件的改动、每一次的报错修复都得喂给它，Token 消耗起来跟喝水一样。这种场景下，怎么管理 Session 才能既不丢失关键信息，又能保持流畅度？今天就来聊聊我在实战中摸索出来的一点经验。

监控上下文使用量，避免被撑爆

别盲目 /clear，先学会看 /cost

很多人（包括以前的我）遇到卡顿第一反应就是 /clear，一把梭哈重开。这确实爽快，但前面所有的上下文全丢了，比如刚才讨论过的业务逻辑、已经确认的代码规范，还得重新唠一遍，其实更浪费时间。

我的建议是，养成多看 /cost 的习惯。这个指令不光是看你花了多少钱，更重要的是看你的 Context Usage 占了多少。

• < 30%：随便造，继续聊。
• 30% - 60%：警惕区间，这时候回复开始有延迟，需要策略性地精简对话。
• > 60%：危险边缘，必须处理，不然不仅慢，还容易超出上下文窗口导致它“失忆”。

使用 /cost 指令查看 Context 占比

/compact 是好东西，但别迷信它

官方文档推荐的 /compact 指令，作用是把当前的对话历史压缩成一段摘要，释放 Token 占用。听起来很完美，但实测下来有个坑：它压缩得并不总是精准。

我在那个 Vue 项目里试过，有时候它会把关键的某个接口定义或者之前达成共识的 Hack 写法给压没了，导致后续代码生成出现偏差。而且，压缩本身也需要时间，上下文越大，压缩越慢，甚至比直接回答一个问题还慢。

什么时候用 /compact？

1. 当你们正在进行同类型、重复性的操作，比如连续修 10 个类似的 UI Bug，这时候压缩摘要通常比较安全。
2. 刚完成了一个大功能模块的迭代，准备切入下一个模块时，让 AI 总结一下当前模块的状态，然后压缩。

什么时候别用？

1. 正在调试一个复杂的、涉及多个文件的诡异 Bug 时。此时每一个细节都可能是破案线索，压缩极易丢失关键线索。
2. 你感觉 AI 最近有点“飘”，理解能力不如刚开始时。这时候压缩可能会加剧它的“幻觉”。

我的“换挡”策略：分而治之

其实最好的 Session 管理不是在一个会话里熬到死，而是学会“换挡”。针对那个老 Vue 项目，我现在的工作流变成了这样：

1. 项目启动/环境配置阶段：独立 Session。搞定依赖安装、Lint 配置、构建脚本报错。一旦跑通了，直接清掉，后面不需要再带这些信息。

2. 核心功能开发阶段：按“功能点”切分 Session。比如今天只做“用户登录模块”，所有对话都在这个范畴里。感觉 Context 超过 50% 了，就把这个 Session 暂存（如果是 Web 端），然后新建一个 Session，开篇第一句话就把之前的约定好的规范“灌”进去：

   “我们要改写这个登录模块，请注意使用 Composition API，并且所有请求都要加上 Auth Header，遵循之前的 XXX 风格。” 这样既省 Token，又不会让它瞎发挥。

3. Bugfix 阶段：这是最耗 Context 的。如果遇到那种改了又坏、坏了又改的死循环，我果断 /clear 重开。重开时，我会把报错日志和最核心的代码片段直接贴给它，而不是把之前半小时的试错过程再走一遍。直接抛出最终确定的“症状”和“代码现状”，效果往往更好。

总结一下

别把 Claude Code 当成一个无限聊天的窗口，它更像是一个有状态限制的智能终端。

• 勤用 /cost 监控状态，别等卡死了才反应过来。
• 慎用 /compact，在关键调试环节宁可多输几行字，也别省那点 Token 把关键上下文丢了。
• 大胆分 Session，按任务切分，把脑子里的“上下文”和 AI 的上下文分开管理。

毕竟，我们是为了让 AI 帮我们提效，而不是为了教它怎么在有限的窗口里背下整本代码书。希望这几个小技巧能帮你在改老项目时少一点焦虑，多一点流畅。