异步AI生成等待体验：从转圈到任务式设计

一张照片输入，一段视频输出，中间大约十分钟的空白。这十分钟，往往是AI产品流失用户的地方。Burning Bridges Studio创始人分享了他们如何将等待设计成产品的一部分，而非一个旋转的加载图标。这些模式适用于任何慢速AI任务——图像放大、声音克隆、长文写作，远不止视频生成。

为什么慢任务需要重新设计等待

一个持续十分钟的HTTP请求极其脆弱：代理超时、手机休眠、标签页关闭，用户根本不知道任务是否还在运行。Burning Bridges Studio的做法是把工作建模为一条持久化的任务记录，而非一个挂起的请求。

type GenerationTask = {
  id: string;
  status: "queued" | "running" | "ready" | "failed";
  createdAt: string;
  updatedAt: string;
  outputUrl?: string; // only when ready
  errorCode?: string; // only when failed
};

这带来两个直接好处：UI可以轮询或订阅状态，而不是维持长连接；用户关闭标签页后，任务仍属于账户而非页面，之后可以找回。如果产品按次收费，把任务ID关联到扣费记录上——这个外键让退款、客服和重复检测成为可能。

要点在于，任务记录是比请求更可靠的抽象。请求会断，任务不会。

幂等性（Idempotency） 是指一个操作执行一次与执行多次产生相同的结果。在慢速 AI 任务的轮询场景中，幂等意味着每一次状态查询都不会改变任务状态或触发新的生成，因此客户端可以安全地高频刷新。反之，如果刷新页面就创建一个新任务，不仅浪费计算资源，还可能造成重复扣费。实现幂等通常需要服务端为每个任务分配唯一 ID，并将状态查询设计为只读操作；对于提交请求，则可通过客户端生成的幂等键（idempotency key）来识别重复提交，确保同一请求只被处理一次。

诚实面对时间：不要假进度条

永远不要显示虚假的百分比。一个无意义的移动进度条比一句朴素的说明更糟，因为用户会围绕它做计划。

更有效的做法是：用平实语言说明预期时长（“大约10分钟，高峰期可能更久”）；展示当前阶段而非数字（排队中、生成中、已完成）；显示任务最后更新时间，让停滞可见而非神秘；保持轮询廉价且幂等，刷新绝不创建第二个任务。

诚实版本设定一个较低预期，通常会被超越；乐观版本设定一个较高预期，通常会被辜负。这个取舍在慢任务场景下尤其关键。

轮询（Polling）与订阅（Subscription） 是客户端获取异步任务状态的两种常见模式。轮询是客户端按固定间隔（如每 5 秒）主动向服务器查询任务状态，实现简单、兼容性好，但会产生大量无效请求，且存在延迟。订阅则通过 WebSocket、Server-Sent Events 或推送通知，由服务器在状态变化时主动通知客户端，实时性高、请求少，但需要维护长连接，对移动端和弱网环境不够友好。文章建议“保持轮询廉价且幂等”，正是考虑到慢任务可能持续十分钟以上，长连接容易中断，而轻量轮询配合任务持久化能提供更稳健的体验。实际设计中，常采用轮询为主、辅以退避策略（逐渐拉长间隔）来平衡实时性与服务器负载。

为第二次访问而设计

十分钟里的大部分时间发生在屏幕之外。这是常态，不是边缘情况。

UI需要回答：用户能否从列表中而非书签找到任务？列表是否展示足够信息以识别所用照片？能否在不联系客服的情况下删除已完成或失败的任务？空状态是否解释了这里会出现什么？

任务列表还自然承载了失败解释。“失败”没有原因是客服工单，“失败——积分已退回”是一个已解决的时刻。

关于失败契约，原文给出了三条明确规则：

• 任务失败时，积分或配额自动退回。
• 任务保持可见并附明确原因，而非悄然消失。
• 重试创建新任务，而非修改失败任务。

第三点对审计很重要。如果失败任务可以被编辑成成功任务，你就丢失了实际发生什么的记录。慢任务失败率高于快任务，因为活动部件更多、可出错的窗口更长，失败契约必须在发布前定好。

交付文件，而非围墙花园

对于任何有可见输出的产品，让用户能把结果带走。在Burning Bridges Studio的案例中，结果是一个15秒、16:9的MP4，用户预览后下载。预览先于下载很重要：它让人在不离开产品的情况下决定结果是否值得保留。

如果结果只能在应用内查看，你就是在和截图竞争。一个可下载的文件是个小功能，却改变了产品的传播方式。

处理中断的提交

“任务已创建”和“收到响应”之间存在一个棘手情况：如果服务器接受工作后网络中断，客户端无法判断是否该重试。两条规则防止双重扣费：给客户端一个短暂的恢复窗口（原文使用20分钟），期间它可以查找现有任务而非重新提交；明确告知用户在恢复运行期间不要重新提交。

这需要跟踪少量状态，却能避免最昂贵的客服类别：“我付了两次，只得到一个视频。”

恢复窗口（Recovery Window） 是客户端在提交任务后等待响应的一个短暂时间段。如果网络中断导致客户端未收到“任务已创建”的确认，它可以在窗口期内用相同的请求标识（如客户端生成的 UUID）向服务器查询是否已存在对应任务，而不是立即重新提交。这要求服务器端记录每个提交请求的标识与任务 ID 的映射，并在窗口期内保留该映射。窗口期过后，若仍未确认，则可安全地视为任务未创建，允许用户重新提交。恢复窗口的长度需权衡用户体验与资源占用：太短则无法覆盖常见网络抖动，太长则用户等待过久且服务器需保留更多临时状态。原文使用 20 分钟，正是基于视频生成任务的平均耗时和用户耐心做出的产品决策。

发布前检查清单

上线慢速AI功能前，确认：工作以显式状态的任务存储；预期时长被诚实说明；任务在页面刷新后存活且可在某处找到；失败自动退回用户积分或配额；结果可预览可下载；中断的提交不会创建重复扣费。

这些都不新颖。它们只是在模型演示一次成功时容易被跳过——而演示从不等待十分钟。

原文作者声明：他构建了Burning Bridges Studio，因此描述的是自己的产品而非独立评测。文中十分钟和15秒为产品声明的估计值，非实测基准。