用户放弃任务需要有明确出口
别名: 对话里的取消 · 放弃要能走出去 · cancel as a dialogue act
概念解释
披萨问到第三种配料，用户说「不要了」。下一句若仍是「还加什么」，放弃没有被当成一次合法的对话行为，人被关在一张自己已经撕掉的单里。明确的任务出口（explicit task abort）要求取消、算了、不做了能结束当前任务——弹出栈、停住追问、给出可听见的收束——而不是把这句话当成又一个没填上的槽。出口要在任何议程拍上都通，不只在最后确认。
机制
任务状态机喜欢待在「还缺槽」里，因为那是它唯一训练过的正向路径。放弃是一条负向边：没有新的槽值，只有「这个目标不再被追求」。若这条边不存在，任何否定都会被回流到最近的问句。用户说放弃时，共同基础上的半成品应被标成已关闭，而不是挂起等恢复——挂起是还想回来，放弃是不要回来。出口还要防止「关了一半」：技能停了，但定时器、购物车、待付款还在后台活着，下一次唤醒又把半成品递回来，等于没出。可听见的收束（「好，这份披萨取消了」）是把关闭写进双方耳朵，避免一边以为结束、一边还在等配料。
怎么研究
收集取消用语在真实日志里的后续：系统是否仍问原槽、是否开启新技能、是否给出收束、后台对象是否还在。自变量：取消出现的议程位置（第一槽、中段、确认前）、用语强度（「停」对「取消订单」）。因变量：追问延续的轮次数、半成品被再次提交的比例、用户重复取消的次数。
Wizard-of-Oz 在每个必填槽上都放一次放弃。若只有确认拍能出去、中段出不去，出口不是全局的。不要把放弃和修正、切换混在一个「否定」桶里计数——三种后续状态完全不同。
边界
「不要蘑菇」是在修一个槽，不是放弃整单；出口若过于灵敏，会把修正误杀成取消。高后果动作在放弃之后可能仍须一句确认（「确定取消转账？」），那是后果匹配，不是把人留在原流程里继续填。放弃一个嵌套任务应只关当前层，父任务还在就应恢复，而不是把整栈清空；用户说「都别做了」才清栈。无障碍用户可能用非标准取消词，出口的触发不能只绑「取消」这一个词。把出口做成必须说唤醒词加「退出技能」的隐藏语法，等于没有出口。
怎么落地
- 每个任务状态都挂一条放弃边：识别到取消类话语行为，立即停问、关闭该任务对象、说一句收束。
- 收束后落到空闲，不要立刻用通用「还需要什么」把人拉进另一个任务；空闲可以短，但必须先让取消被听见。
- 嵌套中的放弃默认只关当前层，并走父任务的恢复线索；只有明确的整栈取消才全清。
- 验证：在配料中段、在确认前各说一次「不要了」。中段仍被追问配料，或后台仍能把这张披萨提交出去，出口就还没打通。