保护你的 TTS 积分，打磨你的音频：内容评分与文本规范化

在网站上构建自助式 TTS，会悄悄遇到两个与音色、模型或 API 关系不大的问题。第一，原始文本很少能以你期望的方式从扬声器里播放出来。第二，一旦你把 TTS 接口放到公开页面上，陌生人就能调用它。TTS2Go 用两个专门的系统来解决这两个问题：一条在合成前改写别扭输入的文本规范化流水线，以及一个只自动批准真正属于你网站内容的 AI 内容评分层。本文将逐一介绍这两个系统、它们存在的原因，以及为什么两者结合起来才至关重要。

浏览器 SDK 需要知道自己属于哪个项目，而这个标识符就存在于用户可以查看的代码中。你可以用域名白名单和速率限制来加固它，但这个标识符并不是机密。如果有人找到了这个接口，就能发送请求。而每一个请求一旦进入合成环节，都可能消耗你在服务商那里的额度。

本能的做法是要求每个请求在生成前都由人工审批。这样做没错——TTS2Go 默认也正是这么做的。但这项工作的增长速度会超过负责它的团队。等你的网站有了真实流量，人工审批就会变成一项全职的打扰。

在质量方面，不同的 TTS 服务商对常见格式的读法并不一致。像 “2026-04-21” 这样的日期，在一个引擎上可能读成 “April twenty-first, twenty twenty-six”，在另一个引擎上却读成 “twenty twenty-six dash oh four dash twenty-one”。货币、时间、缩写和大数字的表现都难以预测。你的写作者无法控制服务商的内部实现，而服务商也不了解你的内容。

每个 TTS2Go 项目一开始都使用人工审批。当 SDK 发出生成请求时，请求会进入控制台的队列。你审核之后批准或拒绝，只有获批的请求才会消耗积分。这是安全的默认设置，而且行之有效——在意以自己品牌声音发出的每一段音频的团队，可以完全掌控一切。

但它也很慢。流量足够大时，它就会变成那种让你开始希望能交给机器处理的工作流程。

AI 内容评分就是那台机器。你为每个项目配置一份简短的内容配置文件：描述网站的主题、类型、语言，并提供几段示例片段。当生成请求到来时，TTS2Go 会把请求文本和配置文件一起发送给语言模型，模型返回一个 1 到 10 的分数，并附上简短的理由。

你可以自行设定阈值。达到或高于阈值的请求会被自动批准并送去合成。低于阈值的请求，可以根据你网站的实际情况，选择退回人工审批队列，或直接拒绝。这个评分并非非此即彼——从最低的 “垃圾内容或滥用”，到 “略微相关”、“可能匹配”、“较好匹配”，一直到最高的 “完全匹配”。你可以根据内容构成，设定严格或宽松的标准。

效果是：那些找到你的接口、试图生成无关文本的陌生人会得到低分，根本到不了合成环节；而来自你自己页面的正常内容会得到高分，无需你介入就能被朗读出来。你只需要关注中间地带，而且只在你想看的时候看。

评分针对的是原始文本，而不是规范化后的版本，因为评分关注的是内容是否合适，而不是音频最终听起来如何。

内容获批生成之后，下一个问题是它听起来会怎样。TTS2Go 会让每个获批的请求在到达服务商之前，先经过一条基于规则的规范化流水线。这条流水线会改写原始文本中服务商处理不一致的部分：整数和小数、日期和时间、多种格式的货币、百分比、罗马数字，以及 “Dr.”、“Mr.” 和 “etc.” 等常见缩写。

例如，“The invoice of $1,234.56 is due on 2026-04-21” 会变成 “The invoice of one thousand two hundred thirty-four dollars and fifty-six cents is due on April twenty-first, twenty twenty-six.”；“Chapter IV has 5 sections” 会变成 “Chapter four has five sections.”。每一项转换都是确定性的，都有对应的单元测试，而且在运行时没有任何开销——这些全部是本地处理，合成路径上不会多出任何 API 调用。

选择基于规则、而不是再加一层 AI，是有意为之。规则是可预测的：你可以复现它们、解释它们，也可以比对它们的差异。如果用户听到了奇怪的读法，你可以准确找到原因，并修正产生问题的那条规则。音频是一场表演，而表演需要一份可重复的剧本。

这两个系统分别作用于流水线的两端。评分决定什么内容能进入合成，规范化决定它听起来如何。一个守护你的预算，另一个守护你的输出质量。去掉评分，你的积分就会暴露在风险之下；去掉规范化，你的音频就会参差不齐。两者结合，让 TTS 集成从一个需要内容审核员和语言学家的项目，变成一行 SDK 代码。

这两个系统在控制台侧边栏中都有实时演示。在 AI Content Scoring 页面，你可以粘贴示例文本，查看它在你任意项目的内容配置文件下得到的确切分数、理由以及是否会被自动批准。Speech Formatting 页面则有一个 Try-It 输入框，能显示你输入的任何内容在规范化之后的版本，并附有前后对比示例。两者都有速率限制，都不消耗积分，并且都与真实请求到来时生产环境的处理方式完全一致。

如果你已经有 TTS2Go 项目，打开控制台把两个都试一试。如果你刚刚起步，就创建一个项目，把 React SDK 放到页面上，让人工审批队列接住最初的几个请求——你就能完整地看到整条流水线从头到尾的运作过程。