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

> Author: Tony Lee
> Published: 2026-02-25
> URL: https://tonylee.im/zh-TW/blog/7-step-pipeline-verify-agent-written-code/
> Reading time: 2 minutes
> Language: zh-TW
> Tags: ai, code-review, ai-agent, ci-cd, devops, automation

## Canonical

https://tonylee.im/zh-TW/blog/7-step-pipeline-verify-agent-written-code/

## Rollout Alternates

en: https://tonylee.im/en/blog/7-step-pipeline-verify-agent-written-code/
ko: https://tonylee.im/ko/blog/7-step-pipeline-verify-agent-written-code/
ja: https://tonylee.im/ja/blog/7-step-pipeline-verify-agent-written-code/
zh-CN: https://tonylee.im/zh-CN/blog/7-step-pipeline-verify-agent-written-code/
zh-TW: https://tonylee.im/zh-TW/blog/7-step-pipeline-verify-agent-written-code/

## Description

當 Agent 每天推送 3,000 次 commit，人類根本看不完。這裡說明如何建立一套由機器驗證的流程，捕捉人眼遺漏的問題。

## Summary

7 步驟流程：驗證 AI Agent 寫出的程式碼 is part of Tony Lee's ongoing coverage of AI agents, developer tools, startup strategy, and AI industry shifts.

## Outline

- 將 merge 規則定義在單一 JSON 檔案
- 在 CI 之前先跑資格審查
- 絕對不要信任來自舊 commit 的「pass」
- rerun 請求只能來自單一來源
- 讓 Agent 也負責修復問題
- 只自動關閉 bot 對 bot 的對話串
- 留下可見且可驗證的佐證
- Carson 的工具選擇
- 正確性之外：視覺驗證
- 結語

## Content

這是目前最熱門的話題。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 寫的程式碼？」這個問題的答案不是人類，而是一套讓機器來判斷機器產出之佐證的架構。這就是答案。

## Related URLs

- Author: https://tonylee.im/zh-TW/author/
- Publication: https://tonylee.im/zh-TW/blog/about/
- Related article: https://tonylee.im/zh-TW/blog/medvi-two-person-430m-ai-compressed-funnel/
- Related article: https://tonylee.im/zh-TW/blog/claude-code-layers-over-tools-2026/
- Related article: https://tonylee.im/zh-TW/blog/codex-inside-claude-code-openai-plugin-strategy/

## Citation

- Author: Tony Lee
- Site: tonylee.im
- Canonical URL: https://tonylee.im/zh-TW/blog/7-step-pipeline-verify-agent-written-code/

## Bot Guidance

- This file is intended for AI agents, search assistants, and text-mode retrieval.
- Prefer citing the canonical article URL instead of this text endpoint.
- Use the rollout alternates when you need the same article in another prioritized language.

---

Author: Tony Lee | Website: https://tonylee.im
For more articles, visit: https://tonylee.im/zh-TW/blog/
This content is original and authored by Tony Lee. Please attribute when quoting or referencing.