混淆两者会让用户误以为耗时任务已经完成
别名: false completion · premature success · asynchronous feedback · completion illusion
概念解释
过早完成信念（premature completion belief）发生在系统把「已收到请求」或「已开始处理」用完成性语言、对勾或成功样式表达，用户因而以为耗时任务已经产生了结果。对上传、发布、支付、生成、同步和审核而言，这种误解会让人离开页面、通知他人、执行依赖步骤或停止检查，随后才发现任务仍在排队、失败或结果尚未对外可见。它不是文案小问题，而是系统状态被错误承诺。
机制
人会把高确定性的视觉符号——绿色、对勾、「成功」「已发送」——当作任务结束的证据，而不会自行推断隐藏的异步链路。一次过早的成功提示还会关闭用户的监控行为：他们不再查看进度、保留输入或寻找错误。任务后续失败时，责任在用户心中会显得无端且难以恢复，因为系统此前已经宣告完成。状态语义若与真实承诺点错位，越即时、越醒目的反馈反而越会放大伤害。
怎么研究
为同一任务设计接收即成功、明确处理中、完成后成功三种表达，并在延迟、拒绝、网络断开和后台完成条件下比较用户是否离开、是否执行依赖动作、是否能找到失败及是否保留恢复材料。询问应针对现实后果，例如「现在可以通知客户吗」「可以关闭窗口吗」「结果在哪里验证」。仅测主观满意度会遗漏最危险的误信行为，因为错误提示往往让等待体验看起来更轻快。
边界
不是所有即时反馈都危险。若本地操作已经原子地完成，或结果可立刻在对象上验证，完成表达是诚实的。相反，外部投递、后台处理或依赖第三方的结果可能永远无法被本系统最终保证，此时不应用模糊的成功绕过不确定性。过度保守也会伤害体验：无需把每个极短步骤都展开成复杂流程；应围绕会改变用户下一步决定的真实风险拆分状态。
怎么落地
- 审核所有成功图标、绿色状态和完成动词，逐项确认它们对应的是接收、开始、内部完成还是外部可见结果。
- 对未完成任务使用明确的 pending/processing 语言，并保留进度、结果位置、失败出口和完成通知的可见路径。
- 在用户可能离开、依赖或对外承诺的节点前，提供可核对完成证据，而不让短暂 toast 充当最终证明。
- 通过故障注入观察用户是否过早关闭、重复提交或提前继续后续流程；这些行为比点击率更能揭示完成状态的误导。