AI 功能的状态与恢复：会话中断了怎么办

用户会关页面、断网、切 App。本文给出三类状态（会话/任务/草稿）的分开处理与恢复方式、恢复时要告诉用户什么、五个容易做错的点、该测的四个指标与一个最小实现。

会话中断是常态

AI 长任务里，用户会关页面、会断网、会切到别的 App ✔。**中断是常态，不是异常** ✔。

如果你的产品在中断后"什么都丢了"，用户会认为它不可靠 ✔（见长任务可恢复那篇的同理 ✔）。

**要做的是"状态与恢复"** ✔：随时可中断、回来能接上 ✔。

| 状态 | 存哪 | 恢复方式 |

|---|---|---|

| **会话状态**（当前对话、上下文） | 服务端 + 本地缓存 ✔ | 重新打开自动接上 ✔ |

| **任务状态**（长任务进度） | 服务端（检查点 ✔） | 从断点续跑 ✔ |

| **输入草稿**（用户没提交的内容） | 本地（localStorage ✔） | 打开时还原 ✔ |

**关键**：三类要**分开存** ✗ ✔ —— 把草稿与会话混在一起，会导致"没提交的内容也进入上下文" ✗。

**明确提示**（"已恢复上次的会话，共 12 轮" ✔）；

**标出断点**（"上次进行到第 3 步" ✔）；

**给出选择**（继续 / 重新开始 / 导出已有结果 ✔）。

**忌讳**：静默恢复 ✗（用户不知道发生了什么 ✔）或静默清空 ✗（更糟 ✔）。

1. **只在内存里存状态** ✗ → 服务重启就丢 ✔（见长任务那篇 ✔）；

2. **草稿不落地** ✗ → 刷新即丢 ✔（低成本，高感知 ✔）；

3. **恢复后重复执行有副作用的步骤** ✗ → 必须靠幂等键 ✔；

4. **恢复时把已过期的上下文原样带上** ✗ → 可能引入过时信息 ✔（见版本那篇 ✔）；

5. **多设备并发** ✗ → 同一会话两处同时改 ✔ → 需要版本/冲突策略 ✔（至少给"另一处已更新"提示 ✔）。

**中断恢复成功率**（关页面再回来，能否接上 ✔）；

**草稿还原率** ✔；

**重复副作用次数**（应为 0 ✔ —— 用幂等键保证 ✔）；

**恢复耗时** ✔（别让用户等太久 ✔）。

```

① 每轮结束把会话与任务检查点写入服务端（带版本号 ✔）

② 输入框内容节流写 localStorage ✔

③ 打开页面时：拉会话 → 若有未完成任务，提示"继续/重新开始" ✔

④ 继续时从最后一个检查点续跑（幂等键保证不重复副作用 ✔）

```

> 用户**拔网线 5 分钟再回来** ✔，需要重新输入多少内容 ✔？

> 如果需要重打一遍，说明状态与恢复没做 ✗。