Loop Engineering 是什麼？從 Prompt Engineering 進化到 AI 迴圈工程

「我不再直接提示 Claude 了。我讓迴圈跑著去提示 Claude、自己決定要做什麼。我的工作是寫迴圈。」
— Boris Cherny，Anthropic Claude Code 負責人

2026 年 6 月，這段話在工程師社群炸開了。

Claude Code 的創造者在訪談裡宣告了一件事：他已經不再親自輸入提示詞給 AI。他的日常工作，變成了「設計讓 AI 自己去工作的系統」。這不是一個工具技巧的升級，而是一整個思維模式的轉換。

這個概念迅速引爆討論，一週之內，Google 工程師 Addy Osmani 在自己的部落格上為它命名——Loop Engineering（迴圈工程）——並系統性地拆解出五個積木，讓這個概念從「工程師的私房心法」變成了人人可學的方法論。

這篇文章會用白話把 Loop Engineering 從頭到尾講清楚：它到底是什麼、五個積木各自解決什麼問題、實際怎麼建出第一個迴圈，以及它的三個最大陷阱。無論你是工程師、PM、還是內容創作者，這套思維都與你有關。

一、為什麼突然所有人都在談 Loop Engineering？

三個獨立信號，指向同一個方向

這波浪潮不是憑空冒出來的。2026 年上半年，有三個相互獨立的信號同時出現，把「迴圈」這件事推上了檯面。

信號一：Peter Steinberger 的那條貼文

OpenClaw 開源工具創辦人、現任職 OpenAI 的 Peter Steinberger 在 X 上寫了一句話：「你不應該再去提示你的程式碼代理了。你應該設計會去提示代理的迴圈。」這條貼文獲得了超過三百萬次觀看。

信號二：Karpathy 的 700 次實驗

前 OpenAI 研究員 Andrej Karpathy 用 630 行 Python，讓一群 AI Agent 連跑兩天，自己執行了 700 次實驗，發現 20 個有效優化，最終讓語言模型的訓練時間縮短了 11%——全程零人工介入。他把這套系統稱為「autoresearch」，並說：「所有頂尖 LLM 實驗室都會走上這條路，這是最終的 boss 戰。」

信號三：Boris Cherny 的那段採訪

Claude Code 的締造者在訪談中直白地說：他一天同時開著 5 到 10 個 session，夜間有幾千個 Agent 在背景跑。他的工作，已經從「寫好提示詞」升維成「設計讓 AI 自己工作的迴圈系統」。

三個不同背景、不同公司的人，在同一週指向同一件事。Addy Osmani 看到這個訊號，在 2026 年 6 月 7 日寫出了定義 Loop Engineering 的那篇文章，把散落的概念整合成了一套完整框架。

二、Loop Engineering 到底是什麼？白話定義

最精準的一句定義

Addy Osmani 給了一個清晰到無法再更精準的定義：

Loop Engineering，就是把「負責提示 AI 的你」這個角色，換成一套替你做這件事的系統。

意思是：你不再是那個一輪一輪對 AI 說「請幫我做這件事」的人。你設計一個小系統，讓這個系統自己去尋找工作、把工作交給 Agent、檢查結果、記下進度，然後決定下一步——你只設計這套系統一次，之後它就自己持續運轉。

跟傳統 Prompt Engineering 差在哪？

用一個對照來看：

一句話濃縮：提示工程師說「幫我寫一個函式」；迴圈工程師說「寫出來、測試、修到全部通過為止」。

Prompt Engineering 沒有消失，它只是「降格」成了迴圈的一個元件——Loop 裡面仍然有 Prompt，只是你不再是那個每次手動按下送出鍵的人。

Loop 與「寫腳本自動化」有何本質不同？

很多人第一反應是：「這不就是 cron job 加 bash script 嗎？」不完全是。傳統自動化腳本是「把固定流程寫死」，Loop Engineering 的本質差異在於三個新能力：

1. 能讀 Context：Agent 能理解當前狀況，而不是盲目執行預設指令。
2. 會產生假設：Agent 能自己推理「下一步應該做什麼」。
3. 從失敗中學習：當一個方法失敗時，Agent 能根據失敗原因調整策略再試。

這三件事，是 cron job + bash script 天生做不到的。

三、五個積木 ＋ 一個靈魂：Loop 的完整結構

Addy Osmani
Addy Osmani 把一個完整可運作的 Loop 拆成了五個積木加一個記憶層。缺任何一塊，Loop 就會從「自動工作的系統」退化成「燒錢的玩具」。

積木 ① Automations（自動化）：迴圈的心跳

