如果你還在一句一句下指令給 AI 寫程式，2026 年一批站在 AI coding 工具前線的工程師，已經換了一種工作方式。
近期 X 上有兩則貼文被反覆轉傳。一則來自 Peter Steinberger（@steipete，開源工具 OpenClaw 創作者，現於 OpenAI 任職）：
「你不該再去提示（prompt）你的程式碼代理了。你應該設計會去提示代理的迴圈。」
另一則來自 Boris Cherny（@bcherny，Anthropic 旗下 Claude Code 負責人，Claude Code 是 Anthropic 的 AI 寫程式工具）：
「我不再直接提示 Claude。我讓迴圈跑著去提示 Claude、自己決定要做什麼。我的工作是寫迴圈。」
兩位在 AI 工具圈很受關注的工程師，講的是同一件事。但多數人看完只有一個問題：這到底是什麼意思？
本文以下先把「迴圈工程（Loop Engineering）是什麼」講清楚，後半段再帶你建出第一個迴圈。
迴圈工程是什麼？
開發者 Addy Osmani（@addyosmani，Google 工程師、長期撰寫 AI 開發方法論）給了一句最精準的定義：迴圈工程，就是把「負責提示 AI 的你」這個角色，換成一套替你做這件事的系統。
也就是說，過去兩年你跟 AI 寫程式的方式是這樣：你輸入一段提示、讀回覆、再輸入下一段，你整個過程都握著這個工具，一輪接一輪。你自己就是那個迴圈。
迴圈工程要做的，是建一個小系統，讓它自己去尋找工作、把工作交給代理、檢查結果、記下做了什麼，再決定下一步，然後由這套系統去戳 AI，而不是你。你只設計這套系統一次，之後它就持續運轉。
可以用一組對照來看：提示，是給代理一道指令；迴圈，是給代理一份工作。
跟「寫提示詞」差在哪？
迴圈工程不是更厲害的提示詞技巧，兩者是不同的技能。
提示工程師拚的是語言能力：把指令寫得更精準，換來一次更好的單次輸出，但每跑一次他都要手動檢查，他本人就是回饋迴圈。
迴圈工程師拚的是軟體工程能力：設計更好的回饋循環，換來「可靠、已驗證」的結果，系統自己跑、自己檢查、自己修正，系統本身就是回饋迴圈。
差別濃縮成一句：提示工程師說「幫我寫一個函式」；迴圈工程師說「寫出來、測試、修到全部通過為止」。Cherny 的重點從來不是工作變簡單了，而是槓桿點往上移了一層，從「打字下提示」變成「設計那套會下提示的系統」。
每個迴圈無論簡單或複雜，都走同樣五個階段：探索（Discover）→ 規劃（Plan）→ 執行（Execute）→ 驗證（Verify）→ 迭代（Iterate）。通過驗證就交付，沒通過就再跑一次。
整個概念其實就這麼簡單，後半段要談的，是怎麼把這個循環「建得對」。
為什麼該關注迴圈工程？
最關鍵的轉變，是迴圈工程已經不再是「工具能力」的問題。
Osmani 點出，一年前你想要一個迴圈，得自己寫一堆 bash 指令稿、永遠自己維護，那套東西只屬於你。現在這些零件已經陸續內建在主流產品裡了。
Steinberger 列出的清單，能對應到 OpenAI 的 Codex（Codex 是 OpenAI 的 AI 寫程式工具），也能對應到 Claude Code；但兩邊的指令名稱、成熟度與可用介面不完全相同。
更精準的說法是：Claude Code 官方文件已列出 /loop、/goal、worktree、skills、MCP、subagents 與 memory；Codex 官方文件也列出 automations、worktrees、skills、MCP、subagents 與記憶／狀態機制。
當你發現兩邊的形狀相近，就不必再爭論該用哪個工具，而是設計一個「坐在哪一邊都能跑」的迴圈。
但要先有一個觀念：迴圈工程位在 Osmani 先前提出的「代理束縛工程」（agent harness engineering，指打造單一代理運行的環境）的上一層。束縛是固定的環境，迴圈則是「會自己定時跑、會生出小幫手、會自我供給」的束縛。
一個好迴圈要建哪些東西？
概念講完，進入實作。一個迴圈在概念上有五個階段，但你實際要「建」出來的是六塊組件。Claude Code 與 Codex 都已提供相近能力，但實際操作時要按各自的官方文件確認指令、介面與權限設定。
1. 自動化（Automations）：迴圈的心跳。 這是讓迴圈成為「迴圈」而非「跑過一次」的關鍵。你定義一段提示、一個執行頻率、一個目標，它就照排程跑，有發現才回報給你。在 Claude Code 裡，/loop 負責按週期重跑，/goal 則負責讓代理持續工作到你寫下的條件成真。你可以丟給它「test/auth 底下所有測試通過、且程式碼檢查乾淨」，然後就走開。
2. Worktree（工作樹）：讓多個代理平行跑而不打架。 一旦同時跑兩個以上代理，檔案就會撞在一起，等於兩個工程師沒先講好就改同一行程式。git worktree（git 版本控制的一種隔離工作目錄機制）給每個代理一個獨立的工作目錄與分支，共用同一份專案歷史，誰都動不到別人的檔案。
3. 技能（Skills）：把專案知識寫一次，每次都讀。 一個技能就是一個內含 SKILL.md 檔案的資料夾（SKILL.md 是一份純文字檔，寫下專案慣例、建置步驟、「我們因為某次事故所以不這樣做」這類規矩）。沒有技能，迴圈每一輪都要從零重新摸索你的專案；有技能，知識就會累積複利。
4. 外掛與連接器（Connectors）：讓迴圈碰得到你真正在用的工具。 只看得到檔案系統的迴圈是個小迴圈。連接器建立在 MCP（Model Context Protocol，一套讓 AI 串接外部工具的開放協定）之上，讓代理能讀你的待辦追蹤系統、查資料庫、戳測試環境的 API、在 Slack 丟訊息。這是「告訴你怎麼修」與「自己開好 PR、連好 Linear（一套團隊任務管理工具）票、CI 一綠就通知頻道」的差別。
5. 子代理（Sub-agents）：讓驗證誠實，檢查的人絕不是動手的人。 寫程式的那個模型，對自己的作業太寬容了。換一個有不同指令、有時甚至是不同模型的代理來檢查，才抓得到第一個代理「自己說服自己」的問題。這正是 Anthropic 在 2024 年 12 月就寫過的「評估者／優化者模式」（evaluator-optimizer pattern，一個模型生成、另一個批改、反覆進行）。
6. 記憶（Memory）：讓迴圈跨次不失憶。 一個 markdown 檔案、一塊 Linear 看板，任何活在「單次對話」之外、記著「做了什麼、還剩什麼」的東西都行。Osmani 的原則很傳神：代理會忘，倉庫不會忘。 明天早上的那一輪，就接著今天停下的地方繼續。
第一個迴圈怎麼建？
別一開始就堆大系統。@0xCodez 在他的 14 步路線圖裡給出最小可行迴圈，四個零件，不搞代理群：
- 一個自動化：照週期觸發、遇到明確條件就停的排程執行。
- 一個技能：一份
SKILL.md，存好代理本來每次都要重新摸索的專案脈絡。 - 一個狀態檔：一個 markdown 檔或 Linear 看板，記下做了什麼、還剩什麼，讓明天的那一輪是「續跑」而非「重開機」。
- 一道關卡（gate）：能自動把爛結果擋下來的測試、型別檢查或建置。這一塊決定了迴圈是在幫你，還是只在燒錢。
順序很重要：先讓「一次手動執行」穩定可靠，再把它變成技能，再包成迴圈，最後才排程。跳步驟，正是迴圈在正式環境翻車的主因。
要看的指標只有一個，「每個被採納的修改花了多少成本」，而不是燒了多少 token。採納率低於五成，代表迴圈省下的審查工作又回到你身上了。
我到底需不需要建迴圈？
這是最被略過、卻最該誠實面對的一段。@0xCodez 強調：多數開發者現在還不需要迴圈。 迴圈只在四個條件同時成立時才划算，缺一個，它的成本就高於回報：
- 這件事會重複：迴圈靠多次執行攤平建置成本。一次性的工作，一個好提示更快更省。
- 驗證能自動化：迴圈需要一個「沒有你在場也能讓工作不及格」的東西，測試、型別檢查、linter、建置。
- 你的 token 預算扛得住浪費：迴圈會反覆讀脈絡、重試、探索，不管最後有沒有產出都在燒 token。
- 代理有資深工程師等級的工具：日誌、可重現問題的環境、能跑自己寫的程式並看到哪裡壞掉。
還有一個 30 秒戰術版檢查表，套在「某個具體任務」上，少勾一項就讓它維持手動提示就好：這件事至少每週發生一次、有自動關卡能否決爛輸出、代理能跑它改動的程式、迴圈有硬性停止點（預算/次數/時間上限）、不可逆動作（合併、部署、改相依套件）前有人類審核。
成本問題還有解方。多位作者都提到，迴圈最大的瓶頸不是智慧，是 token 消耗。一次執行可能燒掉 5 萬到 20 萬 token，跑多代理或每天排程更是直線上升。
因此，有作者主張 DeepSeek、Kimi、MiniMax 等以低價著稱的中國模型，可能讓迴圈在經濟上變得更可行；當每跑一輪的成本夠低，普通預算的人才更有機會建得起一個迴圈。
迴圈不會幫你扛的三件事
迴圈改變了工作，但它沒有把你從工作裡刪掉。 有三個問題會隨著迴圈越做越好而越尖銳，不是越輕鬆：
- Ralph Wiggum 迴圈（無聲失敗的迴圈）：工程師 Geoffrey Huntley 命名的失敗模式，代理本該完成才發出「完成訊號」，卻提早發出，迴圈就在半成品上退出，還繼續燒錢。解法就是那道關卡：一個客觀、能讓工作不及格的訊號（測試過不過、能不能編譯），而不是一個「有意見」的驗證者。
- 理解債（comprehension debt）：迴圈越快交付你沒寫過的程式，你懂的和倉庫裡實際有的，落差就越大。真正會痛的不是 token 帳單，而是某天你得去除錯一套全隊沒人讀過的系統。解法不是技術性的：讀那些 diff。
- 認知投降（cognitive surrender）：迴圈自己跑起來後，很容易就放棄形成自己的判斷，全盤接受它丟回來的東西。
Osmani 講了一句值得記住的話：兩個人建出一模一樣的迴圈，可能得到完全相反的結果。一個用它在自己深刻理解的工作上跑得更快，另一個用它來逃避理解工作本身。迴圈分不出差別，你分得出。
所以結論很簡單：先過四條件測試，再決定要不要建；先讓一次手動執行穩定，再包成迴圈；先設好那道客觀關卡，再讓它自己跑。建你的迴圈，但要像一個打算「繼續當工程師」的人那樣建，而不是只當那個按下執行鍵的人。
資料來源：@sairahul1、@addyosmani（Addy Osmani）、@0xCodez；補充查核：Claude Code Overview、Claude Code /goal、Claude Code scheduled tasks and /loop、Claude Code skills、Claude Code worktrees、Anthropic—Building effective agents、OpenAI Codex automations、OpenAI Codex subagents、OpenAI Codex skills、OpenAI Codex MCP
本文初稿為AI編撰，整理．編輯/ 李先泰
