县级电台搞 AI 的三个常见坑（和我们怎么帮人填回去）
KAVANA 工程团队 — 2026 年 6 月
2024 年前后，国内县级广播台掀起了一轮"AI 跟风潮"。省级台做了，地市台跟着做，县级台在政策压力和同行对比下，也得表个态、出个方案、立个项。
我们在这两年里接触了大量县级台的案例，有主动找来咨询的，有出了问题来问怎么修的，也有上面检查之前紧急找来救场的。多接触几家，模式就清晰了——大家踩的坑，基本就是那几个。
这篇文章不讲理论，只讲实际踩过的坑，以及我们见过的、真正能用的解法。
坑一：用云端通用 TTS 当广播主播
最常见的问题，没有之一。
一家台的技术员，某天在网上看到某大厂云服务 TTS 效果演示，听起来挺像人声，就直接接 API 接进来，生成出来的音频推进播出链路。合成速度快，成本看起来低，文字进去、音频出来，挺顺畅。
问题从哪里来？
第一是 prosody（韵律）。通用 TTS 系统针对的是阅读场景——电商客服、导航播报、屏幕阅读。这类场景的节奏是平的：每句句尾往下压，语速均匀，情感中性。广播播报不是这套节奏，广播主持人有自己的呼吸节拍、轻重对比、句间停顿设计，尤其是路况类和新闻类内容，有明确的强调逻辑。
把通用 TTS 接进广播，听众在车里、厨房、户外听，第一感受就是"机器味"。不是说 AI 味，是那种特定的"客服语音味"。一家县级台上线三个月后，听众热线收到的反馈有十几条，集中在两个词：机器人、不自然。
第二是 专名发音。通用 TTS 的字典覆盖的是普通话标准发音，地方专名往往有约定俗成的读法。某个县名、某个地标、某个路段，当地听众都知道该怎么念，外地系统不知道，生成出来就念错，或者念得生硬。这个问题在县级台里格外突出，因为本地地名密度高。
第三是 广播规范适配。广播播出对响度、频率、格式有要求，通用 TTS 输出的音频往往需要额外处理才能进播出链路，有些台直接推进去，音量忽高忽低，被监听编辑发现后手动拦截，手工处理，效率反而不如人工录音。
我们在 KAVANA AI 合成工具 里专门针对广播场景做了韵律调校——不是在通用 TTS 基础上微调，是从语料采集阶段就按广播主持人的实际发音习惯建库，做 prosody 标注，再训练专用音色。这套流程走下来的结果，是听众大多数时候分不清是真人录音还是 AI 合成，而不是感觉到"挺像但不对劲"。
坑二：没有三审就上了 AI 内容
这个坑踩下去，后果比第一个严重得多。
我们合作台里有一家，2024 年下半年刚上 AI 路况播报，某天下午的一条播报里，把某路段限行的结束日期读错了。数字问题——AI 生成"12 月 30 日"，实际是"12 月 3 日"，差了整整 27 天。那条内容合成完直接推进了播出队列，没有人工核对，播出去了。
事后追查，技术员说"系统这块当时还没设置审核"，编辑说"以为技术那边处理过了"，主任说"没人告诉我有审核节点"。责任链断了，但内容已经播出去了。
这不是个例。AI 内容的审核失位，有一个特殊的心理原因：AI 看起来很自信。人工撰稿的编辑会犯不确定的错误，会在稿子里留问号、加括号，看的人知道这里需要查一下。AI 生成的文本格式整齐、语气笃定，读起来像"已经查证过"的成稿，实际上可能数字是幻觉出来的、地名是拼错的、引述是凭空捏造的。
这种"自信感"会降低审核人的警惕，让审核变成走过场。
广播 AI 内容的三审，必须在系统层面强制走流程，不能靠人的主动性。具体来说，三个层次：
一审（自动校验）：生成完成后，系统自动对专名、数字、来源一致性做基础核验。专名字典要定期维护，地方地名全部录入。数字类内容要标注来源字段，AI 生成的数字要能追溯到原始数据源。
二审（编辑人工确认）：AI 内容进播出队列之前，必须有一个人工确认节点，不能绕过。确认不等于逐字重新审稿，但至少要对照来源核实关键字段。系统要记录是谁、在什么时间、确认了哪一条，不能只有一个"通过"按钮而没有日志。
三审（节目责任制）：AI 内容和人工内容一样，纳入节目责任制。每条内容有责任编辑签字，出了问题追责链路清晰。
KAVANA 三审系统 做的就是这套流程的系统化实现——状态机驱动，每条内容有明确的审核节点，日志可追溯，播出链路对未完成审核的内容做硬拦截。
坑三：GPU 服务器买太贵或者根本没买
这个坑有两个方向，互为镜像。
方向一：跑云 API，用着用着成本爆了。
县级台项目立项的时候，技术评估往往只算了前几个月的用量，或者按演示场景的低负载算。实际上线以后，路况每天 6 条、新闻每天 10 条、节目预告每天 4 条，再加上采编部门偶尔用一下 ASR 转写，一个月下来，云 API 账单比预算高两三倍，这种情况我们见过不止一次。
更麻烦的是，云 API 的费率会变。某大厂去年调过一次价，调完之后一家台的月账单从 1800 元涨到了 3100 元，没有提前通知，账单出来才发现。台里去问，客服说价格已经公示了，合同里也有费率变动条款。这种情况很难申诉，只能接受或者换方案。
方向二：被供应商忽悠买了太贵的 GPU 服务器，实际没跑满。
县级台体量，TTS 日均字符量一般在 1-3 万，ASR 日均不超过 10 小时，LLM 文案辅助日均 token 量不大。这种负载，按实际计算，一台中等 GPU 服务器（RTX 4080 或同等算力）可以覆盖。
但我们见过有台被供应商建议买了两台 A100，说是"够用十年"。实际用起来，TTS 任务一条合成不到 10 秒，机器大部分时间在待机，RTF（实时率）压到 0.06 以下，用 80% 算力处理 10% 的实际需求。这是资源的严重浪费，购置成本几十万，运维成本也高，性价比极低。
正确的算账方式是：先评估实际峰值并发需求，再选对应算力。一般县级台，如果只做广播单频率的 TTS+ASR，一台 24GB 显存 GPU 就够用，花费在 3-6 万区间，性价比远高于"配齐了再说"的大机器。
我们的 AI 合成系统 支持本地 GPU 部署和云端混用两种模式，可以根据实际负载自动切换：高峰期本地算力不够时，短时间走云端 API 补量；日常负载本地覆盖，不产生额外云 API 费用。这样既控住了固定成本，也避免了单纯依赖云端的费率风险。
为什么这三个坑是连在一起的
回看这三个坑，表面上是三个独立问题，实际上有一条共同的根因：在没有理解广播行业特殊需求的情况下，用了通用技术方案。
通用 TTS 是给大众互联网场景设计的，不是为广播规范设计的。云 API 的计价模型是为互联网应用设计的，不是为广播日常高频稳定用量设计的。标准的内容管理流程是为图文内容设计的，不是为广播播出链路设计的。
这些不是批评通用方案不好，而是广播行业有自己的特殊性：播出时效性强、内容合规要求高、受众在移动和嘈杂环境中接收、本地化内容密度高。把通用技术直接套进这些场景，摩擦不可避免。
我们做 KAVANA 这二十年，从硬件设备开始，一路走到 AI 系统，有一个认识越来越清楚：广播行业的 AI 化，不是买个 API 接进来就完事，是要从播出链路的每个节点去重新设计，让 AI 在对的地方发力，在需要人工的地方不越俎代庖。
坑是填得回去的，但不能等到已经出了问题才来填。
如果你们台正在评估 AI 方案，或者已经踩进去了某个坑，欢迎联系我们。/aiUtils 工具清单、/ai 合成系统、/aiSanShen 三审平台 都有详细介绍，也可以直接跟我们的工程团队预约交流。
KAVANA，2005 年至今服务中国广播行业，广播 AI 系统覆盖全国多个省市县级台。