Gary Talks Stuff：Loop Engineering 解析，大神都不寫 prompt 了？

6 月初，OpenClaude 創辦人 Peter Steinberger 在 X 上發表了一則引起關注的觀點：不該再替 coding agent 寫 prompt，而是應該設計 loop，讓 loop 去 prompt 你的 agent。

幾乎同一時間，Claude Code 負責人 Boris Chen 也表達了類似看法。Google 的 Engineering Lead Adi Osmani 更進一步將這個概念整理成「Loop Engineering」框架。這一連串來自頂尖 AI 工程師的發言，意味著寫 prompt 的時代正在轉變。

什麼是 Loop Engineering？

Loop Engineering 的核心概念非常直觀——將過去「人類每一輪手動審核、給予回饋」的工作模式，轉變為由使用者預先設計好完整的迭代邏輯，再交由 AI Agent 自主執行的循環系統。

傳統上，當我們請 AI 幫忙修 bug 時，流程是：你下指令 → AI 修改 → 你檢查結果 → 發現還有問題 → 再下指令 → AI 再修改。審核與推動進度的人永遠是你。

Loop Engineering 的做法截然不同：你一開始就把目標、可用工具、驗證方式、完成條件全部設定好，然後讓 Agent 自己改程式、跑測試、讀錯誤回報、再修正，直到測試通過或確認無法繼續進展後才停下來回報。

舉一個具體案例來說明：假設你需要 AI 幫你製作 YouTube 封面圖。你可以告訴它「幫我做 10 張封面圖，評分標準包含四個面向——觀眾能否一眼看懂主題、能否勾起好奇心、視覺對比是否夠強、是否與內容相符。做完後用這四項標準打分，沒過關的重做一遍，再重新評分，最後把分數最高的 3 張發給我。」這看起來只是一段 prompt，但它背後其實已經包含了「觀察 → 執行 → 驗收 → 修正」的完整循環。

從被動操作者到系統設計者

過去我們和 AI 協作時，從來就不是一次到位。通常是 AI 交出第一版，我們看看哪裡不對，叫它改第二版，再看看，再改第三版。品質就是這樣一點一滴從 60 分修到 100 分的。

Loop Engineering 提出的核心問題在於：既然來回修改的過程本來就會發生，為什麼每一輪都必須有人類坐在螢幕前按下一步？

它的答案是：將一部分的檢查與修正工作交給 Agent 自己跑幾輪。雖然無法保證一次就到 100 分，但至少可以讓 Agent 第一次交到你手上時，版本已經從 85 分起跳。這就是工作重心的轉變——從執行者變成系統設計者。

Loop Engineering 與其他 Engineering 的關係

這幾年 AI 圈子誕生了許多專有名詞，彼此之間既有延續也有分工。要理解 Loop Engineering，最好先釐清它在整個體系中的位置：

• Prompt Engineering：強調與 AI 溝通的技巧，要求使用者把話說清楚——語氣、格式、限制、輸出樣貌，越具體越好。
• Context Engineering：強調在正確的時機提供正確且適量的資訊，讓 AI 有足夠的背景知識來完成任務。
• Harness Engineering：為 AI 設定運作環境與邊界，就像老闆要給員工辦公室、工具、流程和權限一樣。
• Loop Engineering：專注於將 Human in the loop 轉變為 Agent in the loop，將人類提供回饋的邏輯標準化，讓 AI 可以自行審查與迭代。

Trigger 與 Verifiable Goal：Loop 的兩個核心骨架

一個成功的 Loop 由兩個基本問題定義：什麼時候開始？什麼時候停止？

這兩個問題分別對應到 Trigger（觸發機制）和 Verifiable Goal（可驗證目標）。

Trigger 決定 loop 何時啟動，可以是一個事件（如 GitHub 有人開 PR）、一個排程（如每天早上定時整理資料），或由你手動觸發。

