M3.04.1barge-in on speech output设计研究
用户需能随时打断播报
别名: 打断播报 · duplex barge-in · 随时打断
概念解释
系统还在念的时候，用户必须能开口把播报停掉。这叫打断（barge-in）。电话菜单在念完套话之前人已经知道下一句要说什么，车载开始朗读一条长短信时司机要改口问出口，通道若要等播完才听人，人就在给机器排队。要求的是输出侧的双工（duplex）：播报期间麦克风仍算开着，用户一说话，TTS 就停。这是「地板能不能被拿走」，不是检测在声学上有多难。
机制
口语对话里重叠和插话是合法的。半双工把 TTS 放到结束才交地板，用户的唯一合法动作是等。等没有预告终点时尤其糟。人把嗓音听成一个主体，这个主体不肯让路，工具就变成在主导。可打断把识别（至少是有没有人在说话）保持在播报期，切断是默认，不是例外。听感上的量是从开口到声音消失的时延：切得慢，人会以为没被听见，接着去砸键或挂机。短提示会和开口赛跑，但「默认不可打断」仍是把通道锁死。
怎么研究
打断时延：从用户语音起始（或按键）到 TTS 静音。再计有多少次开口发生在播报中、其中多少次真的切断。自变量：提示类型（告知对提问）、用户是否熟手。因变量：时延、以及「人一直等到播完」的比例——后者是通道被锁的行为痕迹。
安静实验室、按键说话一直开着，测不到现场打断。车里、大厅喇叭上，开口时间会更晚、更短。不要用「打断之后他想干什么」当主因变量。这里只问切断有没有发生。
边界
疏散、法定一次必读的警告可以要求念完，但要短，并且说明为什么。老式只能按键的电话菜单，按键打断仍算可打断。一秒以内的短句，打断会和提示自己赛跑，可以不作为主路径。公共场合对着喇叭抢话有社交代价，那不取消可打断，只是人可能改去砸「跳过」键。用户明确设定「短信读完」是自愿收窄，不是产品默认锁死。
怎么落地
- 默认：TTS 期间麦克风开着，检测到语音就切播报。
- 平行提供物理打断：方向盘键、一体机上的跳过，不把唯一出口放在说话上。
- 任何「不可打断」都要有书面理由，促销和告知不算理由。
- 验证：埋点切断时延；回看播报中用户开了口而提示仍在走的会话——那些就是这条失败。