比你想的更簡單！Claude Code 官方的Loop循環設計指導
整理版優先睇
Claude Code 循環設計其實好簡單，四種套路搞掂，唔好俾啲黑話嚇親
呢篇文章係作者針對 AI 圈成日造詞嘅風氣，對 Claude Code 官方嘅循環設計指南（Getting started with loops）進行嘅整理同拆解。作者本身好反感啲人用「Loop Engine」呢類生僻詞彙嚟故弄玄虛，佢話明「Loop 就係讓 Agent 按規律重複幹活」，冇咩花臣。官方定義係：Agent 不斷重複執行工作週期，直到滿足預設嘅停止條件。整體結論係，搞清四種循環套路，配合自己嘅任務性質去揀，就唔會俾人哋嘅複雜術語帶偏。
首先，回合制循環靠你手動觸發，Claude 自己判斷做完未，適合臨時性、短嘅任務，關鍵係將驗收標準寫入 SKILL.md，越量化佢越準。其次，目標導向循環用 /goal 觸發，畀個具體目標同次數上限，Agent 會自動迭代到達標或撞上限，適合有客觀數據判斷嘅嘢，例如「Lighthouse 跑分要上 90」。
第三，基於時間嘅循環用 /loop 同 /schedule，適合週期性任務（例如每日彙總 Slack）或要監察外部變化嘅任務（例如睇住 PR 有冇新 comment）。最後，主動式循環係以上三種加動態工作流同自動模式嘅結合，適合長期跑嘅複雜工作流，例如漏洞分診、依賴升級。官方重提醒，代碼庫乾淨同用全新 Agent 做 Code Review 效果好啲，循環唔係萬能，token 消耗大，小任務唔好亂用複雜循環，先從簡單回合制開始，問自己三個問題：可否寫出自動驗證檢查項？…
- 循環本質係 Agent 重複工作週期直到滿足停止條件，唔好畀「Loop Engine」呢類黑話混淆
- 四種循環模式：回合制（手動觸發+自我判斷）、目標導向（/goal）、時間循環（/loop、/schedule）、主動式（組合+動態工作流+自動模式）
- 回合制適合短任務，目標導向適合有客觀標準嘅任務，時間循環適合週期性任務，主動式適合長期複雜工作流
- 代碼庫要乾淨，用全新 Agent 做 Code Review 可減少偏見；循環唔係萬能，token 消耗大，小任務唔好亂用多Agent
- 從最簡單嘅回合制開始，問自己三個問題：可否寫自動驗證檢查項？目標夠清晰？任務是否週期發生？
揭穿 Loop 黑話：根本冇咁複雜
AI 圈最中意造詞，搞到啲人覺得唔識幾個生僻詞就 out 曬。作者話佢好憎呢種風氣，尤其係啲人講「Loop Engine」講到天花亂墜，聽完得一頭霧水。其實 Loop 就係讓 Agent 按某種規律重複幹活，就咁簡單。
所謂 Loop，翻譯過來就係讓 Agent 按某種規律重複幹活而已
四種循環套路，全部有實例
- 1 【回合制循環】靠你手動觸發，Claude 自己判斷做完未。適合臨時性、唔入常規流程嘅短任務。做法係將驗收標準寫入 SKILL.md，例如「UI 改完要起開發 Server、真實撳掣、截圖對比、Check Console 錯誤」。驗證越量化，佢自我判斷越準。
- 2 【目標導向循環】用 /goal 觸發，畀目標同標準。例如：「Lighthouse 跑分提到 90 以上，嘗試 5 次為止」。佢會不斷迭代直到達標或撞次數上限，適合有客觀數據判斷嘅活。
- 3 【基於時間循環】用 /loop 或 /schedule。/loop 喺本地行，關機就停；/schedule 可搬上雲 7x24 值班。適合週期性任務（例如每日彙總 Slack）或要監察外部變化（例如睇住 PR 有冇新 comment / CI 跑掛）。
- 4 【主動式循環】將上面三種加動態工作流、自動模式拼埋一齊。用 /schedule 定時檢查有冇新嘢，用 /goal 定義「本輪所有報告處理完先叫完」，用動態工作流讓幾個 Agent 分頭分類、修復、審查，最後開自動模式唔使逐下 Confirm。
/goal 畀目標同標準，Agent 會自動迭代直到達標或撞次數上限
/loop 喺本地行，/schedule 可搬上雲 7x24 值班
呢四種循環可以按任務性質揀，唔好一開始就諗住用最複雜嗰種。
代碼質量同使用貼士
官方建議，代碼庫本身要乾淨，Claude 寫出嚟嘅嘢先會跟住乾淨。用一個全新 Agent（冇俾歷史對話帶偏）做 Code Review，偏見會少好多。作者親身體會，同一條 Context 行到尾嘅 Agent 好易陷入自欺欺人嘅循環，揾個乾淨上下文的裁判角色，效果立竿見影。
用全新 Agent 做 Code Review，偏見更少
不過 Loop 唔係萬能藥，token 消耗極大，小任務唔好亂用多 Agent 複雜循環。大規模跑動態工作流之前記住切細試跑，確定性嘅工作直接上 Script，唔好靠大模型每次現場推理。以目前模型能力，長時間行 Loop 好易走偏。
token 消耗極大，小任務唔好亂用多 Agent 複雜循環
確定性嘅工作直接上 Script，唔好靠大模型每次現場推理
總結：搞清套路，用對方法
成篇文章嘅精髓就係，唔好俾 AI 圈嘅黑話嚇親。Loop 就係讓 Agent 按規律重複幹活，四種循環各有用途。由最簡單嘅回合制開始，逐步升級，先從手頭最卡嘅任務入手，諗清楚驗證、目標、週期三件事，自然揾到適合嘅循環模式。
由最簡單嘅回合制開始
- 迴圈選擇三問：有冇自動驗證檢查項？目標夠清晰？任務係週期性？
- 大任務先考慮主動式循環，否則用回合制或目標導向就夠
今日 Claude 官方出咗份關於設計循環 Loop 嘅指南 Getting started with loops，睇完你會發現，呢個概念其實係舊酒新瓶。
咁循環究竟係咩嚟？
第一種，回合制循環。
第二種，目標導向循環，靠/goal觸發。
都講過。Codex & Claude Code 嘅 /goal 指令嘅高級進階使用技巧
講白啲就係俾個目標，俾個標準，叫 Agent 去做。
例如："Lighthouse 跑分提到 90 分以上，嘗試 5 次為止"。
佢就會不斷迭代，直到達標或者撞到次數上限先停手，呢種就適合有明確客觀數據判斷對錯嘅嘢。
第三種，基於時間嘅循環
同樣都講過：Loop Engineering 解析同應用案例
所用嘅工具就係/loop和/schedule。
有啲嘢係週期性嘅，例如每日早上匯總一次 Slack，有啲就需要睇實外部系統嘅變化，例如睇住一個可能隨時收到 review 意見或者 CI 跑死咗嘅 PR。
/loop喺你本地跑，熄機就停，想搬上雲端 7x24 小時值勤，用/schedule。
第四種，主動式循環。
將前面三種加上動態工作流、自動模式拼埋一齊，就係主動式循環。
佢就可以處理長期運行嘅複雜工作流，例如漏洞分類、依賴升級呢類源源不絕嘅嘢。
點樣組合？
用/schedule定時檢查有冇新反饋，用/goal定義「呢輪所有報告都處理曬先算完成」，再用動態工作流俾幾個 Agent 分頭去分類、修復、審查，最後開自動模式令成條流水線唔使你手動㩒確認。
關於程式碼質量呢方面，官方建議係程式庫本身乾淨，Claude 寫出嚟嘅嘢先會跟住乾淨。
用一個冇被歷史對話影響嘅全新 Agent 做 code review，偏見更少。
呢點我自己好有體會，用同一個上下文一路跑到尾嘅 Agent，好容易陷入呃自己嘅循環，揾個乾淨上下文嘅裁判角色，效果立竿見影。具體做法可以睇Fable5 只用咗 2% 嘅額度 1:1 複製 Notion
Loop 呢樣嘢佢都唔係萬能藥，首先係 token 消耗極大，所以細任務唔好出動多 Agent 複雜循環，殺雞唔使用牛刀。
大規模跑動態工作流之前，先切細塊試跑，心中有數先加量。
確定性嘅工作直接寫 script，唔好指望大模型每次都現場推理一次，以而家嘅模型能力嚟講，長時間跑唔走樣，好難好難，就算係 Fable 5 都係咁話。
循環都唔係越複雜越好。
先由最簡單嘅回合制開始，揀一個你手頭上成日卡住嘅任務，問自己三個問題：
寫唔寫得到自動驗證嘅檢查項目？目標夠唔夠清晰？任務係咪按週期發生？
諗清楚呢三點，應該用邊種循環基本就有答案。
今天 Claude 官方出了一份關於設計循環Loop的指南Getting started with loops，看完你會發現，這個概念就是舊瓶裝新酒。
那循環到底是什麼？
第一種，回合制循環。
第二種，目標導向循環，靠/goal觸發。
也講過。Codex&Claude Code的 /goal 指令的高級進階使用技巧
說白了就是給一個目標，給一個標準，讓 Agent 做。
例如："Lighthouse跑分提到90分以上，嘗試5次為止"。
它就會不斷迭代，直到達標或者撞上次數上限才收手，這種就適合有明確客觀數據能判斷對錯的活兒。
第三種，基於時間的循環
所使用的工具就是/loop和/schedule。
有些活是週期性的，比如每天早上彙總一遍 Slack， 有些是需要盯着外部系統變化的，比如盯一個可能隨時收到review意見或者CI跑掛的PR。
/loop在你本地跑，關機就停，想搬到雲上7x24小時值班，用/schedule。
第四種，主動式循環。
把前面三種加上動態工作流、自動模式拼在一起，就是主動式循環。
它就能處理長期跑的複雜工作流，比如漏洞分診、依賴升級這類源源不斷的活。
怎麼組合？
用/schedule定時檢查有沒有新反饋，用/goal定義"本輪所有報告都處理完才算完"，再用動態工作流讓幾個Agent分頭去分類、修復、審查，最後開自動模式讓整條流水線不用你手動點確認。
關於代碼質量這塊，官方建議是代碼庫本身乾淨，Claude寫出來的東西才會跟着乾淨。
用一個沒被歷史對話帶偏的全新Agent做code review，偏見更少。
這條我自己深有體會，用同一個上下文一路跑到底的Agent，很容易陷入自己騙自己的循環，找個乾淨上下文的裁判角色，效果立竿見影。具體做法可以看Fable5 僅用 2%的額度 1:1 復刻 Notion
Loop這種東西它也並不是萬能藥，首先是token消耗極大，所以小任務別動用多Agent複雜循環，殺雞用不着牛刀。
大規模跑動態工作流之前先切小塊試跑，心裏有底再上量。
確定性的工作直接上腳本，別指望大模型每次現場推理一遍，以現在的模型能力來長時間跑不跑偏，很難很難，即使是 Fable 5。
循環也不是越複雜越好。
先從最簡單的回合制開始，找一個你手頭總卡殼的任務，問自己三個問題：
能不能寫出自動驗證的檢查項？目標夠不夠清晰？任務是不是按週期發生的？
想清楚這三條，該用哪種循環基本就有答案了。