---
title: "`claude -c` — 继续最近的对话"
description: "把昨天没做完的任务接起来：恢复的是对话而不是文件，先核对工作区、再重申目标，分清哪些情况该续、哪些该重新开一条会话。"
updated: 2026-11-13
canonical: https://docai.cc/learn/continue-last-conversation/
markdown_mirror: https://docai.cc/learn/continue-last-conversation.md
---
## 接着昨天那半件事

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

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

## 恢复后的三步

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

示例开场：

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

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

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

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

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

## 跨天的任务，别只靠记忆

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

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

## 什么该续，什么该断

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

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

## 带上新指令一起恢复

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

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

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

## 它管不到的地方

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

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

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