你還在手寫 Prompt？聰明的人早就用上了循環工程，AI 的自動駕駛時代來了

2026 年 6 月初，OpenClaw 創辦人 Peter Steinberger 在社交平台拋出一句話：別再手動為 AI 編碼代理撰寫提示詞，應該設計一個能自動產出提示詞的系統。短短幾天內，Claude Code 負責人 Boris Cherny 公開呼應，表示自己的日常工作已經變成「寫迴圈」，讓迴圈去調度 Claude，不再逐條下達指令。隨後 Google Cloud 工程總監 Addy Osmani 將這套做法進行系統性拆解，並賦予正式名稱——Loop Engineering，也就是循環工程。

三家公司、三位關鍵人物在同一週得出相同結論，這不是巧合，而是宣告 AI 程式輔助工具正式進入新階段。什麼是循環工程？它是一種面向 AI 代理（Agent）的工作流程設計方法，目標是建立一套完整的執行系統，能自動發現任務、分配給 AI 代理執行、檢查產出品質、記錄進度，並決定下一步是繼續、重試或停止。整個過程可以在無人值守的狀態下持續運轉，直到滿足預設的退出條件。如果用比喻來說明，提示詞工程（Prompt Engineering）像是棋盤上每一步的精準落子，循環工程則是設計下棋的規則與裁判機制，讓 AI 按照規則自行完成整盤棋。

雖然目前循環工程主要應用在軟體開發領域，但其底層邏輯並不限於寫程式；任何需要反覆執行與判斷的流程，從運維巡檢、內容生產、客服分流到資料清洗，都能用同樣思路建構，只是程式領域的工具鏈最先成熟，討論也最密集。回顧 AI 輔助程式設計的發展路徑，可以清楚看到三個階段。第一階段是提示詞工程，工程師透過精心設計提示詞，設定角色、給予範例、加入鏈式思考引導，讓模型產出更準確的結果。但這種方式有個結構性問題：提示詞是手工製品，高度依賴特定模型版本與上下文長度。模型一更新或輸入稍有變化，之前調好的提示詞可能悄悄失效，團隊甚至得為提示詞撰寫回歸測試，卻看著它們在每次模型升級後批量過期。

這個現象被稱為「提示詞漂移」（Prompt Drift），是把確定性期望綁在機率系統上的必然結果。第二階段是上下文工程（Context Engineering）。業界很快意識到，與其反覆打磨措辭，不如把力氣放在模型輸入的數據上。RAG 管線、向量資料庫、嵌入策略陸續出現，上下文窗口從幾千 Token 擴展到百萬級別，工程師的工作重心從「怎麼說」變成「讓模型看到什麼」。上下文工程解決了資訊供給問題，但仍有一個缺陷：一個被充分餵養上下文的模型，如果第一次就答錯，它不會自己發現，也不會主動驗證，整個管線沒有任何機制推動它進行二次檢查。第三階段正是循環工程所補上的環節。

它不再試圖優化單次輸入，而是圍繞模型搭建一個閉環系統：模型執行操作 → 確定性工具（如編譯器、測試框架、Lint 工具）評估結果 → 評估反饋傳回給模型 → 模型修正後再次執行 → 如此反覆直到通過所有預設驗證門檻。工程師的角色也隨之改變，不再是每一輪對話的參與者，而是閉環系統的設計者，必須定義什麼算完成、用什麼驗證、失敗後如何處理、何時需要人工介入。三個階段之間並非替代關係，好的提示詞與充足的上下文依然有用，但它們已從主要工程挑戰變成循環內部的子模組，真正決定產出品質的是循環本身的設計。根據 Addy Osmani 的拆解，一個能投入實際使用的循環需要五個結構性組件，加上貫穿始終的記憶層。

首先是自動化觸發（Automations），讓循環有別於一次性腳本；可以是定時任務、事件鉤子或持續監聽。在 Claude Code 中可透過 /loop 設置定時巡檢，Codex 則提供 Automations 面板可直接配置執行環境。其次是工作樹隔離（Worktrees），當多個 AI 代理同時處理同一程式碼倉庫時，檔案衝突會第一個爆發。Git Worktree 為每個代理提供獨立工作目錄與獨立分支，Codex 內建此支援，Claude Code 也透過 --worktree 參數達成。

