会话中断是常态
AI 长任务里，用户会关页面、会断网、会切到别的 App ✔。中断是常态，不是异常 ✔。
如果你的产品在中断后"什么都丢了"，用户会认为它不可靠 ✔（见长任务可恢复那篇的同理 ✔）。
要做的是"状态与恢复" ✔：随时可中断、回来能接上 ✔。
一、三类状态要分别处理
| 状态 | 存哪 | 恢复方式 |
|---|---|---|
| 会话状态（当前对话、上下文） | 服务端 + 本地缓存 ✔ | 重新打开自动接上 ✔ |
| 任务状态（长任务进度） | 服务端（检查点 ✔） | 从断点续跑 ✔ |
| 输入草稿（用户没提交的内容） | 本地（localStorage ✔） | 打开时还原 ✔ |
关键：三类要分开存 ✗ ✔ —— 把草稿与会话混在一起，会导致"没提交的内容也进入上下文" ✗。
二、恢复时要告诉用户"接上了什么"
- 明确提示（"已恢复上次的会话，共 12 轮" ✔）；
- 标出断点（"上次进行到第 3 步" ✔）；
- 给出选择（继续 / 重新开始 / 导出已有结果 ✔）。
忌讳：静默恢复 ✗（用户不知道发生了什么 ✔）或静默清空 ✗（更糟 ✔）。
三、五个容易做错的点
- 只在内存里存状态 ✗ → 服务重启就丢 ✔（见长任务那篇 ✔）；
- 草稿不落地 ✗ → 刷新即丢 ✔（低成本，高感知 ✔）；
- 恢复后重复执行有副作用的步骤 ✗ → 必须靠幂等键 ✔；
- 恢复时把已过期的上下文原样带上 ✗ → 可能引入过时信息 ✔（见版本那篇 ✔）；
- 多设备并发 ✗ → 同一会话两处同时改 ✔ → 需要版本/冲突策略 ✔（至少给"另一处已更新"提示 ✔）。
四、该测什么
- 中断恢复成功率（关页面再回来，能否接上 ✔）；
- 草稿还原率 ✔；
- 重复副作用次数（应为 0 ✔ —— 用幂等键保证 ✔）；
- 恢复耗时 ✔（别让用户等太久 ✔）。
五、一个最小实现
① 每轮结束把会话与任务检查点写入服务端（带版本号 ✔）
② 输入框内容节流写 localStorage ✔
③ 打开页面时：拉会话 → 若有未完成任务，提示"继续/重新开始" ✔
④ 继续时从最后一个检查点续跑（幂等键保证不重复副作用 ✔）
一条判据
用户拔网线 5 分钟再回来 ✔，需要重新输入多少内容 ✔？
如果需要重打一遍，说明状态与恢复没做 ✗。