D1.13.4Phase-specific stall feedback设计研究
某阶段卡住时需要指出具体阶段而非笼统等待
别名: stuck phase · progress stall · diagnostic feedback · task recovery
概念解释
阶段特定的停滞反馈（phase-specific stall feedback）是在任务某一阶段超出正常等待范围或无法继续时，明确说明卡在哪项工作、已完成什么、下一步可做什么，而不是只显示「请稍候」或持续旋转。用户需要区分上传慢、验证失败、等待审批、网络断开和系统异常，因为这些情况的等待价值、恢复方式和责任方不同。笼统等待把所有问题压成同一个黑箱，既无法建立信任，也不能帮助行动。
机制
停滞破坏的不只是速度，还包括对过程的可解释性。若用户只看到总进度不动，无法判断应该继续等、重试、检查输入、切换网络、联系支持还是取消；不确定性会诱发刷新、重复提交和放弃。阶段名称和状态证据为异常提供定位，将错误从「系统坏了」转成可诊断的工作节点。即使暂时没有自动修复方案，知道具体卡点也能防止用户做出会扩大问题的错误操作。
怎么研究
在上传、校验、服务端处理、审核和发布等不同阶段分别注入延迟、断连、拒绝和可恢复失败，比较笼统等待与阶段特定反馈下的等待决策、错误恢复、重复提交和支持请求质量。记录用户是否能准确说出当前卡点与可用选项，及是否将异常归因于错误对象。只测错误是否被展示不够；要测试信息能否帮助用户采取正确且安全的下一步。
边界
不能在诊断尚不确定时编造精确原因。若系统只能知道「尚未收到下一阶段信号」，应诚实说明正在等待什么，并提供安全的检查或退出方式。也不必向所有用户暴露完整技术栈；阶段标签应保留用户对象和工作意义，详细错误码可放在展开层。短暂正常波动不应频繁触发警报，否则会制造焦虑和通知疲劳。
怎么落地
- 为每个阶段定义正常时长范围、超时检测、可见状态证据和转换到停滞/失败的条件，而非让总进度永久静止。
- 停滞时显示当前阶段、已完成工作、可能等待的外部条件及可选动作，如继续等待、重试、检查连接、保存后离开或联系支持。
- 将操作限制与风险说明清楚：重试是否安全、取消会丢什么、离开后任务是否继续，避免用户靠猜测恢复。
- 通过故障演练验收：用户应能定位卡点、选择正确恢复而不重复产生副作用，并为支持人员提供有用的阶段信息。