一句話概覽
起因是Claude Code 團隊發了一篇博客，標題很不起眼，叫“Getting started with loops”。
我完整看完了，發現裏面藏着一個我認爲被嚴重低估的信號：AI 編程的核心操作單元，正在從“一次對話”變成“一個循環”。
什麼叫 loop？Claude Code 團隊給了一個乾淨的定義：
Agent 重複執行工作循環，直到滿足停止條件。
聽起來平平無奇，但仔細想，這和你平時用 Claude 的方式完全不同。你現在的用法大概率是：寫 prompt，等回覆，看結果，不滿意就再寫一條，每一步都是你在驅動。
Loop 的意思是：你不再逐步驅動，你設計一個循環結構，定義好觸發條件和退出條件，然後 Agent 自己跑。
這不是微調，這是一種操作範式的切換。
四種循環，四种放手程度
Claude Code 團隊把 loop 分成四類。我覺得最有意思的不是分類本身，而是它們背後暗含的一條線：你願意把多少控制權交給 Agent。
1⃣Turn-based Loop（回合制）
你發一條 prompt，Claude 讀代碼、改代碼、跑測試、返回結果，然後你檢查，再發下一條。
這就是大多數人現在的用法。
嚴格來說它也是 loop，因爲 Claude 內部確實在”讀取-行動-驗證”地循環，但觸發和停止都由你控制。
提效關鍵：別讓 Claude 改完代碼就報告“完成了”，用 SKILL.md 把你的驗證步驟編碼進去。比如：改了前端組件，必須啓動 dev server、截圖前後對比、檢查控制檯零報錯，現在是Claude 自己跑完這些檢查再交活。
這一步很多人跳過了，但它是後面所有高級 loop 的基礎，因爲如果 Claude 連自我驗證都做不好，你給它再多自主權也沒用。
2⃣Goal-based Loop（目標制）
用 /goal 命令定義成功標準，Claude 會反覆迭代，直到達標或者達到你設的輪次上限。
比如：
/goal 把首頁 Lighthouse 分數提到 90 以上，最多試 5 次
關鍵區別在哪？在回合制裏，Claude 每做完一步就會停下來等你。因爲它不確定什麼算“夠好”，所以傾向於提前交差。
/goal 解決的就是這個問題：你把“什麼算完成”說清楚了，Claude 就不用猜了。每次它試圖停下來，一個評估模型會檢查目標是否達成，沒達成就打回去繼續。
做過開發的應該秒懂，這就是 retry with backoff，只不過退出條件從 HTTP 200 變成了”Lighthouse 90 分”。
這裏有個很實際的經驗：目標越量化，loop 越高效。 “優化一下性能”是模糊目標，Claude 跑兩圈就會停。“LCP 降到 2.5 秒以下”是精確目標，Claude 會持續迭代直到命中。
3⃣Time-based Loop（定時制）
/loop 按時間間隔重複執行同一個 prompt，/schedule 把它搬到雲端，你關機也照跑。
比如這樣：
/loop 5m 檢查我的 PR，處理 review 評論，修復失敗的 CI
這類 loop 解決的問題是：有些工作是重複的，只是輸入在變。
每天早上總結 Slack 消息，每隔五分鐘檢查 CI 狀態，每週生成依賴更新報告。
人做這些事的方式是”想起來就去看一眼”，效率極低，定時 loop 把它變成了 cron job。
4⃣Proactive Loop（主動式）
這是最激進的形態，沒有人類實時參與，Agent 自己監聽事件、自己決定行動、自己驗證結果。
Claude Code 團隊給了一個組合例子：
/schedule 設定每小時檢查反饋渠道
/goal 定義每個 bug report 必須被分類、修復、回覆
Dynamic Workflows 並行派出多個 Agent 探索不同修復方案
Auto mode 全程無需人工審批
說白了就是一條流水線：觸發、執行、驗證、交付，全自動。
我的判斷：Loop 是 Harness Engineering 的執行層
Harness Engineering 講的是”設計賽道”。圍欄怎麼裝，彎道怎麼設，剎車放在哪。但它沒回答一個問題：賽道設計好了，Agent 具體怎麼跑？
Loop 就是這個答案。
SKILL.md 是圍欄（做什麼、不做什麼的規則）
Loop 類型 是賽道結構（直道還是彎道、單圈還是多圈）
Stop criteria 是終點線（什麼時候算跑完）
Prompt Engineering 管你說什麼，Context Engineering 管 Agent 知道什麼，Harness Engineering 管 Agent 在什麼環境裏做事，Loop Design 管 Agent 怎麼反覆做事直到做對。
這四層疊在一起，纔是完整的 AI 編程工作流。
實操建議：別從 Proactive 開始
你在探索或試驗？ 用回合制，重點投入寫好驗證 Skill。
你知道”做完”長什麼樣？ 用 /goal，把退出條件量化。
這件事你每天/每週都在重複做？ 用 /loop 或 /schedule。
這件事完全可以標準化，輸入輸出都確定？ 上 Proactive，全自動。
順序很重要，跳過前面的基礎直接上 Proactive，大概率翻車。原因很簡單：如果你連回合制的驗證 Skill 都沒寫好，自動循環只會更快地產出垃圾。
還有一條容易忽略的：Token 成本會隨 loop 複雜度指數級上升。
Dynamic Workflows 可以並行派出幾百個 Agent，如果你沒在小規模上先驗證過，一次 run 燒掉的 Token 會讓你心痛。Claude Code 提供了 /usage 和 /workflows 來監控消耗，但最好的策略是：先跑一個小切片，確認成本和質量都可控，再放大。
從 prompt 到 loop，本質上是一個權力轉移的過程。
你把越來越多的判斷權和執行權交給 Agent，自己退到更上游：設計循環結構、定義成功標準、構建驗證機制。
不是每個任務都需要 loop，但如果你還在逐條 prompt 驅動一個重複性的工作流，你正在做一件 cron job 該做的事。
值得想一下：你手上哪個任務，可以從”你驅動”變成”循環驅動”？
更多遊戲資訊請關註：電玩幫遊戲資訊專區
電玩幫圖文攻略 www.vgover.com
