GPT 语音活人感爆炸！万字深入解读 GPT Live 语音模型

 

这几天，GPT‑5.6 正式发布，Chat、Work、Codex 也被装进同一个 ChatGPT 桌面 App，几条新闻接连刷屏。GPT‑5.6 与 Fable5 打的有来有回，模型能力、产品入口、工作方式都在变。新闻多得有点让人反应不过来。

昨天晚上，我习惯性在睡前拿 ChatGPT 聊聊最近的热点，往常我的动作基本是手动打字，最近用的多点的就是豆包语音输入，我一般很少用ChatGPT 的语音功能，一方面他中文能力确实一般，另一方面我不那么喜欢生硬的 ai 感语音对话，可我手一滑，点到了聊天输入框旁的语音功能，聊了两句，我立马从床上坐起来，虽然口音还是不那么正宗，有点老外腔调，但我脑海中闪出一个词：活人感。不儿，这电子老外咋那么活溜呢？

先说感受，正常普通话和 ChatGPT对话与豆包有一个区别，就是情绪不像装出来的， 豆包也能模拟情绪，但我说不上来的有一种语音上的“恐怖谷”效应，以至于我不那么喜欢和她聊，但 GPT 没有，每段话的语气、腔调、神态，虽然没看到人，但确实能感觉到对面有不可言说的神态。我恶趣味上来，让它用北京口音跟我聊天，结果它一开口，我直呼牛逼。儿化音很顺，北京人常用的词张口就来，说话时那股腔调也有了。整句话听起来很自然，没有刻意模仿的感觉。我一个外地人听着，真真儿的，太对味了。

我又让它说客家话，属实是有点刁难了，果不其然一换客家话就不行了，直接蹦出粤语，客家话本身有很多分支，不同地区的发音和用词差异很大。应该是没有投喂过专门的语音数据进行训练。

以前和语音助手聊天，我脑子里一直知道对面是个 AI，声音再自然，也能感觉它在等我说完，再一板一眼地接话。这次它会听着，会接话，还会顺着我的语气往下聊。听久了以后，我甚至会忘记自己正在和一个模型说话。这谁顶得住啊！

作为一个 AI 产品经理我的职业病犯了。产品体验突然出现这种级别的变化，我肯定不能只停在一句好牛逼上。我想知道 OpenAI 到底动了哪里，用了什么技术，又是怎么把这些技术变成我耳朵里这股真人味的。于是我开始刨资料，官方发布、技术分析、第三方实测来来回回翻了一圈，最后盯上了两个东西：全双工架构和任务委派机制。

语音 AI 以前为什么总有一股客服味？

这次的 GPT 更新后，语音使用的是专门的语音模型 GPT‑Live 。在 GPT‑Live 出来之前，我们已经和各种语音助手聊了很多年。早些年是 Siri、小爱同学，到了现在，国内用户最熟悉的 AI 助手之一是豆包。我用豆包对话有时候会发现，豆包在专业知识的回复和普通聊天的回复使用的腔调明显不一样，而且在模拟一些情绪的时候会出现明显的“断痕”，只要多聊几句，总会冒出一股熟悉的客服味。说话你得等它说完，它也在等你说完。每次中途打断她的长对话输出需要有几秒的延迟，聊天节奏容易乱。你停顿久了一点，它以为你讲完了。你随口嗯了一声，她可能停下来问你是不是有新问题。这些别扭的体验，和语音 AI 处理对话的方式直接相关。

语音 AI 的架构，大致经历了三个阶段。

第一代，级联式语音系统

级联式语音系统通常由三个独立模块组成。第一个模块是 ASR，也就是自动语音识别，负责把用户的声音转换成文字。第二个模块是 LLM，大语言模型根据文字理解问题并生成回答。第三个模块是 TTS，语音合成模型把回答重新转换成声音。

整个过程按照固定顺序串行执行：

上一个模块处理完，下一个模块才能开始。ASR 要花时间，LLM 要花时间，TTS 也要花时间。每个环节的延迟叠在一起，用户就会感觉 AI 总要愣一下才开口。

级联式系统像三个人排成一排传话。第一个人负责听写，把你说的话记在纸上。第二个人只看纸上的文字，负责想答案。第三个人拿到答案，再照着稿子念给你听。三个人都很努力，传话过程还是会丢东西。

