Voice AI 面试别只讲 STT：延迟、打断和恢复才是追问重点

面试官问“怎么把 Voice AI 做到实时”，你如果只回答换更快的 STT，下一问通常就会暴露缺口：用户停顿半秒算不算说完？助手播到一半被打断，旧答案还在生成怎么办？网络恢复后为什么不会重复播报？

Voice AI 工程师面试考的不是单点识别率，而是一整个回合能否快速开始、正确结束、随时取消，并在故障后回到可理解的状态。

先把 Voice AI 说成一条回合链路

第一层回答可以先画七段：音频采集、媒体传输、轮次检测、STT、模型处理、语音合成、客户端播放。再补三条横切能力：状态管理、取消传播和恢复确认。这样面试官知道你讨论的是用户听到的完整体验，不是某个 API 的局部耗时。

第二层追问往往是“哪一段最慢”。不要急着猜。先定义观测点：用户开始说话、最后一个有效语音片段、系统判定回合结束、首个转写片段、模型开始响应、首个音频分片到达、用户真正听见声音。只有时钟口径一致，分段延迟才可比较。

还要区分一次通话、一个用户回合和一次模型请求。三者混成一个 request id，断线重连或重试后就很难判断旧输出属于哪一轮。关于输入质量对答案的影响，可先复习实时 STT 到 LLM 答案质量指南，但本题必须继续讲到播放、打断和恢复。

从麦克风到第一段声音，延迟花在哪里

强回答会给延迟做预算，而不是给系统报一个神奇总数。采集侧可能有缓冲和设备处理；传输侧有网络抖动与重连；轮次检测要等待足够证据；STT、模型和语音合成都可能流式返回；播放侧还要排队和解码。某段更快，未必让用户更早听见正确内容。

第一层回答应说清你优化的用户事件，例如“从用户结束有效发言到听见首段可理解语音”。第二层追问要补 p50、p95 或尾部样本，并按语言、网络、设备和回合长度切片。本文不提供通用合格阈值，因为不同产品的任务容错与交互节奏不同。

WebRTC 可以作为实时媒体传输方案的一部分，Twilio Media Streams 也提供通话媒体流的实现入口，但协议或服务名称本身不保证低延迟。面试中要解释测量、背压、缓冲和降级策略，而不是把技术名词当作性能结论。

停顿不是结束：Endpointing 为什么难

用户思考时会停顿，报邮箱、代码或专有名词时也会断开说。过早结束会截断问题，等待太久又让助手显得迟钝。Endpointing 因而是响应速度与语义完整性的权衡，不是把静音毫秒数调小就结束。

第一层回答可以提出多信号判断：声学停顿、已识别文本是否像完整句、当前任务类型、用户是否仍在持续输入。第二层追问则要说明错误成本。客服确认号被截断，可能导致错误查询；开放式闲聊多等片刻，代价可能只是节奏变慢。策略应该随场景风险调整，而不是一套参数覆盖全部流量。

Deepgram 的 Endpointing 文档可以帮助理解当前接口概念，但厂商功能会持续变化。面试时更可靠的表达是说明你需要什么行为、如何做匹配测试、怎样观察早切与晚切，而不是声称某家方案在所有语言上最准确。

用户插话后，要取消的不只是声音

Barge-in 的表面动作是用户一开口，助手停止播放。真正难点是旧回合可能仍在模型端生成，语音合成队列里还有音频，客户端缓冲仍待播放，工具调用甚至已经准备执行。只把扬声器静音，会留下一个看不见的旧任务继续推进。

第一层回答要给出取消链：检测到可信的新语音后，停止当前播放，丢弃未播放缓冲，向上游传播取消，冻结旧回合可产生的副作用，并为新回合创建明确状态。第二层追问是竞态：取消消息和最后一个音频分片谁先到？旧工具调用已经成功怎么办？此时需要回合标识、幂等键和“过期输出不得进入当前播放队列”的检查。

