為什麼 AI 會議記錄工具 99% 都需要人工修正——用企業知識庫來救
當我還在物流業的時候，某個週一下午，PM 在 email 上丟出上周五會議的AI自動紀要。 我看了兩眼就懵了：「我們物流業什麼時候決定投資英鎊了？」後來看一下會議轉寫稿。我看到這個才恍然大悟，原來 AI 把 物流的 InBound(入庫) 聽成英鎊了。
AI 轉寫工具的極限
2024 年末，AI 會議記錄工具滿天飛。Ottr、Plaud、各種標榜「自動轉寫、秒出紀要」的應用，都在宣傳自己的驚人準確度。
只是現實很殘酷，實際到了可以寄給客戶的會議紀要階段，90% 都需要人工修正
不是技術問題。是語境問題。一個通用的 ASR（自動語音辨識）無法理解你公司內部的黑話。它聽不懂你的同音混淆、分不清人名、搞不懂企業專有名詞。而這些東西，決定了會議記錄到底能不能用。
我在工作中觀察了足夠多的會議記錄失敗案例，歸納出 4 個層級的問題。越往下，解決難度越高。
Layer 1：多語言同音混淆
我目前負責管理台灣、香港跟東南亞的專案，中英文夾雜是常態。某些傳統企業甚至中英台語一起混。ASR 在判斷「到底這個同音字是哪個」時，完全沒有公司語境。例如：
「奧拉雅」→ 實際是「Outliner」 「留一些 Rick」→ 實際是「留一些 Record」。
在香港開會時「英粵語夾雜」，連我自己瞬間都會愣住。這類錯誤是 ASR 的「同音優先級」問題。純靠通用語言模型很難修正，因為它不知道你公司用的是哪個詞。
Layer 2：企業行業專有詞彙
每間公司都有相關技術，內部黑話。客戶代號、Project Code Name。像是我之前工作整天在物流業，行業詞彙超級多的，例如 ASRS、棧板、全拖、回單等。我在講一些 data project 時，GCP 相關技術常常是重災區：
「手動按 BQR ROM」→ 實際應該是「手動按 BigQuery Run」。BigQuery 的發音有一百種聽錯的可能。除非你知道這家公司用 GCP 的 BigQuery，否則「比奎瑞」對 ASR 來說就是某個陌生詞彙。
其他例子：每個企業的內部 Project Code Name，ASR 根本不知道，完全無法判斷。
Layer 3：人名與供應商混淆
這是最傷害會議紀要可用性的重災區。我曾看過一個 30 秒的轉寫稿，同一個人（小君）用四種寫法被提及：小軍、小君、小俊、小均。最後自動化會議紀要就把 Action Item 指派給三個人，其實都是同一個人。
供應商名字的混淆更誇張：
「新竹 Carry 與褲孔」→ 實際上是三間廠商：「新竹」、「嘉里」、「酷澎」
「鄭旦宇」→ 實際是「震旦雲」（打卡系統名稱被聽成人名）
Layer 4：數字與單位
這個問題算是大魔王了，有一次我看過逐字稿寫「300 萬」，一開始嚇到——這小業務一天有 300 萬營收？回去回聽才發現他說的是「300 板」（物流倉儲單位）。真是很可怕。
其實在真實場景下，純語音很難準確傳遞數字。人的耳朵就是這樣，從聲音判斷數字天生困難。而且涉及大量數字的會議，通常有 Excel、Dashboard、投影片在螢幕上投影。這時候語音只是輔助，視覺才是主要信息來源。
解決方案：企業知識庫架構
對於 Layer 1-3（多語言、詞彙、人名供應商），企業知識庫可以優雅地解決。核心思路很簡單：在逐字稿轉成會議紀要之前，插入一個「企業語境校正」
需要的三個主要資料集：
- 關鍵 stakeholder 清單（包含常見同音混淆）：核心人物（CEO、CFO、PM、關鍵工程師）、客戶窗口人名、常見同音混淆記錄
- 供應商與合作夥伴名單：正式名稱、常用簡稱與別名、常見發音混淆
- 企業專有詞彙與 Project Code Name：內部技術術語、Project Code Name 與正式產品名的對應、行業黑話
解決範例
有了這樣的數據庫，在逐字稿轉譯之後會議紀要之前，我們就可以插入一個校正的環節，我們這裡用以下 prompt 來做範例
解決範例 - 專業詞彙
如同此範例，有了相關的數據庫，之前提到的專業詞彙可以良好的解決
這樣就可以做到比較適合的轉寫，並且保留原文確保 AI 搞錯時可以追溯。同樣只需要 Prompt 加入相關人名跟供應商，剩下交給 LLM 來處理即可。
解決範例 - 數字/單位校正
這個就很難了，這個也不是用企業資料庫來修正，這個需要的是會議錄影的圖片跟 OCR 抓取數字。因為我們開會如果是「純電話會議」通常也不會講一堆數字，人天生的構造就很難用聽的抓取全部的數字。
通常一堆數字的會議，都會將報表、Excel 或是 Dashboard 投影到螢幕上，這時候反而語音是輔助。我之前的做法是寫一個程式去掃螢幕的固定時間截圖（例如每 15 秒一次），然後將轉寫稿跟截圖放在一起變成圖文的會議記錄。這樣遠比去逐字稿猜數字來的更有用。
總結
與其被 AI Agent 的五花八門迷花眼，不如從現在開始，把精力投入在建立屬於你們的企業知識庫上。人名、供應商、技術術語、業務邏輯……這些是你企業的 DNA。
一份完整的知識庫，可以讓任何 Agent——無論是今天的、明天的、後天的——都能更聰明地為你工作。這是唯一不會過時的投資。
常見問題 Q&A
Q: 為什麼 AI 轉寫準確度這麼高，但會議紀要還是要人工修正？
ASR（自動語音辨識）的準確度是針對「通用語言」，但企業內部有大量的同音混淆、專有名詞、人名簡稱，這些 ASR 根本沒見過。準確度 95% 聽起來很高，但在關鍵詞上錯一個，整個會議紀要就不能用了。
Q: 企業知識庫需要包含哪些內容？
三個核心資料集：(1) 關鍵 stakeholder 清單，包含常見同音混淆；(2) 供應商與合作夥伴名單，包含正式名稱、簡稱、發音混淆；(3) 企業專有詞彙與 Project Code Name，包含技術術語和行業黑話。
Q: 這個方法適用於哪些 AI 會議工具？
任何有提供逐字稿的工具都適用，包括 Otter.ai、Fireflies、Plaud、Zoom AI、Teams 等。核心概念是在「逐字稿→會議紀要」這個步驟中插入企業語境校正。
Q: 數字轉寫錯誤怎麼辦？
這個很難用知識庫解決。建議的做法是：會議錄影定時截圖（例如每 15 秒），然後把截圖和逐字稿合併成圖文會議記錄。因為涉及大量數字的會議，通常有 Excel 或 Dashboard 投影，視覺才是主要信息來源。
Q: 建立知識庫需要多少時間？
初版大概 2-3 天，主要是整理現有的人名清單、供應商名單、內部術語。之後就是日常維護，遇到新的混淆案例就加進去。投入產出比非常高。
Q: 小公司也需要建這套系統嗎？
如果你每週有 3 場以上需要產出正式會議紀要的會議，建議建立。如果只是內部溝通，逐字稿錯一點其實沒差，不需要過度投資。
Q: 可以用 ChatGPT 或 Claude 來做校正嗎？
可以。核心是把你的企業知識庫（人名、術語、供應商）放進 system prompt 或 RAG，然後讓 LLM 在生成會議紀要前先做一輪校正。文章中的範例就是用這個方法。