比如你皱着眉头说了一句，行，你说得都对。ASR 最后交出去的内容只有几个字。你的语气、停顿、重音和不耐烦，很难完整保留下来。大模型看到这行字，可能把它当成赞同。TTS 再用热情洋溢的声音回复一句感谢认可。就很难评。

文字可以记录你说了什么，很难完整记录你是怎么说的。声音进入系统以后，先被压缩成一行文字，模型收到的信息已经少了一层。等答案再次被合成为语音，TTS 只能根据文字重新组织语气。

级联式架构容易理解，也方便替换其中的模块。它至今仍然大量存在于客服、外呼、车载和智能硬件中。它的短板同样明显，延迟会叠加，情绪信息会损失，对话通常以一问一答的形式推进。

第二代，轮次式语音模型

之后，语音模型开始直接处理音频，也可以直接生成音频。声音进入模型以后，无需每次都完整转成文字再参与理解。模型能接触语速、语调、停顿、重音和情绪等信息，生成的声音也自然了很多。

这类系统的交互单位通常还是一个个离散的话轮。系统会通过 VAD，也就是语音活动检测，判断当前有没有人在说话。它还会结合静音时长、语义完整度等信号，判断用户这一轮是否已经结束。确认用户说完以后，模型开始生成回答。回答结束，发言权再交回用户。这像一台声音自然的对讲机。你按住按钮说一段，对面听完再回一段。声音已经很像真人，双方仍然要轮流使用这条通道。谁先说，谁后说，边界需要系统判断。

比如你对它说，我想订一张明天去上海的票。说到这里，你停了一秒，突然想起时间不对，又准备补一句，等等，后天吧。这一秒的停顿对人来说很正常，你只是在想事情。系统如果把静音当成话轮结束，就会直接开始查明天的票。等你补上后天吧，它已经沿着错误的日期往下走了。

所以，语音 AI 的难点一直没有停留在识别准确率。它还要判断一句话有没有讲完，停顿代表思考还是结束，旁边的声音算背景噪声还是新指令。

第三代，全双工架构语音模型

全双工架构允许输入音频流和输出音频流并行运行。模型在生成语音的过程中，仍然持续接收并处理用户的声音。

再往底层看一步，公开研究里的主流做法，是把对话建模成两条并行的音频 token 流。一条是用户的声音，一条是模型自己的声音，两条流对齐在同一条时间线上。模型每生成一帧自己的音频，同时也在读用户这一帧说了什么。听和说在模型内部没有先后顺序，它们是同一次计算的两个通道。所以这类模型里没有【等你说完】这个概念。它在一条不断变化的时间线上，连续判断现在该听、该说、该停，还是继续保持当前状态。

就好比语音 AI 从对讲机走到了电话。对讲机里，一方说完，另一方再说。电话里，双方都可以开口，也都能在说话时听到对方。

别看OpenAI 吹的那么牛逼，实际上全双工架构的思路，早就有人跑通了。开源组织 Kyutai 在 2024 年 9 月发布的 Moshi 模型，已经证明了双流并行 token 生成的可行性。它的 Mimi 编解码器以 12.5Hz 的帧率运行，每 80 毫秒生成一帧音频，端到端延迟约 200 毫秒。模型一边听你说话，一边生成自己的声音，两个人同时开口的重叠语音也能处理。

而且Google 的 Gemini Live 早就支持同时听说。豆包能随时插话，火山引擎公开的技术方案里有全双工通信、音频帧级 VAD 和智能打断，同声传译模型 Seed LiveInterpret 2.0 也采用了全双工语音理解与生成框架。

所以，GPT‑Live 玩的这套属实是 emmm，别人玩剩下的。

双工架构的坎，懂你为什么开口

线路同时打开很容易，判断谁该继续说很难。这是双工架构到今天都没完全迈过去的坎。

我在收集资料的时候，有一个概念差点搞混，能打断和全双工是两层能力。豆包说话时，你直接插一句，它会停下来听你。这类中途打断叫 Barge-in，翻译过来就是插话机制。AI 播放语音时，系统继续运行 VAD（可以理解为人声检测），一旦检测到用户开口，就停止当前音频，把你刚说的内容送进下一轮处理。它解决的是输出取消问题。

