多所高校实现语音大模型新突破：当AI开口说话的同时还能写代码

来源：市场资讯

（来源：科技行者）

这项研究由多所高校及科研机构联合团队完成，论文以预印本形式于2026年5月4日发布在arXiv平台，编号为arXiv:2606.07547，有兴趣深入了解的读者可通过该编号查询完整原文。

假设你正在和一个AI语音助手交流，用说话的方式请它帮你写一段Python代码。它听完之后，嘴里流利地说着"好的，给你一个经典的二分查找实现"——但与此同时，一段完整、可以直接运行的代码也同步出现在你面前的屏幕上，就像有人边解释边写黑板一样。这不是科幻电影里的场景，而是这篇论文正在做到的事情。

这项研究的核心问题，其实可以用一句话来描述：当AI通过声音和你交流时，它有没有办法同时保留文字的能力？

### 一、说出来的答案，未必是最好的答案

人类在交流的时候有一个默契：嘴巴说出来的话和手写下来的内容，天生就适合做不同的事情。说话擅长的是节奏、轮换、互动，而写下来的东西——无论是代码、表格、数学推导，还是会议纪要——才是需要被精确保留、反复查阅、逐字核对的内容。想想一个技术评审会：与会者口头讨论，但最终要签字确认的是那份书面文件，没有人会把核心架构决策只寄托在声音上。

大语言模型本质上是一种"文字动物"。它最拿手的那些事情——写代码、生成结构化报告、推导数学步骤、制作Markdown表格——都需要在文字的空间里展开。但当这类模型被接上麦克风和扬声器，变成一个"语音助手"之后，一道无形的墙就出现了：所有输出都必须经过"能不能说出口"这道关卡。结果就是，一个本来可以输出漂亮Python代码的模型，只能对着用户把代码一个字母一个字母地念出来，逼得用户手忙脚乱地转录；一个本来可以生成整洁Markdown表格的模型，只能把表格拍扁成一段线性的口头叙述，让人听完一头雾水。

这就是这篇论文要解决的核心矛盾——研究团队把它称为"语音模态对LLM能力的压制"。

### 二、前人走过的路，以及那条没人走的路

在这项工作之前，已经有不少研究团队尝试为语音AI引入"思考"能力。这些尝试大致分成几条路线，可以用一场音乐会来打比方：有的方案是"演出前先排练"，也就是让模型先在脑子里把推理做完，再开口说话，这样虽然质量好但响应慢，而且在用户说话期间模型什么都没有做；有的方案是"边演奏边翻谱"，也就是把思考和说话交织在一起，但这种思考过程用户根本看不到，仍然是隐藏在幕后的；还有一类方案专注于解决"全双工"问题，也就是让AI在说话的同时也能听用户说话，但这类系统的输出只有声音，没有文字。

这篇论文的研究团队把这些方案整理成了一张对比表，沿着四个维度衡量每个方案：能不能实现真正的全双工互动（一边说话一边还在听）？能不能输出自由格式的文字？能不能在听的时候就开始认知处理？能不能在说话的同时继续产出文字？现有的任何一个方案，都在这四个维度里至少缺一项。有的模型可以全双工但没有文字输出，有的模型有文字输出但不是全双工，有的模型在听的时候有思考但一开口说话就停止了。

没有人走过这样一条路：让文字输出成为一个始终开着的、用户可见的"第一输出通道"，同时保持全双工的听和说。这就是研究团队选择开辟的方向，他们把它叫做**Listen-Write-Speak（听-写-说，简称LWS）**。

### 三、三个同时开着的频道，一个模型来承担

LWS的核心设计理念，可以用一个广播直播间的画面来理解。直播间里有三件事同时发生：主播的耳机里一直在收听外部的声音（听）；主播面前有一块白板，他用笔在上面实时写下结构化的信息——图表、代码、大纲（写）；同时主播的嘴也在对着麦克风说话，用口语化的方式向听众解说（说）。这三件事并不是依次进行的，而是真正同时运作的，共享同一个意识上下文。

LWS把整个对话时间轴切成一段一段的"单元（Unit）"，每个单元的时长是1秒。每一秒里，模型都在做以下的事情：接收这一秒的用户音频，生成这一秒的可见文字，以及（如果到了该说话的阶段）生成这一秒的语音内容。

当用户还在说话的时候，每个单元叫做"监听单元"。在这种单元里，模型一边消化音频，一边在屏幕上实时写出它正在理解到的内容——比如用户说"帮我写一个二分查找"，模型在用户话说到一半时，屏幕上可能已经出现了"用户在问关于二分查找的Python实现"这样的中间理解笔记。这些文字就像一个人边听边做的速记，用户可以全程看到。

当用户说完、模型进入回应阶段时，单元变为"发言单元"。在这种单元里，三件事同时运行：耳机还开着（模型仍在监听，以备用户随时打断）；嘴里开始说口语化的回应（"好的，这是一个经典的二分查找实现"）；白板上同时出现完整的代码（`def binary_search(arr, target): ...`）。说出来的话是对写出来的内容的口语解说版本，两者内容一致但形式不同，各司其职。

