如何为 TTS 正确书写数字、日期、金额和单位

数字对阅读很紧凑，对语音却天然更容易产生歧义。人看到 1/5、2026、$14.99 或 3–30 s 时，会结合上下文迅速猜到读法；TTS 模型却必须在多个可能的 spoken form 中选择一个。

因此生产环境里最安全的原则不是“假设所有数字格式模型都能自动读对”，而是先决定听众应该听到什么，在重要场景用短句测试，必要时把写法改成更明确的口语形式。

先决定听众应该听到哪些词，再决定怎么写

先问一个简单问题：如果这句话由真人旁白来读，你希望他逐字说出什么？

例如：

你可能希望听到“fourteen dollars and ninety-nine cents”，也可能接受“fourteen ninety-nine”。只有 $14.99 这个视觉符号，并不能表达你的生产偏好。

如果精确措辞重要，就把 spoken form 直接写进生成脚本。

这对广告、教程、金融说明、产品定价，以及任何数字读错会损害信任的内容特别有价值。

年份不一定按普通基数词读

英文里的 2026 常见读法是 “twenty twenty-six”，但模型也可能根据上下文和语言采用更逐字的数字读法。

年份重要时，把它放进完整句子测试，而不是单独测一个数字。

如果结果不是你想要的，在 speech script 里显式写出目标读法。

但不要未经测试就把所有年份全局改成文字。很多模型本来就能正确处理年份，过度展开反而让源脚本更难维护。只在一致性真正重要时使用明确 spoken form。

日期必须消除 locale 歧义

08/09/2026 连人类都会根据国家习惯读成两个不同日期。

对旁白脚本，应直接写成目标语言里无歧义的形式，例如英文可使用：

或：

本地化时按照目标语言的正常日期顺序写，并实际试听。

不要以为切换了界面语言，numeric date 就自动不再有歧义。法律、账单、发布日期、活动日期等场景，应始终把清晰放在“格式紧凑”之前。

货币符号需要上下文

$ 并不只代表一种货币，而音频播出后听众也看不到原来的 symbol。

如果币种重要，不要只让模型读 $500，而应明确是 US dollars、Mexican pesos 或其他货币。

对于 $14.99 这类价格，可以比较紧凑数字输入和完整 spoken form，选择既正确又符合目标受众习惯的版本。

多语言内容也不要把英文货币书写规则原样复制到所有语言，因为货币名称、数字顺序、小数和千位分隔方式都可能不同。

百分比要和周围数字一起审核

简单的 25% 通常不难，但问题常出现在同一句里叠加多个百分比、小数和 range。

例如：

语法和数字都可以是正确的，但对听众一次性处理三个百分比仍然很重。

如果三组数字都必须保留，可以拆成两个句子，让每个数字有更明确的语义位置。

对旁白来说，“能否第一次听懂”也是质量指标。技术上读对不代表这句就是好音频。

长小数要先确认是否真的需要全部精度

3.14 很容易理解，但 0.037582 这样的长 decimal 可能变得冗长，甚至被逐位读出。

先问听众是否真的需要完整精度。如果不需要，而且内容允许，可以在脚本层做合理 round；如果必须精确，就应测试实际朗读，并在必要时显式写出目标 sequence。

科学、金融、医疗等高风险内容不能为了“听起来更顺”擅自降低或修改精度。这里应保持事实，并进行人工审核。

范围符号容易产生误读

3–30 seconds 可能正确朗读，也可能因为 dash type、locale 或模型行为出现不稳定。

如果这是重要用户说明，可以直接写成：

目标是让听众知道范围，而不是保留漂亮但有歧义的 typography。

日期范围、价格范围和数量范围都可以采用同样原则。

单位和符号要匹配受众

5 km、10 GB、44.1 kHz、250 ms 都是“数字 + abbreviation”。

技术受众可能更习惯听缩写；普通用户则可能更容易理解完整展开形式。

例如教程可以说：

而不是强迫模型解释 10 MB。

两种都可能正确。先看听众和最终媒介，再决定是否展开。如果模型已经自然读对，就没有必要为了形式统一而全部改写。

序数词与版本号需要专门检查

1st、2nd、3rd、21st 常出现在排名、步骤和日期中。

要在完整句子里测试。若 21st 不稳定，就写成 “twenty-first”。日期则优先采用目标语言自然日期表达，不要自己拼数字 + suffix。

版本也一样：如果听众没有画面支持，the second version 可能比 v2 更容易理解。

大数字不仅要“读对”，还要“听得懂”

1,250,000 即便发音完全正确，放在一串其他数字旁边仍可能让听众失去重点。

可以根据信息需求选择：

或者在必须精确时：

决定标准是“听众必须记住什么”。

旁白不是 spreadsheet，不需要为了忠实视觉格式，把听众推入一堵数字墙。

acronym + number 会叠加歧义

API v2.5 supports 5 languages 同时包含 acronym、version 和 count。

不要分别测试三个 token 后就认为整句没问题，应把它当成一个完整语音单元测试。

需要时可以改成：

至于 API 是否展开，应根据项目的既定发音和受众决定。重点是逐个诊断歧义 token，而不是在整句话周围乱加标点。

多语言脚本必须按目标语言重新审核数值格式

英语能工作的 numeric format，未必适用于 Spanish、Japanese、Chinese 或 Arabic。

多语言生成前至少确认：

1. 数字格式本身也进行了本地化，而不仅是旁边文字；
2. decimal 和 thousands separators 符合目标地区；
3. 日期没有 day/month 歧义；
4. 必要时明确货币名称；
5. unit 与 abbreviation 在目标语言中读法正确；
6. 试听完整句子，而不是只听孤立数字。

跨语言声音克隆不会消除语言编辑工作。

建立一个小型 numeric regression set

如果项目经常出现价格、日期、版本、百分比和单位，保存一段固定测试脚本。

例如：

每次切换模型、目标语言或重要数字格式规则后，先重新生成这段。

它不能替代完整审核，但可以快速发现“以前稳定的已知数字突然读变了”。

数字读错时做单变量测试

如果某一行失败，不要同时换 reference、调 pace、改标点、换 model。

先只比较两种文本：

A：

B：

其余条件保持不变。

如果 B 解决问题，说明这是 text normalization 问题，而不是 reference voice 问题。

最终检查清单

正式生成前扫描脚本，重点找：

• 可能被两种方式解释的 numeric date；
• 没有明确币种的 currency symbol；
• 过长 decimal 或没必要的精度；
• 使用不明确 dash 的 range；
• 模型可能读不好的紧凑 unit；
• ordinal 和 version number；
• 听觉上过于复杂的大数字；
• 应逐字符朗读的 identifier；
• 从其他 locale 直接复制来的 separator。

目标是可预测、清楚的语音，而不是尽可能短的文字。

只要某个数字重要，就应该站在听众角度写。脚本里多几个词，往往能避免成片里最尴尬、最损害专业感的一句。