谷歌发布了 Gemini 3.5 Transcribe，一款不满足于“把录音逐字打出来”的语音转文字模型。它的目标是将口语中的停顿、重复和临时改口整理成更像成稿的文本，因此更适合语音听写、做笔记、发送消息以及通过语音修改内容。谷歌称这是其迄今“最精准”的语音转文字模型，并将其定位为 Chirp 3 之后的一次重要升级。1 12

但这项改进也带来了一个不能忽略的区别：如果系统会删除“嗯”“呃”、合并自我纠正，并根据上下文推断说话者的意思，那么它可能生成更好读的文字，却不一定保留说话者的每一句原话。

Gemini 3.5 Transcribe 改变了什么

Gemini 3.5 Transcribe 的核心是谷歌所说的“智能转写”。传统语音识别通常会尽量把所有停顿、重复和未完成的句子保留下来；新模型则可以清理口语中的不流畅表达，采用说话者后来修正的版本，并自动添加标点和排版。它还能够理解语音编辑指令，将零散、没有结构的口述内容整理成更易读的文字。1 8 12

这使它尤其适合日常语音输入。用户可以像说话一样先快速讲出一段不完整的想法，最终得到更接近消息、文档或表单回复的文本，而不必一边说一边刻意组织句子。

模型还针对背景噪声、技术术语和专业词汇进行了优化。谷歌表示，用户可以提供自定义词汇表，让人名、产品名以及行业术语更有机会以指定拼写呈现；模型能够自动识别 85 种以上语言。1 7

在处理预录音频时，Gemini 3.5 Transcribe 支持时间戳，并可对最多三位说话者进行说话人区分，帮助开发者将不同片段对应到具体参与者。1

与 Chirp 3 相比：更快，也更准确？

谷歌将 Gemini 3.5 Transcribe 描述为对上一代 Chirp 3 的大幅提升。引用 Artificial Analysis 测量结果的报道显示，模型在非流式音频中的词错误率为 2.6%，流式音频为 4.0%，得到最终转写文本所需的时间则减少了 70%。3 4 9

不过，这些数字不能被理解为所有场景下都能稳定复现的保证。词错误率会受到语言、口音、录音质量、背景噪声和测试数据集等因素影响。谷歌官方材料引用的 FLEURS 基准测试则显示，该模型在流式模式下的词错误率为 5.50%；由于测试条件不同，这一结果不能与所有第三方测量直接横向比较。1

更实际的结论是：谷歌同时在追求两件事——让实时语音交互的等待时间更短，也让录音或听写内容在最终输出时更整洁。

开发者可选择两条路线：实时或预录音频

谷歌根据应用场景提供了不同的接入方式。

实时转写

实时方案面向需要持续接收音频并快速回应的应用。Gemini Live API 支持低延迟、实时的语音交互，也能提供用户输入和模型输出的音频转写。12 20

这类能力可用于语音助手、实时字幕、对话式界面，以及需要在用户仍在说话时同步生成文字的产品。谷歌 API 参考文档还区分了单次请求、流式和实时交互等调用方式。24

预录音频转写

对于已有的录音，开发者可以上传音频文件或引用文件地址，再通过 Gemini API 的交互流程提交处理。这种方式更适合批量处理现有录音，时间戳、格式化、自定义词汇和说话人归属往往比即时响应更重要。1 12 18

谷歌目前的 Gemini API 文档将 Interactions API 作为新 Gemini 应用的标准接口，而 Live API 则主要用于持续、低延迟的语音和视觉体验。19 20

它已经出现在哪些产品中

Gemini 3.5 Transcribe 并非只停留在开发者预览阶段。报道称，它已经为 Android Gboard 中的 Rambler 语音听写功能以及 macOS 版 Gemini 应用提供支持。2 13 26

谷歌还表示，Chrome 将加入由该模型支持的语音转文字功能。未来用户或许可以直接在网页文本框中听写消息、帖子、表单内容或提示词，而不必先打开专门的语音输入应用。1 8 13

该模型与 Gemini 3.5 Live、Gemini 3.5 Live Experimental 一同发布，构成谷歌更大的 Gemini Audio 产品线。在这一组合中，Transcribe 主要负责将语音转换为文字，Live 系列则侧重互动式音频体验。12 26

最大卖点，也是最大风险：润色文本不等于逐字记录

Gemini 3.5 Transcribe 最有吸引力的功能，恰恰也是它最需要用户留意的地方。删除填充词、合并改口并按照可能的表达意图整理句子，会让听写结果更容易阅读，但也会改变音频与文字之间的关系。

经过润色的结果可能省略有意义的停顿，只保留说话者修正后的版本，或抹平某些体现个人风格的表达。对于写消息、记笔记和填写表单，这通常是优点；但如果用户需要的是原话记录，它就可能成为问题。

在采访、法律或医疗记录、研究转录、无障碍文档以及需要直接引用原话的场景中，用户应保留原始音频，并核对重要段落。除非具体产品提供明确的“逐字转写”模式，否则 Gemini 3.5 Transcribe 更适合被理解为一种会进行智能整理的转写系统，而不是完全中立的录音文字化工具。

这次发布意味着什么

谷歌正在把语音识别进一步推向“语音辅助写作”。Gemini 3.5 Transcribe 将转写、内容清理、格式化、语言识别、自定义词汇和说话人信息整合到同一套能力中，同时为实时音频与录音文件提供不同工作流。1 12

对开发者来说，这可能减少语音识别之后所需的后处理工作；对普通用户来说，语音听写也许会不再像“对着机器小心翼翼地说话”，而更像是把一份粗略草稿交给编辑整理。

真正值得追问的，已经不只是模型能否生成更干净的文字，而是具体应用需要“干净的文字”，还是需要“准确记录说过什么”。

