Google 在 Gemini API 中推出 Gemini 3.5 Transcribe，提供实时流式和预录音频两条转写路径，支持 85+ 语言、自我纠正、填充词清理、说话人归属与逐词时间戳等功能。该服务面向实时字幕、语音代理与会议转写，强调可嵌入工作流、与其他 Gemini 模型协作及开发者自定义词汇能力。
Google 正把语音识别从“把声音变成文字”推向更接近工作流组件的方向。公司在 Gemini API 中推出 Gemini 3.5 Transcribe，面向开发者提供实时流式转写和预录音频处理两条路径，支持自动识别 85 种以上语言、处理自我纠正和填充词，并在录音场景中提供说话人归属与逐词时间戳。
需要先厘清一个名称问题：目前能够由 Google 官方页面核实的产品名称是 Gemini 3.5 Transcribe，实时模型的模型代码为 gemini-3.5-transcribe-live。原始输入中出现的“Gemini 3.8 Live”并未在此次语音转写发布的官方页面中得到对应支持。Google 官方文章的发布日期为 2026 年 8 月 26 日，而此次开发者资讯页面标注为 2026 年 9 月 15 日，两者属于发布时间记录差异。
两条 API 路径对应两种语音需求
Gemini 3.5 Transcribe 并不是一个只提供单一接口的通用听写工具。Google把它拆分为实时流式和预录音频两种模式，分别服务于不同的产品流程。
实时模式通过 Gemini Live API 调用 gemini-3.5-transcribe-live。它使用双向流式连接，让开发者在用户说话的同时接收不断更新的转写结果。Google称，该模式面向语音代理和实时字幕等交互式应用，延迟可低于一秒。
开发者可以通过 WebSocket 或 Google Gen AI SDK 接入实时转写。Live API 会先提供仍可能变化的临时结果，随后在说话人停顿或语音段落结束后发送最终转写。这样的设计适合字幕、语音输入和实时客服等需要即时反馈的场景，但实时模式目前不支持说话人分离和逐词时间戳，单个会话最长为 10 分钟。
预录音频则通过 Interactions API 调用 gemini-3.5-transcribe。该模式可处理会议录音、客服通话和其他音频文件，最长音频时长为一小时；如果启用说话人分离或逐词时间戳，音频上限会缩短至 30 分钟。Google的开发者文档显示，文件转写支持最多 8 名说话人，但三名以上说话人的归属仍属于实验性能力。
这一区分反映了语音产品中的一个基本取舍：实时系统首先要降低延迟、保持连续交互，离线处理则可以牺牲部分即时性，换取更丰富的结构化输出。
Google强调“智能转写”而不只是降低字错误率
Gemini 3.5 Transcribe 的主要卖点，是让转写结果更接近可以直接使用的文本。
Google举例称，模型能够处理“我们周二见——不，周三”这样的自我纠正，把最终文本整理为正确表达；它还可以删除“嗯”“啊”等填充词，并自动处理标点、大小写和列表格式。在需要保留原话的场景，开发者也可以使用默认的逐字转写模式，而不是让模型主动清理口语。
模型还支持自定义词汇。开发者可以提交最多 1,000 个术语、缩写、品牌名或专有名词，帮助系统识别行业 jargon 和特殊拼写。Google表示，这项能力可用于订单号、邮政编码、产品编号、医疗术语和企业内部名称等容易在普通语音识别系统中出错的内容。
官方文档称，Gemini 3.5 Transcribe 可自动识别 85 种以上语言，并处理对话中的语言切换。支持列表包括简体中文、粤语、英语、日语、韩语、印地语、越南语和阿拉伯语等。不过，“模型支持某种语言”与“所有消费者产品都已在该语言和地区开放”并不是同一件事，实际可用范围仍取决于 API、产品入口和账户地区。
性能数字亮眼，但不能脱离测试条件理解
Google引用 Artificial Analysis 的测量结果称，Gemini 3.5 Transcribe 在流式场景的平均词错误率（WER）为 4.0%，非流式场景为 2.6%；公司同时表示，相比此前的 Chirp 3，最终转写所需时间缩短了 70%。在 FLEURS 多语言基准上，Google给出的流式和非流式 WER 分别为 5.50% 和 5.04%。
这些数字提供了发布时的性能锚点，但并不等同于所有设备、语言和录音环境中的结果。WER主要衡量文字错误，不能完整反映背景噪声、多人重叠说话、口音、停顿、数字识别和长对话稳定性。
这也是为什么语音模型的比较越来越需要多维度评测。AIFlux此前报道的 Hume Real World VoiceEQ 语音评测就指出，语音 AI 的能力可能在自然度、可靠性、噪声处理和长对话等维度上分化，单一排行榜或单项分数很难代表真实使用体验。
对于开发者来说，Google公布的 WER 和延迟数据更适合作为选型起点。真正部署前，仍需要用自己的音频样本、专业词汇、说话人数量和隐私环境进行测试，尤其不能把经过“智能清理”的文字未经审核地用于医疗、法律、客服投诉或其他高风险决策。
语音模型开始嵌入更长的任务链
Gemini 3.5 Transcribe 的重要变化还在于，它被定位为可嵌入其他系统的组件，而不是一个独立的转写页面。
一个实时语音代理可以先通过 Live API 接收语音，再把最终转写交给对话模型和工具调用系统。会议或客服平台则可以用预录音频接口生成带有说话人和时间戳的文本，再把结果交给其他模型完成摘要、分类、质检和信息抽取。转写、理解和执行被拆成不同环节后，企业可以分别管理模型、权限和成本。
Google称，Gemini 3.5 Transcribe 的能力已经出现在 Gemini 应用、Android 手机上的 Rambler，以及 macOS 版 Gemini 中。在 macOS 应用里，语音输入可以与屏幕上下文结合，帮助用户摘要本地文件、改写文本或触发图像生成等任务；Chrome中的网页语音输入功能则被列为即将推出。
这种“先说出目标，再由软件组织信息”的方向，也延伸到了 Google Workspace。此前的 Workspace 语音功能报道显示，Google正在把语音放进 Gmail、Docs 和 Keep，使其承担检索、整理和记录等更完整的操作入口。Gemini 3.5 Transcribe则为这类产品提供了更底层的语音理解能力。
但“能从语音中提取意图”并不意味着系统可以在没有授权的情况下替用户执行所有操作。Google的开发者文档仍然把函数调用、屏幕上下文和具体产品权限分开描述。对于企业部署而言，管理员能否限定数据访问范围、用户能否追溯信息来源、转写是否会保存，以及后续动作是否需要确认，可能与识别准确率同样重要。
与专用 ASR 模型形成不同路线
Gemini 3.5 Transcribe 还显示出通用音频模型与专用 ASR 模型之间的路线差异。近期 AIFlux报道的 IBM Granite Speech 5.0 TurboCTC主打约 4.7 亿参数、英语语音转录和高吞吐量，更适合大量录音的批处理或边缘部署。
相比之下，Gemini 3.5 Transcribe强调多语言、上下文、智能格式化、说话人信息和与其他 Gemini 模型协作的能力。两者并非简单的替代关系：批量归档可能更看重轻量模型的速度和成本，实时代理和跨语言工作流则可能更看重接口整合与上下文理解。
这意味着语音 AI 的竞争重点可能从“哪个模型的总分最高”，转向“哪一组组件更适合具体任务”。在同一企业系统中，转写、摘要、检索、工具调用和人工复核未必由同一个模型完成。
开发者可以从公开预览开始测试
Google表示，Gemini 3.5 Transcribe 已通过 Gemini API 在 Google AI Studio 中向开发者开放公开预览，也可通过 Gemini Enterprise Agent Platform 使用。企业客户未来还可以在 Gemini Enterprise for Customer Experience 中访问相关能力。
开发者可先从 Gemini 3.5 Transcribe 官方模型文档了解文件转写、语言检测、自定义词汇和输出限制，再根据实时需求查看 Live Transcription 文档。Google也提供了 Gemini 3.5 Transcribe 开发者指南，其中包含 Python、JavaScript 和 WebSocket 示例。
从目前的产品边界看，Gemini 3.5 Transcribe更像是 Gemini 音频模型家族中的一个专用组件，而不是解决所有语音识别问题的通用方案。它一方面提高了原始语音到格式化文本的质量，另一方面为实时代理、桌面助手和企业分析流程提供了更容易连接的入口。
语音 AI 下一阶段的关键，可能不只是把每个词听对，而是在真实噪声、多人对话和复杂工作上下文中，稳定理解用户的意图，并在获得明确授权和可追溯的前提下完成下一步工作。