別只信一個 AI：多模型交叉驗證的三種實作
同一個問題丟給兩個 AI，答案不一樣的地方，往往就是幻覺藏身的地方。
前言
用 AI 工作一段時間後，我學到最重要的一課不是「怎麼下 prompt」，而是「不要只信一個模型的答案」。這篇整理我在真實專案裡實際跑過的三種多模型交叉驗證做法：研究比對、盲測評分、對抗式規劃。它們的成本不同、適用場景不同，但共同的價值只有一個 —— 幫你找出「該親自查證什麼」。
做法一：研究比對 —— 分歧點就是幻覺偵測器
情境：幫一個客戶評估「零預算」網站架構，需要調研一堆免費工具與免費額度（UI 元件庫、AI 建站工具、Netlify、Supabase 等）的授權與限制。
做法很簡單：先讓 Claude 做一輪完整調研，再讓 Codex 針對同一批結論逐項複核官方來源，最後把兩邊意見整理成一張「共識 / 分歧與裁決」表。
結果分歧點非常有料，幾個例子：
- 某元件平台：Claude 認為定價沒有免費方案所以不可用；Codex 查官方 pricing 發現其實有 $0 的 Hobby 方案。→ 過時資訊。
- Supabase 免費專案數：初版寫「每個 organization 2 個，可以另開 organization 加量」；官方文件明確寫免費額度是跨所有 organization 計算的。→ 聽起來合理的幻覺，而且照做會踩到服務條款。
- 用 cron 打 API 避免免費資料庫休眠：官方只說「通常」足夠、不保證。→ 不是錯，但不能當 SLA 承諾寫進提案。
注意這裡的重點：兩個 AI 都同意的地方也不代表是對的，但分歧的地方幾乎一定值得回查官方來源。 分歧清單把「全部重查一遍」的成本，壓縮成「只重查有疑慮的十件事」。
做法二：盲測評分 —— 幫任務挑對模型
情境：想知道同一家的三個模型版本（Opus 4.6 / 4.7 / 4.8），哪個最適合做深度分析類工作。
做法：拿一份真實專案的除錯根因分析（RCA）文件，設計四個子任務（因果鏈梳理、修法完整性分析、補測試情境、文件品質評分），三個模型收到完全相同的 prompt，然後把三份輸出打亂順序、匿名成 Model A/B/C，交給另一家的模型（Codex）做五個維度的盲評。
結果出乎我意料：勝出的不是最新版本。中間版本抓到一個另外兩個模型都沒發現的邊界情況（迴圈解碼中途失敗會留下半解碼的中間態），而且評分校準最誠實、資訊密度最高。最新版本最系統化、掃得最全，但深度和批判力稍弱。
結論不是「哪個模型最強」，而是不同深度的任務適合不同模型：深度審查用抓得到獨家問題的那個，首輪大範圍掃描用系統化的那個。這種結論只有盲測能給你 —— 不盲測的話，你的印象分數會被「版本號比較新」綁架。
做法三：對抗式規劃 —— 把交叉驗證做成固定流程
前兩種是一次性的，第三種是把多模型驗證直接寫進開發流程的規則裡。我在一個 side project 的 CLAUDE.md 裡定了這條：改動檔案超過 2 個的功能規劃，自動跑一個 multi-model workflow —— A 模型出架構方案、B 模型審查現狀相容性、再由 A 模型做對抗性審查（專門挑毛病），全部通過才進人工 LGTM 關卡；workflow 掛掉就退回單模型規劃。
另外搭配一條「獨立驗證」規則：行為或流程變更在宣告完成前，回歸驗證和 review 必須交給一個乾淨上下文的獨立 subagent，不准寫 code 的那個 session 自己審自己。原因很直白：同一個上下文裡的模型會傾向替自己的產出護航，換一個沒有包袱的上下文，挑錯的意願和能力都明顯更好。
共同心法：價值在分歧點清單，不在多數決
三種做法背後是同一件事：多模型交叉驗證的價值不是投票表決誰對，而是產出一張「分歧點清單」。 兩個模型都說對的事你未必要信，但它們吵架的地方，就是你該親自打開官方文件、親自跑指令驗證的地方。AI 幫你把無限的查證範圍收斂成有限的待辦清單 —— 這才是它省時間的方式。
如果你只想先試一種：從做法一開始。成本最低，一次調研加一次複核，你就會親眼看到「講得頭頭是道的幻覺」長什麼樣子，之後就再也不敢只信一個 AI 了 XD