當你開始嘗試建置自動化的 Loop（循環）時，很快就會遇到一個極為致命的技術難關：如果沒有設定好邊界，這個 Loop 會像一輛煞車失靈的火車，在背景瘋狂運轉、不斷燃燒你的 API Token，最後在月底送給你一張「極具教育意義」的破萬美元驚悚帳單。
要讓 AI 自我修正的迴圈既高效又安全，你必須像個嚴格的系統架構師一樣，精準定義兩大核心要素：Trigger（觸發機制） 與 Verifiable Goal（可驗證目標）。
Trigger 與 Verifiable Goal
定義什麼情況啟動循環。
把目標寫成可驗證條件。
用 Rubric 或 Yes/No 清單判斷。
通過、修正，或交回人類。
實戰步驟一：設定精準的觸發條件 (Trigger) 與兩種可驗證目標
你必須像拉起一條物理警戒線一樣，精準控制 Loop 的「生」與「死」：
精細化配置觸發條件 (Trigger)：決定 Loop 什麼時候該跑，不能讓它整天無意義地空轉。在 Harness 中，你可以將 Trigger 設定為以下三種模式之一：
事件驅動 (Event-driven)：例如「當有人在 GitHub 上提交了新的 Pull Request（PR）時，自動觸發 Loop 進行代碼安全性審查」。
定時排程 (Scheduled)：例如「每天清晨 4:00 自動啟動 Loop，清理資料庫中的冗餘資料、重構代碼並更新對應文檔」。
手動按鈕 (Manual)：只有在你覺得這項複雜任務需要 AI 大規模疊代時，才手動點擊執行。
將抽象意圖轉化為「可驗證目標 (Verifiable Goal)」：AI 絕對看不懂「幫我把這篇文章改得更通順、更大氣」或「幫我把網頁設計得更有科技感」這種極度主觀、抽象的廢話，這會導致 AI 在 Loop 裡無效空轉。你必須把大腦的模糊意圖，轉譯成系統可以客觀核對的 verifiable goal：例如「網站必須成功部署到指定網網域，且在 Chrome Lighthouse 測速中載入時間低於兩秒」、「TypeScript 編譯器零錯誤，且測試覆蓋率達到 90% 以上」。
實戰步驟二：實作 Rubric 評分表與 Yes/No 檢查清單，並導入「球員與裁判分離」架構
對於寫文章、設計畫面這類「沒有絕對對錯、非二元」的主觀任務，你必須導入以下兩種高階評估技術：
實作 Rubric（量化評分表）：針對任務的不同面相（如：品牌人設語氣、內容豐富度、排版格式），寫出極為清晰的 1 到 5 分級別定義。例如「5 分代表：內容完全符合個人人設、專有名詞無一出錯；3 分代表：大體符合人設，但偶爾出現與人設不符的公版措辭；1 分代表：完全是 AI 的機械化公版腔調」。在 Loop 終點規定：必須所有面相的評分均達到 4 分以上，Loop 才能圓滿停止。
實作二元檢查清單（Yes/No Checklist）：將品質拆解成一連串非常死板、機器極易判斷的 Yes 或 No 問題。例如：「開頭前三句有沒有包含我們新產品的關鍵字？（Yes/No）」、「結尾有沒有附上客服聯繫連結？（Yes/No）」。這種 Yes/No 檢查清單在實務上比打分數更加穩定，AI 在自我核對時也極不易鑽空子偷懶。
防作弊大招：「球員與裁判分離（Separation of Concerns）」：如果同一個 AI 負責產出，又同時負責給自己打分，它一定會為了快速交差而無情作弊（自己給自己打滿分）。在 Loop 工程設計中，你必須安排兩個獨立的 Agent：Agent A 專職做工（Runner），Agent B 拿著 Rubric 與 Yes/No 清單在終點線後冷酷地把關（Checker）。只有當 Checker 滿意點頭時，Runner 的 Loop 才能放行，這才是生產級系統最安全的防翻車保證！