Verifiable Goal 則決定 loop 何時停止，又可以拆成兩個子問題：什麼叫做完成？AI 要如何檢查自己是否已經完成？

在程式開發領域，這個標準相對明確——所有測試通過、TypeScript 無報錯、Lint 無違規、Build 成功，這些都是機器可以直接檢查的完成條件。但對於較為抽象的主觀任務，例如寫文章或改產品頁，就需要更精細的驗收設計。

Gary 在影片中提出了兩種實務上常用的驗收方法：

第一種是 Rubric 評分表，先選定幾個評估面向（如風格、人設、語法用詞、內容主題），再為每個面向定義 1 到 5 分的評分標準。關鍵在於每個分數都要有清楚的行為定義，AI 才有依據可循。

第二種是 二元檢查清單，將品質拆解成一串 Yes/No 問題，例如「開頭三句有沒有抓住重點？」「有沒有冗詞贅字？」這種方式比打分數更穩定、更容易判斷。

什麼樣的任務值得做 Loop？

每次 AI 圈出現新名詞，總有人會迫不及待地將它套用到所有場景。但 Gary 特別提醒，要先理解功能運作的底層邏輯，再思考自己的工作流程是否適合。

他提出三個判斷標準：

第一，任務是否會重複發生？ 一次性任務直接寫一個 prompt 就好，沒有必要設計一整組 loop。Loop 的價值體現在那些反覆出現、流程相似但每次細節略有不同的任務上。

第二，完成標準是否清楚？ 這是最關鍵的判斷條件。你必須能夠明確說出什麼叫做「這件事做完了」——可以具體量化，例如將網站部署到指定網域且載入時間低於 2 秒，或是修復所有 CI 錯誤直到狀態變回綠色。

第三，Token 成本是否扛得住？ Loop 不是免費的。每跑一輪，AI 要讀取上下文、思考下一步、呼叫工具，甚至可能還要請 Reviewer Agent 再次檢查。原本手動 prompt 三次就能解決的事，如果做成 loop 跑了 20 輪還停不下來，帳單會非常有「教育意義」。

除了以上三點，還有一種情況適合用 Loop：當你想快速做一個 Demo，核心功能的驗收標準很清楚時。例如你希望做一個讓用戶搜尋最新新聞的網站，其他細節先不追求完美。這時可以用 Loop 先把主功能跑出來，細節再有人接手調整。

三種最常見的 Loop 失控模式

Loop Engineering 真正的難點，在於人類很難一次把所有偏好、細節和例外狀況都講清楚。如果標準不夠明確，Loop 可能會跑出以下三種問題：

不知道該何時停止

如果你跟 AI 說「幫我把這個 App 優化一下」，它改了一點，覺得還能再優化，再改一點，又覺得還有空間。因為你沒有定義清楚「優化」的具體範疇——是前端視覺還是後端回應速度？

沒有明確的終點，Loop 就會變成 Token 黑洞。解決方案是設定硬性的停止條件（Hard stop）：最多跑幾輪、最多跑多久、最多花多少 Token，或連續三輪沒有進展就停下來回報。

修改了不該碰的東西

你說優化效能，它可能開始重構原本不該動的架構。你說改善 UX，它順手把元件拆掉重做。你說修 bug，它為了讓測試通過而改了旁邊無關的程式碼。

因此，除了告訴 AI 要做什麼，你還必須明確劃定邊界——不能刪測試、不能改公開 API、不能動資料庫 Schema、不能碰某些核心檔案。

驗收機制失效

如果目標模糊到無法使用有效的 Verifier，Agent 只能靠主觀判斷來決定是否完成——「這樣改完後看起來是不是差不多了？」這是非常危險的。

驗收標準必須盡量化為可檢查的項目：測試、效能數字、審稿清單，都比「看起來不錯」來得具體。同時也要注意，讓同一個 AI 既產出又評分，等於是球員兼裁判。更好的做法是將產出與檢查分開，由不同 Agent 各自負責。

