# AI 互相查錯之後：如何把第二意見變成可追溯的工作制度

> 從 Cloudflare security-audit skill 與一次網站部署流程的來源查核，討論如何保存證據、分離查核與授權，並讓下一位協作者接得上工作。獨立複核與格式驗證各有邊界，未解問題需要被明確留下。

- Author: Paul Kuo（郭曜郎）
- Date: 2026-10-03
- Pillar: 智能與秩序 / Intelligence & Order
- Tags: AI 治理, 第二意見, 可追溯性, 人機協作, Cloudflare, 資安查核
- Canonical: https://paulkuo.tw/articles/ai-evidence-review-workflow/
- Site index for LLMs: https://paulkuo.tw/llms.txt

---

檢查網站部署流程時，一段共用工具讓人懷疑：資料缺失，防護就會略過。往上追到正式入口，才看到呼叫端早已擋下這種情況。這個候選因此被推翻。

這次我請 Codex 先固定同一個程式版本，只讀來源。若只留下最後的摘要，把反證省略，下一次審查就可能再追一次同一條線。

> 查核要留下結論的根據，也要留下推翻它的理由。尚未回答的問題，則需要有名字、來源與下一步。

## 第二意見之後，還有一段工作

我在[〈我讓 codex 挑 Claude 的錯，但不照它說了算〉](https://paulkuo.tw/articles/ai-second-opinion-independence/)寫過如何保護第二意見的獨立性：提問保持中性，原始回報留下來，審查者只指出問題，由握有完整脈絡的人決定是否採用。

那次經驗也有一個限制。機器可以擋住完全空白的審查輸出，但一段有字的回報，是否真的完成了實質審查，仍需要人判斷。

工作一多，這個問題會延伸到交接。幾天後換一個視窗，接手的人知道哪個結論已經核對過嗎？程式改版之後，舊證據還適用嗎？一條被推翻的意見，有沒有留下理由，還是只從最後摘要消失了？

我希望第二意見能被下一次工作接續使用。這需要比聊天摘要更明確的紀錄。

## Cloudflare 如何保存未解問題

Cloudflare 公開的 [security-audit skill](https://github.com/cloudflare/security-audit-skill)提供了一個參照。它安排不同代理發現與複核候選，要求驗證者尋找反證，並把結果分成已確認、需要驗證與已推翻。查核範圍另有帳本，不讓一份結果報告代替整體覆蓋情況。

本文參照 Cloudflare 官方文章 [Build your own vulnerability harness](https://blog.cloudflare.com/build-your-own-vulnerability-harness/)、公開的 security-audit skill 及其驗證規則，把證據、反證與待查事實的分法，用在作者自己的工作紀錄上。

我想借用的是它對「需要驗證」的處理。這個狀態要指出尚未解決的確切事實，不給漏洞嚴重度，也不能因為線索看起來有說服力，就被寫成已確認。

例如，有些判斷需要知道實際部署設定，有些需要在受限環境中執行最小測試。只讀程式碼時看不到的事實，應該在紀錄裡保持可見。

同一套分法也能用在我的日常工作：線索、待查事實與已被推翻的判斷，分開記錄。會議中提過合作方向，仍要回到原始訊息，確認誰有權承諾；文件中有一個數字，仍要核對版本與適用日期。AI 可以先整理線索，再把需要人的地方寫清楚。

## 機器檢查能證明到哪裡

Cloudflare 的[驗證規則](https://github.com/cloudflare/security-audit-skill/blob/main/skills/security-audit/VALIDATION-AND-REPORTING.md)明確限定：驗證器成功，證明的是格式與帳本一致性。它無法代替對漏洞事實的判斷。

換一個新的代理複核，可以降低沿著原作者思路走的偏誤，但不同代理仍可能共有盲點。多跑幾輪，也不能直接換算成「找到了全部漏洞的多少比例」。Cloudflare 在[介紹其 harness 做法的文章](https://blog.cloudflare.com/build-your-own-vulnerability-harness/)裡指出，沒有涵蓋所有真實漏洞的完整標註集，不能據此宣稱召回率。

第一輪先保存固定版本與來源指紋，另一個代理回到同一份來源找反證。自製檢查器核對紀錄間的關聯、行號範圍與來源身分；這一輪沒有執行目標程式。

能重查一份來源，與已經觀察到程式行為，是不同層次的證據。報告必須讓讀者分得出來。

## 一條部署線索，如何走到修補驗證

第二輪才進入受控本機重現。我們保留實際的部署入口、防護與基本功能檢查（smoke）腳本，讓 Git 使用真實的版本關係，將服務、網頁回應與建置換成離線替身。由作業系統強制限制的沙箱，先通過拒絕網路與越界寫入的測試，再執行案例。

這個部署流程一次更新兩個部分：網站頁面（Pages）與後端服務（Worker）。舊的聯合部署入口，只從混合帳本取最後一筆成功來源。若帳本後面是 Pages 的舊來源紀錄，它就可能忽略 Worker 已使用的較新來源。

在隔離的離線環境裡，我們讓服務與建置都使用替身，重現了聯合部署將模擬 Worker 換回舊來源，整個入口卻仍記成功的情況。同一個舊來源單獨部署 Worker，則被擋下。查核期間程式已有更新；固定更新後的來源重跑，仍得到同樣結果。

這裡的「帳本後面」指檔案中的排列位置，不能拿來代替真實部署的時間順序。

這個結果支持修正版本比對邏輯，還不能支持「正式環境已出過事故」。本次只驗證這條版本回退路徑，沒有完成資安漏洞判定，也未評定嚴重度。假服務沒有執行真正的 Worker，實際功能有沒有受影響、過去帳本是否真的出現這種排列，仍是另外兩個問題。

第三輪由我同意後，Codex 才在隔離副本修補部署入口。聯合部署改為分別查核 Pages 與 Worker 的上次成功來源，共用防護檢查保持原樣。新增的測試先在舊碼上抓到問題，再確認修補後會擋下；六個完整入口案例中，四個回退情境都在任何服務部署呼叫前被攔下，兩個正常更新則完成檢查與成功記帳。

獨立複核代理接受這個限定範圍的修補，也指出錯誤訊息沒有隨部署目標切換，我們補上修正與對照測試。這次交付到可審查的補丁和本機驗證。在 2026-10-03 這次隔離驗證結束時，補丁留在隔離副本，尚未合併與正式部署；本文保留當時的驗證邊界，不追蹤後續部署狀態。「查核通過」「修補驗證通過」與「正式環境已更新」，需要分開記錄。

## 把證據與行動授權分開

對我這種跨專案使用 AI 的工作方式，我把下一次交接希望能查回的內容，整理成六欄：

| 欄位 | 要回答的問題 |
|---|---|
| 主張 | 這次究竟在判斷什麼？ |
| 來源與版本 | 根據哪份程式、文件或原始訊息？ |
| 證據狀態與理由 | 已核對、待查，還是被推翻？依據或反證是什麼？ |
| 未解事實 | 現在還缺哪個具體答案？ |
| 責任人與下一步 | 誰能補上證據，怎麼補？ |
| 行動授權 | 誰同意哪些操作？授權的原始紀錄在哪裡？ |

用這次的部署線索填進去，大致會是這樣。這是 2026-10-03 隔離驗證結束時的紀錄，不代表現在的進度：

| 欄位 | 本次部署案例（2026-10-03 當時紀錄） |
|---|---|
| 主張 | 聯合部署可能漏掉 Worker 已使用的較新來源，讓後端回到舊版本。 |
| 來源與版本 | 固定版本的部署入口、對應的離線測試紀錄，以及另外保存的隔離補丁。 |
| 證據狀態與理由 | 離線路徑已重現。聯合部署回退且記成功，同條件單獨部署被擋；修補後六個入口案例得到預期結果。 |
| 未解事實 | 正式環境是否曾出現相同帳本排列與來源條件，真實 Worker 功能是否受影響，均未驗證。 |
| 責任人與下一步 | 當時的下一步：我決定後續範圍與承辦者，再核對主分支版本，評估補丁是否合併及正式部署。 |
| 行動授權 | 當時已同意隔離修補與本機驗證，授權回查原始對話；補丁的合併及正式部署當時另行決定。 |

最後一欄尤其需要獨立。查證一項事實，並不會同時取得修改、寄送或發布的權限。幾個模型一致，也不會替合作對象做出承諾。

部署查核同樣如此。發現一個問題後，修補方案、程式變更與正式部署，各有不同的驗收與責任。把它們全部包進「已完成」，下一位接手的人就得重新猜一次。

這份紀錄也適合接到會議與信件整理。重要期限附上原始訊息，合作承諾留下確認者，部分讀取失敗則照實標記。資料擷取失敗與沒有符合條件的訊息，不能共用同一句「沒有事項」。

## 從能維護的範圍開始

我先選網站部署流程做試行，沒有把每份日常摘要都送進多輪審查。第一輪先把本機子代理呼叫的規劃上限定為三次；這限制的是呼叫次數，並非 token 或帳單。來源閱讀與後續本機執行各自記錄範圍，才能回頭判斷增加一個代理解決了什麼問題。

被推翻的候選需要留存，讓下一次查核能先讀過反證，再判斷是否值得重查。尚未驗證的線索也要留下，指出工作還欠哪一步。這些紀錄提供安排測試的依據；是否讓人更省時，仍需要後續比較。

下一輪，我會看這套紀錄是否讓複核更省時、交接是否少了重複查找。第一次試行還沒有可比基線，不能先寫下節省比例。

我想保留下來的判斷位置，很具體：下一次看到「已完成」，能沿著證據查回去，也知道還有哪一步沒有完成。

## 原始來源

- [Build your own vulnerability harness](https://blog.cloudflare.com/build-your-own-vulnerability-harness/)，Dan Jones、Alexandra Godoi、Grant Bourzikas，2026-06-18：說明從 skill 發展到跨 repo 內部 harness 的設計與侷限。
- [cloudflare/security-audit-skill](https://github.com/cloudflare/security-audit-skill)：支持六階段單 repo 起點、獨立證偽、confirmed／needs_validation／rejected 三種狀態與 coverage ledger。
- [VALIDATION-AND-REPORTING.md](https://github.com/cloudflare/security-audit-skill/blob/main/skills/security-audit/VALIDATION-AND-REPORTING.md)：支持格式與紀錄一致，不等於漏洞事實成立。

本文的部署案例來自作者 2026-10-03 的固定來源查核、離線重現與隔離修補紀錄，只支持文中限定的本機結果。