TTS 中如何正确朗读缩写、产品名和特殊词

当“写法”和“自然读法”开始分离时，TTS 就会变得明显更难。缩写、公司名、开发者工具、版本号、用户名、外语姓名和新造品牌，在屏幕上可能一眼就懂，但对语音模型来说仍存在多种读法。

最可靠的生产习惯，是把两个目标明确分开：可见文字保留官方、准确的写法；语音脚本则使用能够稳定生成目标发音的写法。

这样做比在原稿里不断加入神秘标点、空格和临时 phonetic hack 更容易维护。

先决定：它应该当一个词读，还是逐字母读

有些 acronym 已经像普通词一样朗读，例如：

另一些通常逐字母念，例如：

常见词模型可能能自动判断，但少见缩写不一定。

不要只单独测试这个 token，而要把它放到自然句子里，例如：

如果读错，再测试更明确的 speech form，例如：

空格可能影响模型，但不同模型和语言表现可能不同。如果简单空格不稳定，可以进一步写成目标语言里明确的字母名称。

关键是：先做短测试，再决定是否要在整个项目中替换，而不是未经验证就全局改写。

把显示文本和语音文本分成两层

假设正式产品名是 IndexTTS2。页面、字幕和截图中应该继续保持这个官方拼写，但旁白完全可以使用一个已经验证、模型更容易读对的 speech rendering。

不要为了让 TTS 好念，就把正式产品名在所有地方改掉。

可以明确维护两层：

• display text：官方品牌、产品或技术写法；
• speech text：为了生成目标发音而准备的口语版本。

这对“文章同时又是视频脚本”“产品 tour 既有字幕又有旁白”“播客脚本来自文档”等场景特别有价值。

屏幕负责精确拼写，声音负责自然沟通。

字母 + 数字混合名称必须在上下文测试

GPT-5、iPhone 17、HTTP/2、IndexTTS 2.5 同时包含多种判断：

• 字母是逐个念还是当词念；
• 数字如何朗读；
• 连字符、斜线、小数点是否有意义；
• 产品名与版本号之间在哪里停顿。

不要假设紧凑显示形式每次都会得到同样声音。

必要时可以在英语 speech script 中测试：

但不要把这种英文逐字母方案机械复制给所有语言。不同 locale 的字母名和自然品牌读法可能完全不同。

品牌可能故意使用非标准读法

造词品牌的官方发音不一定和拼写看起来的一样。

如果品牌已经提供官方 pronunciation，就以它为目标。如果没有，在开始批量生产前也应该先确定一个内部标准，否则不同视频、不同编辑者可能把同一个品牌读成不同版本。

例如项目内部可以记录：

这类规则应该写进制作文档或项目 style guide，而不是依赖下一个生成者“还记得上次怎么念”。

不要用随机标点当发音 hack

一种常见做法是不断往词里塞句点、连字符、斜线或 apostrophe，直到某一次听起来接近目标。

问题是：这些符号不仅影响发音，也会改变 pause 和节奏。一条句子里偶然成功，并不代表在别的上下文稳定。

如果必须使用 workaround，至少测试：

• 位于句首；
• 位于句中；
• 后面接数字；
• 临近逗号、句号等标点。

只在一条句子中有效的写法是脆弱的。能用更清楚的 speech rendering 解决时，通常更值得采用。

把困难复合词拆成可听懂的单元

技术产品经常把几个熟悉部分拼成一个新词。

模型可能不认识整个 compound，却能正确读出拆开的各部分。在尝试复杂 phonetic spelling 前，先测试加空格或用更显式的描述能不能解决。

常见对象包括：

• 内部工具名；
• 模型 alias；
• repository 名；
• domain；
• command 名。

如果教程里用户必须知道精确拼写，可以先自然念名称，再在屏幕上展示准确 token；必要时再逐字母拼出来。

域名应该为“听众”设计读法

indextts.online 在视觉上很清楚，但点号对语音并不自然。

