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

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

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

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

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

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

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

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

Cloudflare 如何保存未解問題

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

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

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

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

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

機器檢查能證明到哪裡

Cloudflare 的驗證規則明確限定：驗證器成功，證明的是格式與帳本一致性。它無法代替對漏洞事實的判斷。

換一個新的代理複核，可以降低沿著原作者思路走的偏誤，但不同代理仍可能共有盲點。多跑幾輪，也不能直接換算成「找到了全部漏洞的多少比例」。Cloudflare 在介紹其 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 或帳單。來源閱讀與後續本機執行各自記錄範圍，才能回頭判斷增加一個代理解決了什麼問題。

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

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

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

原始來源

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