一份 AI 整理的會議摘要，可以寫得很完整。
但要真的拿它做事，至少得回答三件事：這句是誰說的？原話在哪一段？摘要裡的待辦，真的是會議中的決定嗎？
這三題答不出來，摘要再漂亮，也不適合直接當成會議結論。
前兩天，我把發文自動化裡的品質站拆得很細。Day 3 講怎麼把規則接進流程，Day 4 再往下追：這些規則本身有沒有真的在工作。
驗證很重要，但整個系列如果一直停在驗證，內容產線就會失焦。所以今天換一種輸入：語音。
Day 4 結尾原本預告要接著拆「交付出口」。重排 30 天地圖後，我把那一題移到 Day 22，屆時再把本機、門禁入口、可撤回分享與長期公開一起講完。這裡先回到內容產線，開始拆第一條實際工作流。
會議裡有決定、待辦、問題和背景脈絡，也可能留下之後值得繼續研究的內容。一段超過兩小時的錄音丟給 AI，最後得到一份完整摘要，只能證明模型有輸出，還不能證明這條自動化已經完成。
最直覺的會議自動化，大概長這樣：
這條流程很短，也很適合拿來示範 AI 有多快。問題是，它把所有中間狀態都藏起來了。
只要摘要開始整理交付期限，至少還得知道三件事：
如果只剩最後一份摘要，這三個問題都只能重新聽一次錄音，或乾脆相信 AI。
所以這篇不是要做一個更會寫會議摘要的 Prompt。我想拆的是另一件事：一段錄音經過 AI 之後，至少要留下哪些狀態，才有辦法回查、修正，也看得見哪裡還不確定。
我手上這份去識別化的工作包，來源是一段超過兩小時的真實會議錄音。公開能談的只有流程與產物，不包含日期、對象、內容、逐字引用或音檔本身。
工作包裡不是只有一個 summary.md。我核對到的產物與元件，可以整理成八個狀態：
這張狀態地圖是設計圖，不是單次執行紀錄。它把已核對的公開轉錄骨架、ElevenLabs 說話者能力與本機工作包產物排在同一張圖上，方便看見應該保留什麼；它不能證明同一段錄音已經自動跑過八站。
我公開的 media-to-text-skill 已經能接收影片網址、本機影片或音訊，統一音訊格式，再用 Whisper 產出原始 JSON、含時間戳逐字稿、純文字稿，最後依範本整理摘要。
這份會議工作包裡另外有說話者處理、分段複核與報告整理。它們是同一個問題裡已存在的零件，但 Whisper 與 ElevenLabs 的結果目前怎麼接、哪些步驟屬於同一次執行，還沒有核對完成。
這個差別很小，卻是技術文章不能省略的一句話。功能存在，不等於整條路已經接好；資料夾裡有產物，也不等於每次執行都會自動得到同樣的結果。
轉錄完成後，我不會只留下最方便閱讀的版本。原始 JSON、Markdown 逐字稿和純文字稿，各自有不同工作。
| 狀態 | 裡面保留什麼 | 後面拿來做什麼 |
|---|---|---|
| 原始 JSON | 完整文字、語言、分段、起訖時間，支援時也可能有 word 資訊 | 重做逐字稿、重新切段、定位問題 |
| 含時間戳 Markdown | 人看得懂的段落與時間位置 | 閱讀、搜尋、找出附近的錄音位置 |
| 純文字稿 | 拿掉時間標記的連續文字 | 提供給摘要、分類與後續內容處理 |
原始 JSON 最不適合直接閱讀，卻是最不能丟的一份。因為後面的逐字稿和摘要如果出錯，至少還有共同起點，不必從音檔全部重跑。
Markdown 版本則像索引。看到一段可疑內容，我可以先找到附近的時間，再回去聽原音。純文字稿最乾淨，適合交給模型做長文整理，但它也最容易讓人忘記內容原本來自哪個位置。
這三份檔案分別服務「機器重做」「人類回查」「模型加工」，少一份，後面就少一條回頭的路。
時間戳看起來很精準，甚至可以細到每個片段的起點與終點。但它只能告訴我：「系統認為這段文字大約來自這個位置。」
它不能單獨證明文字一定正確。
Whisper large-v3-turbo 的模型卡直接提醒，模型可能輸出音訊裡沒有出現的文字，而且不同語言、口音與方言的表現不一。OpenAI Whisper 的程式碼也仍把 word-level timestamps 標為 experimental：它透過 cross-attention pattern 和 dynamic time warping 推估字詞時間，很適合拿來導航，卻不該被當成逐字精準的時間證據。
時間戳在這裡只負責「帶人回去找原音」，不負責替文字蓋上「已證實」的印章。
這個觀念會直接影響後面的設計。只要摘要涉及責任、金額、期限或承諾，不能因為旁邊有時間就自動升級成已確認事實。時間只能縮小人工要聽的範圍。
會議記錄的第二個麻煩是：誰在說話。
我目前用 ElevenLabs 做說話者區分。開啟 diarization 後，它能在轉錄結果中保留 speaker_id、起訖時間與文字。這比把所有人混成一整段好很多，因為後續至少能知道哪些片段可能來自同一位說話者。
但 speaker_id 比較像匿名分組，不是身分證。它能表達「這幾段可能是同一個人」，不代表系統已經知道那個人是誰。
還有一個很容易混淆的地方：ElevenLabs 回傳的文字辨識 logprob，是在描述文字辨識訊號，不是「這個 speaker_id 有多可信」。兩者如果混在一起，後面很容易把不確定的說話者寫成確定的姓名。
我的本機流程另外有一條 fallback，會根據聲紋嵌入、相似度、候選差距與片段長度，把結果分成 high、medium、low 與 context；低信心或太短的片段就標成「未確認」。但這是本機延伸，不是 ElevenLabs 原生提供的 speaker confidence，也不是目前主要路線的替代名稱。
相關研究也指出，背景噪音、重疊語音與說話模式變化都可能讓 diarization 誤標。segment-level confidence 的用途，是把風險繼續送到下游：低信心的片段不要直接進入姓名、責任與決策欄位。
如果回查的單位仍是整段錄音，前面留下那麼多狀態也沒有太大幫助。
本機處理腳本會保留每段的起始時間，產出一份連續逐字稿，再另外切成 review chunks。工作包裡也有說話者標記與未確認狀態，但它們是否在同一次執行裡自動對齊，目前還不能這樣宣稱。
光是把長錄音切成可以定位的複核區段，人工就不必一直在兩小時的音檔裡來回拖拉，可以把注意力放在真正會影響意思的片段。
這裡切段的目的，是把人工判斷變成可以指派、可以暫停、可以重做的工作單位。
短片段、低信心片段，和涉及負責人、期限、交付內容的片段，不該排在相同的複核優先序。角色一旦認錯，後面的決定與待辦都可能跟著改變。
這樣人工不必從頭到尾逐句重做 AI 的工作，但流程仍要讓人找得到該看的地方。
表面上只有逐字稿、摘要、報告三類；實際處理時，我會再把逐字稿分成原始與清理後兩層，總共四層。這條產線最容易犯的錯，就是把它們當成同一份文字的不同排版。
其實它們回答的問題不同：
| 產物 | 它負責回答什麼 | 應該回到哪裡查 |
|---|---|---|
| 原始逐字稿 | 系統聽到了什麼、位置在哪裡 | 原始音訊、時間戳、segment |
| 清理後逐字稿 | 這段話在保留原意下，怎麼變得可讀 | review chunk、speaker label、原始逐字稿 |
| 結構化摘要 | 討論主題、決定、待辦與未解問題是什麼 | 清理後逐字稿、重要片段 |
| 可回查報告 | 讀者怎麼搜尋、判讀狀態並回到來源 | 上面所有狀態 |
我的會議摘要範本會拆出與會者、議程、討論、決定、行動項目、下次會議和未解問題。這些欄位能讓模型知道怎麼整理，卻不能替內容創造證據。
範本裡有「負責人」欄位，不代表會議一定指定了負責人；有「期限」欄位，也不代表錄音裡一定講過日期。沒有根據的欄位就應該空著、標示待確認，或乾脆不寫。
摘要可以增加結構，不能增加原話。
把中間狀態留下來，不是要讓人每次都審完兩小時逐字稿。剛好相反，這是為了把人放在少數真正需要判斷的位置。
按照前面的風險，這條線至少該留四個人工停靠點：
speaker_id 沒有可靠對應時，不替它補上一個看起來合理的名字。
Minuteman 這套研究原型也採取類似方向：它同時讓人編輯逐字稿與摘要，因為 ASR 可能聽錯專有名詞，摘要模型也可能誤解逐字稿。這項研究不能替我的流程證明效果，但它支持一個設計選擇：把人工修正放在錯誤會改變意思的位置。
這也呼應前兩天一直在談的 Harness。Prompt 可以提醒 AI 小心，但真正有用的工程層，應該讓低信心片段有狀態、讓重要欄位能連回來源、讓未確認內容停在發布前。
人不必守著每一個字，系統也不能把最後一份摘要偽裝成全部都已確認。
這種做法的成本很明顯：檔案變多、流程變長，狀態也比「錄音進、摘要出」複雜。
但它換來一個很實際的能力：哪一層出問題，就回到那一層處理。
內容產線的重點從來不只是快。當輸入本身有雜訊、模型可能誤判、輸出又會影響後續行動時，「可以回頭」本身就是功能。
最後把今天的設計收成一張檢查表。之後不管用哪一套模型或會議工具，都可以先問：
如果四題都答不出來，那套工具可能很會寫摘要，卻還稱不上是一條可回查的內容產線。
今天先把會議自動化的骨架停在這裡。安裝、模型選擇、說話者校準、摘要範本與完整介面，都值得各自再拆一篇，現在全部塞進來只會讓主線失焦。
下一篇我會換另一種常見輸入：影片。會議錄音至少還是我自己的原始材料；影片轉成深度文章之後，還多了一個更麻煩的問題——AI 聽到了什麼，不代表它寫下的每個主張都有外部來源。
iThome鐵人賽
看影片追技術