Bringing AI into Council Interpellation: The Complete Before-During-After Workflow

Every council session sends agency staff into interpellation hell: digging through past records, compiling sentiment issues, guessing which topics members will pursue, and chasing commitments afterwards. AI has clear leverage at all three stages — pre-session issue assessment and debate preparation, real-time transcription and structuring during sessions, and post-session task tracking. This article covers the concrete practices at each stage, the data foundations required, and how to connect the three into a closed loop.

Before the Session: Issue Assessment and Debate Preparation

The core pre-session question is: who will ask what this session? AI cross-references three sources:

• Past interpellation records：Each member's past interpellation topics, follow-up patterns and constituency concerns, to estimate the likelihood of continued questioning.
• Recent sentiment hotspots：Media and social issue volume in the weeks before the session — controversies running hot in public sentiment almost inevitably enter interpellation.
• Policy progress and weaknesses：Delayed projects, contested policies and items with low budget execution rates are all predictable interpellation targets.

From these, preparation materials are produced for each high-risk issue: likely question phrasings, factual and data evidence, a recommended answer structure, phrasing to avoid, and traceable sources. Staff work shifts from compiling from scratch to reviewing and supplementing.

1. 備詢資料的標準欄位

備詢資料要能在台上被翻閱，欄位就必須固定。機關若讓每個局處各自用自己的格式撰寫，長官在質詢台上得先花時間找資訊在哪一段，這正是備詢資料最常失效的原因。建議統一為七個欄位，無論議題大小、無論由哪個主政單位撰寫，版面一致、順序一致；AI 負責把外部輿情與內部知識填入前六欄的初稿，承辦人負責檢核與修正，長官只需記住欄位順序。以下是跨機關通用的七項欄位：

• 議題名稱與風險等級：以一句話界定議題範圍，並標示高、中、低風險，決定準備深度與長官預讀順序。
• 可能的提問方式（含追問路徑）：不只列出主問題，也要推演對方在得到某種答覆後最可能的第二問與第三問。
• 已確認事實與數據依據：只放經主政單位確認過的事實與統計，未確認的資訊另行標註，避免在台上被追問來源時失據。
• 建議答覆架構：先講結論、再講依據、最後講下一步，三段式架構讓答覆在時間壓力下仍然完整。
• 不宜使用的說法：列出容易被斷章取義、與既有立場衝突或超出權責範圍的措辭，這一欄往往比正面稿更關鍵。
• 相關歷史承諾與辦理情形：把過去在議事場合承諾過的事項與目前進度並列，避免出現前後不一致的答覆。
• 原始資料連結：每一項事實都要能一鍵回到原始新聞、公文或報表，讓長官與幕僚可以自行查證。

2. 開議前準備時間軸

備詢準備失敗多半不是能力問題，而是啟動太晚。把準備工作往前拉，並且切成四個檢查點，就能讓資料在開議當天已經過至少兩輪人工檢核。以下是建議的時程安排，機關可依會期長度調整，但四個檢查點的先後順序建議維持：

• 開議前一個月：彙整會期間的輿情熱點與歷史質詢紀錄，交叉比對後產出高風險議題清單，並指定每個議題的主政單位。這個階段的重點是涵蓋率，寧可清單長一點，也不要在開議後才發現漏項。
• 開議前兩週：各主政單位依七欄位格式完成備詢資料初稿，並完成第一輪人工檢核。AI 產出的事實與數據必須逐項核對原始資料，確認無誤才進入下一階段。
• 開議前一週：更新最新的輿情變化，補入這段期間新爆發的議題，並調整既有議題的風險等級。輿情在開議前一週往往最活躍，這一輪更新不能省。
• 開議前一日：產出當日重點提醒：今日排定的質詢單位、對應的高風險議題、昨日至今的輿情異動，控制在一頁以內，供長官與隨行幕僚快速掌握。

During the Session: Real-Time Transcription and Structuring

The pain point during sessions is record-keeping: oral exchanges move fast, manual notes miss things, and reviewing recordings afterwards is slow. Speech recognition (ASR) with meeting intelligence tools transcribes interpellation verbatim in real time and auto-structures it into a member–question–answer–commitment list. For the team on duty, real-time structuring has a tactical value too: back-row staff can push relevant materials to the official at the podium before the member's follow-up lands.

1. 即時轉錄的技術要點

議事場景是中文語音辨識最困難的情境之一，導入前必須先認清三個挑戰。第一是專有名詞：人名、地名、法案名稱、機關簡稱與預算科目在通用模型的訓練資料中出現頻率低，容易被辨識成同音的日常詞彙。第二是台語與華語夾雜：質詢過程中語言切換頻繁，且常出現同一句話中夾雜兩種語言的情況。第三是多人交錯發言：質詢與答詢互相打斷、旁邊還有議事人員的說明，語者分離的難度高於一般會議。實務上的解法是建立機關詞庫，把該機關的組織名稱、業務術語、正在推動的計畫名稱與常出現的法規名稱匯入，讓辨識模型在解碼時優先採用；同時對關鍵段落保留人工校對流程。要理解辨識準確率如何量測，可參考ASR 語音辨識的模型架構與 CER 指標說明。需要特別強調的是，即時逐字稿的定位是會中掌握與會後整理的工作稿，正式紀錄仍應以人工確認版為準。

