H3.02.3error next action in the recovery flow设计研究
说明如何解决
别名: 恢复动作 · how to fix · 下一步
概念解释
结果和原因齐了之后，恢复流程必须给出现在能做的那一步：改这个字段、换一种支付、查看订单状态、带着编号找人。这一步要是界面上的动作，而不是一句「请重试」的劝告。这条只谈把人送回任务的出口，不谈原因怎么写，也不谈错误码给客服看。
机制
失败后的目标不是理解系统，是把任务重新接上。工作记忆已经被结果句占满，人没有余量去搜索设置页或回想该找谁。把下一步做成就近的控件，等于把恢复从回忆改成识别：按钮上写「修改有效期」，焦点回到那个字段。动作必须与原因匹配——规则错误指向改输入，系统故障指向查询或等待，权限不足指向谁能批。错误的出口比没有出口更伤：对已经扣款的支付再放「立即再付」，会把恢复变成第二次损失。无法恢复时，诚实的下一步是保存现场和升级，而不是假装有修法。
怎么研究
同一失败下比较三种出口：只有文案劝告、一个可点的动作、多个未标明差异的动作。
自变量：动作是否出现在错误表面、动作是否真能完成、是否与注入的原因匹配。 因变量：首次选对恢复路径的比例、无效动作次数、完成原任务的时间、把不可恢复当成可重试的比例。
实验室里的按钮往往都被做成能用的，会高估「有动作就够」。要掺入不可用或会重复扣款的动作，看文案能不能拦住。
边界
下一步必须是当前角色做得到的。给普通用户「请联系管理员」却不提供可复制的上下文，等于把出口建在别人家里。自动重试正在进行时，人为动作要让位于取消和等待，而不是再叠一个「重试」。法律或风控禁止的路径不能做成绿色按钮。多个合法出口时要标差异（改卡 / 换余额 / 放弃），不要并列三个「确定」。
怎么落地
- 每条错误绑定一个首选动作，放在错误表面里，文案与按钮同义；次选动作降为文字链接。
- 动作可执行性与权限、幂等性一起测：会重复提交的，按钮改成「查看结果」而不是再提交。
- 无法当场恢复时，动作改为「保留草稿」「复制说明给支持」，并写清暂时不能完成的部分。
- 验证：故障演练里按下错误上的每一个按钮，记录是否回到原任务、是否造成第二次副作用。按下后原地打转或账上多一笔，出口就设计错了。