逐字稿告訴你大家說了甚麼，卻不會自動說明團隊最後決定了甚麼、為何如此決定、誰答應要做甚麼，或哪些事情仍待查證。
幾週後，這個差異就會變得很棘手。搜尋找得到一句似曾相識的話，卻沒人能確定那究竟是決定、建議，還是反對意見。摘要讀來合理，但要找回支持它的原句卻很困難。
真正有用的目標，不是把逐字稿修飾得更漂亮，而是整理出一小組可供審閱的知識項目，而且每個項目都能追溯到它所依據的原話。
Table of Contents
寫摘要之前，先決定紀錄類型
先從人們在會議後真正會問的問題開始：
- 客戶提出了甚麼要求？
- 我們聽到了甚麼市場訊號？
- 有人建議了甚麼產品改動？
- 出現了甚麼技術問題？
- 我們為甚麼作出這個決定？
- 有人提出了甚麼風險？
- 哪些事情仍待查證？
- 我們是否發現了新機會？
- 我們對競爭對手有了甚麼新認識？
- 誰承諾採取下一步行動？
這些類型比一份冗長摘要更實用，因為每一類需要不同處理。承諾需要負責人和到期日；風險需要後果，或許也需要緩解方案；決策應保留理由；尚待查證的項目則不應悄悄變成事實。
你不必第一天就設計出完美的本體模型。十個清楚的類型，再加上一個 other 待整理佇列，已足以讓你了解團隊實際上都在談些甚麼。
把逐字稿保留為證據
每個擷取出的項目都應保留來源指標。以下節錄實作示範中一個項目的相關欄位：
{
"type": "decision-rationale",
"summary": "Ship an upload-first workflow because it is easier to audit than a live meeting bot.",
"review_status": "manually reviewed",
"source_span": {
"speaker": "Maya",
"start_ms": 22200,
"end_ms": 27500,
"transcript_start_char": 228,
"transcript_end_char": 308,
"text": "We will ship upload-first because it is easier to audit than a live meeting bot.",
"source_hash": "4087a4626f719379ff78971865c9a5e931c1024aea8a24d77116f7f54f956d74"
}
}處理錄音資料時，時間戳能讓審閱者回到音訊中的相應位置。這份編寫好的示範中，時間是預先設定的，並非從錄音量得。字元偏移量仍能在逐字稿中定位原話，而來源雜湊則標明逐字稿的版本。
也要保存完整的來源節錄。摘要是一種方便的閱讀方式，卻不是證據本身。
把觀察與詮釋分開
假設有人說：「在模擬回饋中，三個測試角色都要求同時搜尋中英文資料。」這句話足以支持這次練習中的一筆市場訊號紀錄，卻不能證明市場規模、付費意願，或練習範圍以外的需求。
這條界線很重要：
source words → reviewed knowledge item → later interpretation把這三層分開。來源原話應保持不變；經審閱的項目可以把內容整理成實用類型；之後的策略筆記則可拿它和其他會議、銷售資料或研究結果比較。
如果把三者合併成一段生成文字，結論的信心往往會超出證據所能支持的範圍。
用新版取代舊版，不要抹除紀錄
會議紀錄偶爾一定會出錯。審閱者可能發現「摘要面板」原來應是「證據檢視」，又或某項行動其實應由另一個人負責。
不要直接覆寫舊紀錄，假裝它從未存在。新增一個修訂版本，把舊版標記為已被取代，並保留修改原因。目前檢視可以只顯示已接受的版本，同時留下完整歷史以供稽核。
當幾個人共同審閱同一場會議時，這一點尤其有用。修正會成為正常流程，而不是大家暗地爭論哪一份匯出檔才是最終版。
從已接受的紀錄建立圖譜
紀錄穩定後，知識圖譜才真正有用。它可以把一場會議連結到相關決策、行動、風險、人員、產品和後續會議；但圖譜不應變成第二套事實來源。
每一條圖譜邊都應能回到一筆已接受的紀錄，而該紀錄又應能回到逐字稿證據。如果決策有變，下一個修訂版本會更新圖譜目前呈現的內容，但不刪除歷史。
這樣便形成一條精簡路徑：
project → decision → reviewed record → speaker and timestamp → exact transcript span圖譜幫助人們瀏覽；證據鏈則讓人們能信任找到的內容。
匯出成一般格式
即使主要介面做得很好，也要保留可攜式 JSON 或 SQLite 匯出檔。匯出內容應包含穩定 ID、紀錄類型、修訂狀態、證據連結和來源雜湊。
接著把它拿到應用程式之外測試。一段簡短程式能否列出所有尚待查證的項目？另一個工具能否重建目前的決策檢視？你能否證明每一條已接受的圖譜關係都能連到一段來源原文？
如果答案取決於某家供應商不公開的索引，你擁有的只是一個展示，不是可長久保存的公司知識。
先用一場短會議測試
處理整批檔案之前，先選一場五至十分鐘、已有正確答案可核對的會議。當中至少應包含一項決策、一項行動、一項風險、一次修正，以及一個必須維持「尚待查證」狀態的要點。
請當時出席的人一起審閱，並逐項確認：
- 每個項目的類型是否正確？
- 項目的措辭是否沒有超出實際說過的內容？
- 來源連結是否會開啟確切的支持原文？
- 修正時能否保留較早的版本？
- 已接受的狀態能否匯出並重建？
記下審閱所花的時間和修正次數。這些數字遠比籠統宣稱系統「理解」了會議更有用。
一個可操作的示範
LazyingArt 的會議轉知識示範把這套結構用在一份由專案自行編寫、長 54.8 秒的中英文逐字稿上。它包含十種經審閱的知識類型、精確的發言者與逐字稿範圍、一筆保留下來的修正紀錄、一份圖譜投影，以及可下載的 JSON。
這份測試資料是預先編寫的文字，沒有附上錄音，因此它展示的是證據模型和人工審閱生命週期，而不是轉錄、自動擷取或客戶部署成果。
如果你有權使用一批範圍明確的逐字稿，USD 250 的 Local Knowledge Terminal 資料集適用性短期評估可以在現有機器上評估雙方同意的樣本。流程會先從免費的適用性檢查開始；在雙方接受書面工作範圍之前，不會上傳來源檔案或付款。
先保留原話。只為真正有用的項目分類並審閱，保存每一次修正，讓每一條圖譜邊都能指回原始會議。