OpenRouter AI 程式碼審查教學：能重現問題，為何還不能自動相信補丁？
OpenRouter AI 程式碼審查官方教學用沙盒重現問題，但補丁仍需另跑測試。解析confirmed、退出碼、四模型小型比較、容器費用與程式碼外送限制。
OpenRouter AI 程式碼審查教學把模型判讀與程式執行放進同一條流程，讓問題報告能附上復現指令及輸出。復現就是用可重跑的檢查，確認問題在什麼條件下出現。
只把 Git diff，也就是這次修改的差異，交給模型時，它可能不知道周圍函式如何使用。即使評論讀起來合理，也需要更多依據才能判斷程式真的有錯。
OpenRouter 在 2026 年 11 月 1 日發布官方教學，並於隔天的社群貼文受到討論。範例用233行Python，把修改後檔案與測試內容上傳，再讓模型在由服務商代為管理的 Linux 沙盒執行檢查。
這套做法把已復現與未復現的發現分開，但沒有讓每個補丁都自動變成正確答案。問題能被證明，和提出的修法不會破壞其他呼叫，是兩個不同關卡。
官方刻意放入五個錯誤的小型測試，也呈現模型找得到問題、卻修壞程式的情形。因此，不能把這份示例讀成大型專案或所有模型的通用排名。
它適合能將程式碼交給外部服務、願意閱讀證據並跑測試的團隊。費用除了模型文字用量，還包含容器存續時間，模型思考的等待也可能計費。
要判斷這種審查是否適合自己的專案，先看檔案如何從本機進入沙盒，以及補丁最後在哪裡驗證與套用。
OpenRouter AI 程式碼審查如何串接四個部件？
這個範例依序提供完整上下文、執行環境、補丁工具與結構化報告，讓每一步都有較明確的輸入與結果。
依 OpenRouter 官方教學，腳本先從 Git 取得差異及修改檔案，再加入開發者指定的測試等額外內容，透過 Files API 上傳。
API 是程式呼叫服務的介面。這裡上傳的是修改後檔案全文，讓模型能查看差異之外的型別、輔助函式或其他呼叫，減少只看局部程式時的猜測。
接著，Shell 伺服器工具把檔案放進由服務商管理的容器。容器是隔離的執行環境，模型能在其中寫短檢查並執行 Python 或 SQLite，而不是只用文字描述可能發生的結果。
第三個部件是 Apply Patch 工具，讓模型以指定差異格式提出新增、修改或刪除檔案。平台會檢查差異語法，但實際檔案寫入仍由應用程式處理。
最後，模型要呼叫 submit_review 函數工具，交回符合欄位要求的報告。官方在開發過程中發現，單靠要求文字輸出遵守結構，在同時使用工具時可能出現格式偏移。
這些部件解決的是不同問題，所以結構化報告並不等於內容正確，差異語法正確也不等於修復有效。讀報告時，仍要先看它究竟證明了什麼。
confirmed 與 unconfirmed 各能支持哪種判斷？
已確認的發現應附上能展示失敗的指令與輸出。未確認的發現則保留尚無法用短檢查證明的疑慮，方便人工繼續判讀。
例如，某段分頁程式在特定輸入下少回一筆資料，模型可以建立一組輸入，執行後列出預期值和實際值。這種結果比「看起來可能少算一筆」更容易檢查。
但這個證據也有範圍，它只展示該輸入與環境下的行為。若輸入前提與真實應用不同，團隊仍要判斷這是否屬於本次修改引入的問題。
連線未關閉或競爭條件等問題，可能較難用短腳本穩定呈現。官方示例允許模型將它們列為未確認，並說明理由，而不是為了讓每一條發現看起來完整就捏造輸出。
因此，已確認可以作為較強的調查訊號，未確認也不代表一定無害。兩者讓審查者知道下一步需要的是核對前提，還是補上更合適的測試。
退出碼如何避免把未完成誤認成通過？
腳本以退出碼告訴自動化流程結果。預設嚴重度門檻是 high，達到門檻的發現會回傳1。沒有達門檻的發現，或沒有差異可審，則可回傳0。
回傳2代表審查未完成，例如超過八輪仍沒交出報告，或變更檔案超過範例限制。這個狀態需要另外處理，不能因為沒有完整問題清單就視為通過。
門檻也沒有自動保證只阻擋已復現問題。範例是依發現的嚴重度判斷，所以團隊在設定工作流程時，仍要決定如何處理高嚴重度但未確認的項目。
這也影響自動化通知的寫法。若工作流程只顯示「AI檢查失敗」，維護者可能不知道是發現程式錯誤，還是服務根本沒完成審查。因此，狀態、發現與執行證據應一起保留。
當另一位工程師接手時，他可以先讀問題對應的檔案與行數，再看復現輸入是否符合產品條件。這種交接能把討論落在可檢查的假設上，減少對模型語氣強弱的依賴。
如果證據不足，也可以保留為後續人工調查項目，而不急著修改正式程式。這正是區分已復現與未復現的用途：說清楚下一步缺哪種證據，才能安排合適的處理方式。
五個刻意植入的錯誤，透露了哪些模型差異？
這份小型比較最值得讀的，是找出錯誤、執行證明與正確修補之間的落差，並非把幾個數字直接當成模型整體能力排行。
官方建立的範例含資料庫查詢、分頁、字串比較、重試與連線關閉等五個錯誤，而且原有單元測試仍可通過。這顯示測試全綠的意義，仍取決於它實際覆蓋哪些情境。
每個模型各執行三次，找出問題的計數，則合併已完成的審查。若某款只完成兩次，它的分母就不能直接當成另外三款完成三次的分母。
| 模型 | 完成次數 | 找到的植入錯誤 | 補丁修好全部五項 | 平均費用／時間 |
|---|---|---|---|---|
| Claude Haiku 5.5 | 3／3 | 14／15 | 1／3 | 0.0153美元／125秒 |
| Claude Sonnet 5.5 | 3／3 | 15／15 | 3／3 | 0.0447美元／60秒 |
| DeepSeek V4.1 Flash | 2／3 | 10／10 | 2／2 | 0.0307美元／206秒 |
| GPT-6 Luna | 3／3 | 12／15 | 1／3 | 0.0167美元／156秒 |
表格的費用與時間是官方這組範例的平均值，DeepSeek 的已完成結果另有一輪未完成，不能從10／10推成所有審查都會成功。
官方說明其中一輪 DeepSeek 反覆送補丁，直到用完八輪仍未提交最終報告。這次花了0.034美元卻回傳未完成，提醒團隊成本與完成率要一起衡量。
Haiku 的兩次補丁則把資料存取方式改錯，讓原本傳入字典的呼叫端出問題。它已指出可疑程式，仍可能在修補時擴大改動範圍，造成另一個錯誤。
Sonnet 在這份示例的三次補丁都通過官方另做的檢查，但樣本仍小，而且是固定的五個錯誤。選擇模型時，應拿自己的程式型態與可接受的等待時間再比較。
為什麼補丁套得上，還不代表錯誤已修好？
範例先在本機暫存副本套用補丁，確認差異能正確落到檔案。原始沙盒中的程式並沒有同時被修改，所以模型先前的檢查仍針對原碼。
這個差別直接影響驗收。若報告證明原始程式有錯，後續回傳的「套用成功」只證明修補文字符合檔案內容，沒有證明新程式通過測試。
開發者明確指定 --apply，腳本才會把修改後檔案複製回工作樹。工作樹是本機正在編輯的專案內容，因此套用前應閱讀改動，之後再跑受影響的測試。
若補丁修的是共用函式，也要檢查原本合法的呼叫是否仍成立。前述字典存取案例正說明，只用一個局部輸入證明修法，可能漏掉其他使用方式。
官方的工具實作也核對模型提供的檔案路徑，拒絕專案外的位置，並在臨時副本中測試差異。這些保護處理寫入邊界，但不會代替對商業邏輯的判斷。
因此，團隊可以把「問題證據」「補丁可套用」「修補後測試」分開記錄。三者都有結果，才比較容易追蹤修復是否完成，以及失敗發生在哪一步。
模型費用之外，沙盒時間與檔案限制如何影響成本？
有執行證據的審查，會增加容器費用與等待時間，所以應比較完整一次審查的成本，不能只看每單位模型文字的定價。
依官方教學，這組服務的沙盒費率為每秒0.0001美元，從第一個 Shell 指令起算到回應結束，包含模型思考的時間。這個數字應以查詢時的官方價格為準。
在範例中，Haiku 的模型用量較便宜，但因等待較久，每次沙盒費約0.0074至0.0159美元。Sonnet 較快，其沙盒費約0.0047至0.0068美元。
這說明較低的文字單價，不一定對應最低的整體等待或容器費。若團隊把它接進每次推送前的檢查，使用頻率也會放大這種差異。
官方的純差異文字審查範例約0.001美元，沙盒做法約高十至四十倍。但兩種流程提供的證據不同，應先決定哪些修改值得付出執行檢查的成本。
範例每次最多接受二十個檔案識別，其中一個留給差異檔，因此修改檔案與額外上下文合計最多十九個。超過時需要分批，並保留各批之間的必要關係。
沙盒預設沒有對外網路，依賴第三方套件的檢查可能無法直接執行。若要開放套件來源，需要另外安排網路政策，不能把缺少環境造成的失敗讀成程式本身有錯。
放進推送或 CI 流程前，應確認哪些資料與信任邊界？
先確認程式碼可以交給哪些服務，再決定如何讓結果影響合併。這兩項安排分別處理資料流向與流程權限，不能只靠模型提示詞完成。
官方明列，修改檔案、上下文與差異會上傳到 OpenRouter 工作區，模型供應商也會收到內容。因此，禁止外送的程式與真實機密，不能直接交給這個示例執行。
腳本完成時會刪除自己上傳的檔案，但這不等於整個服務的資料處理條款都由這個刪除動作取代。團隊仍需核對供應商安排是否符合專案要求。
報告預設放在 .git 內，是為了減少跟著一般程式提交的機會。因為完整回應也可能含程式片段和執行輸出，分享報告前仍應檢查內容。
CI 是在雲端或伺服器自動跑檢查的流程。官方 GitHub Actions 範例使用基底分支的審查腳本，避免提案者先修改審查器，再用修改後版本審自己的程式。
同時，範例避開沒有安全取得金鑰安排的外部分支提案。這讓審查程式、輸入程式與服務憑證的信任來源保持區分，而不是把外部提交內容當成操作指令。
Files、Shell 與 Apply Patch 目前都屬測試中的伺服器工具，範例使用全球端點。要導入團隊流程，應先在範圍小、可外送的專案驗收，再決定嚴重度門檻與人工覆核方式。
OpenRouter AI 程式碼審查常見問題
回傳0是否代表程式完全沒有錯？
回傳0可能是沒有達到嚴重度門檻的發現，也可能沒有修改需要審查。它不保證所有輸入與環境都正確，更不能取代專案本身的測試。
confirmed 是不是所有修補都已驗證的意思？
它表示模型附上了能展示問題的執行證據。補丁要另外套用與跑測試，因為原始沙盒並沒有自動變成修補後的程式。
換成其他 API 或區域端點就能直接使用嗎？
官方範例建立在 Responses API 與全球端點，Shell 工具也支援 Messages API。不能直接把同一工具設定搬到舊的 Chat Completions 或區域端點，應核對最新工具文件。
只要刪掉上傳檔案，就不算把程式碼交給外部嗎？
這條流程已把內容送到 OpenRouter 與模型供應商。完成後刪除檔案是後續清理，無法改變先前資料曾被傳送的事實。
讓審查證據接到自己的修復驗收
這份教學提供的是可追溯的審查起點：模型指出問題時，要說明如何證明。模型提出補丁後，團隊再確認改動是否符合原本需求。
對準備導入的工程團隊，先用自己的小型變更衡量誤報、漏報、補丁品質與完整費用，較能看出這套流程適合放在哪一關。想持續追蹤 AI 編程工具的實際分工，歡迎免費訂閱 AI 郵報。
延伸閱讀：Claude Code Review 正式開放：Team、Enterprise 的 Quick、Standard、Deep 怎麼選？
延伸閱讀：Greptile 多模型審查案例：Together 稱首字延遲減半，為何不等於每次 PR 都快一倍？