这种打断像AI 说话的时候一直在听你说，你一开口他就闭嘴，开始听你的下一句话。

假设豆包正在念一份很长的旅行攻略，你听到第三个景点就发现方向错了，可以直接说，我不想去热门景点，换一批人少的。它会停止原来的回答，再按照新条件生成。这项能力已经很好用，也解决了过去必须听 AI 把整段话念完的的问题。

全双工处理的范围要大得多。两条音频流持续并行只是基本功，模型还要理解你此刻为什么开口。用户发出的声音进入系统后，模型要判断它属于哪一种情况：

• 用户正在表达一个完整的新要求
• 用户在纠正刚才的信息
• 用户只是在说嗯、对、然后呢
• 用户希望模型暂停
• 用户想把发言权拿回来
• 背景里有人说话，和当前对话无关
• 当前任务需要调用工具或交给后台处理

同样是用户开口，作用可能完全不同。你和朋友打电话时，对方讲到一半，你说嗯，他一般不会停下来问你有什么新需求。这个嗯代表你还在听。你突然提高音量 【嗯？】一下，对方就会理解刚刚是不是说错内容了，等你纠正。

如果系统只依赖 VAD，它只能发现你出声了。它很难仅靠有没有声音判断你是在附和，还是准备抢回发言权。全双工模型需要持续理解声音里的语义、语气、时机和上下文，再决定要不要停。好，来到我们熟悉的地方了，这不就又是意图理解吗。。现在所有agent产品的最头疼最希望提高准确率的问题，之前在负责某本地生活 agent的时候，做的最大的架构变动其核心也是为了解决意图路由分发问题，这里不展开说。

这也解释了一个很尴尬的场景。用户随口说了个嗯，模型突然停了。用户安静下来等它继续，它也在等用户说话。两边一起沉默，最怕空气突然安静，气氛瞬间降到冰点，用户体验也直线下降。这就是意图理解出了偏差，GPT‑Live 的第三方实测里同样出现过。

话轮管理，语音 AI 最容易被低估的技术

在语音交互里，谁在说话、谁在倾听、什么时候换人，这套机制叫作话轮管理。

话轮管理需要综合多类信号。VAD 负责检测声音活动，端点检测负责判断一句话是否结束，语义模型判断表达是否完整，韵律信息提供语速、音高、停顿和重音，历史上下文帮助系统理解用户当前的意图。

系统还要处理重叠语音。用户和 AI 同时开口以后，谁继续说，谁停下来，当前生成到一半的内容要不要保留，用户的新要求要从哪里接入，这些都需要实时决策。OpenAI 在 GPT‑Live 的发布资料中说，模型会在每秒内多次决定继续听、开口、暂停、打断或发起工具任务。

话轮管理是不是很像眼力见。一个人会聊天，靠的并不只是能听清内容。他知道别人停下来是气口，还是已经讲完。人类每天都在做这些判断，下意识就能理解。但模型需要把这些细节拆成一连串计算，这要相对复杂很多。毕竟人类有时候一个眼神就能秒懂很多，大模型还做不到。

这里还有一个很麻烦的问题，停止说话和停止任务是两回事。比如你让语音助手帮你搜索北京周边的露营地，它正在介绍第一个地点时，你说停一下。系统至少要判断三件事：只停止播放声音，搜索继续进行；停止当前回答，已经找到的结果保留；连后台搜索任务一起取消。

对普通用户来说，只说了三个字。对产品和技术团队来说，背后对应三种完全不同的系统状态。语音交互越自然，这类状态越需要设计清楚。用户开始像对人一样说话以后，不会每次都给出一条格式完整的命令。

全双工可以让 AI 一边说一边听，也能让话轮切换更自然。可当用户提出复杂问题时，等待依然存在。网页搜索需要时间，读取多个页面需要时间，比较信息需要时间，深度推理也需要时间。

这可以理解为实时交互与深度计算之间的延迟矛盾。语音对话要求系统快速响应，最好尽快给出反馈。复杂推理追求答案质量，需要更多计算步骤和更长处理时间。两个目标放在一个模型、同一条执行链里，很容易互相拉扯。

