AI 生成的內容，在電臺播出前怎麼審？我們的三審實操
AI 生成的內容，在電臺播出前怎麼審？我們的三審實操
去年我們有一家合作臺，AI 生成的一條路況播報裡，把某路段施工限行的資訊播錯了——不是敏感詞，但數字讀錯了，播的是"限行到 12 月 30 日"，實際是"限行到 12 月 3 日"。聽眾打進熱線質疑，臺裡自查，發現那條播報是 AI 生成、編輯沒有逐字核實就透過了的。
沒有釀成什麼大事故，但足夠讓我們認真重新梳理一遍三審流程。
這篇文章寫的是真實的稽覈工作流——不是規章制度裡寫的那套，是實際在系統裡跑、日誌裡能查、簽字能追溯的那套。
為什麼 AI 內容的稽覈不能套用人工內容的稽覈流程
先說一個很多臺容易忽視的前提：AI 生成內容的稽覈，和人工內容的稽覈，不是同一件事。
人工撰稿，編輯負責，有明確的責任主體。稿子出了問題，追到記者、追到編輯，流程清晰。
AI 生成內容，責任主體是誰？是觸發生成的那個操作員？是稽覈透過的編輯？是系統提供商？在實踐中，這個問題沒有統一答案，但監管的立場是明確的：上了播出鏈路的內容，臺裡負責，不管是不是 AI 生的。
這意味著：AI 內容的稽覈，必須和人工內容同等嚴格，甚至在某些維度上要更嚴格。
人工稿子，編輯看稿，看的是內容對不對、表達合不合適。AI 生成內容，編輯還得額外看：生成結果和輸入來源是否一致（有沒有幻覺）、數字和專名是否準確（AI 在數字和地名上的錯誤率高於文字描述）、語氣是否符合廣播規範（AI 有時候會生成書面感過強或口語感過弱的表達）。
這些差異，如果不體現在稽覈流程設計裡，就等於沒有稽覈。
三審是一個狀態機，不是三個人看一遍
國內廣播的"三審制"，一般描述為：一審（編輯自審）、二審（責任編輯審）、三審（節目主任終審）。
這個描述在人工內容時代基本夠用，因為稿子在編輯們手裡傳來傳去，誰看過自然有記錄。
但 AI 內容速度快、批次大——一檔路況節目可能一天生成 6 條，一檔新聞播報可能一天 10 條以上。如果每一條都走三個人手動簽字的流程，不是不行，但在人手有限的縣級臺，這套流程能不能在播出時間視窗內完成，是一個現實問題。
我們在系統層面做的，是把三審變成一個有明確狀態機的工作流，而不是人工傳籤的流程。
狀態機有五個狀態：
- 生成完成（Generated）：AI 合成完成，進入待審佇列
- 初審透過（Pre-cleared）：自動內容安全掃描透過，進入人工稽覈佇列
- 人工確認（Approved）：值班編輯在系統中確認，操作者身份和時間戳鎖定
- 播出完成（Aired）：系統實際播出，自動記錄播出時間和音訊雜湊
- 歸檔（Archived）：播出後 90 秒自動歸檔，包含完整的內容生成引數、稽覈記錄、音訊檔案
這五個狀態，只能按順序推進，不能跳過。人工確認環節是硬卡點：沒有操作者身份的確認記錄，內容不能進入播出佇列，無論編輯有沒有"口頭說過可以"。
初審：自動過濾做的是什麼
第一道關是自動的。AI 內容生成完成後，系統立即對文稿做關鍵詞掃描和語義敏感度檢測。
關鍵詞庫分兩層：一層是硬性攔截詞，命中即打回，不進入人工稽覈；一層是軟性標註詞，命中後繼續流轉，但在人工稽覈介面高亮標註，提示編輯重點核查。
敏感詞庫的維護是個持續工作。不是部署一次永久生效，而是需要根據時事定期更新。我們在實踐中遇到過幾次：某個詞在日常情況下完全正常，但在特定政治節點視窗期會變成敏感詞，AI 生成的稿子裡沒有問題，但播出時機不對。這種上下文敏感性，純靠關鍵詞庫很難覆蓋，需要人工判斷。
這也是為什麼初審只能做過濾，不能代替人審。
除了關鍵詞，初審還做一件事：數字和專名的一致性校驗。AI 生成內容時給了什麼輸入（新聞原文、路況資料來源、天氣 API 返回值），生成結果裡的數字和地名是否和輸入一致，可以做機械比對。這一步能捕捉到相當一部分的幻覺錯誤，成本很低，但效果明顯。
那條路況播報數字錯誤的事故，如果這一步在那時已經上線，應該可以被捕捉到。我們那時候還沒做這層校驗。
人工確認：編輯實際做什麼，不做什麼
人工確認環節，在系統裡呈現給編輯的是：
- 文稿全文（不是摘要）
- 生成的音訊檔案（可以在系統裡直接播放）
- 生成時使用的來源資料（新聞原文、路況資料、天氣引數）
- 初審標註的高亮項（如有）
- 建議播出時間和所在節目欄目
編輯的操作只有兩個：透過或打回。打回需要填寫原因，原因進入日誌。
我們刻意沒有做"編輯可以修改文稿再透過"這個功能。原因是：如果允許編輯修改，修改後的內容和 AI 生成的原始內容混在一起，責任歸屬就模糊了，而且修改後的版本沒有經過初審的自動掃描，引入了一個新的安全盲區。
如果文稿有問題，正確做法是打回，重新生成，新版本重走初審流程。這會慢一點，但每一版的來源和稽覈記錄都是乾淨的。
一次真實事故：敏感詞怎麼過了初審
大約 14 個月前，一條 AI 生成的新聞導讀播出後，被臺裡的合規自查發現了一個問題：文稿裡有一個詞，在特定上下文中含義模糊，按照廣播稽覈規範，這類詞應該在用詞說明中註明出處或改寫。
這條內容透過了初審，因為這個詞本身不在關鍵詞庫裡。透過了人工確認，因為值班編輯看了一遍沒有標註這個詞有問題（這個詞確實不顯眼，在上下文裡不突出）。
事後的改進措施有兩條：
一是補充了一批"語境敏感詞"進入軟性標註庫——這些詞單獨拿出來不是問題詞，但在特定組合下需要人工關注。這需要合規編輯參與維護，不是工程問題，是內容專業問題。
二是在人工確認介面加了"確認無模糊用詞"的顯式勾選項。這是一個微小但重要的改變：它不是攔截，而是強制編輯對這個維度做一次顯式思考，而不是泛讀一遍就點透過。
行為設計上的細節，往往比流程規章更有效。
簽字留檔：稽覈記錄怎麼在監管檢查時用得上
廣電局對播出系統的檢查，核心關注點之一是：你的稽覈記錄是否可追溯、可查驗、不可篡改。
我們的歸檔設計：
- 每條 AI 內容的完整生命週期記錄（生成時間、生成引數、初審結果、人工確認操作者 ID + 時間戳、播出時間、音訊檔案雜湊）存入專用稽覈日誌庫
- 日誌庫只能追加，不能修改或刪除（Append-only），系統層面強制
- 日誌保留 90 天，可匯出為 PDF 格式供監管查閱
- 音訊檔案歸檔 30 天（磁碟佔用考量，如需更長可配置）
這套記錄在實際檢查中用到過兩次，都順利透過了。檢查人員最常要求核查的是：某段時間內的播出記錄是否完整，某條具體內容的稽覈責任人是誰。這兩個問題，我們的日誌都能直接給答案。
三審之外：播後的持續監控
三審流程覆蓋的是播出前的稽覈。但廣播內容的合規風險不止在播出前——還有播出時和播出後。
播出時：實時音訊分析模組對播出訊號做持續監控，包括靜默檢測、異常電平告警、以及（可選）關鍵詞實時監測。如果播出時檢測到靜默或異常，立即告警，不等人發現。
播出後：每條播出內容的實際音訊（不是合成文字，是真正的播出錄音）會被自動擷取歸檔，對照文稿做 ASR 轉寫比對，確認播出內容和稽覈透過內容一致。這一步能捕捉到一類極端情況：文稿稽覈透過了，但 TTS 在某個詞上有奇怪的發音，轉寫出來和文稿不符。
這種情況極少發生，但發生過。
完整的三審實現可以訪問 https://www.kavanafm.com/aiSanShen，內建工作流配置和許可權管理，也可以獨立於我們其他產品單獨使用。如果你的臺已經有 AI 生成內容但還沒有系統性稽覈流程，https://www.kavanafm.com/aiUtils/programShen 是一個可以快速接入的輕量版稽覈工具。
KAVANA 由湖南聲廣科技有限公司開發，廣播電視節目製作經營許可證湘字第 00565 號，網路安全等級保護三級認證。技術文件與開放規範：github.com/kavanafm