Gemini API TTS 流式输出分段试听与验收

先划定草稿与成片边界

将每次生成的音频先标为草稿，只有完成检查后才转为可用版本。官方发布说明确认，Gemini API 曾为 TTS 预览模型提供语音流式支持；实际可用模型、请求字段和权限应以调用时的官方文档为准。

• 准备已确认可使用的文案，并保留原始版本号。
• 为每个试听单元分配段落编号，例如 P01、P02。
• 建立状态字段：待生成、生成中、待试听、需重做、已通过。
• 将草稿音频与最终导出目录隔离，避免误拿未完成文件。

按可试听的语义单元切分文案

不要仅按固定字数硬切。优先在自然段、完整句子或明确转折处切分；数字、专有名词和括号说明不要被拆到两个单元。每段应能独立试听，也要能和前后段连起来检查。

1. 先删除不需要朗读的标题标记、链接和编辑批注。
2. 用段落编号标记每个单元，并保留原文起止位置。
3. 在停顿处增加人工可读的断句标记，但不要把内部备注发送给语音请求。
4. 为容易读错的名称、英文缩写和数字建立发音备注，交由试听人员核对。

接收流式音频并保存过程状态

发起请求后，不要等全部音频完成才创建记录。收到流式数据时，将数据追加到当前段的临时文件或缓冲区，同时更新段落编号、请求时间、文案版本、模型标识和处理状态。界面可以提供试听入口，但应清楚显示该段仍在生成中。

当一个单元结束时，先把它标为待试听；只有整篇所有需要的单元都完成，才进入合并和发布检查。请求失败或用户主动取消时，保留已收到的片段及失败原因，不要自动把残缺结果标记为完成。

用一条口播样本建立版本记录

例如一段产品介绍分为 P01 开场、P02 功能说明、P03 行动提示。第一次生成后，P02 的停顿不自然，只重做 P02，并把新记录写为 v2；P01 和 P03 继续引用原先通过的版本。版本表至少包含段落编号、文案摘要、音频文件位置、生成时间、状态、试听结论和修改原因。

若团队还要把音频转为文字复核，可参考转写校对清单，将听到的关键数字、术语和人名与原文逐项对照。

常见故障怎么定位和修正

• 故障：中途有音频但状态一直未完成。原因可能是连接中断或完成信号未被应用记录。修正动作是将该段保留为未完成，记录最后接收位置，再重新请求该单元，不与旧片段直接拼接。
• 故障：断句生硬或读法不对。原因通常是切分位置破坏了语义，或文案中的缩写、数字缺少明确上下文。修正动作是调整到完整句边界，并为高风险词单独建立试听样本。
• 故障：同一段出现多个相似文件。原因是文件名没有关联段落和版本。修正动作是统一使用项目、段落、文案版本和生成序号命名，并只允许已通过状态进入导出列表。
• 故障：剪辑人员拿到了未完成音频。原因是草稿和成片共用目录或状态字段缺失。修正动作是隔离存储位置，并在导出前校验所有段落均为已通过。

发布前逐项验收

• 每个段落都有对应文案版本、音频文件和明确状态。
• 连续试听后，段落衔接、停顿和语速符合口播用途。
• 数字、术语、名称和行动提示没有遗漏或误读。
• 没有残缺音频、重复段落或混入旧版本。
• 导出的最终文件只包含已通过的段落，并保留可追溯的版本记录。