有点像你打电话问朋友，周末去杭州还是苏州，你帮我查一下天气、车票、酒店价格，再算算两个人的总预算。朋友听完以后开始查资料，天气查完了接着查车票，车票查完再看酒店，最后打开计算器算总价。整个过程中，电话那头一直没有声音。等十几秒还能忍。但时间长了，多少吱个声，不然都不知道电话挂了没。

文字产品里，用户可以看加载动画，也可以切出去做别的事。实时语音里的沉默会让人不安。用户不知道系统有没有听懂，不知道任务是否还在运行，也不知道刚才是不是断线了。

这就是语音 AI 长期存在的延迟矛盾。模型越认真干活，电话那头越容易沉默。开口很快的模型，复杂任务又可能做得不够深。

任务委派：对话是对话，工作是工作

GPT‑Live 为了解决上面的问题，给出的方案是任务委派。GPT‑Live 把实时交互层与后台工作层拆开。实时交互层负责接收音频、生成语音、管理话轮、理解用户意图，并维持当前对话。用户的需求涉及网页搜索、复杂推理或多步骤任务时，GPT‑Live 可以把任务委派给后台的前沿模型。发布时承担后台工作的模型是 GPT‑5.5，后续还能随着前沿模型更新。并且后台可以处理多个任务。前台语音模型继续与用户交流，后台任务分别推进。结果准备好以后，GPT‑Live 再把信息带回当前对话。

这套分工缓解了语音产品里的等待问题。负责陪用户说话的模型需要反应快，负责深度任务的模型需要想得细。两个角色分开以后，前台可以维持交流，后台可以把事情做完。

这张图看起来简单，真正做起来全是坑。用户在后台搜索期间改变需求，旧任务要不要取消？多个结果同时回来，哪个先说？当前话题已经聊到别处，突然插入一个航班价格，会不会显得莫名其妙？后台任务失败，前台应该继续聊，还是马上告诉用户？

GPT‑Live 的价值集中在这里。它开始把实时对话、任务路由、后台推理和结果回流放进同一套体验里。用户听到的是一段自然语音，后台实际运行着一个分层系统。

实时语音模型很难同时满足低延迟、自然表达、复杂推理和稳定工具调用。开发者过去常用一套分层架构解决这个问题。前台接入 Realtime API，负责收音、播音、打断和基础话轮管理；后台接入能力更强的模型，负责搜索、推理和工具调用；中间还要补上任务队列、上下文同步、状态管理和结果回传。

大白话讲，就是前台坐着一个反应很快的接待员，后台坐着一群专家。接待员负责听你说话，确认你要办什么，随时回应你。碰到复杂问题，他会把任务发给后面的专家。专家查完资料、算完数据，再把结果交回接待员。

这套做法很有效，但开发成本不低。开发者需要决定任务什么时候发出去，交给哪个模型，最多等待多久，用户改需求后要不要取消原任务。后台返回结果时，当前对话很可能已经聊到了别处。系统还得判断这份结果应该立刻说出来，稍后再说，还是直接作废。

GPT‑Live 把这套分层逻辑放进了 ChatGPT。普通用户无需理解前台模型和后台模型，也不用手动选择由谁处理。系统根据任务复杂度完成分工。

早在今年 5 月，OpenAI 已经在开发者侧推出 GPT‑Realtime‑2、GPT‑Realtime‑Translate 和GPT‑Realtime‑Whisper。一个负责实时推理和行动，一个负责实时翻译，一个负责流式语音转写。这些动作说明 OpenAI 正在补齐整套实时语音技术栈，GPT‑Live 只是普通用户最容易感知的那一层。

但缺点也来了，按照 GPT‑Live System Card 的说法，发布时的 GPT‑Live 缺少对工具的广泛独立访问，也不具备代码执行能力。需要搜索、推理和复杂工作的请求，会更多地交给后台模型。任务如何路由、调用了什么工具、数据经过哪些环节，用户和外部开发者都无法完整观察。

Realtime API 的控制方式更直接。开发者可以决定开放哪些工具，设置超时和重试，保留任务日志，也能规定哪些操作必须让用户二次确认。两套方案对应不同的产品边界。

