AI 语音通话里经常有这样的场景：用户刚说了一半"我不是很方便……"，AI 却already 在念下一句话术，两边声音叠在一起，用户体验瞬间崩掉。这种"抢话"背后，其实是一整套叫**打断处理（Barge-in）**的工程问题。

为什么传统 IVR 不会遇到这个问题

老式的按键 IVR（"普通话请按 1"）不需要处理打断——它压根不听你说话，只等按键。真正的问题是从"语音对话"开始的：只要系统需要一边播报 TTS、一边监听用户说话，就必然要回答一个问题：用户现在说的，是要打断我，还是只是个语气词？

判断错两个方向都难受：

• 该打断没打断：用户已经在纠正/拒绝了，AI 还在自顾自念完整句话术，显得很"呆"。
• 不该打断却打断了：用户只是"嗯""啊"一声，或者背景噪音，AI 却立刻停下来，对话被打得支离破碎。

VAD 只是第一道关卡

大多数系统会先过一道 VAD（Voice Activity Detection，语音活动检测），判断这段音频里"有没有人在说话"。但 VAD 只能回答"有没有声音"，回答不了"这段声音算不算一次有效打断"——纯靠能量阈值的 VAD，对着空调声、键盘声、隔壁电视的声音一样会误触发。

真正可用的打断处理，通常要叠加几层判断：

1. 端点检测（Endpointing）：不只是"有没有声音"，还要判断"这句话说完了没有"，避免用户换气的停顿被误判成"说完了"。
2. 语义层兜底：即便声学层触发了打断，也可以让 ASR 出的文本过一道轻量判断——只有几个字的"嗯""对对对"，跟真正的完整句子，处理策略应该不一样。
3. 状态机而不是开关：AI 说话的过程本身要分阶段（比如"关键信息"和"补充说明"），打断策略在不同阶段可以不一样——念到关键报价数字的时候，可以适当"抗打断"一点。

延迟预算：打断能不能"跟手"，拼的是毫秒

打断这件事最终能不能让人感觉"跟真人说话一样"，本质是一个延迟预算问题。从用户开口到 AI 真正停止播报，中间要经过：

拾音 → VAD 触发 → 打断信号传给 TTS 播放端 → TTS 停止发声

这条链路上每一环都要控制在个位数到几十毫秒级别，任何一环卡住，用户听到的就是"我说话它没反应，过了半秒才反应过来"——比完全不做打断处理还难受，因为它先给了错误的预期。

我们在做的事

打断处理没有"一次做对就一劳永逸"的方案，它更像一套需要持续用真实通话数据去调的参数系统：不同行业（电销 vs. 客服 vs. 陪伴类应用）、不同话术阶段，"该多敏感"这个答案都不一样。这也是我们花了很多精力打磨的地方——目标很朴素：让 AI 在电话里"接话"的感觉，尽量接近打给一个真人。