第三是技能檔案（Skills），如果不把專案約定、建置流程、已知陷阱寫下來，AI 代理每次啟動都得從零推導整個專案，產生所謂的「意圖債務」（Intent Debt）。SKILL.md 檔案記錄指令與元數據，代理啟動時自動載入匹配的 Skill，節省重新解釋背景的成本。第四是插件與連接器（Plugins & Connectors）。一個只能讀寫本地檔案的代理活動範圍非常有限，透過 MCP（Model Context Protocol）協議可以接入外部系統，讀取工單、查詢資料庫、呼叫 CI 管線或發送 Slack 通知。

MCP 已成為 AI 代理與外部工具通訊的行業標準，由 Linux 基金會管理，截至 2026 年 3 月 SDK 每月下載量超過 9700 萬次，公開的 MCP 伺服器數量突破 1 萬。以 ServBay 為例，它內建 MCP Server，開放 39 個工具介面，涵蓋服務啟停、建站配域名與 SSL、資料庫建立與查詢、開發語言版本切換等。接入後，Claude Code、Cursor、Codex 等編碼代理可直接呼叫本地開發環境中的服務，實現「AI 告訴你怎麼配置」到「AI 直接幫你配好」的差距。

第五是子代理（Sub-agents），這是循環中最有價值的架構決策：將生成工作的代理與檢查工作的代理分開。寫程式的模型在評判自己的程式時傾向於過於寬容，一個獨立的驗證代理使用不同指令集甚至不同模型，能抓住第一個代理自我合理化後忽略的問題。Claude Code 的 /goal 命令底層就是這個思路，Codex 則允許用 TOML 檔案定義多個代理並指定不同模型。最後是狀態持久化（State），AI 代理在對話結束後會遺忘一切，但循環不能；需要一個存在於對話窗口之外的持久化儲存來記錄上一輪做了什麼、哪些完成、哪些排隊、哪些失敗。

狀態可以是 Markdown 檔案、Linear 看板或 GitHub Issue 留言區。以實際場景為例，團隊的程式碼倉庫每天都有新的 CI 失敗、新 Issue 和新提交。一個定時自動化任務在早上啟動，呼叫分類 Skill 讀取昨天 CI 失敗日誌、未處理 Issue 與最近提交，將需要處理的事項寫入狀態檔案。對於每個事項，系統在隔離的 Worktree 中啟動一個子代理起草修復方案，同時啟動另一個子代理進行獨立審查，對照專案 Skill 中的編碼規範與測試用例。

審查通過後，連接器自動建立 PR、關聯 Issue，等 CI 通過後在 Slack 發送通知；審查未通過則退回重試，超過最大重試次數則升級到人工處理佇列。狀態檔案在每一步更新，第二天新一輪循環啟動時會讀取進度繼續進行。這個流程只需設計一次，之後每天執行不需要任何人手動輸入提示詞。不過，循環工程在真實落地時，Token 消耗是能否上生產環境的硬門檻。每一輪迭代都在消耗 Token，沒有迭代上限的循環就像沒有油量表的車。

根據 FinOps Foundation 2026 年調查覆蓋 1192 家企業、代表超過 830 億美元年度技術支出的數據，98% 的企業已主動管理 AI 成本，兩年前這個比例只有 31%。某個團隊配置夜間無人值守循環讓 AI 代理自動修復失敗測試，卻遇到一個 Flaky Test（不穩定測試），AI 判斷不了這個情況，連續嘗試十幾種修復方案，每輪都把完整測試輸出與 diff 歷史重新讀取，第二天 Token 暴增。問題不在循環工程本身，而在於上線時缺少預算上限、最大迭代次數和人工升級通道。

