迴圈什麼時候啟動、什麼算做完

把自己從迴圈換掉那篇把迴圈接起來了。接起來之後第一個會撞到的問題是：它什麼時候該跑？跑到什麼時候算完？

這兩題答不清楚，迴圈有兩種死法。一種是整天空轉，沒事也在跑。另一種是永遠停不下來，因為它不知道「做完」長什麼樣。

所以在讓任何迴圈自動跑之前，先定義兩個東西：什麼事件讓它開始，什麼狀態算做完。

觸發寫清楚，目標寫到能驗證

觸發只有三種。事件驅動：有人提交 PR、有新客訴進來、某個檔案被改動。定時排程：每天清晨、每週一早上。手動：你判斷這件事值得讓它大規模疊代，按一下才跑。三種各有適合的場景，共同的原則是不要讓它沒事也在跑，每一輪都是錢。

目標要寫到「系統可以核對」。「幫我把這篇改得更通順」「把網頁設計得更有科技感」，這種目標迴圈看不懂，它會無效空轉，因為它永遠不知道自己到了沒有。可驗證的寫法是：「TypeScript 編譯零錯誤，測試覆蓋率 90% 以上」「部署到指定網址，Lighthouse 載入時間低於兩秒」「產出的 JSON 通過 schema 驗證」。

判斷一個目標可不可驗證，問一句：如果我不在場，系統能自己判斷它到了沒有嗎？不能，就還不是目標，是願望。

主觀的事怎麼驗：評分表、Yes/No 清單，球員和裁判分開

寫文章、做設計這類沒有絕對對錯的任務，一樣可以驗，只是方法不同。

評分表。對任務的每個面向寫出 1 到 5 分的定義。例如「品牌語氣」：5 分是用詞完全符合品牌手冊、專有名詞零錯誤；3 分是大致符合，偶爾出現公版措辭；1 分是完全機械化的公版腔。迴圈的終點寫成「所有面向 ≥ 4 分」。

Yes/No 清單。把品質拆成一連串機器好判斷的二元問題：「前三句有沒有提到新產品的名字？」「結尾有沒有附客服連結？」「有沒有任何一句超過 40 個字？」實務上 Yes/No 比打分數穩定得多，分數有模糊空間，Yes/No 沒有，AI 自我核對時也比較難鑽空子。我通常兩者並用，能拆成 Yes/No 的盡量拆，拆不了的才用評分表。

球員和裁判分開，這一條最重要。同一個 AI 又產出、又給自己打分，它會傾向給自己過。不是故意作弊，是它天生傾向認同自己上一句話。Anthropic 的做法叫 evaluator-optimizer：一個負責產出，另一個拿著評分表獨立評估、給回饋，來回直到過關。實作上就是兩個獨立的對話，Runner 做工，Checker 拿清單在終點線把關，Checker 點頭迴圈才放行。

Anthropic 那篇文章對這個模式的適用條件講得很清楚：當你有可衡量的評估標準、而且反覆修改確實會讓結果變好的時候，才用它。兩個判斷指標：人給回饋時 AI 的回應會變好；AI 自己也能給出類似的回饋。

動手做

有一個目標、不確定能不能驗證的，讓 AI 幫你把願望改寫成目標：

下面是我對一件事的期望。請把它改寫成「不在場也能被系統判斷到了沒有」的可驗證目標：
1. 能寫成機器檢查的，寫成具體的數值或指令（例：測試全過、字數 ≤ 800、JSON 通過 schema）。
2. 不能機器檢查的，拆成 Yes/No 問題清單（每題只能答是或否）。
3. 還是拆不了的，寫成 1–5 分的評分表，每個分數給具體定義。
4. 最後告訴我：哪些原本的期望其實無法驗證，應該拿掉或改寫。
我的期望：（貼上，例：改得更通順、更有科技感）

主觀任務想建裁判，開兩個全新對話。第一個（Runner）給任務和目標，叫它產出。第二個（Checker）貼這段：

你是驗收員。你沒有參與產出，也不要修改它。拿著下面的 Yes/No 清單和評分表逐項核對，每項寫「Yes/No」或分數＋一句理由。任何一項 No 或低於 4 分，列出具體要改的地方，回傳給產出方。全部通過才寫「放行」。
清單與評分表：（貼上）
待驗收的產出：（貼上）

把 Checker 的回覆貼回 Runner，改完再送 Checker。手動做兩三輪，你就會知道這個迴圈值不值得自動化。迴圈已經在跑但停不下來的，先讀迴圈的停損。

做對了的樣子：每個迴圈你都答得出「什麼事件讓它開始、什麼狀態讓它停」；目標裡沒有「更好」「更通順」這類詞，只有數值、Yes/No、或分數定義；產出的和打分的是兩個獨立對話；Checker 曾經打回過 Runner——從沒打回過的裁判，多半不是在驗收。

拿你最近交給 AI 的一個目標，問「我不在場，系統判斷得出它到了沒有嗎？」答不出來的，用上面第一段改寫。

迴圈要先定義兩件事：什麼讓它開始，什麼讓它停。目標的判準只有一句——我不在場，系統判斷得出它到了沒有嗎？主觀的事用 Yes/No 清單和評分表。產出的和打分的不能是同一個；從沒打回過的裁判，不是裁判。

站內延伸

• 什麼時候必須強制停下來 → 迴圈的停損
• 為什麼寫的人不能驗自己的東西 → 什麼時候該分身
• 驗收清單的完整寫法 → 找方法AI Agent 測試

來源： Anthropic：Building effective agents（evaluator-optimizer 的定義與適用條件）。觸發三型、評分表與 Yes/No 的寫法是我自己的整理。