普通聊天很适合托管方案。进入企业客服、医疗咨询、金融服务和设备控制后，黑箱会变成产品风险。用户问一句为什么给我这个结果，系统需要拿出可追踪的过程。语音助手准备付款、订票或修改账户时，产品团队也得知道任务走到了哪一步。

平台化省下了大量工程工作，也收走了一部分控制权。AI 产品经理得先判断自己的场景能不能接受这种交换。

技术都不是新鲜技术了，但 GPT‑Live 做得更有价值的一步，是把这些技术积木拼进一个面向大量普通用户的产品。全双工负责持续交流，话轮管理负责控制节奏，后台委派负责处理复杂任务，前沿模型负责提供认知能力。几块能力组合到一起，用户才会感到它突然像个真人了。

这也是 AI产品经理需要思考的问题，如何将已有的技术与模型能力，更换组合方式让产品的体验跨上一个台阶。

语音产品的指标得重新算

过去做文本 AI，团队经常盯着回答准确率、表达合理性、首字延迟和用户满意度，听说某厂有一项指标是傻x率，指的是用户吐槽模型的频次。实时语音出现后，这些指标依然有用，但衡量体验的颗粒度还得更细。

在从业者的角度来看，语音交互需要关注端点检测、话轮预测、打断响应、输出取消、后台任务延迟和对话恢复。每一个环节都有自己的时间指标和错误率。OpenAI 为 GPT‑Live 增加了对话流畅度和愉悦度人类评测，也会观察轮流发言、打断处理、整体对话偏好和每次互动的自然程度。

如果让我做 GPT‑Live 这类产品，我会重点盯下面几个指标：

假设 GPT 查航班用了八秒，最后结果完全正确。用户在电话里听了八秒沉默，已经会怀疑断网了。文本页面可以放一个加载动画，语音场景需要更自然的反馈。它可以先确认正在查周六的航班，再询问用户能不能接受中转。后台继续跑任务，前台继续收集信息。

低延迟到了语音产品里，已经不只是性能指标。它会被用户直接感知成反应力、性格和态度。慢半拍的安慰听起来很敷衍，抢半拍的回答又会让人火大。毫秒级的技术指标，最后都变成了人与 AI 相处时的情绪。

实时语音里的打断涉及多层状态。系统要暂停音频播放，终止当前语音生成，更新对话上下文，还要判断后台任务是否继续。几个动作的执行对象不同，后果也不同。用户说一句等一下，背后可能有好几种意思。他可能只是嫌 AI 说得太长，想让声音停下来；也可能觉得答案方向错了，后面的内容不用再生成；还有一种情况更麻烦，AI 已经开始查资料、写邮件、订票或付款，用户希望整件事立刻取消。

比如用户说帮我订明天去上海的机票，过了两秒又说等等，我记错日期了。系统只停止播音没有用。后台如果仍在提交订单，几分钟后可能真的买一张错票。

产品界面需要把这些状态讲清楚。AI 当前是在听、在回答、在搜索，还是正在执行操作，用户应该看得见。涉及真实世界操作时，取消入口和二次确认也得放在显眼位置。声音可以从界面里消失，系统状态不能一起消失。

官方演示很顺，真实使用还有不足

OpenAI 官方的人类评测显示，GPT‑Live‑1 和 mini 相比高级语音模式获得了更高的体验，评估维度包括轮流发言、打断、对话流和每次交互的自然程度。这些结果能说明方向有效，真实世界的使用仍然会暴露裂缝。

第三方语音智能体公司 Regal.ai 做了直接测试。GPT‑Live 的声音和来回对话确实自然。进入网页搜索或工具调用后，它有时仍会沉默。用户发出嗯、好的这类附和时，模型也可能误判为打断，原本的回答会突然停住。

全双工保证输入流和输出流能够并行处理。它无法保证每次话轮预测都正确，也无法消除搜索、网络请求和外部工具带来的实际耗时。架构提供了能力，产品体验还要依赖模型判断、任务调度和界面反馈。就像电话两边都能同时开口，不代表两个人一定聊得顺。有人爱在你说话时不断嗯嗯，有人一听到嗯就以为你要发言。线路通了，默契还得慢慢练，它把持续对话、话轮判断、复杂推理和任务委派放进了一套产品。具体体验能不能稳定达到官方描述，还要看真实场景。