Automations 是讓 Loop 成為「迴圈」而不是「跑一次就結束的腳本」的關鍵。你定義一個任務、一個執行頻率、一個目標條件，系統就照排程自己啟動——有發現才回報，沒有發現就自動封存，不打擾你。

在 Claude Code 裡，/loop 指令負責按週期重跑，/goal 則讓 Agent 持續工作直到你寫下的條件成真。你可以丟給它「test/auth 底下所有測試通過、且程式碼檢查乾淨」，然後走開。OpenAI Codex 有對應的 Automations Tab，同樣支援設定任務、頻率、環境，跑完的結果會進入 Triage 收件匣。

OpenAI 工程師真實使用場景：每日 Issue Triage（自動分類問題清單）、匯整 CI 失敗報告、寫 commit 摘要、追蹤上週新增的 bug。

💡 沒有 Automation，Loop 就只是一段你跑了一次的腳本。

積木 ② Worktrees（工作樹）：多 Agent 並行不打架

一旦同時讓多個 Agent 工作，就會遇到一個問題：兩個 Agent 同時修改同一份檔案，就像兩個工程師沒有溝通就改了同一行程式碼，最後誰的版本都不對。

Git worktree（Git 版本控制中的一種隔離工作目錄機制）解決了這個問題：給每個 Agent 一個獨立的工作目錄和分支，共用同一份專案歷史，讓不同 Agent 的修改彼此不干擾。

Claude Code 支援 --worktree 旗標，讓每個 session 在自己的 checkout 環境中執行；Codex 則直接把 worktree 支援建入多執行緒設計中。

💡 Worktrees 解決了「機械性衝突」，但你的審查頻寬，仍然是整個 Loop 能並行多少工作的真正上限。

積木 ③ Skills（技能）：知識寫一次，永遠複利

Agent 有一個根本的弱點：每次對話開始都是「冷啟動」。它不記得上次你告訴它「我們因為那次事故，所以不能這樣寫」，也不記得你的程式碼規範是什麼、建置步驟怎麼跑。

Skills 解決這個問題。一個 Skill 就是一個包含 SKILL.md 的資料夾——一份純文字檔，把你的專案慣例、架構決策、禁止做法、過去的「血淚教訓」全部寫進去。Agent 每次執行都會先讀這份文件，讓知識從「在你的腦袋裡」變成「在系統的輸入端」，持續複利累積。

沒有 Skills：每一個 Loop 循環都要重新摸索你的專案，等同於每次都從零開始。
有了 Skills：Agent 站在前一輪的肩膀上，直接繼承所有已知的專案脈絡。

💡 Addy Osmani 說：Skills 是「把意圖外部化」的機制——你的決策不再只存在於 Prompt 裡，而是永久寫在倉庫中，讓每一輪都更精準。

積木 ④ Plugins / Connectors（外掛與連接器）：讓 Loop 碰得到真實世界

一個只能看到本機檔案系統的 Loop，是一個極度受限的 Loop。Connectors 建立在 MCP（Model Context Protocol，Anthropic 推出的 AI 串接外部工具開放協定）之上，讓 Agent 能讀取你的 Issue Tracker、查詢資料庫、呼叫 Staging API、在 Slack 發送通知。

這是「告訴你怎麼修」和「自己開好 PR、連好 Linear 票、CI 一綠就通知頻道」的本質差距。

Claude Code 和 Codex 都支援 MCP，這意味著你為其中一個工具寫的 connector，通常可以直接用在另一個工具上。

💡 Connectors 讓 Loop 從「在沙盒裡空轉」升級成「真正改變外部世界狀態的系統」。

積木 ⑤ Sub-agents（子代理）：寫的人和查的人，永遠不能是同一個

這是整個 Loop 架構裡最關鍵、也最容易被忽略的設計原則。Addy Osmani 說：「寫程式的那個模型，對自己的作業太寬容了。」

讓一個 Agent 同時負責「生成輸出」和「審查輸出」，等同於讓同一個人既當球員又當裁判——它會說服自己輸出是對的，而看不見自己犯下的錯誤。Sub-agents 把「製造者」和「檢查者」強制拆開：一個 Agent 負責寫程式，另一個有不同指令（有時甚至是不同模型）的 Agent 負責審查，抓出第一個 Agent「自圓其說」後留下的問題。

Claude Code 的 /goal 指令，底層就是這個原理——一個全新的小模型負責判斷「這個 Loop 到底算不算完成了」，而不是讓做事的模型自己打分。

在 Claude Code 中，你可以在 .claude/agents/ 目錄定義子 Agent；Codex 則是用 .codex/agents/ 目錄的 TOML 設定檔。典型的分工是：探索 Agent → 實作 Agent → 驗證 Agent，三個角色分開，互不相見。

