H3.02.2error cause that selects the recovery branch设计研究
说明为什么发生
别名: 错误原因 · why it failed · 诊断信息
概念解释
人已经知道失败成立之后，下一句要回答为什么发生：是输入不满足规则、余额不够、对方拒绝、还是服务端自己挂了。原因的作用是给恢复选路，不是写一篇故障分析。不知道原因时要标明未知，不能拿「网络不稳定」当万能填空。这条不管结果怎么陈述，也不管按钮上写什么修法。
机制
同一结果对应多条完全不同的恢复分支。订单没支付成功，可能是卡被拒、额度不足、商户侧超时、或前端没等到回包。没有原因，人会执行默认分支——再点一次支付——于是在非幂等链路上制造重复扣款，或在规则错误上空转。原因把失败从「一种红」拆成可分派的类别。安全与隐私会限制能说多深，但分派仍需要足够的粒度：改输入、换方式、等系统、找人工，四选一必须能选出来。编造的原因比沉默更糟，因为它把人送上确定错误的那条路。
怎么研究
把同一「提交失败」做成四种真实原因（校验、权限、远端拒绝、未知），每组只给结果句或结果加原因。
自变量：原因类别是否披露、披露是否与注入的故障一致、未知是否被写成具体猜测。 因变量：选择的恢复动作是否匹配真因、无效重试次数、向错误对象修改的次数、把未知当网络问题处理的比例。
不要在实验指导里提示「请根据原因选择下一步」，那会高估原因句的作用。让主任务继续，看人自发走哪条路。
边界
原因一旦可被攻击者利用（还剩几次尝试、风控阈值、用户是否存在），就要停在「这次不能完成」加安全的下一步，不能为了诊断完整性泄密。多原因叠加时，先给挡住任务的那一个，不要开清单。内部服务名、异常类名不是原因：它们不能帮人在四条分支里做选择。自动恢复且用户无感知的故障，不必中途插入原因句。
怎么落地
- 为每类失败准备一张分派表：校验 / 权限 / 余额或配额 / 对方拒绝 / 系统故障 / 未知，每类对应不同的下一步，禁止共用一句「请稍后重试」。
- 原因未知时写「原因还不确定」，同时给出仍安全的动作（查状态、保留草稿、带编号求助），不要补一句听起来具体的猜测。
- 原因只写到能选路的粒度：「发卡行拒绝了这张卡」够了，不必贴拒绝码的内部含义。
- 验证：把四种故障轮流打进同一界面，看用户第一步是否分别走向改字段、换方式、等待/查询、求助。四条路走到同一按钮，原因就没有在分派。