為了讓 AI 吵架 開發了這個小玩意

當三個 AI 吵起來的時候

前陣子，我做了一個小實驗。

事情是這樣的，自從 AI Coding 工具越來越成熟之後，我訂閱了 Claude Code，每天用它寫程式、review 程式碼、做技術研究，說真的～太好玩了，有一種每天都進入心流的感覺。那個感覺，好爽！！！

但用了一陣子之後，我開始有一個揮之不去的疑慮？如果 Claude 看漏了什麼，我怎麼知道？

這不是在質疑 Claude 的能力，而是一個很基本的邏輯問題：用同一個工具去檢查自己寫出來的東西，本質上就是球員兼裁判。 你請 Claude 幫你寫一段認證邏輯，再請 Claude 幫你 review 這段程式碼，它當然會覺得自己寫得很好啊，因為那就是它的思路。這就像你寫完一篇文章，自己校對三遍，還是會漏掉錯字，但拿給別人看，一秒就找到了。

所以我開始想，既然現在御三家的 AI 都有了：Claude Code、Codex、Gemini 到底能不能讓它們同時看同一份程式碼，各自給出意見，然後交叉比對？

雖然我知道好像可以用 pipe 做到，但我不會阿 XD

但真正動手做的時候才發現，這件事情比我想像中有趣得多。

從「順手寫幾個 script」開始

一開始的想法很單純：寫兩個 shell script，一個呼叫 Gemini CLI，一個呼叫 Codex CLI，讓 Claude Code 當調度者，把程式碼丟過去、收回來、整理結果。就這樣，花了一個下午，基本的 /code-review 指令就能跑了。

然後問題來了。

Codex 回傳的格式跟 Gemini 完全不一樣。Codex 可以乖乖地用 emoji 標嚴重程度、列點清楚，但 Gemini 有時候就是一大段散文，沒有分類、沒有分數，你叫它用特定格式輸出，它偶爾聽、偶爾不聽。更麻煩的是，有時候 provider 直接掛掉——API timeout、回傳空白、或是回一個跟你要求完全無關的東西。

如果這時候整個 review 就因為一個 provider 掛掉而中斷，那也太脆弱了。

所以我開始處理各種邊界情況：provider 失敗的時候怎麼辦？格式不對的時候怎麼辦？只有一個 provider 有回應的時候，review 還要不要繼續？這些問題一個接一個冒出來，原本「順手寫幾個 script」的計畫，就這樣一路長了起來。

三方對抗式 Review

真正讓我覺得「欸，這東西好像真的有用」的時刻，是某次跑完 multi-review 之後。

那次我改了一段涉及權限驗證的程式碼，三個 provider 分別回來的結果是這樣的：Gemini 說「這段邏輯看起來沒問題」，Codex 說「這裡有一個先後順序的風險」，而 Claude 在綜合兩邊意見的時候，不但認同了 Codex 的判斷，還補充了一個兩邊都沒提到的潛在問題。

三個 AI 對同一段程式碼的看法居然可以差這麼多。

這就是我一直在想的「同源盲點」問題。每個模型都有自己的訓練資料、自己的推理傾向、自己的盲區。單獨看任何一個，你都會覺得它講得很有道理。但放在一起比較的時候，你才會發現～原來「看起來沒問題」跟「真的沒問題」之間，可能隔了一個 race condition （也是 AI 告訴我才知道這個名詞的 XD）。

後來我把這個模式固定下來：先讓 Gemini 和 Codex 各自獨立 review，再由 Claude 做綜合分析。Claude 的工作不是簡單地把兩邊結果拼在一起，而是要判斷：哪些問題是共識（兩邊都提到的，通常比較可信）、哪些是分歧（只有一邊提到的，需要進一步判斷）、還有沒有兩邊都漏掉的。

這個「對抗式」的 review 流程，反而比任何單一 AI 的 review 都讓我更放心。

從本機到 CI

做到這裡的時候，我突然想到一件事：這些 review 都是我手動觸發的，我在本機打一個指令、等結果、看報告。但如果這個流程可以自動化呢？

每次有人開 PR 的時候，GitHub Actions 自動跑一次三方 review，結果直接貼在 PR 的 comment 裡面。這樣不管是我自己的 PR，還是未來如果有人貢獻程式碼，都能自動獲得多視角的審查。

不過 CI 環境跟本機完全不一樣——CI runner 上面沒有 Claude Code，也不適合裝一堆 CLI。所以我另外寫了一條完全獨立的路徑：直接用 curl 跑REST API，不依賴任何 CLI。這樣 CI runner 只要有 bash 和 curl 好像就能跑，零依賴的感覺 XD

做完 CI 整合之後，整個工具的樣子已經跟最初想的完全不一樣了。一開始只是想解決「球員兼裁判」的問題，最後變成了一個從本機到雲端、從手動到自動的 review 系統。

意料之外的發現

在做這個工具的過程中，有幾個讓我意外的發現。

第一個是 AI 之間的個性差異比我想像中大很多。Gemini 特別擅長抓 UI 和 accessibility 的問題，Codex 對邏輯漏洞和 edge case 比較敏感，Claude 則在綜合判斷和架構層面的建議上更強。這不是刻意設計的分工，而是跑了很多次之後自然浮現的模式。

第二個是 review 的品質不完全取決於模型的能力，更取決於你怎麼問。同樣一段程式碼，用不同的 prompt 去問，得到的 review 深度可以差好幾個等級。這也是為什麼我後來花了不少時間調整 prompt 的設計，而不是一味地追求用最強的模型。

第三個，也是最讓我感慨的：工具本身不值錢，但工作流值錢。 我寫的每一個 script 都不超過兩百行，技術上沒有什麼了不起的東西。但把它們串在一起、設計好觸發的時機和結果的呈現方式之後，它就變成了一個真正能嵌入日常開發流程的東西。

後記

回頭看，這個專案的發展軌跡其實跟很多事情很像你帶著一個小小的問題出發，做著做著，越來越多可能性冒出來，每一個都讓你覺得「好像可以再試試看」。最後回過頭，才發現自己已經走了比預期遠得多的路。

我不確定這個工具最後會變成什麼樣子，但至少現在，每次看到三個 AI 對同一段程式碼吵起來的時候，我都覺得蠻療癒的，而且然後最近看到很多人有做一個虛擬辦公室的像素畫面，感覺做出來應該也很好玩。

畢竟，連 AI 都會有意見不合的時候，那我們人類偶爾吵個架，好像也很正常嘛 XD

最後補上這個專案的連結 專案的名稱叫做 claude-prism

希望它能像「三菱鏡」一樣，透過彼此的審閱，找出集合的優缺點。