💡 Sub-agents 消耗更多 Token，因為每個子 Agent 都要做自己的推理和工具呼叫——所以要用在真正值得「第二意見」的地方。

＋1 記憶層 Memory（State）：Loop 的脊椎

這塊最容易被忽略，但它是整個系統的脊椎。

Agent 在對話結束後會忘記一切。如果沒有一個「活在對話之外」的記憶機制，每次 Loop 啟動都等於重新開機——不知道上次做到哪裡、哪些已完成、哪些待處理。

實作上可以非常簡單：一個 Markdown 檔案、一塊 Linear 看板、一個 AGENTS.md 進度日誌，任何能讓 Loop「明天的那一輪接著今天停下的地方繼續」的機制都行。

Addy Osmani 說了一句很傳神的話：

「Agent 會忘，但倉庫不會忘。」

四、一個完整 Loop 長什麼樣？

把五個積木拼起來，一個真實運作的 Loop 大概是這樣的形狀：

每天早上，Automation 自動啟動，呼叫一個 Triage Skill，掃描昨天的 CI 失敗、未解決的 Issue、最近的 commit，把發現寫入 Markdown 狀態檔或 Linear 看板。

針對每一個值得處理的發現，Loop 開一個隔離的 Worktree，派遣一個實作 Sub-agent 去草擬修正方案，再派一個審查 Sub-agent 對照專案 Skills 和現有測試評估品質。

如果通過審查，Connector 自動開好 PR、更新 Linear 票。如果沒通過，Loop 把問題記入狀態檔，等下一輪再試。Loop 無法處理的例外，會進入 Triage 收件匣，讓人類決定。

你設計這套系統一次。之後你不再手動輸入任何一個步驟的提示詞。

五、三個會讓 Loop 失控的大坑

Loop Engineering 不是「按下執行就高枕無憂」的魔法。Addy Osmani 明確指出了三個會讓系統從「槓桿工具」變成「慢性毒藥」的風險。

大坑 ① 沒設好 Stop Condition：帳單在你睡覺時爆掉

一個沒有明確停止條件的 Loop，就是一個持續燒錢的機器。

Anthropic 自己說，Agent 系統平均會消耗比一般對話多 4 倍的 Token；Multi-agent 系統甚至可以達到 15 倍。 如果沒有設定明確的「達成條件」（例如：所有測試通過、lint 乾淨）、最大迭代次數、或 Token 預算上限，Loop 會在你不注意的時候一直跑、一直花錢。

解決方案：在設計任何 Loop 之前，先寫清楚三件事：成功長什麼樣、最多跑幾輪、花多少錢就停。/goal 指令的條件寫法是好的起手式，例如：all tests in test/auth pass and lint is clean，然後設定 Token 預算上限。

大坑 ② 理解債（Comprehension Debt）：你不懂的程式碼越堆越多

Loop 讓你可以一夜之間合併 10 個 PR，但你真的讀懂這 10 個 PR 改了什麼嗎？

Comprehension Debt（理解債）是指：你在倉庫裡的實際程式碼，和你真正理解的部分，之間的落差。Loop 讓這個落差快速擴大。六個月後，當 production 出了 bug，你站在自己的 codebase 前面，看著一堆沒人讀過的程式碼。真正會痛的不是 Token 帳單，而是那個瞬間。

解決方案：對重要的模組，不要讓 Loop 直接 merge。讀那些 diff。 每個被接受的修改，至少自己看過一遍，留下「為什麼這樣寫」的一兩句筆記。

大坑 ③ 認知投降（Cognitive Surrender）：最舒適的姿勢是最危險的

當 Loop 順暢地自動工作，你會開始不想思考了。

「系統給了什麼，我就接受什麼」——這就是認知投降。設計 Loop 的人，當他用判斷力來設計時，Loop 是倍增器；當他用 Loop 來逃避思考時，Loop 是加速器——加速走向失控。

Addy Osmani 說了一句讓人難忘的話：

「兩個人建出一模一樣的迴圈，可能得到完全相反的結果。一個用它在自己深刻理解的工作上跑得更快，另一個用它來逃避理解工作本身。迴圈分不出差別，你分得出。」

解決方案：定期問自己：「如果今天所有的 Loop 都停掉、所有的 Agent 都關閉，我還知道下一步要做什麼嗎？」如果答案模糊，你已經在認知投降的路上了。

六、我適合建 Loop 嗎？四個條件缺一不可

Loop Engineering 不是每個人、每個任務都適合的。Addy Osmani 和社群裡的多位工程師都強調：多數開發者現在還不需要 Loop。

以下四個條件要同時成立，建 Loop 才划算——缺任何一個，傳統 Prompt 更快更省：

