Claude Code 負責人親口說：我不再直接 prompt AI 了——Loop Engineering 是什麼？

寫在前面

這幾天，矽谷討論最熱烈的話題是：Loop Engineering，循環工程，簡稱 LE。

6 月 7 日，Google Cloud 主管 Addy Osmani 發表部落格文章，引發熱烈討論。

OpenClaw 作者 Peter Steinberger（江湖人稱「蝦爹」）說：

你不該再去 prompting coding agent，而是設計 loops，去 prompt agents。

Anthropic Claude Code 負責人 Boris Cherny（Claude 之父）也說：

我現在已經不直接 prompt Claude 了，有一套 loops 在運作，會去 prompt Claude，並判斷接下來要做什麼。我的工作是寫 loops。

注意說話的人是誰——一個是 Claude Code 的親爹，一個是專業做 AI 程式工具的老手。他們都在說同一件事：直接給 AI 寫 prompt 這件事，正在過時。

這不是概念炒作。這是一線工程師在日常工作中自然演化出來的範式——當你用得夠熟練，你會發現手動 prompt 太低效，開始想辦法讓系統自己跑起來。

過去兩年，我們是怎麼用 coding agent 的

過去兩年，讓 coding agent 做事的基本方式是：

• 寫好 prompt，提供足夠上下文。
• 輸入一段內容，閱讀返回的結果，再輸入下一段。
• agent 是工具，一輪接一輪地操作。

這種人機乒乓球模式中，人類充當 AI 的即時調度器。一旦任務複雜，人的耐心和打字速度就成了系統交付瓶頸。

本質上，這是一個規模化瓶頸：你不可能僱 10 個人來盯著 10 個 Agent 即時餵 prompt。人類注意力是稀缺資源，把它全花在當 AI 調度員上，是一種巨大浪費。

範式轉變很清晰：

• PE（Prompt Engineering）是人類餵 AI 答案——命令式，一步一步告訴 AI 怎麼做
• LE（Loop Engineering）是人類構建 AI 自動演進引擎——宣告式，只告訴 AI 成功是什麼樣子，讓它自己找路

這個類比不是隨便說的。從命令式到宣告式，是程式設計範式史上發生過最重要的轉變之一。SQL 比手寫迴圈高效不是因為它更聰明，而是因為它把「怎麼做」的細節交給了引擎。LE 在做同樣的事——把「怎麼一步步 prompt」的細節，交給 Loop 系統。

不用再鑽研怎麼說話更精準，而是設計這套 loop 法則：定義目標、品檢標準，剩下的讓系統在自我博弈中迭代完成。未來的競爭力不再是會寫 prompt 的人，而是那些設計出最聰明、最閉環系統的規則制定者。

Claude Code 的 /loop 指令就是典型。

Loop Engineering 正在取代「親自給 agent 寫 prompt」。核心：不再直接 prompt agent，而是設計系統去 prompt agent。loop 是遞迴目標：定義目標，讓 AI 不斷迭代，直到任務完成。

Loop Engineering 的五大核心組件

Addy Osmani 的部落格給出了一張框架圖，順時針從 12 點方向看起：

LE 由五個建構塊組成：

• Automations 自動化：按排程自動觸發、發現和分流。
• Worktrees 工作樹：讓兩個並行工作的 agents 不會互相干擾。
• Skills 技能：把專案知識寫下來，避免 agent 靠猜。
• Plugins 外掛 和 connectors 連接器：把 agent 接入已經在用的工具。
• Sub-agents 子 Agent：一個提想法，另一個檢查。

另外還有 memory（狀態）：markdown 檔案、Linear 看板，或任何存在於單次 conversation 之外、能夠保存「已完成事項」和「下一步事項」的地方。

這五個核心模組在 Claude Code 和 Codex 都已具備：

每個模組的工作邏輯：

定時自動化（Automations）：循環的心跳。按時間表自動觸發，完成發現和分類工作，不需人工介入。

並行工作樹（Worktrees）：讓多個 Agent 並行工作而不干擾的隔離機制。沒有 Worktrees，兩個 Agent 會在同一程式碼分支上互相覆蓋對方的改動，循環就此失控。

