已接收表示系统识别到操作，已产生表示结果已生成
别名: input acknowledgement · completion feedback · pending state · asynchronous operation
概念解释
接收确认与完成反馈（acknowledgement versus completion）区分两个不同事实：已接收表示系统识别并接纳了用户的输入；已产生表示请求经过处理，用户可期待的结果已经真实存在。轻触按钮后的按压态、请求进入队列或表单本地保存可构成接收确认；邮件送达、文件可下载、数据出现在目标列表中才是完成。同步小操作中两者可能几乎重合，但在网络、排队、计算、审核和跨设备同步中，必须分开表达。
机制
异步链路包含多个可失败、可延迟的阶段。输入到达客户端、到达服务端、被验证、开始执行、提交结果与结果可见，并不等价。若用户只得到「成功」字样，会把其中任意早期阶段误解为最终状态；若只得到接收确认，又不知道是否仍需等待。清晰的阶段划分让因果感在早期成立，同时把结果承诺留到可核对的时刻，避免重复提交和错误决策。
怎么研究
可在相同任务中分别呈现含混的成功提示、明确的已接收、处理中和已完成状态，测量用户对当前阶段的判断、重复操作、等待策略、错误发现与信任。应故意插入服务端拒绝、网络中断、延迟完成和跨设备延迟，不能只评估顺利路径。访谈问题要具体到「现在能否关闭页面」「对方现在能否看到结果」「任务失败会在哪里出现」，以检验用户是否真正区分两个状态。
边界
极短、可逆且结果直接出现在操作点的任务不需要拆出冗余阶段；额外提示会拖慢节奏。反之，高后果或不可逆操作即使后端很快，也不应以接收信号取代可验证结果。某些外部系统无法给出最终完成保证，此时界面必须诚实表述边界，例如「已交给服务处理」而不是暗示对方已收到。阶段越多也不一定越好，应保留对用户决策有差异的节点。
怎么落地
- 为异步流程定义 received、processing、completed、failed 和取消等语义状态，并规定每个状态的真实技术证据。
- 让接收确认紧贴操作、轻量且快速；只在结果可核对时使用完成语言，并提供查看结果的入口。
- 对离开页面、后台执行和跨端任务说明哪一阶段会继续、何时通知、在哪里追踪，避免用户以为接收即无后续责任。
- 在故障注入测试中要求用户判断当前可做什么；把「我以为已经完成」或「我不知道要不要等」作为状态混淆证据。