整份紀錄只有一個名字錯了

那份會議紀錄段落清楚、決議條列、每一項後面都掛了 owner。掃過一遍沒問題，貼進群組。

兩天後那件事沒有動。owner 掛錯人了。被掛名的同仁沒參加那場會，以為是別的專案；真正該接的人看到名字不是自己，理所當然地跳過。兩天之後才有人在別的場合隨口問起。

摘要準確、時間正確、脈絡沒有失真。錯的只有一個名字，而那個名字剛好是整份文件裡唯一會觸發別人行動的欄位。

檢查被當成均勻分布的事

多數人對 review 的預設，是對「整份輸出」做一次檢查，好像品質是平均分布的，所以注意力也該平均分布。

實際的錯誤成本差好幾個數量級。個人日誌裡描述不精準，成本接近零，因為讀者只有自己。內部筆記寫錯一個參數，成本是下次有人照做多花二十分鐘。而 owner 認錯人、對客戶的日期寫錯、規格漏掉一個相依條件，成本會跳到另一個層級，因為錯誤已經離開你的手，進到別人的行事曆或別人的程式碼裡。

三種值得停下來的節點

高風險：錯了會有人受影響，不只是自己多花時間。不可逆：訊息已發出、資料已寫入、承諾已成立。跨責任邊界：這一步之後事情轉移到另一個人手上，而那個人會把它當成既定條件，不會再驗證一次。

第三種最常被漏掉。前兩種有直覺，唯獨「交接」這個動作本身不像風險，它看起來只是把東西傳出去。但責任邊界就是在那一刻被跨過的。

還有一段常被省略：新資訊出現時，要回頭更新已經發出去的內容。多數流程到「發布」就結束，但三天後常會冒出新事實，而那份已經被別人當成依據的文件還停在舊版本。這條回頭的線接不上，前面跑得再快只是把錯誤傳播得更快。

今天可以做的一件事

最常見的問法是這一句：

幫我檢查這份會議紀錄有沒有錯誤。

回來的會是「整體結構清晰，建議在第二段補充背景說明」這一類東西。它把力氣平均分配到全文，剛好跟今天想做的事情相反。而且它根本沒有能力知道哪個名字是錯的，它沒參加那場會。

能指望它的只有一件事：把你要重看的範圍縮小。下面三段 prompt 可以直接複製，在 demo 站台上跑完再搬回自己的文件。

第一段：生成今天主題的測試資料

請先列出我有權限寫入的 Confluence 空間，挑一個名稱含 test、demo
或 sandbox 的；如果都沒有，就挑我的個人空間，並在開始前告訴我你選了
哪一個。

在那個空間建立一頁練習用會議紀錄，標題為
「[DEMO-REVIEW] 客服工單自動分流 週會紀錄 2026/10/28」，
內容全部虛構，約 600 字，要有討論脈絡，不要只有條列決議。

情境：一家線上教育平台公司，正在推「客服工單自動分流」專案。
開頭列出席名單：Anna Wu（產品）、David Chen（平台組）、
林佩宜（客服組）、王柏凱（QA）。結尾有五項決議。

文中要埋進下面幾件事，但不要標示、不要在頁面裡提到它們：
- 其中一項決議的負責人寫成「陳彥廷」，而這個名字不在出席名單裡
- 一句對客戶的承諾：11/15 正式上線
- 一筆金額：年度授權費 48 萬元
- 一個工單編號：OPS-2201
- 另一項決議的狀態寫成「資安評估已確認通過」，但全文找不到
  是誰確認的、什麼時候確認的

其餘內容寫得正常，不要刻意留下破綻或提示。

第二段：把今天的主題跑在這批資料上

請讀取剛才建立的那頁「[DEMO-REVIEW] 客服工單自動分流 週會紀錄
2026/10/28」。這頁等一下要發給專案關係人。

不要潤稿，不要評論寫作風格，不要做整體摘要。

第一步：列出頁面中所有「會觸發別人行動，或會被別人當成既定條件」
的項目，每一項四欄：
- 原文（逐字照抄，不要改寫）
- 類型（人名／日期／金額／單號／狀態／對外承諾）
- 誰會依據它行動
- 如果這一項是錯的，最早會在什麼時候被發現

第二步：只針對上述項目，指出哪幾項「頁面本身沒有提供足以確認它正確
的依據」。

不要修正任何一項，我要自己確認。

對答案的標準有三個：它要列出陳彥廷、11/15、48 萬、OPS-2201 這四項，要指出陳彥廷不在出席名單裡，要在第二步把「資安評估已確認通過」歸類為頁面本身無法驗證。

三件只抓到一件，通常不是模型不行，是第一步的範圍寫得太寬。回去把「會觸發別人行動」改寫成更具體的欄位類型，再跑一次就看得出差別。

那句「不要修正任何一項」是刻意寫進去的，讓它順手改掉你會拿到一份被動過、但你依然沒有逐格看過的文件，錯誤只是換了個位置躲起來，「最早會在什麼時候被發現」那一欄則是拿來排序的：當天就會被發現的項目其實不太危險，兩週後才會爆的那幾項才值得停下來。

第三段：回頭更新那條線

現在假設今天是 2026/10/31，出現一項新事實：
客戶把上線時間往前壓到 11/05，而且要求先只開放兩種工單類型。

請讀取那頁 [DEMO-REVIEW] 會議紀錄，指出哪幾句因為這項新事實而
不再成立，只列出句子與原因，不要重寫整份文件。

最後告訴我：頁面裡寫得出來的人當中，誰當時是依據這幾句在行動。

多數人只會想到 11/15 那一句，但真正會出事的是另外那幾句——決議的範圍、工時估算、甚至那筆 48 萬的授權數量，都可能跟著鬆動。它抓不抓得出第二句，比抓不抓得出日期更能說明這條線有沒有接上。

留到明天的問題

那份會議紀錄最麻煩的地方在於其餘部分都對，對到讓人不想再看第二遍。當輸出的平均品質高到足以關掉你的警覺，省下來的那幾分鐘就不算效率，它只是把成本往後挪，挪到兩天後那個不知道自己該行動的人身上。盡善盡美從來不是每一格都檢查，而是認得出哪幾格一旦錯了，就會變成別人的時間。

每個欄位都對了東西準時發出去，然後呢？為什麼有些正確的內容，發出去之後還是什麼都沒有發生。

再往下想一層，今天談的雖然是 review，底下那件事其實願不願意替兩天後那個不知情的人多看一眼。生成可以交出去，檢查也可以交出去，但沒有任何一個節點能替你決定，哪一種錯誤你不願意讓別人承受。

工具會一直變快，而那一格判斷始終留在人這裡，也只有人會為它感到不安。