写到这里，再回头看我一开始的体验。虽然 GPT‑Live 的表达挺流畅挺活人感的，但依然无法避免在中文表达能力上，还是个大学留学生的水平，远不及母语者。即便是可以照猫画虎模仿个北京的儿化音，但实际上在方言、中文梗的表现上欠缺很大，露出了模型的边界，但这也能理解，毕竟人家专攻英语，相互的，国内语音模型在英语识别准确率上也还有提升空间

语音模型的能力表现，受到训练语料规模、录音质量、、标注方式和评测等多种因素影响。同一个词在不同语境有不同发音和用法。模型能识别大意，不代表它能稳定生成真正自然的口音。这点在任何一个语音模型上都是如此，即便很准很像了，仍然不及真人。

普通话如此，方言更甚。方言表现既有模型能力差异，也有听众判断标准的差异。方言的地道程度很难只靠一个统一分数衡量。产品团队需要找真正使用这门方言的人来测，还得分清这门方言的发音有没有被普通话通化。实际上我们这一代人之后，方言就更加难以传承下去，如果模型厂商能够将中国大地每个方言的语料收集下来，做成一个语音模型，那文化传承也有了更踏实的平台，对于我这个方言使用者来说，也是最期待看到的事。

语音模型的安全防线

同时安全问题不容小觑，语音会放大信任。一个带着活人感的声音直接进入耳朵，人很容易顺着它的节奏交流，如果它模仿家人催促老人转账，风险会比一段陌生短信高很多。孩子长时间和一个永远耐心、随时在线的声音聊天，也会产生新的依赖问题。

好在 GPT‑Live 针对语音输入和输出增加了持续安全检测。系统发现高风险内容后，可以调整回答、播放语音提示、提供文字资源，必要时结束对话。OpenAI 的红队测试覆盖儿童化声音、身份冒充、说话人识别、自我伤害、情感依赖和诈骗操纵等场景。

实时语音还压缩了安全判断的时间。文本模型可以生成完整答案后再检查，语音模型需要边生成边说。错误内容一旦发声用户就已经听到了，这时候检测、阻断和安全提示必须跟上音频流。

OpenAI 为 GPT‑Live 预设了一组声音，也明确表示产品并非用于模仿真实人物。说实话，这个限制挺重要。真人感越强，系统越要持续提醒用户，对面是 AI，它说得流畅也会犯错。

一个产品经理最后看什么？

我研究 GPT‑Live，最后还是会回到产品里那些的东西。模型架构怎样分工，用户就会怎样等待。话轮系统怎样判断，用户就会怎样被抢话。后台任务怎样封装，用户就会得到多少控制权。训练数据覆盖到哪里。

所以我不会把 GPT‑Live 简单理解成一次声音升级。它背后有一整套系统协作。全双工让模型在说话时继续听，话轮管理决定它什么时候接话，任务委派把复杂工作交给后台，前台交互层负责维持对话，安全系统跟着实时音频持续运行。

这些技术单独拿出来，很多都能找到更早的研究和产品。OpenAI 把它们拼成了一个足够完整、足够自然、能推向大量用户的体验。用户不需要知道 ASR、VAD、TTS、任务路由和后台模型，他们只会觉得这次聊天顺多了。而这也正是我们目前做产品最需要的思路，需要拥有积木思维，牢记奥卡姆剃刀原理：如无必要勿增实体。把已有的技术融会贯通，打造更好的产品体验。

我还是保持那个往下挖的产品洞察习惯。看到一个功能突然好用，我很难只截张图发一句牛逼。我要知道它为什么好用，哪里真的变了，哪些是模型能力，哪些是工程架构，哪些又只是演示时看起来很美。

这次顺着活人感往下挖，答案已经很清楚。GPT‑Live 的活人感来自一整条技术链路。它能同时听和说，能在每秒内不断判断话权，能把复杂任务交给后台，也能在结果回来后重新接进对话。

口语表达依然会露馅，工具调用依然可能沉默，一个语气词也依然可能把它弄懵。线路已经接通，但与用户协作的默契还没有练完。

下一代语音 AI 的竞争也会继续沿着这些细节往前走。谁更用户所需要的细节，谁就更接近我们真正愿意长期交流的那个声音。