这个设计最巧妙的地方在于：它不需要改变模型的架构。整个三频道行为完全通过一套叫做"Token Schema（词元方案）"的特殊标记来实现，在标准的自回归Transformer里就能跑。没有额外的解码器，没有跨频道的对齐模块，模型还是那个模型，只是学会了用一套特殊的标点符号来分隔三条并行的输出流。

### 四、一套特殊的标记，让模型知道自己在干什么

Token Schema的设计思路，类比起来就像是一本有格式规范的会议记录模板。每一页（每个单元）的开头写``，然后先填入这一秒的音频内容，接着用特定的开闭标签包住这一秒的认知笔记或语音内容，最后以``收尾。

监听单元的格式是：单元开始标记，然后是10个音频词元（对应1秒的音频），然后是监听认知开始标记，接着是这一秒的可见文字内容，然后是监听认知结束标记，最后是单元结束标记。

发言单元则更复杂一些：单元开始，10个音频词元，然后是说话开始标记，接着是这一秒的口语词元，然后是语音块结束标记，随后切换到回应认知开始标记，再是这一秒的可见写作内容，最后是回应认知结束标记和单元结束标记。

研究团队特意把"听的时候写的文字"和"说的时候写的文字"用不同的标签区分开来，而不是用一个统一的标签。这背后有一个信息论上的道理：这两段文字所处的"时间位置"不同，所依赖的上下文也不同。听的时候写的内容，只能基于已经听到的音频；说的时候写的内容，除了音频还可以参考模型自己说出的话。把这两种状态明确区分开，可以让模型更清楚地知道自己当下处于哪种信息环境，从而减少下一个词的预测难度，并且避免在全双工互动中产生"时间因果污染"——也就是避免模型用还没说到的信息来影响当前的输出。

### 五、数据从哪里来：一条两阶段的流水线

训练这样一个模型需要特殊的数据：每一秒都有认知标注、与音频时间轴严格对齐的训练样本。这种数据在任何公开语料库里都不存在。研究团队因此设计了一套两阶段的数据构建流水线，从零开始合成这类数据。

第一阶段叫"离线认知合成"。起点是普通的文字问答对，然后用一个强大的"教师模型"（Qwen3-235B）来为这些问答对生成三条并行的文字流。第一条流是"流式推理链"，模拟一个人在逐秒听取用户提问时脑子里产生的理解过程，用来监督监听阶段的写作；第二条流是"语音回应"，是一个简洁的口语化改写版本，用来监督说话内容；第三条流就是原始的结构化回应本身，用来监督发言阶段的写作。这一步有个关键约束：模拟流式推理的时候，教师模型只能看到"到第t秒为止已经被说出的那部分输入"，不能提前知道用户后面还会说什么。这就像让一个人闭上右眼、只用左眼看逐渐展开的字幕，而不是一开始就看完整的文本。

第二阶段叫"在线时间轴构建"。这一步把第一阶段生成的文字流和真实的音频录音结合起来，利用CTC（一种字符级对齐技术）把每个字、每个词精确对应到音频里的时间点，然后按秒把整个对话分配成一系列单元，填入对应的音频词元和文字内容。为了让模型学会处理打断和接话，团队还对一部分训练样本做了"打断增强"——模拟用户在模型说话途中插话的情况。最终的训练集包含50万个中英文混合的样本，全部按照1秒单元的格式排列好。

### 六、实验结果：四个方向的测试

研究团队在四个不同的评测维度上检验了LWS的表现。

在语音理解与推理能力方面，研究团队使用了URO-Bench——一个分理解（U）、推理（R）、口语（O）三个维度、并且区分基础和进阶难度的多语言评测集。LWS在中文进阶（Pro）部分的整体平均分拿到了84.6，是所有测试模型里最高的，显著超过GPT-4o-Audio（67.1）和GPT-Realtime（70.6）。在中文进阶的理解和推理子项上，LWS分别拿到92.5和85.9，也都是最高分。英文部分的表现相对均衡，整体处于竞争水平。更关键的是，研究团队做了两个消融实验——一个去掉了"听的时候写"的功能，一个去掉了"说的时候写"的功能——结果显示，这两项功能任何一个被去掉，模型的表现都会系统性地下降，无论是中文还是英文、基础还是进阶，LWS完整版都稳定地优于两个消融版本。训练损失曲线也显示，三条频道在联合训练过程中都平滑收敛，没有出现互相干扰或不稳定的情况。

在回应质量方面，研究团队使用了VoiceBench AlpacaEval，这是一个语音转文字的评测协议：模型接受语音输入，但被评分的是文字输出，因此直接反映的是可见写作频道的质量。LWS拿到了4.72分，超过了所有列出的开源基线（VITA-1.5拿4.21，Step-Audio拿4.13，Freeze-Omni拿4.03，GLM-4-Voice拿3.97），与GPT-4o-Audio的4.78分只差0.06。

