打断后需判断是纠正还是新请求
别名: 插话是改槽还是换事 · 播到一半被打断 · mid-prompt repair
概念解释
系统正念「将在周五上午十点出发」，用户叠上来「改成周六」——改的是正在被说的那个槽。同一位置若叠上来「先放音乐」，是丢掉当前这句，另起一件。打断被检测到之后，还要判断这句插话是纠正还是新请求（barge-in as repair versus new request）。分类对象是「播报中途闯进来的那一句」，不是系统已经说完之后下一轮的否定。
机制
正在播出的内容本身就是最强的上下文：用户选在哪个词上开口，往往标出他们在修哪一块。叠在「周五」上的「周六」是对日期槽的 other-repair；叠在整句确认的开头、并带上另一个技能谓词的，是新请求。对话管理若把所有打断都当成「取消当前播报，把整句当新意图」，会把「改成周六」做成一次全新的出发请求，已填的目的地被丢掉。若把所有打断都当成对当前句的局部修正，会把「先放音乐」塞进行程的某个槽里。
区分靠三件事同时看：重叠落在正在念的哪一个槽、插话里有没有与该槽同类型的新值、有没有当前任务以外的谓词。只有否定没有新值（「不对」）时，优先当成对当前正在说的那一块的纠正入口，而不是静默开一个新技能。打断检测只解决「停不停」；不停就谈不上分类，停了却分错，损失在任务状态上。
怎么研究
建播报中途插话语料：在系统 TTS 的指定槽上诱发打断，把插话标成纠正当前槽、纠正其他已填槽、新请求、放弃。特征包括：重叠位置相对当前句的哪一段、是否含同槽新值、是否含新技能谓词。看现网把哪一类标错，以及标错之后状态机走了改槽、开新技能还是清空。
Wizard-of-Oz 用同一句「不要周五」接在两个位置：一次叠在「周五上午十点」上，一次叠在无关的天气播报上。同一字符串应落到不同功能。不要用离开播放位置的离线句分类代替——没有「打断了哪一段」，纠正无法定性。
边界
一句话里既改槽又换任务（「周六那班不要了，放歌」）是复合，要拆，不能在纠正和新请求里二选一。列表播报中途的「就要第二家」是选定，既不是改一个槽也不是新技能，应走当前列表的点名。礼貌性的「好好好」叠在播报上可能是反馈而不是指令，不该改状态。识别把「要周六」听成「不要」时，声学错误会把纠正假造成放弃——若后面仍跟着日期值，优先当纠正。
怎么落地
- 打断发生时记下正在播出的槽位或列表项，作为纠正的默认靶；只有出现新技能谓词或明确整单放弃时才离开当前任务。
- 「不对 / 改成」且带同类型新值：改该槽，其余槽保留，不要重开技能。
- 靶不明确时用一句封闭问钉在打断点上（「改出发日，还是不做这趟了？」），不要默默清空也不要默默继续念。
- 验证：同一句确认播报准备两句插话——「改成周六」和「先放音乐」。第一条只改日期并留在行程；第二条离开行程。两条进了同一路径，分类没有切开。