用户求助多发生在失败之后
别名: 失败后求助 · 帮助是修复 · post-error help
概念解释
「帮助」在语音里很少是开场定向，多半是撞墙之后的呼救。失业金热线里，「人工 / 我该怎么说 / 帮助」出现在两轮没听懂之后，而不是唤醒后的第一句。人不是先学语法再办事，是先按对人说话的方式开口，失败了才承认需要说明书。把帮助做成欢迎词里的一项，会等来一个几乎没人在那时按的按钮。
机制
求助是一种修复发起，不是浏览。开口前用户以为自己知道怎么说；失败提供了反证，这才产生「我需要规则」的目标。所以帮助请求的时间戳会贴在识别失败、槽填不上、系统重复同一句之后，而不是贴在会话起点。把帮助内容按产品手册来写（能力总览、品牌故事），答的是一个此刻并不存在的定向问题；用户要的是「刚才那件事怎样才能说成系统听得见的」。
还有一层面子：主动先问帮助，等于承认不会用。失败之后再问，可以把责任推给刚才那次没听懂，面子成本更低。因此即使用户知道有帮助命令，也会把它留到已经难看的那一轮——设计若假定人们会先预习，会把帮助放在他们根本不会去的位置。
怎么研究
日志对齐：把「帮助 / 我该怎么说 / 人工」类请求的时间戳，对到本会话内最近一次识别失败、重复提示或空结果。因变量是帮助请求落在失败后第几轮、失败前主动请求的比例。对照可以看屏幕产品里帮助入口的点击是否也偏失败后（往往会，但语音更极端，因为没有可扫的入口提醒人提前点）。
实验室若一上来就说「你可以随时说帮助」，会抬高起点请求，不像现场。访谈里问「你会先问它能做什么吗」，答案偏向社会期待，不可替代时间戳。把帮助当成独立任务做可用性测试，测到的是说明书好不好读，不是人们何时去找它。
边界
真正的首次探索（刚拆箱、培训课）会把帮助前移，那是任务就是学习。儿童有时会把「帮助」当万能词，时间戳就不贴失败。帮助命令本身识别很差时，日志会低估求助——人已经在找，系统没记到。把所有失败后的「算了 / 转人工」都算成帮助请求，会混进放弃；放弃和求助要分开编码。
怎么落地
- 帮助内容按失败现场来写：默认回答「刚才你在办的那件事可以怎么说」，而不是从产品目录读起。
- 失败轮主动提供一条短帮助入口（「可以说『我该怎么说』」），不要指望人在开场记住这个命令。
- 帮助请求发生时，带上当前任务和最近失败的槽，不要把用户丢回总菜单。
- 验证：画帮助请求相对最近失败的时间差直方图。若质量不在失败后一两轮，检查是不是入口太晚或命令没被识别。失败前的帮助接近零是预期，不要因此把帮助按钮做进欢迎词并宣称「有帮助」。