假設你們部門有一個幫忙回客戶來信的助手，用了一段時間。每隔幾天就有同事來說它又錯了：這次漏看了附件，那次把退貨期限講錯，下一次把一封抱怨信回得太輕鬆。你每次都打開它的說明補一句話，補完那一種錯就少了，過一陣子又冒出新的一種。
問題在於每一次你看到的都只是一封信，從一封信看不出來這個錯是剛好碰上，還是同一類信每次都會錯。
一封信看不出來的事
OpenAI Cookbook 在 2026 年 5 月放了一篇和 Slalom 合寫的範例，叫〈Macro Evals for Agentic Systems〉，講的就是這件事。它開頭說，AI 代理系統出錯時，問題常常比一次壞回答更大：交接可能太晚，某個負責的 AI 可能在很多次執行裡漏掉同一個訊號，人工審核也可能在錯的那一類案件上觸發。要改善系統，得看整批執行紀錄裡重複出現的行為。
它的範例是模擬出來的：讓一組 AI 處理 1,000 筆電動車訂單，其中 992 筆留下完整的執行紀錄，可以拿來評分和比對。它用四個標籤來讀這些紀錄：案件是哪一種情境、最後怎麼結束、評分抓到什麼局部問題、累積起來屬於哪一種重複模式。前三個在分析之前就知道，第四個要把很多筆放在一起才看得出來。
裡面有一個例子我覺得最有用。訂單改走別的出貨路線，在零件要換供應商的案件裡可能是應該的，放在一筆單純的訂單裡可能就是多此一舉。範例的熱度圖也是這樣讀：同一種模式出現在預期會有它的案件裡，跟出現在單純案件裡，可疑的程度不同。我的判斷是，每筆出錯都要記下它是哪一種情境，少了這一欄，很多時候你連它算不算錯都判斷不了。
每筆出錯記三欄
範例用的是分群演算法那一套工具，一般部門用不到。能搬過來的是它的做法：每次出錯都照同一種格式記下來，累積一段時間再一起看。範例自己也提醒，把每一筆紀錄整理好，通常比換一套更複雜的分群設定更能找出有用的模式。
我建議用一張試算表，每筆出錯填三欄：
- 情境：什麼樣的來信或案件（退貨、報價、抱怨、附件很多的信）
- 環節：錯在哪一步（找資料、讀附件、判斷要不要轉給人、寫回覆）
- 結局：後來怎樣（同事改過才寄、客戶又來問一次、已經造成損失）
除了同事回報的錯，還有一些不用問就拿得到的訊號。Microsoft 的 AI 代理入門課在講上線監測時列了幾種：使用者馬上換個說法重問、重複問同一件事、按重試鈕。它說如果看到使用者一直重問同一題，就表示助手沒有照預期在運作。這些也可以記進同一張表。
每次出錯 → 填三欄：情境／環節／結局
│
累積一段時間
│
▼
做樞紐表：哪一格擠最多筆？
│ │
有一格特別多 每格都零星
│ │
▼ ▼
只修那一格的原因 先不改說明
│ 嚴重的個別處理
▼ 其餘繼續記
修完拿同類舊案重跑
再跑幾件原本正常的
歸類之後，先修哪裡
範例排優先順序的方式，是把一種模式的出現比例，乘上依嚴重度加權後的比例，常見又嚴重的模式排最前面。它也講明這不是通用的風險公式，排在前面的模式也不一定就是錯，只是最值得人先去看的地方。
照這個思路，我把常見的幾種集中方式整理成一張表。先看你的樞紐表落在哪一列，再決定動哪裡：
| 類型 | 怎麼認（看哪一欄集中） | 先修哪裡 | 先別做 |
|---|---|---|---|
| 某一類情境特別常錯 | 情境欄同一種佔掉一大半，其他情境很少錯 | 那類情境需要的資料或專屬規則 | 改整份說明，連帶影響其他情境 |
| 同一個環節一直出事 | 情境各不相同，環節欄卻都是同一步 | 那一步用到的工具、資料來源、附件讀取 | 叫它寫得更小心 |
| 該轉給人的沒轉，或簡單的也轉 | 結局欄常是「同事事後補救」，或單純案件也一直轉 | 轉交的條件寫法 | 只補一個例外 |
| 某次修改之後才冒出來 | 出錯日期都在同一次修改說明之後 | 回頭看那次修改，必要時退回上一版 | 再疊一句新規則上去 |
| 每格都只有零星幾筆 | 樞紐表沒有一格明顯比較多 | 只處理後果嚴重的那幾筆 | 每一筆都改一次說明 |
作者整理，非官方。最後一列最容易做錯。每格都只有零星幾筆的時候，先不要改說明，因為你分不出來那是偶發還是樣本還不夠。為了每一筆零星的錯各補一句話，說明會越疊越長，彼此還可能打架。
修完之後怎麼驗，阿里雲的 Agent 手冊第 22 章有寫。同一種遺漏，挑幾筆有代表性的就好，但要同時保留邊界情況，和一部分原本就正常的任務，才看得出這次修改有沒有把別的地方改壞。修完之後，拿同一類的舊案件重跑，也要跑幾件原本就正常的。手冊也提醒，平常要優先看關鍵指標下降、反覆出現的問題和新出現的情境，每次只挑一小組明確的問題去改；分數高的案例也要抽查，免得漏掉評分沒抓到的嚴重問題。
Cookbook 範例最後的建議裡也有一條可以照做：把最明確的那幾筆失敗收進一份回歸測試清單，之後每次改說明都重跑一次；歸出來的模式也按說明的版本分開追蹤，才知道是哪一版帶進來的。
動手做
試算表累積了一段時間，可以整份貼給另一個 AI，請它先歸類，不急著給修法：
下面是我們的 AI 助手一段時間以來的出錯紀錄，每筆有編號、情境、出錯環節、結局，有的有備註。 請先不要提出修改建議，照這個順序做： 1. 把紀錄歸成幾種重複出現的模式，每種模式寫：名稱、判斷依據、屬於這種模式的紀錄編號、筆數。 2. 說明每種模式是集中在某一類情境、某一個環節，還是某段時間之後才出現。 3. 歸不進任何模式的紀錄，另外列成「零星」，不要硬塞進某一類。 4. 依「筆數多」和「後果嚴重」排出先後，只對排第一的模式提出一項修改，並說明修完後要拿哪幾筆舊紀錄、加上哪類原本正常的案件重跑來驗證。 紀錄太少、判斷不出模式時，直接說判斷不出來，並說還需要記哪些欄位。 出錯紀錄：（貼上）
樞紐表做出來之後，先看最多筆的那一格是落在情境、環節還是結局，再對照歸類表那一列的「先修哪裡」動手。
站內延伸
- 單一一筆低分要先查是哪一種原因 → AI 助手分數變低，先別急著改指令
- 改了說明之後出錯變多，要退回 → 共用助手被改壞了，怎麼退回上一版？
- 測試題庫怎麼建、改完怎麼重跑 → 找方法AI Agent 測試
來源： OpenAI Cookbook：Macro Evals for Agentic Systems（2026-05-19，OpenAI 與 Slalom，MIT；問題常比一次壞回答更大、四個標籤、1,000 筆模擬訂單、改走出貨路線在換供應商案件合理而在單純案件多餘、整理紀錄比換分群設定更有用、出現頻率乘嚴重度排序且非通用公式、高排名模式不一定是缺陷、收進回歸測試與按版本追蹤）；aliyun/ai-agent-handbook 第 22 章（Apache-2.0；22.3 同一種遺漏挑代表性幾條、保留邊界場景與原本正常的任務、高分樣本抽檢、日常優先看指標下降與反覆出現的問題；簡體中文改寫）；microsoft/ai-agents-for-beginners 第 10 課（MIT；隱性回饋：馬上換說法重問、重複問、按重試）。三欄紀錄與歸類表為作者整理。2026-10-25 查證。