一種沒人及時發現的失誤
請 AI 總結一條 CI pipeline，你會得到一段很整齊的話：lint 階段 42 秒、build 3.5 分鐘、整條 pipeline 16.4 分鐘、比上週快 18%。讀起來像一份報告。兩小時後才有人發現 build 從來沒花過 3.5 分鐘，而失敗率是從另一週抄來的。
這段話看起來沒有任何可疑之處。問題就在這裡：編造的數字和真實的數字，排版上完全一樣。
為什麼模型會這樣
AI 寫摘要時並不是在查你匯出檔裡的行，而是在生成「最像下一個詞」的內容——而「像」不等於「有出處」。兩種失誤最常見：
- 編造：那個位置需要一個數字，於是就生了一個。「失敗率 2.4%」會出現，是因為 pipeline 摘要裡通常有失敗率，而不是因為 2.4% 真的存在。
- 漂移：數字本身是真的，但在流轉中變了樣——被四捨五入兩次、秒與分鐘換算錯、從相鄰的行／週／專案串了行。
這兩種都能通過人工審閱，因為審閱看的是文字邏輯，不是算術。
五分鐘核驗流程
1. 留原始匯出，不要只留摘要。 把 CSV、日誌、SQL 查詢結果交給 AI。如果來源本身就是摘要，就沒有東西可以核對了。
2. 把每個數字都當成需要出處的斷言。 一條實用規則：沒有來源行號，就不進報告。 這跟新聞業要求引用出處是同一個道理，只是用在算術上。
3. 先對單位，再對數值。 1500 ms、1.5 s、0.025 min 是同一個時長。AI 摘要裡大量「看起來錯」的數字其實是單位或四捨五入造成的，而真正編造的數字就藏在這片雜訊裡。
4. 留出容差。 摘要裡保留三位有效數字的數值不可能和原始的 4183000 完全相等。設一個小的相對容差（1% 是合理預設值），超出容差的判定為「待核實」，而不是直接判錯。
5. 把「待核實」和「錯誤」分開。 待核實代表你貼的來源裡找不到它——它可能是對的，只是來自你還沒提供的資料；但在找到那個來源之前，它不能進報告。
AI 數字核驗器 把第 3～5 步自動化了：把 AI 回答和來源一起貼進去，它會抽出每個數字、正規化單位與倍數量詞、逐一比對，並把找不到出處的標紅，同時給出對應的來源行號作為證據。
標紅之後要做什麼
按影響從大到小處理，並替每個數字歸類：
| 現象 | 常見原因 | 處理方式 |
|---|---|---|
| 完全找不到，但量級合理 | 編造 | 刪掉，或要求提出出處 |
| 差幾個百分點 | 四捨五入、口徑不同、週期不同 | 確認統計週期再用 |
| 只在單位換算後才相符 | 摘要造成的偏差 | 可以用，但要寫清單位 |
| 對到相鄰但不同的行 | 串行 | 更正，並複查相鄰數字 |
這套方法的邊界
比宣傳更重要的是講清楚限制：核驗工具確認的是可追溯性，不是真實性。
- 數字全對，結論仍可能是錯的——判斷那一段還是要人來做。
- 如果你貼的來源本身是舊的、錯的，甚至是 AI 生成的，所有檢查都會通過。
- 截圖與對話摘要不適合當來源，因為你要核對的數字可能在複製前就已經被四捨五入掉了。
- 只存在於你沒貼上的系統裡的數字，會一直是「待核實」，這是正確行為，但它不是結論。
把它當成一道低成本的第一關：攔下「編造的數字直接進了彙報」這種代價最高的失誤，論證本身仍然交給人的判斷。
讓它變成習慣，而不是救火
兩個做法能讓這件事長期跑得下去：
- 要過程，不要只要結論。 請 AI「把用到的原始數字與指令列出來」，多數情況下就能得到可核對的內容。
- 開會前核，而不是會後核。 核驗只要幾分鐘；等一個編造指標已經送出去之後再發更正信，是幾個小時。
核驗器 完全在瀏覽器本地執行，內部報表、CI 日誌與財務數字不會離開你的電腦；如果來源是從 API 拿到的 JSON，先用 JSON 格式化工具 整理一下再貼進去會更順。