技能知識沉澱（Skills）：把專案知識寫下來，避免 Agent 每次都只能靠猜測。這是把「只有你知道」的上下文轉化為「Agent 也知道」的結構化輸入。在我看來，這是五個組件裡最容易被低估的一個——它決定了系統的「記憶上限」，直接影響循環的品質天花板。

外掛與連接器（Plugins and Connectors）：把 Agent 接入已有工具鏈——GitHub、Linear、Slack、資料庫。循環要讀取實際環境資訊，也要把結果寫回環境，連接器是這個雙向通道。

製作者與驗證者分離的子 Agent（Sub-agents）：一個 Agent 提出方案，另一個檢驗——製造者與審查者天然分離。這是循環裡內建的品質關卡，防止單個 Agent 的錯誤在無人知曉的情況下蔓延。

Loop Engineering ≠ cron job

等等，看起來，LE 不就是定時循環任務嗎？

這是很多人的第一反應，但有一個關鍵區別：cron job 是確定性的，LE 是自適應的。

cron job 每次執行的都是完全相同的操作——它不會因為上次結果不理想就調整策略。而 LE 的核心是回饋循環：系統根據上一輪的輸出，決定下一輪怎麼做。LLM 能讀懂上下文、理解結果好不好，並據此調整——這是普通 cron job 做不到的。

就像開發團隊要了解新功能回饋、使用者問題、工作流優化，然後調整迭代計畫。LE 就是把這個「理解→調整→再執行」的循環，嵌入到系統裡自動跑。

YC CEO Garry Tan 提醒：別把 Agent 變成「富士康工廠」式重複勞動機器，開發者應讓 Agent 承擔更多工作。

但也有人指出：要讓 Agent 做更多事，必須明確邊界——提供清晰上下文、可信工具、可稽核操作紀錄和安全停止條件。

這個提醒很重要。LE 不是「放任 AI 自己跑」，而是「設計好規則，讓 AI 在規則內自己跑」。規則設計得好，系統越跑越聰明；規則設計得差，系統越跑越偏——而你可能幾十輪之後才發現。

LE 的三個已知問題

① 除錯難度大

除錯跑 47 輪的狀態機，比修好 prompt 難 10 倍。而且大多數人連可靠的一次性 prompt 都寫不好。

• 一開始設定容易，但之後有很多痛點，修復費勁。
• 有人後悔引入 Loop，遷移到其他方案耗費時間和資源，只能繼續撐著。
• 還有人建議儘早遷移，時間越久情況越糟。

這裡有個反直覺的建議：LE 其實對 prompt 能力要求更高，而不是更低。 你在循環系統裡寫的那個核心 prompt——目標定義、驗收標準——如果寫得模糊，會被放大幾十倍地出錯。先把單次 prompt 寫好，再考慮搭 Loop，是更穩健的路徑。

② Token 消耗大

LE 模式下，Token 消耗量高。Boris Cherny 和 Peter Steinberger 背後公司提供近乎無限 token 支援，但社群很多人 token 預算有限。

怎麼辦？

• Token 充裕的公司可用 while 迴圈
• Token 緊張的新創公司可用 for 迴圈實現目標

Claude Code 對 token 消耗問題做了各種限制：Loops 支援最小 1 分鐘間隔，最長執行 3 天，到期自動停止；Loops 綁定當前 Claude Code 會話，關閉終端機或結束會話後停止；還提供禁用 Loop 的開關。

換個角度看：Token 消耗高，其實是一個天然過濾器。 它迫使你只把 LE 用在真正值得的地方——高價值、高重複性、人工處理成本更高的任務。如果一個任務用 LE 跑起來 token 成本遠超節省的時間，那它可能本來就不適合 LE。

③ 長任務穩定性

LE 重點是讓 Agent 長時間執行不跑偏，並能判斷對錯。

Anthropic 應用 AI 團隊工程師 Ash 表示：公司探索方向更偏「盡量完全自主」，目標是把人類判斷寫入 Harness，而不是插入人工兜底。

