Claude Code 用久了你会发现一个挺反直觉的现象它越用越笨的时候往往不是模型出了问题而是会话没管好。我自己有一段时间就是习惯打开终端直接claude一个会话里连续干三四个需求结果做到后面它开始选择性失忆——一会儿忘了刚才定的接口字段一会儿又把上一个需求的临时方案搬到新需求里。后来把会话管理这件事单独拎出来梳理了一遍该续的续、该断的断、该清的空整个协作体验完全不一样了。这篇就把我对 Claude Code 会话管理的完整思路和实操经验整理出来适合正在用 Claude Code 写项目、又觉得对话一长质量就下降的人参考。1. 会话是什么把 Claude Code 从聊天工具变成开发协作者的关键1.1 会话、工作区与上下文窗口的关系Claude Code 不是一个问一句答一句的问答机器人它在每个项目目录里运行可以读文件、改代码、执行命令。它之所以能做到这些依赖的是一个持续存在的交互状态——也就是会话。会话可以简单理解成AI 在你这台机器、这个项目里的工作现场它包含了你和它之间的全部对话、它看到过的文件内容、它执行过的命令结果、它做过的代码修改以及它在整个过程中形成的临场判断。这个工作现场和 IDE 打开一个工程窗口很像。你打开一个新的 IDE 窗口编辑器是干净的只有已保存的代码文件是确定状态你用同一个窗口连续改 A 模块、B 模块、C 模块改到最后其实已经分不清哪些代码是给哪个模块用的了。会话就是 Claude Code 的窗口一段会话天然绑定一个工作区目录并在运行期间不断累积上下文最终受限于模型的上下文窗口容量。上下文窗口是有限的这决定了会话不是越长越好。窗口里的信息被塞满之后Claude Code 有两种表现要么自动或提示你做压缩把早期对话浓缩成摘要要么干脆遗忘一些早期细节。很多人在一个会话里连续做一周任务做到后面明显感觉回答质量下降本质是窗口里的有效信息被无效信息挤占了。会话管理的第一个核心认知就是会话是廉价可创建的但上下文窗口是宝贵且有限的。1.2 会话日志真正存储在哪里很多人以为会话只存在于内存里关掉终端就没了。实际上 Claude Code 会把每个会话的完整过程持久化到磁盘默认位置是用户目录下的.claude/projects/。每打开一个项目目录它会在该目录下生成一个以项目路径编码命名的文件夹里面存放一个或多个会话日志文件每个日志文件以会话 ID 命名后缀是.jsonl。这意味着三件事关掉终端、重启电脑会话都还在只要你知道会话 ID 或者能通过交互式列表选择。会话日志是全量记录包括你发过的消息、Claude Code 读过的文件、执行的命令、工具的输入输出都在里面。会话日志也带来安全与磁盘占用问题如果项目内容敏感这些日志等同于一份明文副本。实操中我拿到一台新机器或者换人接手时第一件事是查看这个目录能快速了解之前在这个项目里做过什么。按时间倒序看.jsonl文件名和相关时间戳基本能还原出整个项目的 AI 协作轨迹。1.3 会话管理失控的典型症状经验不足时会话管理失控是有规律可循的。典型症状包括症状一上下文污染。新需求出现时还在旧的会话里直接说现在换个需求……导致模型把上一任务的思路混进来。症状二恢复困难。跨天想继续昨天的任务却忘了会话 ID只能打开一个新会话从零解释背景浪费大量 token 和描述精力。症状三上下文膨胀。一个会话里反复修改同一模块旧的方案、误操作、无效尝试全部留在上下文中模型被大量废案干扰。症状四日志泄露隐患。所有敏感操作和对话被持久化为 jsonl 文件后既不清理也不加密留着潜在风险。这些症状的共同根源是没把会话当作一种需要主动管理的开发资源而是当成了普通聊天窗口。后面几节我会把操作方法和场景选择分开讲先解决怎么操作再解决什么时候该用什么操作。2. 核心操作新建、继续、恢复与清理2.1 从零开始什么场景必须开新会话claude --new是显式开启一个新会话的命令等价于不带任何参数直接运行claude但它的意义在于明确告诉 AI现在是一个全新任务请不要携带旧上下文。我判断是否需要新会话有三个硬性条件满足任何一个就开新的任务边界变化。上一段还在做登录模块现在要去做支付模块这属于不同任务。即便代码在同一仓库里也应开新会话因为支付模块需要的背景知识与登录模块完全不同旧上下文只会干扰。集成测试前的状态梳理。如果你希望 Claude Code 基于当前代码库状态重新理解项目而不是依赖对话里那些可能已经过时的描述让它在干净会话里重新读代码会可靠得多。跨 git 分支工作。从feature/login切到feature/payment后旧会话里所有关于文件路径、依赖变量、分支状态的认知都可能失效。新会话并不是从零记忆。Claude Code 启动时会自动加载CLAUDE.md项目级记忆和用户级记忆文件这些文件相当于项目说明书是每次会话开始时的固定初始化输入。所以把项目约定、架构决策写在CLAUDE.md里比在很长对话里反复嘱咐 AI 要可靠得多。这也是我会在切换任务后第一时间更新CLAUDE.md的原因等于把上一个会话的结论沉淀为长期记忆再开新会话继续用。2.2 断点续传--resume 与 --continue 的差异跨天、跨时间段继续一个未完成的任务最常用的命令是claude --resume。直接不带参数运行claude --resume它会弹出一个交互式列表让你选择要恢复的历史会话列表里通常能看到会话 ID、创建时间、开头内容摘要等信息。如果你已经知道具体的会话 ID可以直接指定claude --resume 6f1a2b3c-xxxx-xxxx-xxxx-xxxxxxxxxxxx这里的会话 ID 在上面的选择列表里能看到在~/.claude/projects/下对应的.jsonl文件名里也能找到。还有一条更快的命令claude --continue简写是claude -c。它的语义是无缝接续最近一次会话不需要选择、不需要记 ID适合那种中午吃饭前还在调同一个 bug下午回来继续调的场景。我日常用的最多的是-c因为它足够快。这里有一个容易混淆的点--continue和--resume之间的界限。我用下来的理解是--continue本质上是自动恢复最近那个会话的快捷方式--resume则可以指定任意历史会话如果不指定就交互式选择。所以如果你只有一个活跃任务用-c就行如果你手上同时有好几个会话在推进那么建议记住关键会话 ID用--resume id精确跳转。注意恢复会话时Claude Code 会先确认当前工作区是否与会话记录中的项目目录一致。如果你在别的目录执行claude --resume可能无法正常恢复或恢复后项目状态对不上。会话本质上与项目目录绑定跨目录恢复是我实际踩过最多的坑。2.3 清理与归档日志目录管理与会话瘦身会话日志长期堆积后有两个问题必须处理一是磁盘占用二是日志泄露风险。先说磁盘占用每个.jsonl会话文件的大小从几十 KB 到几十 MB 不等取决于会话长度和工具输出量。一个高强度使用 Claude Code 的仓库几个月积累下来占据几百 MB 是很正常的。我习惯每完成一个里程碑就归档一次会话。归档方式不复杂把~/.claude/projects/项目编码/下的旧.jsonl文件移动到专门备份目录或者直接删除。删除前我会确认几个点关键决策和结论是否已经写入CLAUDE.md或代码注释。涉及发布、部署的脚本是否已经沉淀到仓库中。有没有需要在未来追溯的对话过程。清理非法会话不只是顺手删文件而是把人可读的工作资产从机器可读的日志中提取出来的过程。真正有价值的东西应该进入仓库和文档而不是停留在日志里。另外Claude Code 支持通过配置目录环境变量来改变日志存放位置。如果你有多套项目要隔离或者想让日志落在加密磁盘上可以在启动前设置CLAUDE_CONFIG_DIR指向自定义路径。比如export CLAUDE_CONFIG_DIR/path/to/shared/claude-config claude改掉配置目录之后会话日志、认证信息、CLAUDE.md 记忆都会跟随这个目录走。多环境隔离场景下这个变量很实用但也容易引起为什么新环境找不到旧会话的困惑排查时先检查它是不是被指向了另一个位置。3. 实操一个跨天需求的完整会话管理流程3.1 场景设定需求拆解与会话规划我用一个模拟项目来走完整流程。假设有一个内部工具项目当前需要实现一个批量导出报表并自动发送邮件的后台任务。这个任务可以拆成三个子阶段阶段一设计导出任务的数据模型和队列逻辑。阶段二实现邮件模板和发送服务的集成。阶段三写自动化测试并跑通全链路。这三个阶段之间有依赖但各自的上下文差异很大硬塞到一个会话里会让模型在切换话题时卡壳。我的规划是一个阶段一个会话且每个阶段结束都在CLAUDE.md里追加一段简短结论。这样阶段二开始的新会话天然了解阶段一的产出又不背负阶段一大量的试错细节。实际操作中我在项目根目录执行claude --new关于这个新会话我会在第一条消息里就写清楚目标和边界格式大致是当前任务设计批量导出报表的数据模型与队列逻辑。 项目背景请先阅读 CLAUDE.md 和 server/ 目录结构。 交付物在 docs/export-design.md 中输出设计文档不要改任何业务代码。 约束本次会话只做方案设计不进入编码实现。为什么这么写因为新会话虽然自动加载CLAUDE.md但本次会话要完成什么、不做什么是需要显式声明的。这在会话管理里叫会话边界设定边界设好了AI 的注意力才会集中在任务主线上。3.2 实操命令序列与 JSON 输出实践阶段一的会话进行到方案确认后我可能因为开会、review 等原因中断。下午回来继续时我直接执行claude --continue这个命令把上午的会话完整接起来AI 记得刚才讨论的数据模型、队列选型、以及你没来得及落盘的临时决定。这里有个体验细节--continue接续后建议先用一句话让 AI 复述当前进度例如请先总结一下我们目前的设计方案确认变更点然后我们继续聊队列消费失败的重试策略。这么做有两个作用一是验证恢复的上下文是否正确二是快速把 AI 的注意力拉回最新的决策位置。很多人恢复会话后直接抛新需求结果 AI 还在处理旧问题这是上下文串台的常见原因。如果需要脚本化获取会话内容--output-format stream-json很好用。它能把会话运行过程中的事件流输出为结构化 JSON结合指定会话 ID 使用可以精确分析某个会话里 AI 到底执行过什么步骤claude --session-id 6f1a2b3c-xxxx-xxxx-xxxx-xxxxxxxxxxxx \ --output-format stream-json \ -p 继续刚才的导出任务检查 server/queue.py 的消费逻辑-p表示以非交互模式运行适合在自动化脚本中调用。这种组合在 CI 场景特别有价值比如定期让 AI 基于同一个历史会话继续跟进某个长期任务。不过要注意--session-id只能引用本地存在的会话历史不能凭空指定一个不存在的 ID。想拿到当前可用的会话 ID最稳妥的方式是在交互式--resume列表里查看或者从~/.claude/projects/目录中按时间排序查找。3.3 compact 与 clear 的实战取舍会话进行到中后期上下文窗口的剩余空间会明显减少。此时 Claude Code 内有两个斜杠命令非常关键/compact和/clear。它们的区别如果不搞清楚很容易把会话彻底搞坏。/compact压缩当前会话的历史消息。Claude Code 会对之前的内容做摘要式重写保留关键信息丢掉的是一些重复对话和冗余细节。它不会结束会话AI 仍然记得项目的来龙去脉只是细节粒度变粗了。适合会话还得继续但窗口快满了的情况。/clear清空当前会话的可见对话历史。执行后 AI 不记得刚才聊过什么但整个会话记录仍保留在日志文件中可以通过恢复会话重新找回。适合模型状态已经明显错乱我希望在不新建会话的情况下重置现场的情况。我的建议排序是优先用/compact其次用/clear最后才考虑新开会话。因为/compact保留了思考惯性AI 知道我们在做导出任务、选了什么队列、写到哪个文件了只是忘记了一些中间过程。而/clear相当于让 AI 短暂失忆本地环境还在但它的工作现场消失了恢复成本较高。这里还要补充一个实操心得/compact不是万能的它受限于模型对摘要的理解能力。如果压缩发生在任务中途某些虽然没写在代码里但双方默认知道的隐性共识可能被压缩掉。所以我在压缩前会先手动把关键结论复述一遍让它确认后再压缩等于给摘要过程上一道保险。3.4 用会话 ID 做脚本化控制与自动化跟进长期维护类任务很适合脚本化。我其中一个自动化场景是每天晚上让 Claude Code 基于最近一个巡检会话检查服务器日志发现异常则标注。实现思路就是固定一个会话 ID定时任务里执行claude --session-id 6f1a2b3c-xxxx-xxxx-xxxx-xxxxxxxxxxxx \ -p 请基于当前工作区与历史上下文检查 logs/app.log 的新增告警输出摘要 \ --output-format stream-json \ --permission-mode plan这里--permission-mode plan的意思是只让 AI 输出计划不实际执行有副作用的操作。在脚本化场景里权限控制极其重要。因为自动化任务不会像人一样看着 AI 操作如果直接放开写权限AI 可能做出一堆危险的文件改动。我会把自动化线程的权限收敛到只读或计划模式只在人工确认后才切换。会话 ID 脚本化还有个隐藏用途做 A/B 对比。我可以从同一个会话分支衍生两个不同方向的任务分别让 AI 给出实现方案再比对结果。Claude Code 的 fork 能力在这里很好用不过日常中我更常依赖的是基于同一份CLAUDE.md开两个新会话的方式这样对比更加干净不会互相污染上下文。4. 常见问题与排查技巧实录4.1 恢复之后上下文不完整的排查思路很多人遇到过这种情况执行claude --resume恢复某个会话后发现 AI 对之前的细节一问三不知好像恢复了个寂寞。第一反应先别怀疑工具问题。我的排查顺序是检查CLAUDE_CONFIG_DIR环境变量是否指向了另一个配置目录导致会话日志根本没有加载。检查当前工作目录和原会话启动目录是否一致跨目录恢复可能导致上下文加载失败。查看会话日志文件是否被清理或截断如果日志文件损坏或为空AI 自然无内容可恢复。确认恢复时是否误用了--new或其他标志有些命令组合不清时会加载新会话而不是恢复历史。第二注意恢复会话后的首条消息策略。如果 AI 需要一点时间重新定位上下文我通常先让它总结当前状态再做下一步操作。用/context斜杠命令可以快速查看当前这是什么会话、加载了多少上下文、还有什么信息在窗口里。这一步等于给人也做一次上下文体检。还有一种更隐蔽的情况会话本身有多个分支。Claude Code 支持从会话历史的某一点继续操作或分叉如果在交互式恢复列表里选错了分支看起来是同一个任务但后续内容和预期完全不同。遇到这种情况回到~/.claude/projects/目录按文件的修改时间和大小筛选能帮助定位真正想要的历史路径。4.2 切换 git 分支后会话内容错乱我踩过最典型的坑是在feature/login分支做完一版改动然后切到feature/payment分支顺手用--continue继续会话。结果 AI 还以 login 分支的文件内容作为基础读出来的代码、改的路径全是旧的整个会话处于精神分裂状态。教训很简单切换分支后永远不要直接续接旧会话。如果你非要在新分支上继续同一个任务的讨论也请先Claude Code中运行类似/clear的重置或直接开新会话并将上一次会话的关键结论写进CLAUDE.md再在新会话中引用。分支切换后有一个更好的做法先让 Claude Code 基于当前分支重新扫描代码结构生成一份分支摘要然后再开正式的工作会话。这样可以确保 AI 的世界观和当前 git 状态一致而不是停留在上一个分支的记忆里。4.3 会话日志中的敏感信息清理会话日志记录了一切这意味着.jsonl文件里可能包含数据库连接串、内网地址、密钥、客户数据等敏感内容。如果你在共用机器、持续集成环境或云端开发环境中使用 Claude Code这个问题尤其需要重视。我目前的清理方案分三层避免在会话中直接输入密钥。需要让 AI 知道密钥配置时通过引用配置文件的方式把密钥本身挡在对话之外。定期清理旧日志。只保留当前活跃任务的会话文件其余归档到一个不在默认扫描路径下的目录。在更敏感的环境中使用CLAUDE_CONFIG_DIR指向加密卷确保日志落盘即加密。还有一点要提醒Claude Code 可能会在需要时读取某些文件内容如果项目目录里有明显敏感的凭据文件一定要先通过权限系统限制或在命令前明确告诉它不要读取 .env 文件内容。这类边界设置不是多此一举而是会话管理里的安全底线。4.4 会话文件膨胀与磁盘占用的治理.jsonl日志文件会随着会话使用而膨胀。如果某个会话长时间没有清理而期间又有大量命令输出、文件读取几十 MB 并不罕见。大量这种日志堆积在~/.claude/projects/会让磁盘焦虑越来越明显。治理经验是三句话长会话要主动压缩能/compact就/compact压缩后的日志文件体积会显著下降。已完成任务的会话及时归档不需要保留完整日志的直接删除或移动到备份介质。用脚本定期统计会话文件大小超过阈值的列表发给自己人工判断清理。我写过一个简单统计命令逻辑就是用find列出所有会话日志的大小排序后人工检查find ~/.claude/projects -name *.jsonl -type f -exec ls -lh {} \; | sort -k5 -h | tail -20这种方式的输出一眼就能看出哪些会话异常庞大值得进一步处理。配合 crontab 定期执行基本能把日志膨胀问题控制在可接受范围。5. 关于会话管理的最后几条私人习惯会话管理做到最后拼的不是命令记得多熟而是有没有形成一套稳定的工作流。我自己现在的固定习惯是每个新需求从claude --new开始第一条消息写清楚目标和边界每完成一个阶段用--continue接着做绝不跨分支续接每到一个里程碑把结论写进CLAUDE.md然后放心清理旧会话日志。最终想强调一点Claude Code 的会话日志不是备份真正值得长期保留的资产永远是代码、文档、测试和CLAUDE.md。会话只是一个工作现场现场每天都可以重新布置但地基要打在仓库里。把会话管理当成软件开发流程的一部分之后你会发现 AI 编程工具从能用到好用之间差的就是这套主动管理的功夫。