💡 核心結論速覽 (TL;DR)
- 一句話定義：迴圈工程（Loop Engineering）就是你不再手動一步步下 prompt，而是設計一套會「自己派工、驗證、修正、決定下一步」的自動迴圈，重點從「會不會講話」轉向「會不會設計系統」。
- 怎麼跑：一個迴圈跑「探索→規劃→執行→驗證→迭代」五個階段，過不了就自己重來；但一次迴圈可能燒掉數萬到二十萬 token，沒設停止條件，帳單會在你睡覺時失控。
- 適合誰：要同時滿足「能自動打分＋失敗代價可控＋有夠硬的驗證機制」三個條件才值得上迴圈；寫文案、做設計這種只能人工判斷好壞的工作，硬套迴圈只會製造一堆垃圾。
- 先做這步：別急著全流程自動化——挑一個「重複又能自動驗證」的小環節（跑測試、去重、查連結），設一個「最多 5 次、有明確停止條件」的最小迴圈，跑穩了再擴大。
你有沒有發現，最近「Prompt Engineering」好像突然退流行了？打開技術社群，大家開始聊一個新詞：迴圈工程（Loop Engineering）。連 NVIDIA 執行長黃仁勳受訪時都在描述類似的東西——未來的 AI 不是等你一句一句下指令，而是自己搜尋、嘗試、驗證、反覆修到好。
簡單講，迴圈工程就是：你不再親手一步步提示 AI，而是設計一套會替你派工、檢查、修正、決定下一步的自動迴圈。
老實說我一開始也覺得這又是哪個科技圈的新黑話。我每天用 AI 超過十小時、同時養 ChatGPT 和 Claude 兩個高階訂閱，本來想說「我 prompt 得很順啊幹嘛搞這麼複雜」——直到某次我把一段每天都要手動重複的整理流程，第一次交給一個會自己跑的迴圈，才有點被電到。但也差點被 API 帳單電到。
所以迴圈工程到底是不是又一個被過度包裝的概念？非工程師、一般的 AI 使用者，需要現在就跟上嗎？這篇我用自己踩過坑的角度，把它講清楚。
迴圈工程是什麼？跟 Prompt Engineering 到底差在哪
最精準的一句話，我看過的版本是 Google 工程師 Addy Osmani 給的：把「負責提示 AI 的你」這個角色，換成一套替你做這件事的系統。過去兩年你跟 AI 協作，是自己打字、讀回覆、再打字；迴圈工程是把這個「人」抽掉，交給一段會自己跑的程式。
如果覺得抽象，有個對照超好懂。提示工程師會說：「幫我寫一個函式。」迴圈工程師會說：「寫出來、測試、修到全部通過為止。」前者管一次輸出，後者管的是「一直修到好」的整個過程。差別不在你多會講話，而在你會不會設計一套能自我檢查的機制。
這股風氣不是憑空冒出來的。Addy Osmani、OpenAI 的 Peter Steinberger、還有 Anthropic 負責 Claude Code 的 Boris Cherny 都公開講過同一件事。Peter Steinberger 說得很直接：「你不該再去提示你的程式碼代理，你應該設計會去提示代理的迴圈。」Boris Cherny 更狠：「我不再直接提示 Claude，我讓迴圈跑著去提示 Claude、自己決定要做什麼。」
換句話說，這些天天在寫 AI 工具的人，自己已經不「聊天」了。他們把槓桿點從「打字下提示」搬到「設計一套會下提示的系統」。這也是為什麼你會覺得 Prompt Engineering 好像退燒——它沒消失，只是被墊到下面去了。
那黃仁勳在這裡的角色是什麼？他在一次受訪時談到，未來的 AI 會從「一次性回答」進化成能自己搜尋、評估、推理、用工具、反覆自我修正的系統，還丟出一句「少一點猜測，多一點研究」。他沒有發明迴圈工程這個詞，但媒體很愛用他的說法來解釋這股趨勢——畢竟由他來背書，話題就熱了。下一步你可以做的：先分清楚 prompt、harness、loop 是三件不同的事，別把它們混為一談（下一段馬上拆給你看）。
迴圈工程怎麼運作？把「探索→規劃→執行→驗證→迭代」拆給你看
一個迴圈不管長得多複雜，核心都跑同一組循環。目前最常被引用的版本是五個階段：探索（Discover）→ 規劃（Plan）→ 執行（Execute）→ 驗證（Verify）→ 迭代（Iterate）。通過驗證就交付，沒通過就把失敗原因餵回去、重跑一次。你可以想成一個永遠不喊累、也不會不好意思重做的實習生。
用寫程式的場景舉例最直覺，跑一輪大概像這樣：
- ❶ 探索：讀專案現況、找出這一輪要解的任務（例如「這個測試沒過」）
- ❷ 規劃：產生一個假設和一段修改方案
- ❸ 執行：真的動手改程式、跑起來
- ❹ 驗證：跑測試、linter、型別檢查，看有沒有過
- ❺ 迭代：沒過就把錯誤訊息帶回第一步，過了就收工
這裡有個我覺得最關鍵、很多人會漏掉的觀念：樓層是往上疊的，前一層不會被取代。2023 到 2024 年大家練的是 Prompt Engineering；2025 到 2026 年初多了 Harness Engineering（幫單一 agent 建一個有約束、有檢查的環境）；2026 年中才輪到 Loop Engineering，在 harness 之上管理多個 agent 的時序和決策。你還是需要好的 prompt、好的 harness，loop 只是把整套東西包進一個會自己重來的程序。
更進階一點的玩法，是「讓 Agent 去 prompt Agent」。主 agent 負責產出、另一個 sub-agent 專門獨立驗證它的成果，避免「同一個 agent 自己改、自己審」的球員兼裁判。有人把一大群 agent 平行跑，形容目標不是模擬「一個博士生」，而是模擬「一整個研究社群」。聽起來很酷，但先別急——這也是帳單開始失控的起點，這點我後面會誠實說。
下一步你可以做的：先在腦中把你某個日常任務套進這五階段，問自己「第四步的『驗證』能不能自動化」。如果答不出來，那你可能還不需要迴圈（原因下一段講）。
非工程師也能玩迴圈工程嗎？我的最小可行迴圈與工具選擇
能，但要選對切入點。迴圈工程被講得很像工程師專利，其實它的核心是一種「把重複工作交給會自我檢查的流程」的思維，不是只有寫程式能用。我自己不是拿它來寫 code，而是拿它來跑內容產線裡最無聊的那段。
講個我踩過的實例。我每天要處理大量素材：蒐集、去重、查來源、整理成草稿。這幾步又臭又長，但共通點是——它們都有辦法「自動判斷做對沒有」（重複的丟掉、連不上的來源標記、格式不對的擋下）。我把這段設成一個會自己跑的迴圈，選題、觀點、最後定稿留給自己。第一次看它自己把重複素材清乾淨時，那種「欸它真的會自己收尾」的感覺確實有點爽。
如果你想試，我會建議從最小可行迴圈開始，不要一次就想自動化整個工作流。最小的骨架其實只要三到四個組件：
- ❶ 一個觸發器：定時或手動啟動這個迴圈（它的「心跳」）
- ❷ 一段執行：叫 AI 做那件重複的事
- ❸ 一道檢查：自動驗證做對沒有（跑測試、比對清單、確認連結）
- ❹ 一條停止線：設「最多重試 5 次」和明確的收手條件，避免無限空轉
那第四條停止線是我血淚換來的重點，沒有停止條件的迴圈，等於一台會自己燒錢的印鈔機（反過來的）。工具方面，現在門檻其實比想像低，我整理成一張表，非工程師也找得到入口：
| 工具 | 迴圈相關功能 | 適合誰 | 上手難度 |
|---|---|---|---|
| Claude Code | /loop、排程、worktree、Skills |
已經在寫程式的人 | 中 |
| OpenAI Codex | /goal：設好終點與驗收條件讓它自己跑 |
想先體驗迴圈感覺的人 | 中 |
| Cursor | Agent 模式、背景代理 | IDE 重度使用者 | 中低 |
| n8n | 視覺化拖拉工作流，可接 AI 模型 | 非工程師、想做通用自動化 | 低 |
如果你完全沒有工程背景，我會叫你先從 n8n 這種視覺化工具下手，用拖拉的方式把「AI 執行→自動檢查→不過就重試」串起來，體感最快。想讓迴圈連到你的資料庫、行事曆或 Slack，靠的是一層叫 MCP 的東西——不同情境該接哪些 MCP server，我另外整理過，想少走冤枉路可以看這份把 MCP 一次講清楚的實戰指南。而如果你想讓 agent 每次都自動記得專案規則、不用重講，可以把知識寫成一個 Skill，用法我也整理在Claude Skills 各情境怎麼用這篇。下一步你可以做的：挑一個你每週手動重複三次以上的小任務，先把它畫成「執行→檢查→重試」三個框。
迴圈工程適合誰？三個條件沒過，我建議你先別上迴圈
先說結論：不是所有工作都值得上迴圈，硬套只會浪費 token 和你的時間。判斷值不值得，我會用三個條件過一遍——這也是我做 PM 這些年，決定「要不要自動化一件事」的老習慣。缺任何一個，我都會先按住不做。
| 判斷條件 | 可以上迴圈 ✅ | 先別上迴圈 ❌ |
|---|---|---|
| 能不能自動打分 | 有明確指標（測試通過、去重率、benchmark 分數） | 只能靠人工感覺好壞（文案口氣、設計美感、創意決策） |
| 失敗代價高不高 | 錯了容易回復（重跑測試、整理草稿） | 錯了很貴（刪檔、對外發布、付款、寄出訊息） |
| 有沒有驗證機制 | 有測試／檢查腳本自動擋著 | 沒有任何自動驗證，全靠人回頭看 |
有句話我很認同：「沒有 harness 的 loop，就是一台自動製造垃圾的機器。」因為迴圈會忠實地把「做不對還一直重做」放大成規模。你的驗證機制有多硬，迴圈的產出就有多可靠；驗證是空的，它就會很努力地大量產出錯的東西給你。
這也解釋了為什麼寫文案、做視覺、談策略這種工作，我暫時不會整段迴圈化。它們沒辦法自動打分——AI 沒法客觀告訴你「這段文案夠不夠打動人」。但它們裡面「重複又能驗證」的邊角料（例如把採訪逐字稿去重、檢查每個外部連結還活著）就很適合。這也是為什麼 AI agent「亂跑」在有些場景特別可怕：它真的會在沒人看的時候刪掉你的檔案或跑錯指令，我把防範它的五道安全防線整理成一篇，上迴圈前強烈建議先讀。
🧭 迴圈工程商業決策速查
- 適合誰：有大量重複、又能自動驗證任務的開發者、資料工作者、經營自動化流程的個人與小團隊。
- 不適合誰：工作以創意判斷為主、或還沒建立任何測試／檢查機制的人——先把 harness 補起來再說。
- 預算心理準備：主要成本不是人力，而是 API 成本＋你設計迴圈的時間；想讓它半夜也跑，可能還要一台雲端主機。
- 下一步：先自動化一個「錯了也不痛」的小環節試水溫，跑順了再往高價值、但仍可驗證的任務擴大。
下一步你可以做的：拿你手上最想自動化的任務，用上面三個條件打勾。只要有一個打叉，這篇的建議就是——先別上迴圈，先把那個條件補起來。
迴圈工程會不會燒爆帳單？我差點踩的成本坑
會，而且這是我最想提醒你的地方。迴圈最迷人的地方（會自己一直跑）也正是它最危險的地方（會自己一直花錢）。Prompt 是你按一次、花一次；迴圈是它自己決定要按幾次，而每一次都在燒 token。
成本大概怎麼算？記一條公式就好：迭代次數 × 每次呼叫的 token × 平行跑的 agent 數。單看一次執行，業界分享的區間大約是幾萬到二十萬 token 起跳；如果你又開了 sub-agent 幫忙驗證，等於每個產出都要再花一次錢，成本直接翻倍。最恐怖的情境是——你設了一個沒有收斂條件的迴圈就去睡了，早上起來帳單已經失控。
我差一點就這樣。那次我把重試次數放得太寬，又忘了設「連續幾次沒改善就自動停」，看著用量往上爬的時候真的手心冒汗。後來我養成幾個習慣，分享給你：
- ❶ 一定要有停止線：最多重試 N 次、或連續 M 次沒進步就自動收手
- ❷ 設 token 預算上限：跑之前先想好這件事「值得花多少」，超過就中止
- ❸ 分層用模型：初步篩選用便宜快的小模型，關鍵判斷才叫貴的大模型上場
- ❹ 換算 ROI：把問題從「省了多少人力」改成「API 成本＋設計時間，划不划算」
關於怎麼把 AI coding agent 的 token 成本壓下來，我專門寫過一篇把帳單砍下來的實戰筆記，裡面的 prompt caching、清理上下文那幾招，套在迴圈上一樣有效。另外提醒一個容易忽略的隱形成本：迴圈狂打 API 很容易撞到限流、甚至讓你覺得 AI 突然變笨。這到底是陰謀還是 bug，我也查證過限流與「降智」的真相。下一步你可以做的：在你第一個迴圈裡，現在就先加上「最多 5 次」這條停止線，其他之後再優化。
當 AI Agent 自己會工作，人類還剩下什麼？
這題其實比技術更重要。當 agent 會自己派工、自己驗證、自己重來，人類的價值就從「動手做」往上移到「決定要做什麼、以及守住底線」。我這種同時在寫東西、又要管流程的人，對這個轉變特別有感。
我自己把「還留在人手上」的事收斂成三塊：選題與目標（要迴圈去追什麼）、品味與判斷（什麼叫做得好，機器打不了這個分）、還有守門（在它把錯的東西大量放出去之前攔下來）。迴圈能把幾十次平庸的嘗試，磨成一個被反覆測試過、比較可靠的成品；但「這件事該不該做、做到什麼程度算好」，還是人說了算。
不過有個陷阱我想誠實講。有工程師提出兩個詞我很喜歡：「認知投降」和「理解債務」——當你太習慣讓迴圈幫你搞定，你會慢慢不再理解系統怎麼運作，等到哪天它壞了、或跑出你沒預期的結果，你連怎麼修都不知道。他的建議很傳神：「建你的迴圈，但要像一個打算繼續當那個工程師的人一樣去建。」別把自己外包掉。
所以我的態度是：迴圈工程是拿來放大你的判斷，不是拿來取代你的判斷。把無聊的重複交給它，把省下來的力氣拿去做只有人能做的事——這才是我覺得最值得的用法。順帶一提，這也呼應我一直有的體會：AI 沒有讓人更清閒，反而讓我更忙，因為它一直在幫我打開新的可能。下一步你可以做的：想清楚你想守住哪三件「不外包」的事，再開始設計你的第一個迴圈。
FAQ 常見問題
迴圈工程和 Prompt Engineering，我該學哪個？兩個要一起學嗎？
兩個一起，但有順序。迴圈工程是疊在 prompt 之上的，你還是需要會寫清楚的提示，只是重心從「講一次好話」變成「設計一套會自己重來的流程」。如果你連 prompt 都還不太順，先把基本功練起來；已經用得很熟、開始覺得「每次都要盯著它好累」的人，才是最該進到迴圈工程的族群。至於迴圈裡該用哪家 AI 當引擎，可以參考我實際養了好幾個月三大付費 AI 的選擇心得。
黃仁勳說的迴圈工程是什麼？真的是他發明的嗎？
不是他發明的。「Loop Engineering」這個講法主要來自 Addy Osmani 等實務工程師社群。黃仁勳是在受訪時描述了「未來 AI 會自己搜尋、評估、推理、反覆自我修正」的方向，跟迴圈工程講的是同一件事，媒體就順勢用他的說法來解釋這股趨勢。所以與其說是他提出的，不如說是他幫這個概念背書、讓它更快被看見。
我不是工程師，完全沒寫過 code，也能做迴圈工程嗎？
可以，切入點不一樣而已。你不用從寫程式開始，改用 n8n 這類視覺化自動化工具，把「AI 執行→自動檢查→不過就重試」用拖拉的方式串起來，就是一個迴圈。關鍵不是會不會 coding，而是你那件事能不能「自動判斷做對沒有」。能，就適合；不能，再厲害的工具也幫不了你。
上迴圈工程之前，最容易被忽略的雷是什麼？
兩個。第一是成本失控——沒設停止條件的迴圈會在你沒注意時燒掉大量 token，一定要先加重試上限和 token 預算。第二是安全——會自己跑指令的 agent 真的可能刪錯檔、跑錯操作，動手前務必先建好權限與驗證的防線。這兩個雷我分別寫過省 token 的實戰筆記和防止 agent 亂刪檔的五道防線，上迴圈前先看能省不少學費。
想讓迴圈在我睡覺時繼續跑，需要準備什麼？
需要一個「你關掉電腦它還在跑」的環境，通常是把迴圈搬上雲端主機，或用工具內建的排程和雲端執行功能。本機跟雲端的差別、費用怎麼算，我比較過Claude Code 雲端環境和本機環境到底差在哪。另外提醒，迴圈跑久了會在背景堆一堆沒收尾的程序吃掉記憶體，記得順手看怎麼用排程自動清理背景程序。
結語：先跑一個小迴圈，再決定要不要全押
繞了一圈，我最想留給你的一句話是：迴圈工程不是要你把整個工作外包給 AI，而是把「重複又能驗證」的那段自動化，讓你有力氣去做只有人能做的事。它很強，但它會忠實放大你的設計——驗證做得好，它幫你省時間；驗證是空的，它幫你製造垃圾還附贈帳單。
所以別被「工程師都不寫 prompt 了」的標題嚇到，也別急著全押。挑一個小任務，設一個有停止線的最小迴圈，跑跑看再說。真正的門檻從來不是工具，是你有沒有想清楚「什麼值得自動化、什麼要守在自己手上」。
如果你已經在用 Codex 或 Claude Code、常被各種怪問題卡住，我把最常見的雷整理成一份完整的排雷指南，很適合搭配這篇一起服用，先把地基顧好再上迴圈。
如果你也是被 AI 越用越忙的那種人，喜歡這種「踩過坑再告訴你」的內容，歡迎訂閱我的部落格，會不定期收到信。我是夜羽凌，一個每天用 AI 超過十小時、還在學著跟這些會自己跑的迴圈相處的人。
參考資料
- Addy Osmani — Loop Engineering（概念主要推廣者的一手部落格）
- 數位時代｜迴圈工程是什麼？工程師為什麼不再寫提示詞
- 天下雜誌｜黃仁勳說必學的「迴圈工程」是什麼
- Anthropic — Claude Code 官方介紹