如果听众真的需要记住这个地址，可以用更适合旁白的形式，比如：

而屏幕继续显示精确域名。

如果 URL 已经显示在画面里，语音甚至可以更简单，因为视觉通道承担了精确拼写。

没有真实必要时，不要朗读长 URL、tracking 参数或 authentication link。它们既难听，也可能暴露不该公开的信息。

文件名和代码 token 要单独判断

教程中可能出现：

voice_01.wav

page.tsx

/api/generations

这些 code-like string 的下划线、斜线、点号对语音模型可能有不可预测影响。

首先问：听众是否真的需要“听懂精确 token”？

如果需要，可以拆成能理解的单位，例如：

如果不需要，更自然的方式往往是屏幕展示精确代码，旁白只说：

教学媒体里，声音适合传递含义，屏幕更适合承担精确 syntax。

外语姓名应由懂来源语言的人审核

多语言生成整体听起来很流畅，并不代表人名、地名或借词一定正确。

选择 Japanese、Spanish、Arabic、Chinese 或 English，也不能自动保证所有外国专名都被正确处理。

重要姓名可以按这个流程：

1. 确认来源语言；
2. 确认目标市场希望采用的读法；
3. 把姓名放进一条短自然句测试；
4. 必要时比较原生拼写或 transliteration；
5. 高曝光内容由懂该语言的人复核。

这是内容质量步骤，不只是一个模型 setting。

缩写可能因为上下文而有不同展开方式

同一个 short form 可能有多个含义。比如 Dr. 在姓名前通常是 doctor，但很多技术缩写可能应该逐字母读。

上下文往往能帮助模型，但重要内容不应该完全依赖猜测。

如果误读会很尴尬，就直接把歧义缩写展开。例如希望稳定朗读 Doctor Chen 时，speech script 直接写完整词可能比 Dr. Chen 更可靠。

对于 ms、GB、kHz 这类单位，也要根据受众决定是保留技术缩写，还是写成完整口语。

建立项目 pronunciation sheet

只要内容会重复生产，就应该维护一份小型发音表。

不需要专门软件。一份放在 repository 里的 Markdown 或文本表就足够。

它真正提供的是一致性：不会因为换了编辑者，同一个产品名突然换了发音。

保存一条 pronunciation regression sentence

当多个困难术语已经稳定后，把它们组合到一条短句里。

例如：

以后切换模型或目标语言时，先跑这条。

它不能证明整个项目都没问题，但能快速发现“之前稳定的已知词突然变了”的回归。

每次只改一个变量

产品名读错时，不要立刻换 reference、调 emotion、调 pace、改文本一起上。

先只做两个 text variant，其余保持不变。

A：

B：

只听目标产品名。如果 B 解决问题，就把 B 的 speech rendering 记录进发音表。

如果两个都不行，再继续测试另一种文本写法。受控迭代比随机调设置高效得多。

发音 workaround 不能改变事实

这是必须锁死的一条规则。

如果模型总把技术值、版本号、法律名称或货币读错，不能因为另一个数字更好念，就偷偷换成另一个事实。

必须保留 factual accuracy。能改的是：

• speech rendering；
• 句子拆分；
• 屏幕辅助信息；
• 发音规则。

不能改的是事实本身。

法律、金融、安全等高风险内容最终需要人工审核。

最终生产流程

正式生成前：

1. 标出所有 acronym、产品名、version、URL、code token 和外语姓名；
2. 为每个术语确定目标读法；
3. 把困难词放进自然短句测试；
4. 把成功的 speech rendering 记录进 pronunciation sheet；
5. 分离正式 display spelling 与语音优化文本；
6. 外语姓名和借词由懂对应语言的人审核；
7. 模型或语言改变后重跑小型 pronunciation regression。

特殊词并不是放弃 TTS 的理由，而是提醒我们：发音应该成为明确的生产步骤。

一旦难词被记录下来，后续脚本就会更快、更一致，也更容易审核。