AI 实时播报：路况、新闻、气象怎么"接得住"

KAVANA 工程团队 — 2026 年 6 月

电台有三种内容最考验播出链路：实时路况、突发新闻、滚动气象。

它们的共同点是——不能等稿。路况堵在桥上不能等编辑写完再播，气象预警发布到生效可能就十几分钟，新闻事件半小时内没有官方口径就会变成谣言的温床。这三类内容，AI 能帮上的不是"写得好"，而是"接得住"——在数据进来和播出出去之间，把节奏、长度、安全、可追溯、跨平台这几件事都接稳。

这篇文章讲的是我们见过的、真正能落地的实时播报工作流。

实时数据进电台的第一道关：源头

很多台一上来就关心 AI 模型怎么样、合成效果像不像真人。但实际跑起来，第一个出问题的，往往是数据源头。

路况数据来源有几种：交管平台对接、地图服务商 API、本台记者现场回报。每种都有它的脾气——交管平台更新有节奏（高峰时段每 30 秒一条，平峰可能 5 分钟），地图 API 在地图上的标注和实际播报要求经常不一致（记者视角需要"市区某桥由南向北拥堵 1.5 公里"而不是"某某路段红色"），现场回报经常是语音消息，需要先做语音转写。

新闻数据走通讯社的有（稿件进得来、有标签、能溯源），走本地爆料的也有（微信群、电话录音、APP 留言），后一种要先进事实核查，不能直接进 AI。

气象数据相对规范，但有个细节：气象预警从发布到生效，时间窗可能只有 10-20 分钟，过了这个窗就过期了，AI 必须能识别预警级别并按级处理（橙色预警和蓝色预警的播报长度、语气、重复次数都不一样）。

数据源接进来时，必须做源头标注：每一条数据进来时带上"来源 + 时间戳 + 原始 ID"。没有这个标注，后面的 AI 整理、合规检查、留痕审计就全断了——出问题的时候连"这条播报是从哪儿来的"都查不到。

我们在 KAVANA 三审平台 里把这个源头标注作为强制字段，AI 生成内容不带源头的，直接被三审系统拦下，不进播出链路。

AI 整理这一步：不是"写"，是"规整"

很多人对 AI 实时播报的期待，是"AI 看见路况拥堵的数据，自动写一段像主持人一样的播报"。这条路技术上能跑，但实际不可控。

我们工程团队实际部署的，不是"AI 自动写播报稿"，而是"AI 做规整"：把结构化数据转成符合广播规范的播报文字。

这一关做几件事：

• 数字读法本地化。AI 默认会把 "1.5 公里" 念成"一点五千米"，听众会愣一下。广播规范里要的是"由南向北拥堵一千五百米"或者"拥堵一点五公里"，由台里事先定好。地名也有类似问题——本地听众约定俗成的读法，AI 默认字典里没有，得有地方专名词典，AI 按词典念。
• 句长与句数控制。一段路况播报通常 15-25 秒、3-4 句。AI 整理的时候按这个模板走，不会生成一段 60 秒的播报——超时的内容会被打回，不会进合成。
• 占位词与紧急级别挂钩。橙色预警插播，需要立即打断当前节目并播三遍；蓝色预警走正常播报节奏，插在两段节目之间。AI 不应该自己判断紧急级别——这个判断由三审流程里的责任人按气象局发布信息决定，AI 只负责按级别套用模板。
• 敏感词与合规检查前置。敏感词、数字、专名错读、占位词错误，这些在 AI 整理完、合成立播之前就要拦下来，不能等合成完再听一遍。

这一关做扎实了，合成那一步基本不出问题；做不扎实，合成出来再听再改，等于把"AI 帮降本"的优势全废掉。

合成 → 播出 → 留痕：闭环

规整好的文字，进合成，合成完进播出，播出的同时要留痕。这是实时播报最难也最关键的一步。

合成这一步对 AI 音色有要求——和通用 TTS 不同，广播用合成需要专门的广播级音色（我们之前在 县级 AI 三个坑 里专门写过这个问题，AI 合成这一身份要明确，不能让听众误以为是真人主持）。听众分不清是 AI 还是真人，监管要追究；听众能听出来是 AI，但觉得够用、够稳，反而是更安全的状态。

播出这一步，实时播报走"插播"通道——打断当前节目、播完、回到原节目。这里的关键是时间窗控制：插播必须在 8 秒内开始、播完时长不超出原节目时间预算。我们见过有台用通用合成卡在加载上，30 秒才出第一句，听众已经换台了。

留痕这一步，每一条 AI 实时播报，必须能查回——查"这条是什么时间合成的、什么时间播出的、播了几遍、内容来自哪个数据源、谁批准的"。这听起来是基本要求，但实际很多台没做到，原因是没有统一的留痕结构，数据散落在合成系统、播出系统、审核系统三个地方。出了事想查，对不齐时间戳，最后只能凭印象。

我们的 KAVANA 播出管理 把合成记录、播出日志、审核签字统一到一根时间线上，一条播报从源头到播出可追溯，事后审计不用拼数据。

跨平台分发：同一份实时内容，多端一致

实时内容播完电台这一头，还有一半工作没做——同一份内容还要发到 APP、官网、微信视频号、短视频平台、播客。

很多台的现状是：电台播完了，再人工把文字稿贴到 APP、官网、公众号，三遍粘贴，效率低还容易出错（电台说"某桥由南向北拥堵 1.5 公里"，APP 上变成"某桥由南向北拥堵 1.5 米"——一个量级的事故）。

AI 实时播报出来的稿子，本身就是结构化的：数据 + 规整文字 + 时间戳 + 紧急级别。这个结构天生就适合多端分发——APP 端要短文案（"市区某桥拥堵 1.5km"），官网要全文（带数据来源 + 播报时间），短视频要 15 秒配音 + 文字字幕，微信要图文推送，播客要口播音频。每种格式从同一份结构化内容里自动生成，不靠人工复制粘贴。

这就是 KAVANA 视频分发 的核心思路：内容是结构化的，分发是多端自动的，人只做审核和决策，不做搬运。

接得住的关键不在 AI，在链路

实时播报做得好不好，不取决于 AI 模型多强、合成效果多像真人，取决于整条链路是不是稳：

• 数据源是不是规范（有没有源头标注、是不是可追溯）
• 整理这一步是不是严（数字、专名、句长、占位都先卡掉）
• 合成到播出的延迟是不是短（8 秒窗口能落地）
• 留痕是不是闭环（事后能不能 5 分钟内查到任何一条）
• 跨平台分发是不是自动（同一份内容能进所有端，不用人搬）

AI 在链路里是工具，不是答案。话筒前依然是人在判断——判断要不要插播、判断紧急级别、判断哪条数据可信。AI 接走的是流程里的重活累活：规整、合成、分发、留痕。链路稳，AI 才有用；链路不稳，再强的模型也救不回来。

经济宽裕时，多堆点人手也能撑起实时播报；经济偏紧时，靠人手撑就是赌。AI 实时播报不是花活，是把"接得住"这件事从依赖经验变成依赖系统，让任何一家电台、任何一个班次，都能把实时内容做稳。

—— 关于 KAVANA（来源：kavanafm.com · 资讯列表）

KAVANA，2005 年至今服务中国广播行业，广播 AI 系统覆盖全国多个省市县级台。

AI 合成系统 · 播出管理 · 三审平台 · 视频分发 都有详细介绍，也可以直接跟我们的工程团队预约交流。

← 返回资讯列表