讓 AI 寫的程式碼交給另一個 AI 審：cc-pair 把「互相 review」做成指令
（事件日期：2026 年 10 月 30 日）開發者 motorme 在 V2EX 分享自製工具 cc-pair，並同步發上 Show HN。這個工具做一件事：把 Claude Code 和 Codex 配成一對，一個寫程式、另一個審查，來回幾輪直到通過。帖子發佈一天內累積八百多次瀏覽，討論集中在同一個問題：跨模型互審，真的抓得到自審漏掉的毛病嗎？
起點是一個很日常的觀察
作者的動機來自使用經驗：讓同一個 agent 審自己剛寫的程式碼，它幾乎都會放行。這其實和人的處境很像，自己檢查自己的作業總是手軟，因為寫的時候已經相信了那套邏輯。模型也一樣，它剛產出那段程式碼時的「思路」還熱著，再回頭看自然覺得順。
cc-pair 的解法是把作者與審查者拆成兩個不同的模型。寫完一輪後，改動會交給另一邊審查，對方給出「通過」或「要改」的結論；作者逐條回應，同意的修改，不同意的說明理由，再送回去覆審。超過輪次上限（預設三輪）就停下來，交給人裁決。
訊息走磁碟，過程看得到
兩個 agent 之間的溝通不靠什麼神祕通道，而是共享目錄裡的編號檔案（~/.pair/
使用上有自動與手動兩種模式。自動模式在終端跑 pair start --as claude（或 --as codex），每一輪自動把另一個 agent 拉起來當審查者，不用開第二個終端（macOS / Linux）；Windows 使用者則用兩個終端各自操作的手動模式。安裝透過 npm，需要 Node 22+，且兩個 CLI 都已登入。
搭配檔次，比工具本身更關鍵
作者在回覆中分享的實際心得，比工具簡介更有參考價值。他常用的配置是審查者的推理強度比作者高一個檔次（例如 author 用 Opus 5.5，reviewer 用更高檔的 GPT 模型），審出的問題品質明顯更好。大多數情況三輪內通過，卡關時停下來由人指方向再繼續；特別複雜的變更，他會在最後額外加一輪高檔模型對整個 PR 總審一次。
他還提到一個延伸用法：這套機制不限於寫完才審。探索方向時，跟 Claude 說一句「ask codex」，兩邊就方案先來回討論幾輪；spec 草案寫好後也可以先吵清楚設計層面的問題再動手。換句話說，這是把「先對齊再施工」的流程，交給兩個觀點不同的模型代跑。這個思路與我們先前談過的AI 編程工具競爭轉向零成本搬遷方向一致：工具的價值正在從單模型能力，轉移到怎麼組合多個模型的工作流。
對一般開發者的意義
過去要跨工具搬運審查意見，常見做法是兩邊各開一個 session 手動複製貼上，多個 worktree 並行時還容易貼錯地方。cc-pair 把這段體力活自動化，本質上是給「模型互相制衡」鋪了一條軌道。這也與coding agent 多數跑在 Node.js 生態的現象相呼應：當開發工具都以 CLI 形式存在於同一個環境，像這樣把它們串成流水線的門檻就降到一個 npm install。
至於跨模型互審的效果，目前只有作者本人的使用報告，缺少更大樣本的驗證。但方向本身值得留意：當單一模型的輸出越來越難靠人眼把關，讓立場不同的模型互相挑毛病、過程留檔、人只在卡關時介入，這種分工可能會成為 AI 輔助開發的常態配置。有興趣的讀者可以在 GitHub 的 README 附錄看到完整的審查往返範例，再判斷適不適合自己的工作流。