讓 GPT 當 Claude Code 的唯讀 reviewer：用 Pi 做對抗式 review

Claude 寫完 code 再自己 review，抓到的多半是它本來就想得到的東西。換另一家的模型來審，第一次實戰就抓到一個 Claude 自己寫、自己審都沒發現的回歸。

做法是用終端 coding agent Pi，透過 API 接 GPT 模型，包成 Claude Code 叫得動的唯讀 reviewer。

做下來有兩個結論：權限規則不是 sandbox（由系統限制程式碰得到哪些檔案），要唯讀，得一開始就不給有寫入能力的工具；對抗式 review 要收斂，得先告訴 reviewer 範圍在哪、上一輪怎麼處理了。

找另一家模型當 second opinion，我的條件只有一個：reviewer 不能改檔，要不要改、怎麼改，由我和 Claude 決定。

用法是在 Claude Code 裡說「叫 pi review」或打 /pi-review，Claude 就把未 commit 的改動、branch、PR 或 plan 文件交給 Pi。

findings 回來之後，Claude 逐條打開 code 核對，標成同意、不同意或無法確認，再回報給我。

Pi 只裝兩個套件

• earendil-works/pi-review：官方的 /review，findings 分 P0 到 P3
• @gotgenes/pi-permission-system：替 tool、bash 指令、路徑設 allow／ask／deny 規則

看過但沒裝的有兩個。pi-web-access 預設走 Exa 搜尋，code 片段會被送到外部服務；pi-simplify 會直接改檔。

我也想過把 Pi 包成 MCP server（讓 Claude Code 用標準協定呼叫的外部工具）。但唯一找到的 pi-mcp-server 已經停更，社群主流做法就是直接 shell-out。

Pi 會自動讀專案的 CLAUDE.md、AGENTS.md，review 時套用同一套專案規則，不用另外交代。

權限規則不是 sandbox

規則這樣設：edit、write 一律 deny；bash 預設 ask，只放行讀取類指令和 git diff/log/show/blame、gh pr diff/view。

.env、.ssh、.aws 和 Pi 自己的 auth.json 連讀都擋。在測試 repo 驗過，write tool 被隱藏、touch 被擋。

但這是規則層，不是 sandbox。

互動模式下，允許的讀取指令搭配重導向，例如 cat a > b，還是寫得了檔。

第一次正式用的時候，我手動開 pi，沒加 --tools。Pi 拿得到 bash，實際跑了 rg 和 git diff，只靠權限規則在擋。

之後 skill 啟動 Pi 一律帶 -na --tools read,grep,find,ls，完全沒有 bash。

Default enabled tools are read, bash, edit, and write, unless defaultTools changes them. --tools with plain names replaces the whole selection, so name every tool you want.

出自 Pi 的 CLI 文件。不帶 --tools，bash 就在預設工具裡；帶了，就只剩點名的那幾個。

diff 先寫成檔案，讓 Pi 用 read 去讀。我直接問它有哪些工具可用，它只回 read、grep、find、ls。

權限規則就退成第二層保險。它擋得住大部分情況，但只適合當備援，要唯讀，就從啟動參數拿掉寫入工具。

跑法有兩種。在 herdr（給 coding agent 用的終端多工器）裡，會在右側開一個 Pi 的 panel，我看得到它在讀什麼，session 也會保留，可以多輪來回。另一種是 headless 的 pi -p，從 stdin 餵 diff。

三輪才收斂

給 Pi 的 prompt 是對抗式的：要它驗證作者自稱的設計是否真的成立，去攻擊邊界輸入、滾動更版、transaction 邊界這些地方。

沒問題的話，第一行要回「無需修正的 finding」，Claude 看第一行就知道要不要進下一輪。

我明說要修，才進修正迴圈。修程式要補測試，還要做 mutation 驗證（故意把程式改壞，看測試會不會失敗）。

第一次實戰跑了三輪。第一輪就抓到一個 Claude 自己引進的回歸：寫入時拿讀出來的舊值去補欄位，會把別人剛改過的值蓋掉。

Claude 自審時沒看到這個。

收斂沒那麼順。一開始每輪都會冒出既有機制的問題，跟這次改動無關。

我在 prompt 加了三個要求才收得起來：base branch 就有的問題標成「既有」、只回報這次改動範圍內的問題、附上上一輪每個 finding 的處置清單。

結果是第一輪 2 個 High、1 個 Medium，第二輪 1 個待確認、2 個 Medium，第三輪回「無需修正的 finding」。

少了範圍和上一輪的處置，對抗式 review 會一直挑出跟這次改動無關的既有問題，收斂不了。

review 過程只留在筆記

修 finding 時寫的程式註解，只寫這段程式現在為什麼這樣寫，不寫「pi 提出」，也不寫之前的寫法。

review 的過程只記在我自己的筆記，不進會 commit 的文件。

另一家模型確實看得到自審漏掉的東西，第一輪那個回歸就是例子。