三個被驗證有效的成本控制策略包括：提示緩存（Prompt Caching），把系統提示詞、工具定義、不變的程式碼上下文設計為可緩存部分；動態模型路由（Dynamic Model Routing），將確定性高、複雜度低的任務交給小型低價模型，只在需要複雜推理的節點才呼叫前沿模型，不同模型價格差距可達千倍；狀態壓縮（State Compaction），對循環運行歷史做摘要壓縮，讓每輪 Token 消耗平穩或遞減。動態模型路由說來簡單，實際操作時每個模型提供商都有不同 API 格式與金鑰體系，手動管理容易洩露且切換模型需改動配置。這正是 AI Gateway 這類工具要解決的問題。

ServBay 的 AI Gateway 在本地提供統一代理端點，將 Anthropic、OpenAI、Google 以及本地 Ollama 模型的請求收歸到一個入口，所有真實 API 金鑰加密儲存於本地機器。開發者可依專案簽發可獨立撤銷的虛擬金鑰，用量與花費在儀表板一目了然。對於循環工程落地，這類 Gateway 讓「把 Lint 檢查路由給低價模型、把架構決策路由給前沿模型」變得可操作，在一個入口切換模型不必更動工具配置。

配合 ServBay 內建的 MCP Server，代理可一邊透過 Gateway 按需呼叫不同模型，一邊透過 MCP 操作本地開發環境中的資料庫、Web 伺服器與域名配置，完整閉環於焉形成。ClaudeDevs 官方歸納了四種循環模式，自動化程度逐級遞增。回合制循環（Turn-based）是最基礎的形式，每次給代理一條指令，代理執行後按預定義驗收清單自查，通過後才提交結果。目標制循環（Goal-based）適用於多輪迭代的複雜任務，透過 /goal 設定可量化目標與最大重試次數，代理在後台反覆嘗試直到達標或觸及上限。

定時制循環（Time-based）適用於重複性日常事務，透過 /loop 設定巡檢間隔，將高頻低創造性工作轉為後台守護程序。主動循環（Proactive）是自動化程度最高的形態，結合事件驅動與多代理協作，系統監聽到新事件後自動啟動處理，可同時在多個隔離工作區產生多套方案，再由獨立審查代理擇優合併。循環工程的工具鏈目前雖然集中在程式領域，但其設計思路可遷移到任何包含重複性判斷的工作流程。

內容團隊可以搭建每天定時掃描行業資訊源、篩選選題線索、生成初稿摘要的循環；運維團隊可讓循環持續監控告警、自動執行預案、無法自動處理時升級到人工；客服團隊可用循環做工單分類與初步回覆，將需要深度溝通的對話路由給真人。這些場景的共同特徵是有明確輸入源、可定義處理規則、可驗證完成標準。循環工程改變了工作方式，但並未把人從流程中移除。隨著循環自動化程度提高，有三件事反而更加突出。驗證責任沒有轉移，無人值守的循環也是無人值守的犯錯，最終為品質負責的還是工程師本人。認知差距會加速拉大，循環產出程式碼的速度越快，工程師若未主動閱讀循環生成的程式碼，與系統之間的認知債務就會擴大。

舒適狀態是危險狀態，當循環自己就能跑出結果時，人容易全盤接受產出，不再形成自己的判斷。同樣使用循環，理解業務的人用它加速已經想清楚的工作，不理解業務的人用它迴避思考，產出質量會如實反映。Boris Cherny 的表述並非工作變輕鬆，而是關注點不同：設計循環比寫提示詞更難，因為它要求工程師對「完成」有精確定義能力，對失敗模式有預判，對成本有約束意識，對何時拉人介入有清醒判斷。循環工程仍處於早期階段，工具快速迭代，最佳實踐還在成形。但它指向的方向已經明確：AI 輔助程式設計正從人驅動每一輪對話，走向人設計系統、系統驅動對話。

想嘗試的開發者可以從一個小的回合制循環開始，為現有的 Claude Code 或 Codex 工作流程加上一份技能檔案與驗收清單，體驗循環帶來的效率變化，再逐步引入目標制循環與子代理驗證。工具在變，工程師的判斷力不會過期。