D1.16.4Delayed error discovery设计研究
无法核对的反馈在出错时难以被用户及时发现
别名: unverifiable feedback · silent failure · error detectability · 反馈可核对性
概念解释
错误发现延迟（delayed error discovery）发生在系统的反馈没有留下可检查的结果证据时：操作实际失败、部分完成、作用到错误对象，用户却从成功提示中继续推进任务，直到后续依赖失败、他人投诉或数据对不上才察觉。问题不只是有没有错误提示，也不只是预防错误；即使不可避免的失败发生，界面仍应让用户有机会在错误影响扩大前看出「结果与预期不一致」。
机制
许多错误并不以明确的失败响应出现。网络重试可能造成重复写入，权限变化可能使发布只在草稿层成功，异步任务可能在用户离开后失败；而一个笼统的成功 toast 把系统的局部回应伪装成最终结果。若缺少对象状态、范围、时间和执行记录，用户没有可用的异常检测信号，只能依据乐观假设继续操作。错误被下游发现时，因果线索已淡化，修复成本和归责难度都会上升。
怎么研究
为关键流程植入现实的异常：部分收件人未收到、后台任务中途失败、版本冲突、延迟同步或对象错配。比较不同反馈方案下从错误发生到首次发现的时间、错误传播到多少后续步骤、是否重复提交，以及参与者能否定位受影响对象和范围。观察不应只在任务结束后提问；记录用户自然何时核对、何时出现怀疑、会参考哪些证据。对于协作流程，还要测试错误由操作者、接收者还是管理员先发现。
边界
让错误可发现并不要求每一个轻微波动都弹出警报。短暂、可自动恢复且没有用户后果的技术重试，通常应以稳定的最终状态为主，避免制造噪声。相反，高后果、不可逆、对外传播或需要用户采取补救行动的结果，不能仅靠乐观确认。检测信息也需可行动：只显示错误码而没有对象、影响范围或下一步，可能让发现变成新的停滞。
怎么落地
- 为重要动作保留可见的最终状态和执行记录，并把「已请求」与「已生效」分开，避免中间确认掩盖最终失败。
- 在对象层标出异常、部分完成、冲突或过期状态；用受影响数量和具体对象说明范围，避免只显示抽象的红点。
- 将失败和不确定状态接入用户仍会访问的地方，如任务列表、文档页、订单页或活动记录，而不是只在瞬时通知中出现一次。
- 用恢复演练检验设计：从植入错误开始，测量用户是否能发现、理解影响、选择安全补救并核对修复结果。