7 步驟流程：驗證 AI Agent 寫出的程式碼

這是目前最熱門的話題。Agent 每天產出數百個 commit，沒有人能全部 review 完。

OpenClaw 的開發者 Peter，有時一天會推送超過 3,000 個 commit。這已遠遠超出任何人能處理的範圍，成了一項人類光靠自己根本無法應對的任務。

一開始我以為這沒有解法。直到讀了 Ryan Carson 的「Code Factory」，整個思路才豁然開朗。與其試圖把所有東西都看完，不如建立一套讓機器來驗證程式碼的架構。

將 merge 規則定義在單一 JSON 檔案

把哪些路徑屬於高風險、哪些檢查必須通過，全部寫進同一個檔案。這樣做的核心洞察是：可以防止文件與腳本之間出現落差。

• 高風險路徑需要 Review Agent 加上瀏覽器截圖作為佐證
• 低風險路徑通過 policy gate 與 CI 即可 merge

在 CI 之前先跑資格審查

對連 review 都還沒通過的 PR 跑 build，根本是在燒錢。在 CI fanout 前面放一個 risk-policy-gate。光是這一步，就能大幅削減不必要的 CI 費用。

• 固定順序：policy gate → Review Agent 確認 → CI fanout
• 不合格的 PR 根本進不到測試與 build 階段

絕對不要信任來自舊 commit 的「pass」

這是 Carson 強調最多的一點。如果某個舊 commit 的「pass」還留著，最新的程式碼就會在未經驗證的情況下被 merge。每次 push 都要重新跑 review，若不相符就擋住 gate。

• Review Check Run 只有在與 headSha 對應時才視為有效
• 每個 synchronize 事件都強制重新執行

rerun 請求只能來自單一來源

當多個 workflow 都在請求 rerun，就會出現重複留言與 race condition。看似小事，但不處理的話整條流程都會震盪。

• 用 Marker + sha:headSha 的模式防止重複
• 若該 SHA 已提交過，則略過請求

讓 Agent 也負責修復問題

當 Review Agent 發現問題，Coding Agent 就修補後推送到同一個 branch。Carson 文章中最犀利的洞察：鎖定 model 版本。否則每次結果都不一樣，可重現性就蕩然無存。

• Codex Action 修復 → push → 觸發重新執行
• 鎖定 model 版本以確保可重現性

只自動關閉 bot 對 bot 的對話串

有人類參與的對話串絕對不要動。沒有這個區分，reviewer 的留言就會被淹沒。

• 只有當前最新 head 重新執行後通過，才自動 resolve
• 有人類留言的對話串永遠保持開啟

留下可見且可驗證的佐證

如果 UI 有變動，不能只是截個圖了事。要求 CI 可驗證的佐證。把線上事故轉換成測試案例，讓同樣的失敗不再重演。

• Regression → harness 缺口 issue → 新增測試案例 → SLA 追蹤

Carson 的工具選擇

以下是 Carson 選用的工具，供參考：code review agent 選用 Greptile，remediation agent 選用 Codex Action，三個 workflow 檔案分工負責 greptile-rerun.yml 處理標準 rerun，greptile-auto-resolve-threads.yml 清理舊對話串，risk-policy-gate.yml 把關前置 policy。

正確性之外：視覺驗證

以上步驟都是在檢查程式碼對不對。但實務上，你還需要驗證輸出的畫面長什麼樣。

有兩種做法值得關注。

Nico Bailon 的 visual-explainer 將終端機的 diff 渲染成 HTML 頁面，而非 ASCII，讓變更集一眼就能閱讀。

Chris Tate 的 agent-browser 走的是另一條路。它逐像素比較實際瀏覽器畫面，捕捉 CSS 與版面破損。搭配 bisect，可以精準定位到底是哪個 commit 造成了 regression。

我在建構 codexBridge 的過程中一直在思考這個問題。光靠 session log 無法追蹤哪個 Agent 寫了哪段程式碼，還需要一套便於檢索的搜尋架構。

結語

「誰來驗證 Agent 寫的程式碼？」這個問題的答案不是人類，而是一套讓機器來判斷機器產出之佐證的架構。這就是答案。