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