怎麼確保 AI 的判斷可信到敢寫進正式資料庫？

把 AI 當成「會出錯的下游」來設計，不是當真理。四層：一、信任分級——高信心自動寫、borderline 保留原判並通知人。二、對抗驗證——同一個判定用多個獨立視角平行去「反駁」它，多數通過才算，不是同一個 prompt 問三次。三、誤判稽核——用 SQL 指紋找出 AI 的「罐頭答案」模式，重讀原文按 rubric 修正。四、寫入保護——鎖定規則加欄位白名單加 force 模式，防重跑覆蓋。

「對抗驗證」跟「同一個 prompt 問三次」差在哪？

差很多。問三次同一個 prompt 只是拿到三份帶同樣偏見的答案，錯的會一起錯。對抗驗證是給每個驗證者「不同的立場」：L1 叫它盡力攻擊原判定、找過度開火，L2 叫它捍衛原判定，只有兩層都同意才改、都反對才駁回、分歧升人工。真實一批 16 票裡，L2 擋掉了 L1 想改的 6 個裡的 4 個——那 4 個是 L1 的誤殺。

AI 批次分析的效能瓶頸在哪、怎麼省 token？

瓶頸幾乎都是 output-bound 不是 input-bound——生成的 token 才是天花板（例如一批 22 張票約 80K 輸出就到頂），所以要砍的是「一次處理幾張票」不是「塞多少 context」。省 token 的招：主票給完整 diff、聚合子票只給檔名（省約 95%）；讓模型輸出結構化資料不要寫 boilerplate；解析結果讓下一步不用重讀 raw log。

AI 回傳「success」就代表寫入成功、可以驗收了嗎？

不行。這是最容易踩的破壞性寫入陷阱。曾有一個寫入 API 無條件覆蓋十幾個欄位，就算把資料清成 null 也照樣回 success——結果洗掉了 36 張票的分數。「API 說成功」不是驗收，「DB 裡的值等於我送進去的值」才是。驗收要回讀資料庫比對，不能信回應碼。

AI 判斷不可信怎麼辦

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

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

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

核心心智模型：AI 是會出錯的下游，不是真理

flowchart TB
    AI[AI 判定<br>估點/風險/OKR/評分] --> L1{信任分級}
    L1 -->|高信心| W[自動寫入]
    L1 -->|borderline| H[保留原判<br>通知人複核]

    W --> V[對抗驗證<br>多視角反駁]
    V -->|多數通過| DB[(正式 DB)]
    V -->|被駁回| H

    DB --> A[誤判稽核<br>SQL 指紋抓罐頭答案]
    A -->|發現系統性誤判| R[重讀原文<br>按 rubric 修正]
    R --> DB

    P[寫入保護<br>鎖定+白名單+force] -.守著.-> DB

    style AI fill:#f59e0b,color:#fff
    style DB fill:#7c3aed,color:#fff
    style P fill:#ef4444,color:#fff

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

第一層：信任分級（不是所有判定都該自動寫）

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

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

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

第二層：多視角對抗驗證（重點：立場要相反）

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

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

flowchart LR
    J[AI 原判定] --> L1[L1 攻擊層<br>refuter / critic<br>盡力反駁原判]
    L1 -->|想改| L2[L2 捍衛層<br>skeptic<br>盡力維護原判]

    L2 --> D{兩層都同意?}
    D -->|都同意改| Y[改]
    D -->|都反對| N[駁回, 維持原判]
    D -->|分歧| E[升人工]

    style L1 fill:#ef4444,color:#fff
    style L2 fill:#06b6d4,color:#fff
    style E fill:#f59e0b,color:#fff

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

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

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

第三層：誤判系統性稽核（AI 會有「口頭禪」）

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

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

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

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

第四層：破壞性寫入保護（「success」不是驗收）

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

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

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

配套的寫入保護：

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

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

附帶心法：批次分析是 output-bound

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

省 token 的實用招：

招式	做法	效果
差異化 context	主票給完整 diff、聚合子票只給檔名	省約 95% token
結構化輸出	讓模型輸出結構化資料，不要寫 boilerplate	省每次數千 token
解析代替重讀	讓下一步讀「解析後結果」不重讀 raw log	下游不再燒 token

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

一張圖收尾：把 AI 當下游來設計

mindmap
  root((敢寫進生產 DB<br>的 AI 判斷))
    信任分級
      高信心自動寫
      borderline 保留原判通知人
      非破壞性預設
    對抗驗證
      立場相反不是問三次
      L1 攻擊 L2 捍衛
      多視角 refuter/critic
    誤判稽核
      SQL 指紋抓罐頭答案
      按 rubric 批量重判
      錨定快照防漂移
    寫入保護
      success 不是驗收
      回讀 DB 比對值
      鎖定+白名單+force
      讀寫同源

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

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