縣級電臺搞 AI 的三個常見坑（和我們怎麼幫人填回去）
縣級電臺搞 AI 的三個常見坑（和我們怎麼幫人填回去）
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 系統覆蓋全國多個省市縣級臺。