Google正式推出Gemini 3.8 Flash TTS，重点面向高保真配音、细腻表演、地区口音和长篇内容稳定性。它与普通聊天语音不同：输入是需要原样朗读的文本，输出是音频，风格通过结构化元数据和少量行内事件标签控制。对于课程、播客、有声内容和企业宣传，正确拆分脚本与声音指令比堆叠形容词更重要。
一、先判断TTS是否适合任务
TTS适合已经确定文稿、需要稳定复现的配音任务，例如产品说明、课程旁白和有声文章。实时客服对话更适合Live API，因为它需要听取用户语音并动态回应。不要用TTS承担事实生成，先由文本模型和编辑人员确认稿件，再进入合成环节，能避免错误内容被批量制作成音频。
二、把台词与表演指令分开
Gemini 3.8把输入文本视为需要原样朗读的台词，持续性的语速、情绪、口音和角色信息应写入speech_metadata，而不是混在正文里。否则“请温柔地说”可能被直接念出来。只有笑声、叹气、咳嗽或短暂停顿等瞬时事件适合使用行内标签。结构分离后，文稿也更容易复用和审校。
三、中文配音提示怎样写
先定义用途、听众、语速和情绪，再补充专有名词读法。例如要求面向初学者、语速中等、语气可信而不过度宣传，并为英文缩写提供读音提示。避免同时要求严肃、兴奋、轻松和紧迫等互相冲突的风格。可先生成十五秒样音，确认声线和节奏后再合成长稿。
四、长内容必须分段生产
长篇课程或有声书应按自然章节切分，每段保留角色、语速和环境一致性。切分点放在段落或场景结束处，不要截断句子。每段生成后记录模型、声音ID、提示版本和采样时间，最后统一响度、静音长度与背景噪声。这样某一段出错时只需重做局部，不必重新生成整集。
五、多角色对话的限制
单次多说话人生成适合最多两位预置声音。若使用自定义或复制声音，应分别合成每位角色的台词，再按时间轴拼接PCM音频。制作访谈时给每轮台词标明speaker，并检查角色是否串音。多人播客则更适合逐轨生产，每个角色独立做音量、呼吸和停顿处理。
六、建立发音词典与样本集
品牌名、人名、地名和行业术语容易读错，应建立项目级发音词典，并用固定短句测试。中文还要检查多音字、数字、日期、单位和中英文混读。验收样本应覆盖短句、长句、问句、列表和情绪变化，不要只听一段最顺耳的展示音频。发现问题后优先修改文本和元数据，而不是反复碰运气。
七、上线前做听感与事实双审
音频验收既要听自然度，也要对照原稿逐字检查。重点关注漏读、重复、数字错误、角色漂移、异常停顿和音量突变。医疗、金融和公共服务内容还要由专业人员确认事实。建议保存文字稿并为播放器提供字幕，让听障用户和静音环境用户也能获得完整信息。
八、适合普通人的落地流程
先完成一篇五百字以内的定稿，选择预置声音做三种风格样音，由目标听众盲听选择；再分段合成、逐段校对、统一后期并导出。上线后记录完播率、跳出位置和用户反馈。不要把“声音像真人”当成唯一指标，听众能否听懂、是否信任、是否愿意继续收听才是最终标准。
