Loop Engineering 解析，大神都不寫 prompt 了？

6月初,OpenClaw的創辦人Peter Steinberger發了篇X帖文主要內容是說,你不應該再替Coding Agent寫Prompt你應該設計Loop,讓Loop去Prompt你的Agent差不多同一段時間Claw Code負責人Boris Cherney也講了類似的東西他說自己不再給Claw寫提示詞了他的工作已經變成寫Loop,讓Loop來做這個工作然後Google的Engineering Lead Adiosmani接著又發布了一篇長文把這件事整理成一個框架,叫Loop Engineering所以這支影片想跟各位聊三件事第一,Loop Engineering到底是什麼?第二,它和Prompt,Context,Harness Engineering的關係第三,為什麼我認為不是每個人都要去做Agentic Loop?那我們直接開始先講定義,Loop Engineering裡面的Loop可以先理解成一個反覆循環的工作方式在過去,你會打字和AI說幫我修這個BuckAI修一下,回你一段你看完,發現測試還是壞的,再說這裡不對,然後它再修,你再看,審核,給修改意見的是你本人而Loop Engineering的做法是你讓Agent自己改程式自己跑測試自己讀錯誤自己再改直到測試過或者連續幾次都沒有進展就停下來回報告訴你他做完了審核的角色一部分由AI取代你不用每一輪都自己來而是一開始就告訴他目標是什麼可以用哪些工具怎麼驗證什麼狀況算完成什麼狀況要停下來找人舉個簡單的例子你可以直接跟Agent說幫我做10張YouTube封面圖評分標準有4個包含能不能讓觀眾一眼看懂影片在講什麼能不能勾起好奇心視覺對比夠不夠強跟影片內容符不符合做完之後用這四個標準幫每一張打分把沒過關的挑出來重做一版改完再用同一套標準重新打分這樣跑兩輪最後把分數最高的三張發給我像這樣只是一句完整的prompt但是它代表了重複觀察執行驗收修正四個步驟也是loop的精髓所在和以往不同的是工作狀況的改變一直以來我們在和AI協作的時候本來就不是一次做到完美是他寫一版你看一下覺得哪裡怪怪的叫他改一版你再看一下他再改一版品質是這樣慢慢從60分修到100分的那既然這種來回修改的過程本來就會發生為什麼一定要每一輪都由人類坐在螢幕前面按下一步呢是不是有些檢查和修正可以先讓Agent自己跑幾輪雖然他不會保證一次到100分但這樣做或許可以讓Agent第一次交到你手上的版本是從85分開始而這就是Loop Engineering以前執行觀察結果再執行並且迭代的這個Loop由你負責推動但Loop Engineering強調的是由使用者設計這個Loop然後讓agent自己推動講完定義後我想要名詞比較一下因為AI圈子這一兩年真的蹦出太多名詞了所以loop engineering和我們前面講過的其他名詞是什麼關係又有什麼差別呢一開始的prom engineering強調跟AI溝通的技巧要使用者把話說清楚你要AI幫你做什麼語氣格式限制輸出長什麼樣講得越清楚結果越符合你的期望Context Engineering 則是強調在對的時機給到 AI 正確而且不多不少的資訊讓 AI 有足夠的背景知識可以幫你做事後來 AI Agents 的觀念興起人人都想要一個貼身的 AI 助理幫忙管理生活大小事但我們發現模型本身再聰明如果沒有一個可靠的環境AI 就無法在現實生產環境中穩定運作所以有了 Harness Engineering在 Harness Engineering 中我們設定規矩和邊界可以想像你是老闆要讓員工有效率工作不能只叫他努力還要給他辦公室工具、流程和權限關於Harness Engineering我也有做一支教學影片有興趣的朋友可以去看看而今天講的Loop Engineering則是專注在把Human in the Loop變成Agent in the Loop從過去的人類審核後給feedbackLoop Engineering強調的是人類把自己提供feedback的邏輯標準化或者說講清楚讓Agent自行Review並迭代Loop的行程可以從兩個問題去決定第一個是什麼時候開始第二個是什麼時候停止而這兩個問題分別對應兩個名詞就是 Trigger 和 Verifiable GoalTrigger 是觸發機制決定這個 Loop 什麼時候開始它可以是一個事件比如 GitHub 上有人開了一個 PI Agent 自動開始檢查它可以是一個排程比如每天早上跑一次資料整理每30分鐘檢查一次任務狀態它也可以由你手動啟動你今天覺得這件事值得跑就按下去而停下來靠的是 Verifiable Goal也就是可驗證的目標白話講就是 AI 做到什麼程度時系統可以判斷它完成了然後把這個路停掉Verifiable Goal又可以猜成兩個問題第一,什麼叫做完成第二,AI要怎麼檢查自己完成了在Coding任務裡比較好理解比如所有測試通過TypeScript沒有報錯Lint沒有違規Build成功這些判斷很乾脆機器可以檢查但很多任務沒那麼乾淨比如你叫AI寫一篇文章什麼就寫好了你叫AI改一個產品頁什麼就改好了把抽象的概念變成清楚的標準是大多數人在實作時比較常遇到的卡點舉例來說如果你希望AI幫你把文章改得更順比較常見的做法有兩種一種是Rubric評分先選定幾個面向例如風格人設語法用詞內容主題再替每個面向寫出分級定義以風格人設為例滿分五分代表完全符合你設定的人設用詞語氣一致三分代表有點像但偶爾會出戲一分則代表根本沒有你的風格在裡面關鍵在於每個分數都要定義清楚你的評分標準AI才會有依據可循而不是隨意給分另一種方法是二元檢查清單把品質拆成一串yes or no問題像是開頭三句有沒有抓住重點有沒有農詞墜字專有名詞有沒有用錯這種方式比打分數更穩定也更容易判斷有沒有過關不論用哪一種最後都要收斂成一個明確的完成條件例如三個面向的rubric都達到四分以上或檢查清單全部通過才算真正的完成那什麼樣的任務值得做loop呢?每次AI圈出現一個新詞很多人會立刻把它用到所有地方尤其你看到一些高手在展示四五個agents同時跑一個manager agent指揮一堆helper agents整套看起來像一個24小時不睡覺的小公司你就很容易心動也想自己搞一個來玩玩但對於所有新功能我建議的approach方式都是先去了解這個功能運作的底層邏輯然後再去思考自己的工作流有沒有可以套用的地方通常一半以上的功能對我們來說都沒有用武之地因為這些功能的設計師以及這些功能的需求來源可能大多數來自OpenAI跟Enthropic的工程師而這些人幾乎是世界上最頂尖的人才他們用得到的東西我們不一定用得到因此絕對不要盲目跟風一個任務值不值得做成loop我會先看三件事第一它是不是會重複發生如果是一次性任務直接寫一個一般的prompt就好了比如你臨時要查一個錯誤訊息或者改一段小文案沒必要為他設計一整套looploop對那些會反覆發生每次流程差不多但每次細節又不完全一樣的任務來說會比較有價值第二完成標準清不清楚這是最關鍵的你要能講出什麼叫這件事做完了可以是把網站部署到指定網域並確保載入時間低於兩秒或在程式碼開發時修復所有CI錯誤直到狀態變回綠色針對較抽象或是主觀的東西可以用我剛剛講到的Rubric或Yes or No方法來寫驗收標準第三Token的花費你是否扛得住Loop不是免費的每跑一輪AI要讀東西想下一步呼叫工具可能還要再請Reviewer檢查你原本手動prompt三次就能解決的是如果做成路跑了20輪還沒有停這個帳單會非常有教育意義教育你下次不要這樣除了以上三點另外還有一種情況是你想快速做一個demo核心feature的驗收標準很清楚比方說你就是希望做一個網站讓用戶可能在上面搜索到最新的新聞其他細節先不追求完美這時候可以用loop先把主功能跑出來其他細節再由人接手調整所以普通人學Loop Engineering第一步不是馬上自己搞一個而是怎麼判斷哪些需求可以用上有沒有想清楚最後的目標但坦白說比起Agentic Loop我自己還是更喜歡Human in the Loop因為大多數人其實不需要一個AI不眠不休的跑27小時還有剛剛說的成本問題如果我像OpenAI Anthropic的工程師一樣有接近無上限的Token預算我也會一直用但一般人都沒有無上限的預算所以Human in the Loop往往更準更有效率也更便宜最後是Loop最大的問題是人很難一次把所有偏好細節例外狀況都講完所以你讓agent自己迭代一整個晚上如果一個不小心可能會偏到十萬八千里遠Loop Engineering真正的難點是如果標準不清楚Loop會跑出三種問題第一種問題是他不知道什麼時候該停你跟AI說幫我把這個App優化一下他改了一點跑一下看起來還能再優化再改一點又覺得還能再改因為你沒有告訴他什麼是所謂的優化是前端視覺還是後端回復的速度沒有定義清楚他就不知道終點在哪裡最後就變成Token黑洞所以第一條規則是一定要有Hard Stop也就是硬性的停止條件最多跑幾輪最多跑多久最多花多少Token三輪都沒有進展就停下來回報這些限制聽起來保守但他們正是Loop不失控的關鍵第二個問題是他可能把不該碰的東西也改掉你說優化效能他可能開始重構一堆本來不該碰的架構你說改善UX他可能順手把元件拆掉重做你說修BUG他可能為了讓測試過改掉一堆旁邊的東西所以第二條規則是要定義邊界你不能只說測試要過你還要說不能刪測試不能改公開API不能動資料庫schema不能碰某些核心檔案最後一個問題是Verifier失效Loop之所以能停下來是因為它有某種驗收機制目標模糊到不能用VerifierAgent就只能用很主觀的方式去判斷比方說他可能會問自己這樣改完後看起來是不是差不多了而這樣做的壞處是非常不可控所以第三條規則是驗收標準要盡量變成可以檢查的東西測試、效能、數字、審稿清單都比看起來不錯、具體、真的很主觀的任務也要猜成剛剛講到的rubric比如語氣是否符合、主題有沒有偏格式有沒有對反正不管你打算怎麼驗收就是要想辦法讓它驗出來但這裡也要小心不是有分數就代表客觀如果你叫AI做任務然後AI自己平分那就是球員兼裁判所以比較好的做法是把產出跟檢查分開一個agent負責產出另一個agent負責檢查或者乾脆在關鍵節點保留human in the loop不然從指標上看測試過了但實際上產品沒有變好反而更糟總結來說loop engineering的核心不是讓AI自己跑而是你能不能把一個模糊意圖翻譯成AI可以執行可以驗收可以停止而且不會鑽漏洞的條件如果你現在手上就有一個任務但不知道可不可以把它做成可控的loop我在Patreon有撰寫完整的文章和提示詞模組幫你釐清你手頭的project是否適合做成loop也會提到除了Trigger和Verifiable Go之外loop的六大股價讓你可以自己動手搭建一個自己的loop有興趣的可以在影片下方資訊欄找到連結那我們繼續最後想聊一下loop最現實的問題就是成本loop很迷人它會讓人覺得按一下按鈕後事情就會自己往前走但每一次自動往前走背後都有成本它要讀context要呼叫工具要跑測試要解讀錯誤要從事你如果再加reviewer agent、sub agent、多輪驗證成本就會不斷往上疊加連Google的engineering leadAdi Osmani都說目前loopengineering還處於早期階段他保持謹慎的態度必須非常注意token的成本更何況就像我剛剛提到的一樣絕對不是每個人都需要一整套multi agent協作系統也不是每個任務都值得用loop燒事實上我覺得至少在這個時間點大多數的人都不會需要這個功能所以如果真的想玩玩看我建議你可以先從一個小任務開始做一個範圍小目標清楚工具有限停止條件明確的loop比如每天整理一次固定資料夾針對某個測試項目進行修復或者針對一篇文章跑固定的品質檢查checklist這些小型的任務不會讓成本失控但也會讓你體驗到loop的精髓像是要怎麼定義目標怎麼設計驗收怎麼控制權限怎麼讓AI在正確的地方停下來loop把人的工作往上移以前你是prompt的操作者一輪一輪的跟AI對話看他做了什麼,再決定下一步現在你更像是一個系統設計者你要定義目標設計驗證設定邊界控制成本你用力的地方不一樣了Loop Engineering 的重點不在於AI能不能自己做事而是你有沒有能力定義一件事應該怎麼被完成如果把 Loop Engineering 往更高階推可能會走向所謂 Software Factory也就是軟體工廠工程師不再只是寫一段程式而是在設計一套可以生產、測試、修正、部署軟體的系統就像業界在研究讓AI模型更會自我提升一樣但回到現在這對我們一般人來說確實太遙遠了就像我這支影片中不斷提到的大多數人並不需要一個agent不免不休的幫你跑27小時而是當agent跟你說他做完的時候你不用再來回調整可以直接把成果發給老闆所以這就是我對loop engineering 的看法不論這個觀念有沒有出現做一個好loop的能力也是現在AI工作者的必備條件包含讓AI知道什麼時候開始知道什麼叫完成知道哪些事情不能做知道失敗時要停下而我們大多數人並不需要去追求這些最新的功能技術更不要因為很多人在討論所以逼著自己去用因為到頭來最新的方法不一定是最好的方法能解決你問題的方法才是好方法以上就是今天的內容各位喜歡的話記得幫我按讚追蹤加分享這是我持續創作下去的動力我是Gary 我們下次見

加入我的 Patreon，查看完整文章還有提示詞模板：https://www.patreon.com/GaryChen/posts/162494198

Loop Engineering 不是把 AI 放著全自動，而是設計 Trigger、Verifiable Goal、驗收標準與停止條件，讓 Agent 在可控範圍內自己迭代。這支影片會拆解它和 Prompt、Context、Harness Engineering 的差別，以及普通人到底該不該用。

時間戳：
00:00 為什麼大家開始討論 Loop Engineering
00:40 Loop Engineering 到底是什麼
02:29 Prompt、Context、Harness、Loop 的差別
03:42 Trigger 與 Verifiable Goal
04:40 Rubric 與 yes/no checklist 怎麼定義完成
05:37 什麼任務值得做成 Loop
08:10 Loop 失控的三個問題
10:40 成本、從小任務開始與最後總結

喜歡這類 AI 工作流拆解，記得訂閱、按讚，也歡迎留言你現在最想做成 loop 的任務。

#AI #LoopEngineering #AIAgent #PromptEngineering #gary