流程需覆盖成功、失败与中途退出
别名: 成功失败退出 · happy path only · task terminal states
概念解释
一条对话技能要能结束，结束只有三类：做成了、做不成、人中途走了。只把「叫到车」画完，不等于流程写完——附近没车、支付被拒、用户报完目的地却挂断，都是同样真实的终点。这里谈的是整段任务有没有三种收束，不是某一个提问节点有没有退路，也不是失败时那句话怎么措辞。
机制
设计者从系统目标往回画：目标达成的那条链最清楚，所以图上只剩成功。失败来自世界（库存、网络、规则），中途退出来自用户（不耐烦、被打断、改主意），这两类事件不在「任务怎么做成」的心理模型里，就进不了图。语音里它们仍要占一轮：系统必须开口或收束，否则会话停在半空，用户以为还在办，后台以为已经完。
三类终点的下一步不同。成功要交付结果并让人听见做完了；失败要说明卡在哪一类原因、是否还有替代；中途退出要把已收集的槽位作废或短暂停住，不能继续对空房间追问。把后两类都并进「未完成」一个桶，验收时只会测成功，现场日志里大量会话会落在图外。
怎么研究
把同一技能的对话日志按终点类型归档，而不是按是否「任务成功」二分。自变量是技能是否在规格里写明三种终点；因变量是落在规格外终点的会话占比、用户在失败后是否还尝试同一技能、中途挂断发生在第几轮。
实验室可做故障注入：Wizard-of-Oz 或已上线技能里，按脚本制造「无结果」「接口失败」，以及在槽填到一半时停止应答。看系统是否给出可识别的失败收束，还是重复成功路径上的追问。不要只用完成率：完成率把退出算成噪声，而这正是要覆盖的第三类终点。
边界
单轮短命令（定十分钟闹钟）的失败和退出会叠在同一声「没听清」里，三类终点仍然存在，只是挤在一两轮，不必为每种各画一条长链。开放闲聊没有单一任务成功标准，硬套三种终点会造假。法规要求必须读完的披露，用户中途说话也不许跳过，退出被推迟到披露之后。把插入的另一件小事当成「中途退出」是另一类现象：那是任务被挂起，不是本任务被放弃。
怎么落地
- 每个技能写三句终端话术：做成了说什么、做不成说什么、人要走时说什么。做不成再拆一刀：世界原因（没车）对系统原因（没听清），两类不要共用一句「出错了」。
- 验收表加两列：强制失败一次、强制在中段停止应答一次。两次若仍走到成功提示或无限追问，覆盖没收齐。
- 中途退出不要默默清空又不吭声；至少承认停办，已填槽位是丢还是留要写死。
- 验证：抽最近一周日志，把每条会话标成成功 / 失败 / 退出 / 图外。图外超过小比例，就补终点，而不是再优化成功链。