去年，Claude Code 從只能連續執行約 20 分鐘、易出錯，進化到幾乎由自己編寫、可連續執行數天。

Anthropic 工程師 Andrew 指出：讓 Agent 連續執行數小時甚至數天，核心難點有上下文、規劃和自我判斷。為解此，Anthropic 採用兩條路徑：

• 提升模型本身，把長時任務能力寫入模型權重；
• 改造模型外部的 Harness。

早期長時執行 Agent 把需求拆解成持久化檔案，在新上下文視窗中反覆執行任務，緩解上下文遺失和任務漂移。隨著新模型能力增強，Anthropic 開始簡化 Harness。

• Opus 4.6 擅長規劃和工具選擇，Sonnet 4.6 以低成本提供接近 Opus 的執行能力，常見組合是用 Opus 做規劃、Sonnet 執行程式碼。
• 伺服器端壓縮和百萬級上下文視窗使模型在單一長會話中保持更久連貫性。

Anthropic 內部實驗的前沿 Harness 模式是生成器—評估器—規劃器結構，借鑑生成對抗網路思想。

這個結構值得單獨強調一下：GAN（生成對抗網路）之所以能生成高品質圖像，是因為判別器不斷告訴生成器「哪裡還不夠好」。把這個思想搬到軟體開發上，意味著一個 Agent 負責寫程式碼，另一個負責挑毛病——兩者形成對抗性壓力，輸出品質比單個 Agent 反覆迭代要高得多。這是架構層面的思維，不是工程技巧層面的優化。

我的判斷：開發者的角色正在被重新定義

Loop Engineering 最深層的影響，不在於工具，而在於開發者的工作內容正在發生結構性轉變。

過去是：理解需求 → 分解任務 → 寫程式碼 → 除錯。

LE 之後變成：理解需求 → 設計循環規則 → 定義驗收標準 → 觀察並調優系統。

這更像一個系統架構師的工作，而不是一個執行層的工程師。能把需求翻譯成精準的循環目標、能設計合理的品檢標準、能判斷系統什麼時候跑偏——這些能力，比「會寫好 prompt」要難得多，也有價值得多。

所以，LE 不是讓開發者可以偷懶的工具，而是把開發者的工作提升到了更抽象的層次。入場門檻更高了，不是更低了。

Claude Code 是什麼？怎麼用上？

Claude Code 是 Anthropic 推出的 AI 程式工具，區別於 Copilot 式的程式碼補全，它更像一個能自主拆解任務、執行多步驟操作的 AI 工程師：讀寫檔案、執行指令、跨檔案重構、自主除錯，並且原生支援 /loop、/workflows、子 Agent 等 Loop Engineering 所需的基礎設施。

官方訂閱：Claude Pro 方案 20 美元/月，Max 方案 100 美元/月起。

常見問題

Q：Loop Engineering 和 Prompt Engineering 的核心區別是什麼？A：PE 是命令式——人類主動給 AI 寫指令，AI 執行後返回結果，人再介入。LE 是宣告式——人類設計一套系統，由系統自動去 prompt AI、獲取回饋、再觸發下一輪，人只需定義目標和驗收標準。兩者的技能要求不同，不是進階關係，而是方向的轉變。

Q：LE 適合什麼類型的任務？A：適合三類：有明確目標且可自動驗證結果的任務（如跑測試並修復失敗）、高重複性但需要智慧判斷的任務（如掃描 issue 並分類）、人工處理成本遠超 token 成本的任務。反之，一次性的、創意性強的、結果難以量化的任務，用普通 prompt 更合適。

Q：普通開發者現在就能用 LE 嗎？A：可以，但建議先打好基礎。Claude Code 的 /loop 和 /goal 指令已具備 LE 的基本要素。但在上 Loop 之前，先確保你能寫出可靠的單次 prompt——LE 會把 prompt 的問題放大，而不是掩蓋它。

Q：LE 最大的風險是什麼？A：跑偏後難發現、難修復。一旦循環執行了幾十輪才發現方向錯了，排查成本極高。建議早期設定明確的停止條件、保留每輪的中間結果、並在關鍵節點插入人工確認節點。