AI 判斷不可信怎麼辦 — 生產環境的對抗驗證與誤判稽核

站上另一篇談的是「AI 寫的 test 怎麼信任」——那是信任 AI 產出的程式碼。這篇更進一步：怎麼讓 AI 的「判斷」可信到敢寫進正式資料庫、甚至拿去影響績效評分。

難點從來不是「接上 AI」。接個 API 誰都會。真正的難題是：AI 的判定是主觀、會出錯、且無法逐張人工複核的，你憑什麼敢把它的估點、風險評估、OKR 歸類、績效評分直接寫進生產資料庫？

答案不是「更好的 prompt」。是把 AI 當成一個會出錯的下游系統來做工程防護。

四層——信任分級、對抗驗證、誤判稽核、寫入保護——缺一層都會在某個時刻讓錯的判定溜進生產。下面逐層拆。

不要「AI 說什麼就寫什麼」，也不要「全部都要人審」（那 AI 就沒意義了）。分級：

• 高信心 → 自動寫入。
• borderline（模稜兩可） → 保留原本的判定不動，另外產一筆「待人工核准」的指令，通知人來看。

關鍵字是非破壞性：borderline 的情況下，系統只產出建議、不自動改動既有值。AI 不確定的時候，預設是「什麼都不動」，而不是「賭一把寫下去」。

這是最容易做錯的一層。很多人以為「驗證」就是同一個 prompt 問三次取多數——錯。問三次只會拿到三份帶同樣偏見的答案，錯的會一起錯。

真正有用的是給每個驗證者不同的立場，讓它們互相對抗：

L1 的任務是「攻擊」——找原判定哪裡過度開火、哪裡誤掛。但只有 L1 會矯枉過正（為了找碴而亂改），所以加一個立場相反的 L2：它的任務是「捍衛原判定」。只有兩層都同意才改、都反對才駁回、分歧才升人工。

真實數字：一批 16 票，L1 想改其中 6 個。L2 擋掉了 4 個——那 4 個是 L1 的誤殺。如果只有 L1，這 4 張正確的判定就會被 AI 自己改壞。

還有一個維度的對抗：對「OKR 歸類」這種判定，用多個獨立視角平行 challenge——業務場景 refuter、季度時間 refuter、漏掛 critic——再綜合裁決，攔截單一視角放過的誤掛與漏掛。同一關鍵字（例如「入金」「清算」）在不同產品線語意不同，要先鎖定業務場景，再對規則的範圍描述（不是標題）做比對。

AI 犯的錯往往不是隨機的，是成模式的——同一種情境它會反覆給同一句「罐頭判語」。這反而好抓：

真實案例：早期批次分析用一句罐頭判語，把一批其實有實質驗收條件的票壓成了低分。做法：用 SQL 去指紋比對（找出重複出現的罐頭措辭）→ 撈出所有中招的票 → 重讀原文、按 rubric 重新評分（多個 agent 平行跑）→ 用最小破壞面寫回。一次修正了 66 張歷史誤判。

這層的價值是：AI 的錯是系統性的，你的修正也可以是系統性的。與其祈禱它不犯錯，不如假設它一定犯錯，然後建一套「定期用 SQL 抓自己的口頭禪、批量校正」的機制。

還要防漂移：AI 重跑同一張票時，估點值容易在幾分之間來回跳（噪音）。把新判定錨定到上一版快照分數，非顯著差異就不動——因為「噪音比漂移更傷」，數字每次重跑都變，人就不信它了。

最後一道，也是最血的一課：不要相信寫入 API 回的 success。

真實案例：一個寫入 API 無條件覆蓋十幾個欄位，而且就算你把資料清成 null 也照樣回 success。結果一次重跑洗掉了 36 張票的分數——API 全程回成功。

「API 說成功」不是驗收，「DB 裡的值等於我送進去的值」才是驗收。驗收要回讀資料庫比對。

配套的寫入保護：

• 鎖定規則：已完成/已終局的票不給覆蓋（判定已定案）。
• 欄位白名單：只允許改指定欄位，其他一律不碰。
• force 模式：要繞過鎖定必須人工顯式指定，不能是預設。
• 分層寫入：接前面的信任分級——高信心自動改、borderline 只留建議。

還有一類靜默 bug 要特別點名：read-local-write-cloud。本地跑 AI 分析、卻讀本地資料寫雲端 DB，當本地落後雲端時就會默默產出錯數字。讀寫必須同源——這是一整類難抓的 bug，不會報錯，只會讓數字悄悄錯掉。

做 AI 批次分析時，很多人本能去壓縮 input（塞更少 context）。方向錯了——瓶頸幾乎都是 output-bound：生成的 token 才是天花板（例如一批 22 張票約 80K 輸出就到頂）。所以要砍的是「一次處理幾張票」，不是「塞多少 context」。

省 token 的實用招：

還有一個校準紀律：用真實結果數據回頭校 AI 的量尺。曾發現「估點 1 分」和「估點 2 分」的實際工時無差別的佔了 81%，於是修正評分映射，把兩級合併——不是拍腦袋調，是拿實測分布當證據。

AI-as-judge、adversarial verification 大家都在講，但真正拿去寫進會影響人事的生產資料庫、還有 production 數字撐著的案例極少。重點一句話：把 AI 當「會出錯的下游」設計，不是當真理——它一定會錯，你的系統要在它錯的時候還守得住。