一份虛構傢俱店錄音稿中，說話人零說“我去確認星期五能否送貨”。摘要卻變成“店長已承諾週五送達”。這裡跨過了兩道未經核實的門：這是誰，以及他說的話是否構成承諾。本文是一張錄音稿編輯單，不是實際錄音分析。先保留匿名說話人標籤，不要直接把摘要寫進客戶訂單。

Amazon Transcribe 的說話人分離功能會給不同說話人的文字分配獨特標籤，並提供發言時間段。 文件示例裡的 spk_0 是輸出標籤，不是員工賬戶。我們的使用建議是把“這個聲音分到哪組”和“這位員工是誰”分開記錄；不因出現順序、座位或某個名字被提到，就自動認領身份。

AWS 的輸出說明包含逐詞時間和信心分數。 這些欄位可幫助定位核對，卻不是業務承諾的批准記錄。即使“確認”這個詞被正確轉寫，也不能把“去確認能否送貨”改成“已確認送貨”。這是我們對業務使用的分析：把原句、解釋和確認狀態放在不同欄位，不用一個漂亮摘要覆蓋三者。

我們建議每條重要結論附上受控錄音引用、起止時間、原始標籤、經人工核實的姓名及核實人。姓名不確定就留空，重疊發言或聽不清就標待核對。只在已獲錄音與使用許可的範圍處理資料，並限制訪問和保留時間。不要為了讓更多人複核，把整段客戶錄音散發到無關群組。

這家虛構店的安全改稿是：某位尚未核實身份的參與者提出去確認週五能否送貨，交貨日期仍待負責人確認。複核者應回聽相關片段，必要時詢問參與者；身份確認後，再單獨確認交貨日期許可權和結論。更正姓名也要重查基於該姓名生成的任務，而不只是修正文稿中的一個字。

本次建議驗收分別看文字、說話人對應和業務含義。用已授權的短片段，請複核者檢查否定句、條件句、插話及身份未明的片段；記錄糾正和未解決項。這裡未做真實錄音測試。上線前確定誰能確認身份、誰能批准承諾，以及錯誤如何回傳，才能讓自動摘要成為協助，而不是替人認領責任。