成本與現實：不是每個人都需要 Loop

這可能是整支影片最誠實的一段話。Gary 坦言，比起 Agentic Loop，他更偏好 Human in the loop。大多數人沒有 OpenAI 或 Anthropic 工程師那種接近無上限的 Token 預算，而 Human loop 通常更準確、更有效率，也更便宜。

連 Google 的 Adi Osmani 都表示，Loop Engineering 仍處於早期階段，必須非常注意 Token 成本。

如果你真的想嘗試，建議從一個小任務開始——範圍小、目標清楚、工具有限、停止條件明確。例如每天整理一次固定資料夾、針對某個測試項目進行修復、或對一篇文章執行固定的品質檢查清單。這些小型任務不會讓成本失控，但能讓你實際體驗 Loop 的核心精髓。

QA 精選

Q1：Loop Engineering 和 Prompt Engineering 最大的差別是什麼？

Prompt Engineering 專注於「如何對 AI 下指令」，而 Loop Engineering 則是「如何設計一個讓 AI 自主迭代的系統」。前者是單向的溝通技巧，後者是包含觸發、執行、驗收、停止的完整閉環設計。Loop Engineering 本質上是將你過去在每一輪對話中給出的回饋，預先標準化為一個可重複執行的流程。

Q2：普通人應該從哪裡開始學 Loop Engineering？

第一步不是立刻搭建自己的 Agent 系統，而是先學會判斷哪些需求適合使用 Loop。建議從一個範圍極小的任務開始，例如每天自動整理特定資料夾、或針對一篇文章執行固定的品質檢查。重要的是先設定好 Hard stop 條件——最多跑幾輪、最多花多少 Token、連續無進展就停止——這樣即使設計不完美，也不會造成成本失控。

Q3：Loop Engineering 的最高境界是什麼？

如果將 Loop Engineering 推向極致，可能會走向所謂的 Software Factory 概念——工程師不再只是寫一段程式，而是在設計一套可以生產、測試、修正、部署軟體的系統。但 Gary 認為，這對一般開發者來說還太過遙遠。多數人需要的不是一個 24 小時不間斷運作的 Agent，而是一個當它說做完時，你不用再來回調整、可以直接把成果交付出去的可靠助手。

Q4：如何避免 Loop 變成不可控的 Token 黑洞？

有三個關鍵規則：第一，設定 Hard stop——最多跑幾輪、最多花多少錢、連續多少次無進展就強制停止。第二，定義邊界——明確告訴 AI 哪些東西不能碰（不能刪測試、不能改公開 API、不能動資料庫 Schema）。第三，將驗收標準具體化——用測試、效能數字、審稿清單取代「看起來不錯」這類主觀判斷。此外，最好把產出和檢查的角色分開，避免球員兼裁判的情況。

Q5：什麼樣的任務最不適合用 Loop 處理？

一次性任務是最不適合的。例如臨時查一個錯誤訊息、改一段小文案，直接寫一個 prompt 就好，完全沒有必要為它設計一整組循環系統。另外，完成標準模糊的任務也很危險——如果你無法清楚定義什麼叫做「做完」，AI 就會陷入無止盡的迭代中。最後，Token 預算有限的情況下也要小心，因為 Loop 的成本會隨著迭代次數快速疊加。

結語

Loop Engineering 的核心不在於 AI 能不能自己做事，而在於你有沒有能力定義一件事應該怎麼被完成。從 Trigger 觸發到 Verifiable Goal 驗收，從 Hard stop 到邊界設定，每一個環節都考驗著系統設計能力。

對多數人來說，最新的方法不一定是最好的方法，能解決你問題的方法才是好方法。與其盲目追求炫麗的 Multi-Agent 協作系統，不如先從一個簡單的小 Loop 開始，體會從操作者到設計者的角色轉變。