这项研究由多所高校与科研机构组成的联合团队完成，相关论文已以预印本形式于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%的情况存在出入。因此，研究团队建议部署时对两个输出均进行审核，切勿仅因屏幕上的文字而直接使用。
