`claude -c` — 继续最近的对话

接着昨天那半件事

昨天让它重构支付模块，改到一半你下班了。今天最重要的不是重新解释背景，而是把上一段对话接上。claude -c 做的就是这件事：恢复当前项目里最近一次会话，连同当时读过的内容、定下的方案、否掉的写法一起带回来。

先弄清它恢复什么：对话记录，不是工作区。代码可能已被你或同事改过，依赖可能升级。所以恢复之后的第一句话，应该用来对齐现状，而不是直接派活。

恢复后的三步

1. 看工作区。git status 加 git diff --stat，确认上次停在哪。
2. 让它重读关键文件。磁盘上的版本可能和对话里记得的不一样。
3. 重申目标。一句话说清今天做到哪一步，别让它沿着昨天的计划闷头跑。

示例开场：

接着上次的进度。先重读 src/pay 下改过的两个文件，说明它们和对话里记得的版本有什么差异，然后等我确认下一步。

这比只说「继续」稳。「继续」两个字会让它沿用旧假设，而旧假设可能已经过期。

下面两组开场白，差别值得体会：

差的开场	好的开场
继续	先读改动过的文件，说明当前状态，再等我确认下一步
接着改那个函数	上次停在第 2 步；先给我看第 3 步的做法，不要直接写
把剩下的做完	列出剩余事项和验收标准，我挑一项你现在就做

好的开场都做了同一件事：把「你以为的现状」换成「可以核对的事实」。

跨天的任务，别只靠记忆

一条会话连着用几天，上下文会越来越重，早先的结论也可能被后来的改动推翻。更稳的做法是每天收工前让它写一份简短交接：改了什么、卡在哪、下一步做什么，存进仓库或任务系统。第二天新开一条会话，先读这份交接，再决定要不要续旧对话。

对话适合承载推理过程，文档适合承载结论。两者分开，换机器、换人接手都不会断。

什么该续，什么该断

情况	做法	原因
同一任务做到一半	claude -c	省去重复交代
方案已被否决	新开会话	旧结论会拖住判断
话题结束、上下文很长	新开，或先压缩	每轮都带旧内容，慢且贵
问一句无关的小问题	新开会话	不必污染主线

判断标准只有一条：旧上下文还有没有用。有用就续，没用就断。别因为懒得重述，把两个不相干的任务塞进同一条对话，后面找结论会很难。

带上新指令一起恢复

恢复的同时可以直接给今天的任务：

claude -c "先跑现有测试，把失败项列出来，不要改代码"

它会在旧上下文里执行这句新指令。适合你清楚下一步要做什么；如果下一步需要它先汇报现状，就把话说成「先说明，再动手」。指令写得越像验收单，恢复后的第一轮就越少返工：做什么、改哪里、什么算完成，三样齐了再发。

它管不到的地方

• 按目录认人。 最近一次会话通常和当前项目目录绑定。换目录启动，续到的未必是你想的那条。
• 只认最近一条。 同时开着几个任务时，「最近」随时会变。要精确回到某条，得用会话编号，下一节讲。
• 恢复不等于回滚。 对话回来了，文件不会。上次改坏的代码还在工作区，该还原就先还原。
• 旧结论一起回来。 包括当时判断错的部分。发现方向不对，明确说「之前那个结论作废」，别指望它自己推翻。

还有一条经验：恢复后别急着批准大改动。先让它用只读方式复述计划，你确认无误再放行。想先了解它的定位，看这个命令行工具是什么。

把 -c 当成接着上次的进度条，而不是时光机：上下文能回来，状态得自己核对。同时推进多个任务时，光靠「最近一次」不够，下一节讲按编号精确恢复：按 ID 恢复会话。