我不想再用一个转圈图标解释所有等待

做普通 CRUD 时，我很少认真设计“等待”。请求发出去，按钮进入 loading，接口回来后更新页面，最多几秒钟。

做 AI 工作流后，等待突然成了产品的一大部分。小说转剧本要经历章节切分、摘要、角色与地点抽取、场景大纲、逐场生成和校验。这个过程可能需要几分钟。一个旋转的圆圈不再是在表达状态，而是在掩盖状态。

用户真正难受的不是慢，而是不知道发生了什么

最早的版本里，长任务提交后页面只能等。后端其实还在工作，但用户看不到。他不知道是模型正在生成，消息还在队列里，还是服务已经报错。这三种情况在界面上长得一模一样。

我后来接入 SSE，把任务提交、资产分析、场景生成、校验完成等事件推到前端。它没有让模型更快，却明显改变了体验。等待从一段空白时间，变成了一条能够理解的过程。

对于无法精确估时的 AI 任务，写一个从 0 缓慢爬到 99 的假进度条，可能比转圈更糟。用户需要的不是虚构的精度，而是几件可靠的事实：当前在做什么、已经产出了什么、哪一步失败了、失败后是否需要重来。

中间结果应该能被看见

AI 工作流经常被设计成一根管道：输入进去，最终结果出来。但很多任务的中间产物本身就有价值。

小说还没全部转成剧本时，已经抽取出的角色、地点和故事事件可以先展示；Offer 的实时研究还没结束时，基于用户明确输入的基线判断可以先返回；摘要尚未全部完成时，已经处理的来源可以先让用户检查。

这不只是前端优化，它会反过来要求后端改变：任务要可分段，状态要可持久化，步骤要能重试，最终结果不能是唯一可用的结果。

等待甚至可以成为一次共同编辑

我还有一个没验证的想法：长任务不一定只能让用户旁观。

当系统完成角色抽取后，用户可以先纠正角色关系；生成场景大纲后，可以删掉不需要的场景，再继续生成对白。这样等待就不再是“AI 工作，人发呆”，而是人和系统交替推进。

代价也很明显。工作流会从线性管道变成带版本的状态机，中途修改可能让后续缓存失效，界面也更难解释。但它可能比单纯追求更快的模型更值得做。

现在我看到 loading 图标时，会先问一句：这段等待真的没有信息可以告诉用户吗？很多时候，不是没有，只是系统还没有把自己的工作讲清楚。