Gemini 3.5 Transcribe 怎么用：文件转录与实时语音 API 选择指南

如果输入是已经录好的会议、采访或客服通话，使用 gemini-3.5-transcribe；如果输入是麦克风或持续到达的音频流，使用 gemini-3.5-transcribe-live。这两个模型都把语音转成文字，但接口、时长和可用标注不同。

不要把它们与 Gemini 3.5 Live Translate 混在一起。Live Translate 的任务是把一种语言的语音实时变成另一种语言的语音；Transcribe 的输出是文字。一般 Gemini 模型虽然也能理解音频、回答问题或总结内容，但新模型给出了专门的转录合同，适合需要稳定字段、实时增量文本或词级标注的应用。

Google 在 2026 年 8 月 26 日发布 Gemini 3.5 Transcribe，并把开发者 API 标为 public preview。这意味着可以开始验证和集成，但模型行为、限制、价格与可用性仍可能变化，不应只凭一次演示直接承担不可回滚的生产流量。

先按输入和输出选路线

官方模型页列出的两条模型 ID 是：

• gemini-3.5-transcribe：处理上传的录音文件，返回文字和可选的 word annotations。
• gemini-3.5-transcribe-live：通过 Live API 的双向连接接收连续音频，返回增量文字。

把 model ID 放进配置而不是散落在业务代码中。Preview 阶段如果接口或版本变化，只需要更新一个受控入口，也更容易保留回滚路径。

逐字稿和“智能转录”不是同一份记录

默认的 verbatim 模式尽量保留说出的内容，包括口头禅、重复、停顿和自我纠正。它适合访谈存档、质检、证据复核、字幕对齐，以及任何需要回到原始音频核查的场景。

smart 模式会主动删除“嗯”“呃”等填充词，把“周二——不，改周三下午两点”整理成最终决定，并自动处理列表、日期、金额、大小写和段落。它适合把口述快速变成会议纪要、待办或可读草稿，但它不是逐字证据。

这个选择还有技术后果。根据音频转录指南，smart 模式不能与 timestamp_granularities 或 diarization_mode 组合。需要时间戳或说话人时，应使用 verbatim，再在应用层另做摘要或润色。这样既保留原始记录，也能生成阅读版本。

用 JavaScript 转录一个文件

下面使用 Google Gen AI SDK 的 Files API 上传音频，再通过 Interactions API 创建转录。API key 由运行环境提供，不要写进浏览器代码或提交到仓库。

js
import { GoogleGenAI } from "@google/genai";

const client = new GoogleGenAI({});

const audioFile = await client.files.upload({
  file: "./meeting.mp3",
  config: { mime_type: "audio/mp3" },
});

const interaction = await client.interactions.create({
  model: "gemini-3.5-transcribe",
  input: [
    {
      type: "audio",
      uri: audioFile.uri,
      mime_type: audioFile.mimeType,
    },
  ],
  generation_config: {
    transcription_config: {
      language_codes: ["cmn-Hans-CN"],
      custom_vocabulary: ["Gemini", "Interactions API", "LaoZhang"],
      mode: { type: "smart" },
    },
  },
});

console.log(interaction.output_text);

Google 当前语言表对简体普通话使用 cmn-Hans-CN，不是 zh-CN。如果音频可能在中文和英文之间切换，可以省略 language_codes 或传空数组，让模型按发言自动识别语言。已知语言时给出正确提示通常更便于测试稳定性。

custom_vocabulary 可以提供产品名、人名、缩写和行业词。上限是 1,000 个词，但 Google 建议通常把高价值词控制在 100 个以内。不要把普通词典全部塞入：只加入模型容易听错、且听错会改变业务结果的词。

如果需要词级时间戳和说话人，把 mode 改为 verbatim 配置：

js
generation_config: {
  transcription_config: {
    language_codes: ["cmn-Hans-CN"],
    mode: {
      type: "verbatim",
      timestamp_granularities: ["word"],
      diarization_mode: "speaker",
    },
  },
}

完整文字仍在 interaction.output_text。详细时间和 speaker 信息位于返回内容的 word annotations 中，需要按 SDK 对象的 steps → content → annotations 读取，不能假设输出文本会自动带 [Speaker 1] 标签。

实时转录需要处理“暂定”和“最终”两种文本

Live transcription 指南把它定义为持续的语音识别管线，而不是会听、思考再说话的语音助手。客户端发送原始音频，服务端会给出快速变化的 interim 文本和确认后的 final 文本。

界面可以用 interim 提供低延迟字幕，但不能立即永久保存或触发业务动作；新的音频可能让模型改写它。数据库、搜索索引、工单摘要和计费记录应使用 final 事件。网络中断后还需要明确会话边界，避免把重连前后的重复片段写两次。

Live 当前不提供说话人分离和词级时间戳。若会议结束后必须得到精确标注，可以实时显示字幕，同时把原音频安全保存；会后再把文件送到 unary 模型生成最终记录。这个双路径设计会增加存储与隐私责任，因此只有在确实需要“现场可见 + 会后可审计”时才值得采用。

价格很低，但别只算音频输入

截至 2026 年 8 月 27 日，Gemini Developer API 定价页给出的估算为：

因此，60 分钟录音的模型费用估算约 $0.30；实时路线按同样时长理论估算约 $0.54，但当前需要跨多个 10 分钟会话。实际总成本还包括上传、存储、重试、后处理、人工抽检和失败录音。价格来自音频与文字 token 的估算，不是固定包月报价。

定价表还注明：免费层提交内容可能用于改进 Google 产品，付费层标为不用于此目的。涉及客户通话、医疗、法律、未成年人或公司机密时，不要只看“免费可用”；应先确认当前条款、地区要求、保留策略、访问控制和删除流程。

上线前用自己的音频做一组可判定测试

Google 的发布说明公布了 4.0% streaming WER 和 2.6% non-streaming WER，并注明测量来自 Artificial Analysis。它还公布了 FLEURS 多语言结果和相对 Chirp 3 的延迟改善。这些数字能说明模型定位，但不能预测你的客服噪声、方言、产品编号或多人抢话。

准备一小组具有明确答案的真实样本，至少覆盖安静与噪声、单人和多人、数字/金额/订单号、代码切换、专有名词和长停顿。分别比较 verbatim、smart、语言提示与精简词表，记录漏词、错号、speaker 归属、final 延迟和每个可接受结果的成本。

如果你需要可审计的会议记录，从 unary + verbatim 开始；如果需要把口述直接变成可读草稿，测试 smart；如果需要现场字幕，再单独验证 live 的重连和 final 事件。先让输出合同匹配任务，再讨论哪项 WER 更漂亮。