OpenAI 做语音 AI，最容易被用户感知的是一个字：快。

你说完，它马上接。停顿少一点，拟人感就多一点。OpenAI 此前谈过自己如何大规模交付低延迟语音 AI，核心路线里有 WebRTC。这个选择很自然：浏览器支持好，实时音视频成熟，延迟也低。

但 Simon Willison 5 月 9 日摘引的 Luke Curley 批评，把这事从“链路怎么更快”推到了更尖的位置：WebRTC 在差网络下会为了低延迟丢音频包。如果这段音频是会议里的闲聊，糊掉几个字还好；如果它是给大模型的提示词，丢掉的可能就是任务本身。

这不是 OpenAI 官方承认了缺陷，也不能推出“WebRTC 语音输入一定会毁掉提示词”。更准确地说，这是一次协议目标和产品目标的撞车。

争议点不在语音识别，而在传输取舍

Curley 的话很刺耳：WebRTC 会在网络差时“degrade and drop my prompt”。

他批评的重点不是模型笨，也不是语音识别不行，而是音频还没到模型那一步，传输层已经可能把内容切碎了。

WebRTC 原本服务的是实时音视频。它的默认信仰很清楚：别等。为了让会议继续，它宁愿丢一部分音频包，也不愿为了完整性把对话卡住。

这个逻辑在会议里成立。

人类听到一句破碎的话，可以凭上下文补。听不清，还能立刻问一句“你刚才说什么”。但 LLM 语音输入不是同一种场景。用户可能在说一段代码修改要求、一封客户邮件的语气、一份合同条款的边界，甚至是一段医疗或法律问题的背景。

提示词少一个否定词，回答就可能拐到另一条路上。

Curley 还提到，浏览器里的 WebRTC 音频包重传并不是你想做就能做。他说 Discord 曾尝试过相关方向，但浏览器实现本身就是围绕实时低延迟设计的。换句话说，产品团队以为自己选的是一条高速路，代价却是路政规则不归自己管。

WebRTC 适合会议，不一定适合提示词

这个争议真正有价值的地方，是把“快”拆开了。

同样是低延迟，不同场景的代价完全不同。

场景最优先目标丢包后的后果更合理的取舍
视频会议对话不断、等待少声音破碎，但还能补问宁可糊一点，也别卡住
LLM 语音提示意图准确、内容完整提示词失真，回答跑偏宁可多等一点，也别乱听
浏览器语音 AI易接入、跨平台受浏览器 WebRTC 栈约束需要确认、回放、纠错机制

OpenAI 重做语音链路，原本说的是低延迟系统工程：模型快了，网络绕远也会拖后腿。这个判断还成立。

但 Curley 补上的变量更麻烦：问题不只是网络路径远不远，而是协议本身把“实时”放在“完整”前面。

这就像铁路和电报刚兴起时，速度改变了一切，但也逼着制度重新定义“准点”和“准确”。速度不是免费午餐。它会改写组织、流程，也会藏起新的故障点。

放到语音 AI 上，最危险的故障不是用户听见断音，而是用户完全没意识到 AI 已经听错。模型还会很流畅地回答。流畅会掩盖前面的损坏。

这才是坏体验里最阴的一种。

受影响的不是所有用户，而是高成本语音任务

普通闲聊、陪伴、客服前置问答，低延迟仍然很重要。用户要的是自然接话，偶尔听糊了，可以再说一遍。

真正该紧张的是两类人。

一类是把浏览器语音入口当核心交互的产品团队。你不能只盯端到端延迟，还要问：

  • 差网络下，音频有没有被丢弃？
  • 用户能不能看到转写文本并确认？
  • 关键任务有没有更可靠的上传链路？
  • 企业场景能不能保留录音、转写和输入审计？
  • 用户能不能选择“更快响应”或“更高准确性”？

另一类是用语音下达高价值任务的用户。比如让 AI 改代码、写合同邮件、总结客户需求、记录会议决议。

这些任务里，错一个词不是“小瑕疵”。它可能变成错误输出、错误执行、错误记录。用户最后只会觉得“AI 又胡说”，但故障点可能根本不在模型，而在音频进模型之前。

这对产品评测也有提醒。别只测安静 Wi-Fi 下的响应速度。地铁、移动网络、蓝牙耳机、嘈杂办公室，才更接近真实使用。

模型实验室喜欢展示干净样本，用户生活从来不干净。

我的判断：语音 AI 要有一条慢路

我不太买账的是，把语音 AI 的体验全压到“像真人一样快”。

真人对话当然需要快。但用户找 AI，不只是为了被陪聊。很多时候，用户是在委托任务。委托任务的第一要求不是热闹，是准确。

“差之毫厘，谬以千里。”这句话放在提示词上很合适。大模型不是只处理声音，它会把输入继续放大。前面听错一点，后面就可能写出一整段漂亮的错答案。

所以语音 AI 迟早要分层。

闲聊模式，可以快。陪伴、口语练习、低风险问答，可以优先实时感。

任务模式，应该允许慢。让用户看一眼转写，允许关键片段重传，必要时保留录音回放。尤其在企业、代码、法律、医疗、财务这些场景里，200 毫秒不是罪，错意图才是罪。

这也是我对 OpenAI 这类语音产品最现实的期待：别把低延迟当成唯一胜利条件。模型越强，输入越要可信。否则就是把一台很贵的发动机，接在一根会漏油的管子上。

速度能制造惊艳，准确才能留下信任。

OpenAI 选择 WebRTC 并不愚蠢。它解决了跨平台、低延迟、浏览器接入这些硬问题。问题在于，WebRTC 的成功经验来自会议，不来自提示词委托。把会议协议搬进 AI 入口，必须补上确认、纠错和可靠传输的产品层设计。

少了这层，语音 AI 会越来越像真人，也会越来越擅长自信地误解人。