跳到主要內容
CAMP 04找觀念›對抗式驗收:產生的不檢查,檢查的不產生
第七架構:多個 AI 一起工作,怎麼指揮與驗收|第 7 篇

對抗式驗收:產生的不檢查,檢查的不產生

寫的那一方看自己的東西,怎麼看都覺得對。2026 年的工具把「另一雙眼睛」做成了機制:/goal 用另一個模型當裁判,Claude 的 Code Review 讓一群代理找問題、再用一道驗證步驟濾掉誤報,本機的 /code-review 讓你用信心等級換覆蓋率。同一套結構也能搬到程式以外的任何產出。

2026-09-04 發布 · 2026-09-16 更新 · 作者整理:Lucas

「誰當總指揮」那篇提到,交接單由上一段產生、由下一段的指揮者檢查。這裡把這個分工攤開來講。

道理很舊。人類組織裡,寫的人不驗自己的東西,這是幾百年的常識。寫的人腦子裡還留著來龍去脈,看自己的產出永遠覺得清楚,漏掉的那一格他自己看不見。AI 更嚴重一點,它本來就容易附和自己上一句話。

我們請 AI 幫忙查證過一段引文,它交回一段看起來很像原文的引文,連它自己附的驗證都全部通過,結果那段引文是編的。寫的和驗的是同一個 AI,驗證當然會過。

新的是工具。2026 年有幾個功能直接把「換一個模型來檢查」做進去了,看它們怎麼設計,大概就知道自己的驗收要長什麼樣。

三個現成的例子,各學一件事

/goal 的裁判是另一個模型。你設完成條件,AI 去做,做完了沒,交給一個小而快的模型(預設 Haiku)讀對話之後判定。這個裁判不跑指令、不讀檔案,只看 AI 秀出來的證據。可以學到的是,裁判可以比選手便宜很多,它不用會做,會對照就好。

Claude 的 Code Review 多了一道「驗證」步驟。這是 Team/Enterprise 方案的雲端服務:一群代理平行審 PR,各找一類問題,然後「一個驗證步驟對照實際程式行為,濾掉誤報」,再去重、按嚴重度排序,貼成行內留言。每個發現附一段摺疊說明,講它怎麼驗證的;嚴重度分三級(該修才能合併、小毛病、本來就有的舊 bug),而且永遠不阻擋合併。每次審查平均 15 到 25 美元。找問題和驗證問題拆成兩步,第二步就是拿來防第一步太熱心的。

它還會讀一份 REVIEW.md。你可以寫「Important 在這個 repo 只代表會壞掉、洩資料、擋回滾的事」「一次最多五個小毛病」「行為判斷要附 file:line 出處,不能從命名推論」。這幾條範例都在縮小範圍,把驗收方能報什麼、要附什麼出處限得很死,報告才不會被小毛病淹掉。

本機的 /code-review 讓你拿信心換覆蓋。它在背景的子代理裡跑,不佔你的對話。effort 開 low、medium,只回報最有把握的,誤報少;開到 high、max,覆蓋廣,但可能夾雜不確定的。也就是說,驗收要先決定寧可漏報還是寧可誤報,看出錯的代價來選。

Matt Pocock 的 code-review 是雙軸:一軸看有沒有照專案規範,一軸看有沒有做到規格要求,兩個獨立子代理平行跑,結果並列,不合併。驗收可以分軸,每一軸配自己的清單,交給不同的子代理去看。

搬到程式以外

上面都是給程式用的,但結構搬得動,一份企劃、一封對外信、一張報價表都行。

驗收方要是另一場對話。在同一個視窗說「你檢查一下」沒什麼用。開新對話,貼產出和清單,過程不貼,讓它只憑產出本身判斷。

驗收方拿到的是清單,不是一句「看看有沒有問題」。以 Yes/No 為主,評分表為輔(可驗證目標那篇的做法)。清單裡要寫證據要求,每個「不通過」都要指出在第幾段、哪一句。

先決定寧可漏還是寧可誤。對外發送、牽涉到錢的,寧可誤報,門檻放低;內部草稿,寧可漏報,只報有把握的。

打回單要有格式。「不通過|第幾項|證據|要改成什麼」,產出方拿到就能改,不用再猜。驗收方只寫打回單,不動手改,一動手它就變成產出方了。

有個限制要講清楚:驗收方也是 AI,它也會錯。它的用處在於跟產出方錯在不同的地方。兩個獨立的錯誤剛好疊在一起,機率比一個人自己看兩遍低得多。

動手做

拿你手上任何一份 AI 產出,開一個全新對話,貼這段,再把清單和產出貼進去:

你是驗收員。你沒有參與產出,也不准修改它。規則:
1. 逐項核對下面的清單,每項寫「通過/不通過」。不通過的必須附證據:第幾段、哪一句、違反哪一項。
2. 判斷傾向:(選一個)寧可誤報,可疑就報;或 寧可漏報,只報有把握的。
3. 只輸出打回單,格式:不通過|項目|證據|建議改法。不要改寫產出。
4. 全部通過就只回「放行」,不要補充。
清單:(貼上)
產出:(貼上)

在 Claude Code 裡,寫完程式打 /code-review medium,先看最有把握的發現;要它直接改就打 /code-review --fix。想把驗收規則固定下來,在 repo 根目錄放一份 REVIEW.md(雲端 Code Review 會讀;本機的 /code-review 不讀,本機規則寫進 CLAUDE.md)。

產出和驗收要是兩場對話。清單上每一項,都要寫得出不通過時證據長什麼樣。這次寧可誤報還是寧可漏報,事前要先想過。然後看驗收方到底打回過東西沒有。一個從來沒打回過任何東西的驗收,我會先懷疑它有沒有在看。

引文的驗收,最後一步還是點開原始出處,用搜尋找那段話有沒有真的出現在原文裡。

站內延伸

來源: Claude Code:Code Review(多代理+驗證步驟、嚴重度三級、不阻擋合併、REVIEW.md 可調項目、每次 15–25 美元、本機 /code-review effort 與 --fix);Claude Code:Keep Claude working toward a goal(裁判為獨立小模型、只看對話證據);mattpocock/skills:code-review(雙軸、平行子代理);Anthropic:Building effective agents(evaluator-optimizer)。

第七架構 · 第 7 篇

做完的東西,
要另開一場對話來檢查

什麼時候看這張:你請 AI 寫完一份東西,在同一個視窗叫它檢查,它說都沒問題。

產出方知道來龍去脈覺得自己都對想把事情做完驗收方只看成品和清單逐項核對只寫打回單
  • 寫的一方看自己的產出,怎麼看都覺得清楚
  • 驗收給清單,不通過要指出第幾段、哪一句
  • 對外或牽涉錢的寧可誤報,內部草稿寧可漏報

第一個動作拿一份手上的 AI 產出,開全新對話,只貼成品和檢查清單,請它寫打回單。程式用 /code-review medium;規則寫進 REVIEW.md

2026-09-16 查證稜線 Ridgeline
← 看更多找觀念文章
取得 AI 實戰工具與更新

之後會不定期整理:新方法、指令包(Prompt Pack)、Checklist 與模板。免費、無廣告;送出後會收到一封確認信,點了連結才算訂閱成功,之後每封信都附一鍵退訂。