如何写出更好的 TTS 脚本：标点、数字、缩写与自然口语

TTS 质量不只由声音模型决定。脚本本身会告诉模型：一个观点在哪里结束、下一个观点在哪里开始，数字应该怎么读，哪些缩写存在歧义，以及一个真人通常会在哪里停顿。

所以真正好用的 TTS 脚本，不是把文章直接复制进生成器，而是为“听”重新编辑过的一版内容。

为“一次听懂”而写

读者可以停下来、回看、扫视标题和重新理解一段话；听众往往只能顺着时间线听一次，而且可能同时在开车、剪视频、做家务或看画面。

这意味着语音脚本应该尽早暴露结构。

优先使用直接句子、明确转场和“一句话一个主要意思”。如果一个句子同时包含多个嵌套从句、条件和补充说明，先拆开，再生成。

目标不是把内容写得幼稚，而是让听众不依赖视觉页面也能理解。

生成前自己朗读一遍

这是成本最低、速度最快的 QA。

如果你自己朗读时会：

• 绊住；
• 一口气读不完；
• 下意识换词；
• 不知道某个缩写怎么读；
• 在文本没有标点的位置自然停顿；

那脚本通常还没准备好。

朗读能很快暴露重复词、隐藏歧义、过长句子，以及“屏幕上看起来正常、说出来却很怪”的标点。

把标点当作表达结构，而不是隐藏控制码

标点不是精确的 prosody language，但它能提供重要结构。

句号通常是最清晰的完整思想边界；逗号适合自然短分组；冒号可以引出解释或列表；问号帮助模型区分问题与陈述。

不要为了强制戏剧性停顿而随机堆逗号、省略号或破折号。脚本首先应该让一个人类编辑看得懂。

如果需要更强停顿，先问：这句话是不是本来就应该拆成两句？

数字按“希望听到的形式”改写

数字在视觉上很紧凑，对声音却可能有多种读法。

例如 2026/08/23 可能存在日期顺序歧义；3.5 在不同上下文里可能希望听到“three point five”或“三点五”；$14.99 还涉及具体货币和小数读法。

重要内容不要完全交给模型猜。

需要时，把日期、金额、百分比、范围和版本号改成目标语言中真正希望被说出的形式。

屏幕显示可以继续保持紧凑格式，speech script 可以更明确。两者本来就是不同媒介。

重要缩写要提前确定读法

有的 acronym 按字母读，有的当一个词读，有的应该展开成完整短语。

模型不一定知道你的项目想采用哪一种。

如果缩写很关键，就用一个自然短句测试它。找到稳定的 speech-friendly rendering 后，在整个项目保持一致。

这对公司名、技术产品、医疗术语、内部缩写、模型名和版本名尤其重要。

URL 和邮箱要有意识地处理

页面上出现一个 URL，不代表旁白必须把整个 URL 读一遍。

先问听众到底需要什么：

• 需要精确输入地址？
• 还是只需要知道“访问我们的网站”？
• 精确地址是否已经显示在屏幕上？

很多视频和产品演示里，更好的设计是让视觉通道负责精确字符串，让语音负责含义和行动指令。

邮箱同样如此。逐字符念完整地址可能非常笨重；如果画面已经显示，可以只说“发送邮件给我们的支持团队”。

不要把所有可见文本都自动塞进 narration。

把视觉列表改造成听觉结构

bullet list 对阅读者很方便，因为他们可以一眼扫到所有项目；听众只能一个接一个接收。

因此长列表直接朗读容易变得机械、单调，也不容易记住结构。

可以加入“首先、接着、最后”等转场，或者把相关项目分成两三组。

如果听众确实需要记住精确清单，可以让音频解释逻辑，同时让屏幕承担完整列表。

姓名和品牌要尽早测试

困难专名不要等到最终批量生成才第一次听。

把姓名或品牌放进一个普通短句测试，比孤立地测试一个词更接近真实使用。

跨语言时还要提前决定：

• 使用 source-language pronunciation；
• 还是采用目标市场常见的 localized pronunciation。

重要的是确定一种合理、经过审核的方式，然后在所有 clip 里保持一致，而不是每次都让模型重新猜。

减少括号式写作

括号、脚注、引用和补充说明在文章里很常见，因为读者能利用排版理解层级；朗读时它们经常变成突然插入的口头中断。

如果括号信息重要，把它改成正常句子；如果对听众没有必要，就删掉。

脚注、citation 和 reference 也要问同样的问题：它们是否属于“听觉体验”，还是只应该留在页面上？

长内容也用较小、完整的语义块生成

最终作品很长，不代表一次生成就应该很长。

paragraph-sized section 通常既保留足够上下文，又方便返工。

按意思和自然停顿拆，不要为了某个字符数限制在一句话中间切开。

如果一个产品名读错，只重生成对应段落，比整章返工更便宜。

把视觉转场改成真正的口语转场

视觉文档依赖标题、字号、留白和章节结构告诉读者“现在进入新主题”。音频没有这些静态提示。

例如页面只有一个 Security 标题时，旁白可能需要一句：

章节变化、话题切换和总结也可以使用类似的 orientation sentence。

不要假设一个不会被朗读的 heading 能自动出现在听众脑中。

保持整篇语气一致

一个脚本可能由 marketing copy、technical docs、help center 和 support text 拼起来。这些原始材料经常使用完全不同的正式程度、句长和词汇。

生成之前，应先统一成一个 speaking style：

• 正式程度；
• 常见句长；
• 术语；
• 第二人称用法；
• 转场方式。

很多所谓“声音不一致”，其实先在写作层面就已经不一致。统一脚本风格往往无需换模型就能改善整体感受。

把发音测试当作写作工作的一部分

如果一个词反复读错，不要等到 final batch 后再逐条修音频。

创建一个短测试句，只改变该词的写法；找到稳定形式后，把它记录到 pronunciation guide。

这意味着发音不是“生成后的 QA 才处理”，而是 script authoring 的一部分。

生成后必须对照批准脚本审核

生成完成后，不只听“好不好听”，还要确认音频是否忠实反映 approved text。

检查：

• 是否漏词；
• 是否重复；
• 是否出现意外停顿；
• 数字或缩写是否被错误解释；
• 某种读法是否改变了原意。

如果同一个错误在很多 section 重复出现，不要逐条手工修 output。应该修的是 script convention，让后续所有生成都受益。

Speech-first 编辑清单

生成前确认：

1. 每句话自己朗读都舒服；
2. 标点对应自然结构；
3. 重要数字不存在读法歧义；
4. acronym 有明确 spoken form；
5. 姓名和品牌已测试；
6. URL、邮箱和视觉专用文字被有意识处理；
7. 视觉 heading 在需要时有 spoken transition；
8. 长段落按含义拆分；
9. 整个项目的 tone、句长和术语一致；
10. 已知 pronunciation rule 被记录并复用。

一个好的 TTS 模型只能利用它收到的结构。真正为听众写作，会减少无意义的重生成，让发音更容易审核，也会让最终音频听起来像“专门为语音设计”，而不是“把文档读出来”。