最小可行 Loop（快速起手式）

如果你確認四個條件都符合，不要一開始就堆大系統。最小可行 Loop 只需要四個元件：

1. 一個 Automation：有明確停止條件的排程觸發。
2. 一個 SKILL.md：把 Agent 每次都要重新摸索的專案脈絡寫進去。
3. 一個狀態檔：Markdown 或 Linear 看板，記下做了什麼、還剩什麼。
4. 一道關卡（Gate）：能自動擋下爛輸出的測試或 lint 檢查。這一塊決定了 Loop 是在幫你，還是只在燒錢。

⚠️ 順序很重要：先讓「一次手動執行」穩定可靠，再把它變成 Skill，再包成 Loop，最後才排程。跳步驟，是 Loop 在正式環境翻車的主因。

七、不同角色的 Loop 應用場景

對工程師：自動優化研究迴圈

Karpathy 的 autoresearch 是最好的示範。一個能修改單一檔案的 Agent、一個客觀可量化的指標（例如：訓練時間、測試覆蓋率）、一個固定時長的實驗窗口，三個元件組合起來，就能在兩天內跑完 700 次實驗，找出 20 個優化方案。[9][11][28]

這種模式適用的場景：API 效能優化、程式碼靜態分析自動修正、每日 Issue Triage、CI 失敗自動分類等重複性高且可量化的任務。

對 PM / Agent 設計者：工作流編排

Boris Cherny 的模式更複雜：多個 Agent 並行運作，彼此透過 Worktrees 隔離、透過 State 共享進度。適合設計「Bug Triage → 自動草擬修補方案 → PR 審查 → 自動合併」這類跨越多個工具的長鏈工作流。

對內容創作者：一條文章自動拆成多格式

這是與 AI 新聞、SEO 內容工作最相關的應用。一個內容生產 Loop 的典型設計：

• Automation：每天定時掃描 RSS 訂閱源、Google Trends、X 熱門詞
• Skills：存入你的選題標準、寫作風格指南、SEO 規則、禁止措辭
• 執行：找出值得寫的主題 → 生成長文骨架 → 自動拆分為電子報、IG 貼文、短影音腳本
• Sub-agent：SEO 檢查 Agent 審查標題、關鍵字密度、meta description
• State：記錄哪些主題已寫過、哪些格式已發佈、各篇文章的表現數據
• Connector：串接 Notion（草稿存放）、Buffer 或原生 API（排程發佈）

這套 Loop 建好一次，你的注意力就可以從「執行」移到「選題判斷」和「內容品質把關」。

八、Loop Engineering 的現在與未來

工具層已經準備好了

2026 年的 Loop Engineering 之所以能成為一個可實踐的方法論，很大程度是因為工具層的成熟：Claude Code 和 Codex 都已內建了完整的五個積木，你不再需要自己維護一堆 bash script。

Prompt Engineering 並沒有消失

需要釐清的是：Loop Engineering 不是 Prompt Engineering 的終結，而是一次升維。Prompt 從「你跟 AI 說話的語言」變成了「Loop 裡的一個組件」。

如果說過去的技能樹是「寫出好提示詞」，現在的技能樹是「設計一套讓 AI 自己走完工作流的系統」。

Boris Cherny 也說，這個轉換的窗口期可能只有「接下來幾個月到今年年底」。在那之後，這會成為預設的工作方式，而不是少數人的前沿實踐。

九、結語：設計迴圈，但不要停止當工程師

Addy Osmani 在原文的最後寫了一段話，是整個 Loop Engineering 概念最重要的警醒：

「建你的迴圈。但要像一個打算繼續當工程師的人那樣建，而不是只當那個按下執行鍵的人。」

Loop Engineering 不是「把工作丟給 AI、自己去睡覺」的躺平術。它是一個槓桿工具——當你用清醒的判斷力來設計迴圈，它讓你的工作效能倍增；當你用它來逃避思考，它只會更快地把錯誤放大。

Karpathy 的 700 次實驗、Boris Cherny 的千個並行 Agent、Addy Osmani 的五積木框架，指向的是同一個未來：工程師的核心價值，從「打字輸入指令」移向了「設計讓 AI 替你打字的系統」。

這個轉換正在發生，現在就是你決定要停留在舊層級、還是往上移一層的時刻。

參考資料：Addy Osmani《Loop Engineering》(2026.06.07) addyosmani.com；Boris Cherny，Anthropic Claude Code 負責人訪談；Andrej Karpathy autoresearch 專案；數位時代《迴圈工程(Loop Engineering)是什麼？》；The AI Corner, Kilo.ai, AlphaMatch.ai 等多個技術分析來源。