取消也不能过度敏感。背景咳嗽、回声或旁人声音不应轻易终止回答。你要解释输入来源、回声处理、置信信号和用户控制，而不是把所有检测到的声音都当作有效插话。

部分转写到达时，怎样保护新一轮状态

流式 STT 会先给部分结果，后续可能修正词语或边界。系统若在每个部分结果上立即启动完整推理，可能制造并发请求、重复回答和过期输出；若坚持等最终文本，又可能失去实时感。

可以把状态分成“正在收集”“候选意图”“已提交回合”和“已取消”。部分转写用于预热或展示，但只有满足提交条件的版本才能驱动有副作用的动作。后续修订必须携带同一回合身份，并能使旧候选结果失效。

第一层回答说状态机，第二层追问说乱序和重复：最终转写先到、取消后旧片段又到、重连补发同一段音频时，系统怎样去重？这里应依赖明确序号、时间边界和幂等处理，不要依赖“通常消息会按顺序到”。更多输入污染案例可参考实时面试转写降噪指南。

断线、错转写和重复播报怎样止损

恢复的目标不是假装什么都没发生，而是让用户知道系统现在听到了什么、保留了什么、接下来会做什么。常见故障至少包括媒体断线、STT 错词、模型超时、TTS 失败和重连后重复播放。

第一层回答可以为每类故障给一个安全状态：短暂传输中断先暂停提交；关键实体不确定时请求确认；模型超时返回简短提示并允许重试；合成失败可降级为文本；重连只恢复仍有效且未确认完成的回合。第二层追问则是“如何避免双写和双播”，答案应包含回合身份、输出序号、确认点和幂等副作用。

用户可见确认很重要。例如明确说“刚才连接中断，我只保留到某句，请从这里继续”，通常比静默拼接更可控。面后还应把失败回合进入漏答恢复闭环，区分是输入丢失、轮次误判，还是恢复策略本身造成二次错误。

事故题要从第一次偏离讲到恢复完成

面试官让你复盘一次 Voice AI 事故时，不要只讲“延迟升高，扩容解决”。用一条可验证时间线回答：用户预期事件是什么；第一处偏离发生在哪个阶段；哪些指标和回放证据支持判断；系统如何限制影响；怎样恢复；哪项机制防止复发。

指标可分四组：分段与尾部延迟、早切和晚切、插话取消成功率、恢复后重复或丢失回合。任何数字都要说明采样范围和测量点。厂商准确率或延迟比较只有在输入、语言、网络和测试方法匹配时才有意义。

最后把可观测性接上：一次用户回合应能串起媒体会话、转写版本、模型请求、语音输出和取消事件，但不应默认暴露完整敏感内容。下一篇Agent 可观测性面试指南会进一步拆解 Trace 与失败凭证怎样支撑这种定位。

常见问题

Voice AI 工程师面试最先应该画什么？

先画端到端回合链路和阶段延迟，再标出状态、取消、超时和恢复边界。这样后续追问都能落回同一张系统图。

实时语音系统有没有统一合格的延迟阈值？

没有。应按具体任务、设备、网络、语言和用户预期定义目标，并报告清楚测量口径与分位数。

用户插话时只停止 TTS 播放够不够？

不够。还要取消或失效旧生成、清理未播放缓冲、保护工具副作用，并确保旧输出不能污染新回合。

WebRTC 是否能保证 Voice AI 的低延迟？

不能。它提供实时媒体通信相关标准能力，最终体验仍取决于网络、实现、编解码、服务处理和应用策略。

参考资料

• OpenAI Docs：Realtime API，当前在线文档，接口能力发布前应重新核验
• Twilio Docs：Media Streams，当前在线文档
• Deepgram Docs：Endpointing，当前在线文档，厂商特性应按目标版本核验
• W3C：WebRTC 1.0，现行 Recommendation

下一步

• 查看 Interview AiBox 功能全景
• 阅读 核心功能使用指南
• 通过 产品路线图 了解实时工作流演进
• 下载 Interview AiBox 开始练习