谷歌发布了 Gemini 3.5 Transcribe，一款不满足于“把录音逐字打出来”的语音转文字模型。它的目标是将口语中的停顿、重复和临时改口整理成更像成稿的文本，因此更适合语音听写、做笔记、发送消息以及通过语音修改内容。谷歌称这是其迄今“最精准”的语音转文字模型，并将其定位为 Chirp 3 之后的一次重要升级。1 12

但这项改进也带来了一个不能忽略的区别：如果系统会删除“嗯”“呃”、合并自我纠正，并根据上下文推断说话者的意思，那么它可能生成更好读的文字，却不一定保留说话者的每一句原话。

Gemini 3.5 Transcribe 改变了什么

Gemini 3.5 Transcribe 的核心是谷歌所说的“智能转写”。传统语音识别通常会尽量把所有停顿、重复和未完成的句子保留下来；新模型则可以清理口语中的不流畅表达，采用说话者后来修正的版本，并自动添加标点和排版。它还能够理解语音编辑指令，将零散、没有结构的口述内容整理成更易读的文字。1 8 12

这使它尤其适合日常语音输入。用户可以像说话一样先快速讲出一段不完整的想法，最终得到更接近消息、文档或表单回复的文本，而不必一边说一边刻意组织句子。

模型还针对背景噪声、技术术语和专业词汇进行了优化。谷歌表示，用户可以提供自定义词汇表，让人名、产品名以及行业术语更有机会以指定拼写呈现；模型能够自动识别 85 种以上语言。1 7

在处理预录音频时，Gemini 3.5 Transcribe 支持时间戳，并可对最多三位说话者进行说话人区分，帮助开发者将不同片段对应到具体参与者。1

与 Chirp 3 相比：更快，也更准确？

谷歌将 Gemini 3.5 Transcribe 描述为对上一代 Chirp 3 的大幅提升。引用 Artificial Analysis 测量结果的报道显示，模型在非流式音频中的词错误率为 2.6%，流式音频为 4.0%，得到最终转写文本所需的时间则减少了 70%。3 4 9

不过，这些数字不能被理解为所有场景下都能稳定复现的保证。词错误率会受到语言、口音、录音质量、背景噪声和测试数据集等因素影响。谷歌官方材料引用的 FLEURS 基准测试则显示，该模型在流式模式下的词错误率为 5.50%；由于测试条件不同，这一结果不能与所有第三方测量直接横向比较。1

更实际的结论是：谷歌同时在追求两件事——让实时语音交互的等待时间更短，也让录音或听写内容在最终输出时更整洁。

开发者可选择两条路线：实时或预录音频

谷歌根据应用场景提供了不同的接入方式。

实时转写

实时方案面向需要持续接收音频并快速回应的应用。Gemini Live API 支持低延迟、实时的语音交互，也能提供用户输入和模型输出的音频转写。12 20

这类能力可用于语音助手、实时字幕、对话式界面，以及需要在用户仍在说话时同步生成文字的产品。谷歌 API 参考文档还区分了单次请求、流式和实时交互等调用方式。24

预录音频转写

对于已有的录音，开发者可以上传音频文件或引用文件地址，再通过 Gemini API 的交互流程提交处理。这种方式更适合批量处理现有录音，时间戳、格式化、自定义词汇和说话人归属往往比即时响应更重要。1 12 18

谷歌目前的 Gemini API 文档将 Interactions API 作为新 Gemini 应用的标准接口，而 Live API 则主要用于持续、低延迟的语音和视觉体验。19 20

它已经出现在哪些产品中

Gemini 3.5 Transcribe 并非只停留在开发者预览阶段。报道称，它已经为 Android Gboard 中的 Rambler 语音听写功能以及 macOS 版 Gemini 应用提供支持。2 13 26

谷歌还表示，Chrome 将加入由该模型支持的语音转文字功能。未来用户或许可以直接在网页文本框中听写消息、帖子、表单内容或提示词，而不必先打开专门的语音输入应用。1 8 13

该模型与 Gemini 3.5 Live、Gemini 3.5 Live Experimental 一同发布，构成谷歌更大的 Gemini Audio 产品线。在这一组合中，Transcribe 主要负责将语音转换为文字，Live 系列则侧重互动式音频体验。12 26

最大卖点，也是最大风险：润色文本不等于逐字记录

Gemini 3.5 Transcribe 最有吸引力的功能，恰恰也是它最需要用户留意的地方。删除填充词、合并改口并按照可能的表达意图整理句子，会让听写结果更容易阅读，但也会改变音频与文字之间的关系。

经过润色的结果可能省略有意义的停顿，只保留说话者修正后的版本，或抹平某些体现个人风格的表达。对于写消息、记笔记和填写表单，这通常是优点；但如果用户需要的是原话记录，它就可能成为问题。

在采访、法律或医疗记录、研究转录、无障碍文档以及需要直接引用原话的场景中，用户应保留原始音频，并核对重要段落。除非具体产品提供明确的“逐字转写”模式，否则 Gemini 3.5 Transcribe 更适合被理解为一种会进行智能整理的转写系统，而不是完全中立的录音文字化工具。

这次发布意味着什么

谷歌正在把语音识别进一步推向“语音辅助写作”。Gemini 3.5 Transcribe 将转写、内容清理、格式化、语言识别、自定义词汇和说话人信息整合到同一套能力中，同时为实时音频与录音文件提供不同工作流。1 12

对开发者来说，这可能减少语音识别之后所需的后处理工作；对普通用户来说，语音听写也许会不再像“对着机器小心翼翼地说话”，而更像是把一份粗略草稿交给编辑整理。

真正值得追问的，已经不只是模型能否生成更干净的文字，而是具体应用需要“干净的文字”，还是需要“准确记录说过什么”。