先把問題定義對：這不是模型戰，而是流程設計題
很多人看到 AI 產生 錯誤，第一反應是換更強的模型。但如果流程仍然是「同一個模型自己寫、自己說完成、自己收工」，那麼同一批盲點仍然可能原封不動通過。真正穩定的做法，是把實作者與審核者拆開，再加上一層不容跳過的 關卡。
比起期待模型零失誤，更務實的是建立一條「就算出錯，也比較難直接過關」的工作流。
這套做法在解決什麼痛點
自寫自查容易漏
同一個模型寫完再自己檢查，常會連同相同假設一起帶進結果，尤其在邊界條件與錯誤處理上最明顯。
審核靠人記得做
如果 審核 只是建議步驟，忙的時候就會被跳過，最後又回到人工補救。
把 審核 系統化
讓 Claude 負責交付、Codex 負責挑錯，並用 掛鉤 攔住未完成審核的結果。
讓流程比紀律可靠
不是靠每次都提醒自己，而是靠系統讓關鍵步驟自動發生。
四個角色拆開後，整件事就清楚了
主力負責產出與修正。它不是不能 審核，而是這條流程刻意讓它不要獨自決定自己是否過關。
用第二視角看 正確性、風險、遺漏測試與邊界條件，讓錯誤不要只靠作者自己想起來。
標準工作流程：不是寫完就算完成
- Claude 先寫計畫與實作。 它可以先修改檔案、補測試、整理方案，但這還不代表可以直接結束。
- 嘗試收工時，由 Stop 掛鉤 攔截。 只要檢查條件不滿足，就不允許直接通過。
- 觸發 審核者 流程。 Claude 依既定 技能 或 審核 指令，把變更交給 Codex 看。
- 雙方反覆修正直到收斂。 Reviewer 提問題，Claude 修，接著再 審核，不是一輪定生死。
- 確認 審核者 同意後，才寫入 標記 放行。 標記 只是信號，不是目的；真正代表的是「審核完成且已收斂」。
很多人會把 標記 當成一個可手動補上的字串。這樣流程就破功了。正確做法是 標記 只能出現在 審核者 真正通過之後。
收斂關鍵：同一個 審核者 工作階段 要持續沿用
固定同一條 審核者 對話
這樣 審核者 會記得前面已經討論過什麼、哪些問題已經修過，整體比較容易走向共識。
每一輪都重開新 審核者
每次都像冷啟動，容易一直冒出新的小挑剔，流程會越審越散，卻不一定更安全。
| 做法 | 優點 | 風險 |
|---|---|---|
| 同一 審核者 工作階段 持續沿用 | 保留上下文、收斂快、重複問題少 | 需要有清楚的 審核 scope，避免 工作階段 漫無邊際擴張 |
| 每輪開新 審核者 | 表面上像是重新獨立檢查 | 容易一直發現不同角度的小問題，難以形成「已足夠通過」的共識 |
Harness 的真正意思：替 AI 準備一個不會漏步驟的辦公室
這裡最值得帶回 Hermes 的觀念，是把問題回推到系統層。當你發現 代理 常常漏做同一件事，重點不該只是再提醒一次，而是問：「為什麼這種結果還能直接過關？」一旦找到那個流程漏洞，就用 掛鉤、技能、檢查條件、狀態標記把它封起來。
強制約束
確保關鍵步驟一定被執行，而不是寄望模型自己記得。
工作方法
規定 審核者 要怎麼檢查，包含正確性、風險、缺失、測試與例外情況。
狀態握手
讓流程知道「這一步真的做完了」，而不是只靠一段自然語言承諾。
沒有同事幫你把關時，這種 harness 就是在替你補上一個不會累、也不會嫌麻煩的第二道審核。
放進 AI 代理 工作流後，最值得先試的四種場景
高風險腳本與自動修改
像本機批次腳本、報表轉檔、知識庫同步、檔案搬移這些動到真實資料的流程，最適合加 審核者 關卡。
- 先讓作者模型修改
- 再讓 審核者 模型專看邊界條件與副作用
- 沒通過就不能直接結束任務
正式輸出前的事實檢查
例如台股報告、教學筆記、客戶說明文件，作者模型先整理，審核者 模型再檢查證據是否不足、推論是否過頭。
教學 HTML 發送前自動複核
在寄信或通知發送前，先做一輪 版面 / 措辭 / 來源風險 審核，避免錯檔或不該公開的內容外流。
例行流程不漏步
像 critical issue、每日維護摘要、異常整理，可把「是否補齊 負責人 / 期限 / 風險」做成 關卡，而不是靠最後人工檢查。
常見誤區：看起來像做了 審核，實際上沒有真正變安全
| 誤區 | 為什麼不夠 | 比較好的替代做法 |
|---|---|---|
| 只在 提示詞 裡說「請自我檢查」 | 是否檢查仍由同一模型自行決定，容易略過 | 加 掛鉤 或固定 審核 step，讓流程必定執行 |
| 審核者 只是過場看一下 | 沒有通關影響力，問題被指出也可能沒修就結束 | 把 審核者 結果接回放行條件 |
| 每次都重開 審核者 工作階段 | 審核脈絡斷裂，容易越審越散 | 同一條 審核者 工作階段 持續沿用到收斂 |
| 固定兩輪就算過 | 流程完成不代表問題已真正解決 | 以 共識 作為結束條件 |
| 讓 標記 可手動補上 | 任何人都能繞過 關卡，整個保護層失效 | 限定 標記 只能在審核通過後自動寫入 |
一頁檢查清單：要把這套搬進自己的 代理，至少先做到這些
- 先定義作者模型與 審核者 模型的分工，避免兩邊都做一樣的事。
- 決定 掛鉤 要攔截哪個時機，通常是在任務準備結束前最有價值。
- 把 審核者 規則寫成 技能 或固定工作方法，不要每次臨時講。
- 設定清楚的通關訊號，例如 標記、結構化輸出 或 狀態旗標。
- 不要用固定輪數作為成功標準，改用 審核者 與作者是否已達成共識。
- 同一個 審核者 工作階段 盡量持續沿用，直到整件事真正收斂。
- 只在高風險或高成本輸出上先試行，觀察是否真的降低返工與漏錯。
參考資料
這份教學頁的可公開依據以官方文件為主，實務案例則用來幫助拆解 工作流程 思路。