2. 幕僚即時支援工作流

會中真正拉開差距的，是後排幕僚的反應速度。傳統做法是幕僚憑記憶判斷議題、再翻紙本資料，等到找齊往往已經錯過追問的時間點。導入即時逐字稿後，工作流改為：系統辨識出當前討論的議題關鍵字，自動比對會前備妥的備詢資料，把對應那一頁推送到後排幕僚的螢幕，幕僚確認後再遞交給備詢長官。同時，系統在會中就把內容整理成議員、提問、答覆、承諾的結構化清單，承辦人只需在旁修正與補註，散會時清單已接近完成，不必再從錄影檔重聽一次。

After the Session: Commitment Tracking and Outcome Comparison

"We'll look into it," "we'll provide the data after the session" — commitments made at the podium, if not systematically managed, become next session's follow-up interpellation: "you said you'd handle it — did you?" Post-session, AI does two things: extracts commitments and assignments from the transcript into a tracking list with lead units and deadlines, and keeps comparing sentiment on related issues so the agency knows whether its response actually resolved the concern.

1. 承諾事項追蹤清單的欄位

承諾追蹤清單之所以常常失效，是因為只記了一句摘要。摘要無法在下個會期還原當時的語境，也無法回答「到底承諾到什麼程度」。清單建議固定六個欄位，讓每一筆承諾在半年後仍然可以被完整重建：

• 承諾內容原文段落：保留逐字稿原文而非摘要，並附上時間戳記，必要時可回放對照。
• 主政單位：明確到局處層級，跨單位事項要指定一個主辦、其餘列為協辦。
• 承辦窗口：記錄職稱與分機而非僅記姓名，人員異動時清單仍然可用。
• 辦理期限：若台上未明確給出期限，由主政單位在會後三日內自訂並回填。
• 目前狀態：以研議中、辦理中、已函復三種狀態列管，狀態變更需留下時間紀錄。
• 對應輿情變化：追蹤該議題在承諾後的討論聲量與情緒走向，判斷回應是否確實化解關注。

這份清單就是下個會期的必考題庫。開議前一個月產出高風險議題清單時，凡是狀態仍為研議中或辦理中、且輿情聲量未下降的項目，應直接列為高風險；已函復但輿情仍有爭議的項目，也要備妥後續說明。換句話說，會後的列管品質直接決定下一輪會前準備的起跑點——清單維護得好，下個會期的準備工作等於已經完成一半。

一個會期的 AI 支援全貌

把三個階段攤在同一條時間軸上，可以看出 AI 與人工的分工邊界始終一致：AI 負責蒐集、比對與初稿產出，人工負責確認、判斷與對外表述。這條界線在導入初期就要跟各局處講清楚，避免承辦人誤以為系統產出的資料可以直接上呈，也避免長官誤以為所有內容都已經過查證。下表以一個完整會期為例，列出各時間點的 AI 產出與對應的人工工作，機關可以直接拿來當作導入時的分工說明。

地方議會與立法院：導入設計的差異

閉環架構通用，但資料設計必須依層級調整。地方議會的議題重心落在選區：一條路的施工進度、一件陳情案的處理速度、一處公共設施的維護狀況，這些議題在地方社團與在地媒體的擴散速度極快，往往在正式陳情之前就已經形成輿情。立法院的議題重心則落在制度：法案的審查進度、預算凍結與解凍的條件、跨部會權責分工，討論場域集中在全國性媒體與政策社群，議題週期較長但牽動面較廣。兩者對追蹤欄位的需求也不同——地方議會的列管重點是個案是否確實解決、承諾的完工時間是否達成；立法院的列管重點則是條文修正的進度、報告的提出時程與跨部會協調的狀態。機關在設定議題分類、輿情來源權重與追蹤欄位時，應依自身面對的層級調整，下表整理四個主要差異面向：

Connecting the Three Stages into a Closed Loop

Each stage delivers value on its own, but the real payoff is the connection: the post-session commitment list is the "guaranteed exam questions" for next session's preparation; session transcripts accumulate into historical data on members' attention patterns; pre-session sentiment assessment decides which issues need live support during the session. This loop is the five-stage AI copilot model — sense, understand, assess, recommend, track — unfolded in the parliamentary setting.

On data foundations: pre-session assessment needs external sentiment monitoring (such as InfoMiner) and historical parliamentary data; in-session transcription needs Chinese speech recognition; post-session tracking needs to connect with the agency's internal case-management mechanisms. For adoption, pilot with a single session and a single committee, validate the workflow, then scale.