摘要： OpenRouter 於 2026 年 11 月 1 日發表教學，示範用一支純標準函式庫的 Python 腳本（review.py，共 233 行）打造 AI 程式碼審查器。它不只是讀 diff，而是把改動檔案上傳到託管 Linux 沙盒，讓模型實際執行檢查、確認 bug 後才回報，修復以 V4A patch 形式交付。對想自建審查流程的開發者來說，這是「只靠 diff 猜 bug」和「先驗證再回報」兩種品質的差別。
只讀 diff 的審查器，先天有盲點
OpenRouter 在教學中點出常見痛點：只讀 diff 的審查器必須猜測檔案其他部分的長相，也無法確認疑似 bug 是否真的會在執行時失敗，建議的修法只能靠人工貼上。這支腳本的解法是把改動後的完整檔案、測試等 context 檔和 Git diff 一起上傳，讓模型掌握 diff hunks 之外的 imports、helpers 與型別。
腳本組合了 Responses API 上的三個 server 工具和一個 function tool：Files API（beta）負責上傳檔案與 diff；Shell server tool（openrouter:shell，beta）把檔案放進託管 Linux 容器，讓任何模型都能跑 Python 和 SQLite；Apply Patch server tool（beta）讓模型用 V4A diffs 提出檔案變更，OpenRouter 會驗證 diff 語法並自動把錯誤回傳給模型，實際寫檔則留給你的應用程式。最後的 submit_review 是嚴格 JSON schema 的 function tool——教學說明，因為在 anthropic/claude-haiku-5.5 上，請求帶有工具時 text.format 的 json_schema 不會被強制執行，答案會變成夾帶多餘欄位的散文或 markdown fences。
每個 finding 都帶證據
審查流程是這樣跑的：腳本從 Git 取得 diff 與改動檔名（單次請求上限 20 個檔案，即 19 個檔案加 diff），上傳到 /api/v1/files；上傳的檔案會以檔案 ID 最後 8 字元加檔名的形式出現在沙盒 home 目錄，腳本因此把重建 repository tree 的 cp 指令寫進提示詞。模型在 ~/repo 工作，對每個疑似 bug 寫並執行簡短檢查：能跑出失敗結果的標記為 confirmed，附上指令與輸出作為證據；跑不出來的（例如連線洩漏、race condition）標記為 unconfirmed 並解釋原因。
有個細節值得注意：模型提交 patch 時，回應會暫停，讓腳本先在你機器上的暫存副本試套用，再告訴模型結果。patch 並不會套用到沙盒裡，所以模型的檢查是針對原始程式碼跑的——用 —apply 之後仍要自己跑測試。
成本與速度的實測數字
在 OpenRouter 對一個含五個 bug 的改動的測試中，四個模型的單次審查費用在 $0.015 到 $0.045 之間，耗時一到四分鐘。Claude Haiku 5.5 平均每次 $0.0153；Claude Sonnet 5.5 在三次執行中全部修好五個 bug，每次 $0.0447、約 60 秒。報告寫入 .git/ai-review.json，當 finding 達到嚴重性門檻（—block-at，預設 high）時 exit 1，可直接接進 Git pre-push hook 或 GitHub Actions。
動手前的三個限制
需要 Python 3.11 以上、Git 和 OpenRouter API key。這幾點會直接影響你能不能用、該不該用：
- Files API、Shell 和 Apply Patch 工具只在全域端點（https://openrouter.ai/api/v1）運作，in-region 端點會回 403。
- 改動檔案和 context 檔會上傳到你的 OpenRouter workspace 並轉送給模型供應商——只對允許分享的程式碼執行，並把 secrets 排除在外。
- 超過 19 個檔案的改動要拆小批次審查。
這個做法和我們之前看過的 OpenRouter Shell 工具如何改變代理的執行邊界 一脈相承：把終端機交給模型，換來的是可驗證的行為，而不是文字上的推測。如果你想自己試，下一步就是照教學把 review.py 放進 repo 根目錄，先在樣本 repository 上跑一輪，再決定要不要掛進 pre-push hook——exit code 和嚴重性門檻的設計，已經替 CI 整合留好了位置。