在写说一致性方面，研究团队担心的一个潜在问题是：同时生成写的内容和说的内容，会不会出现两者互相矛盾的情况？为了量化这个风险，研究团队抽取了636个样本，用GPT-5作为裁判，判断每个样本中说出来的内容是否与写出来的内容在事实上一致。结果是636个样本里有589个通过，一致性达到92.6%，说明两个用户面向频道在绝大多数情况下是协调的，引入可见写作并没有实质性地破坏回应的连贯性。

在全双工互动能力方面，研究团队使用了Full-Duplex-Bench，这个评测集包含四种场景：停顿处理（模型应该在用户暂停时正常接话）、反馈信号（模型应该在合适的时机发出"嗯"、"对"等简短回应）、轮次交替（流畅地从听转换到说）和打断处理（用户在模型说话时插话，模型能否正常响应）。在停顿处理上，LWS在合成停顿和自然停顿两个子项上都达到了0.01的接管率，与GPT-Realtime持平，是所有测试模型里最低的（越低说明模型越不会抢话）。在轮次交替上，LWS以0.48秒的延迟实现了0.97的Candor接管率，比大型商业实时模型快很多，同时保持了有竞争力的交替质量。在打断处理上，LWS以0.65秒的延迟获得了4.02的GPT-4o质量评分，说明它在被用户打断后仍然能够给出有质量的回应。

### 七、这个设计有什么局限性

研究团队坦诚地指出了两个当前的短板。

第一个局限是推理深度受限于实时性。因为每个单元只有1秒，模型必须在这1秒内同时完成听、写、说三件事，这对时间资源的要求很高。当遇到需要多步骤推导、长时间规划或者调用外部工具的复杂任务时，1秒内能写出的文字量是有限的，深度不足。如果要做更复杂的推理，可能需要一种机制让模型在说话之前多写几秒，但目前的框架还没有这样的功能。

第二个局限是输入界面比较窄。目前LWS只接受语音输入，用户不能同时给它看代码截图、粘贴表格或者上传图片。在真实的工作场景中，人们经常需要边说话边分享屏幕或文件，这种多模态输入场景目前还没有被覆盖，研究团队把它列为未来的重要方向。

### 八、这意味着什么

说到底，这篇论文提出的答案其实是一个很直接的想法：语音AI和文字AI不应该是两个分开的东西，而应该是同一个系统用不同的通道输出。声音负责流畅的对话体验，文字负责精确的、持久的、可以被检查和修改的内容。这两件事可以同时进行，而且不需要建一个全新的复杂架构，只需要给模型一套"标点规范"，让它知道每一秒该往哪个频道写什么。

这种思路对于未来的人机交互方式有一定的参考意义。当你对着设备说话，不再需要在"对话体验"和"得到有用的结构化输出"之间二选一。工程师可以口头讨论需求，同时看到代码在屏幕上成形；学生可以和AI口头探讨数学题，同时看到推导步骤被写出来；会议参与者可以在讨论进行的同时，看到摘要和决策被实时记录下来。嘴巴和笔，终于可以属于同一个AI。

值得思考的一个问题是：当AI既能说又能写，而且写出来的东西看起来精心完整，用户会不会更容易把这些输出当作权威答案，从而减少自己的核查？研究团队在伦理声明部分也提到了这个担忧，他们建议在部署时对两个输出频道同步做内容审核，并明确告知用户可见写作是一种辅助性的中间输出，而非经过验证的事实。这个提醒值得记住。

有兴趣进一步了解技术细节的读者，可以通过arXiv编号2606.07547找到完整的原始论文，其中附录部分包含了完整的推理流程示例、数据构建的详细参数和所有评测的评判提示词，信息量相当丰富。

**Q&A**

Q1：Listen-Write-Speak模型和普通的语音助手有什么区别？

A：普通语音助手只能输出声音，你问它写代码，它只能把代码一个字一个字地念出来。Listen-Write-Speak在回答的同时会把完整的代码或结构化内容同步显示在屏幕上，说出来的是口语解释，写出来的是可以直接使用的精确内容，两个频道同时工作，各自做最擅长的事。

Q2：Listen-Write-Speak的"全双工"是什么意思？

A：全双工意味着模型在说话的同时，耳朵也没有关掉，还在持续监听你说的话。如果你在它回答的中途打断它，它能立刻感知到并作出反应，不像很多语音助手说话时完全"失聪"，必须等它说完才能接收新的指令。这让对话更接近真实的人与人之间的交流节奏。

Q3：Listen-Write-Speak在写出来的内容和说出来的内容之间会不会出现矛盾？

A：研究团队专门测试了这个问题，在636个测试样本中，两个频道内容一致的有589个，一致率达到92.6%。也就是说绝大多数时候写的和说的是协调的，但仍有约7%的情况存在出入，因此研究团队建议部署时对两个输出都做审核，不要只看屏幕上的文字就直接使用。