L4.13.2escalation states step and need设计研究
求助需说明卡在哪一步与需要什么，仅报告失败无法被处理
别名: 求助要带步骤和缺口 · actionable escalation · 不要只说失败了
概念解释
上报若只写「任务失败」，人拿到的是一个状态名，不是一份可动手的材料。求助要写出步骤和缺口（escalation states step and need）：卡在计划的哪一拍、缺的是权限、对象、判断还是外部系统、人接上手之后第一件要做什么。
「失败了，请处理」把考古工作交给接管者。移交要因果；求助是失败场景下的那份因果。
机制
处理失败是一次微型接管。接管要状态和「不要再做什么」。失败上报如果只有错误码，人要自己去翻过程视图、猜缺什么、再试一次已经失败的调用。时间花在重建，不花在缺口上。缺口写成可行动项（「需要客户 B 的地址字段」「需要写权限」「需要人决定发不发给外部」），重建被压成核对。
仅报告失败还会鼓励人按「再跑一次」来响应，因为材料不够支持别的动作。重试而不上报是代理侧的问题；人侧被空报告逼着重试，是同一缺口的镜像。
怎么研究
同一失败，比较：只给失败、给错误码、给步骤+缺口+建议的第一动作。因变量：从上报到正确处理的时间、是否重复已失败调用、探询能否复述缺口。自变量：缺口类型（权限 / 缺失 / 判断）、过程视图是否同时打开。
正确处理指补上缺口，不是把任务标成已读。重复已失败调用算求助不可处理。
边界
步骤记录本身若被扔掉，求助再写也指不到那一拍——过程要留痕。部分完成的清理项是另一份材料，不要和「需要什么才能继续」混成一句。上报得晚，历史会变长，材料更要压缩成缺口，而不是把长历史贴上去充数。
怎么落地
- 上报模板固定三栏：哪一步、缺什么、建议的人侧第一动作。缺一栏不得把任务丢进人的队列。
- 建议的第一动作必须是人能做的（给权限、补字段、否决），不能是「请检查系统」。
- 验证：把上报发给没看过过程的人。若第一件事是重跑或翻日志，材料就还不可处理。三栏齐了，第一件事应是补那个缺口。