EP-79｜當 AI 開始有意識地工作：什麼是迴圈工程（Loop Engineering）
2026 年最熱的 AI 工作方式：你不再一句句指揮 AI，而是設計一套會自己啟動、執行、檢查、再迭代的系統。用六個工具和三個例子，帶你看懂什麼是迴圈工程。
在 2024 年的時候，傳統使用 AI 的方式就是你問一句、AI 答一句。
到了 2025 年，大家開始提倡「提示詞工程」（Prompt Engineering），其範疇包括：
指派角色讓 AI 扮演
幫 AI 設計固定產出的流程與格式
後期出現的專案規則與技能
到了 2026 年，又出現了一個更新的名詞，叫做「迴圈工程」（Loop Engineering）。
提到「迴圈工程」，我認為最著名的案例就是龍蝦（Openclaw）。
龍蝦有一個設計，叫心跳機制（Heartbeat）。
透過心跳機制，可以規定它大概每 30 分鐘，或者是每一小時自動啟動，去檢查是否有需要處理的事情。
比如說檢查目前的系統有沒有出錯；如果有，就進行修正。
所以這個機制跟傳統的提示詞工程（Prompt Engineering）有一個很大的不同。
過去可能是寫好一整套的提示詞，讓 AI 根據這些內容去做相對應的工作；而現在我們則是設法建立一個可以不斷迴圈的系統。
根據我們指派的工作，如果系統檢查到、或看到需要開始工作的時候，它就會自動進行相對應的處理。
迴圈工程需要的六個工具
負責 Google Chrome 的工程師 Addy Osmani ，認為迴圈工程大致上需要底下的這些工具：
自動化排程（Automations）：
讓任務不是你手動開啟，而是時間到了自己跑。
有許多 AI Agent 都已經有這個機制，比方說在龍蝦裡面可以設定排程，Claude Code 本身有一個 /loop 的機制，Codex 的桌面版也有一個自動化的按鈕可以設定。
工作樹（Worktrees）：
Git 的一個功能，讓好幾個 AI 代理（agent）各自在獨立的程式碼副本上工作，不會同時改到同一個檔案打架。
技能（Skills）：
基本上就是 SOP，把專案的規則、常見判斷、操作慣例寫成文件，讓代理每次都照同一套標準做事。
外掛與連接器（Plugins and Connectors）：
讓代理能接到外部工具，例如 GitHub、資料庫、任務管理板。
子代理（Subagents）：
把工作拆給不同角色的代理，一個負責寫程式，另一個負責檢查。
你也可以針對不同的角色分配不同的語言模型。
例如有人會說 Claude 的模型比較適合寫程式，Codex 或是 ChatGPT 的模型則比較適合除錯。當然，這就是依照個人的使用經驗去做不同的分配。
像我個人最近私底下有一個 Side Project 在寫修仙小說，我就指派 DeepSeek 來擔任主筆，因為如果你叫 Claude Code 去寫的話，它的中文程度真的是很爛。
外部狀態與記憶（External State / Memory）：
把進度寫到對話以外的地方，例如一個純文字筆記檔（Markdown）或一塊任務板，這樣迴圈跑很多輪也不會忘記自己做到哪一步。
我的 Hermes Agent 就有這樣的機制。他在被指派任務的時候，會先將要做的事情寫下來，寫成 To-Do List，然後再依照完成的進度去劃掉清單上的項目。
範例一：每天自動修程式的迴圈
假設一家軟體公司，每天晚上電腦會自動把大家寫的程式跑一輪測試，看有沒有哪裡壞掉。這套會自動跑測試的系統叫 CI（持續整合，Continuous Integration）。
然後昨天半夜，它測出有個地方壞了。
傳統做法是，你早上進公司打開 Claude Code，一句一句問它。先問「昨天為什麼壞了」，它回答後，你再說「好，修復這個 bug」。
修完，你再說「再跑一次測試」，終於成功了，你再說「幫我整理成一份修改說明送出去」。
上述每一步都要你開口，AI 等於是你的工讀生嘛，你說一動，他才做一動。
迴圈的做法是，你先把這整套流程寫成會自己執行的小程式，設定每天早上自動啟動。它一啟動就照著固定步驟跑一圈：
自己去讀昨天測試壞掉的紀錄
判斷哪些是它有把握修的
開一個獨立的工作空間，不會動到同事正在改的程式
派一個代理去修，再派另一個代理檢查修得對不對
重跑一次測試
測試過了，就自動把修改整理好、送出去等人核准
沒過，就把原因寫進一份紀錄檔
若測試多次都是失敗的，就通知人類，讓人類介入
範例二：用 Codex 的 /goal 設一個會自己驗收的迴圈
如果你不是工程師，但想要趕快來體驗一下什麼是迴圈工程的話，其實你可以使用 OpenAI Codex 。
Codex 有一個 /goal 指令，很類似「迴圈工程」。你不是每一步都下提示詞（prompt），而是先設定一個有驗收標準的終點。
官方文件的說法是，目標（Goal）是 Codex 的持久任務，會包含三件事：
什麼算完成
怎麼檢查成功
過程中哪些限制不能破壞
例如說，你可以下這樣的指令：
/goal 修好登入流程裡時好時壞的測試，直到所有登入測試都通過，而且程式碼檢查沒有錯誤
設好之後，Codex 會自己檢查程式、修改、跑測試、再修正，直到達到條件，或是遇到它判斷需要你出手的地方才會停下來。
範例三：每天早上自動生出電子報草稿的迴圈
迴圈不是只能拿來寫程式，內容整理也可以。
我現在寫電子報的流程其實是屬於「單線性」的。我設定了許多的技能，流程如下：
構思與資料蒐集： 每次要寫電子報時，我會先思考這週的主題，並找好相關資料。
AI 協作撰寫： 資料找完後，我會丟給 AI。它會按照我預先設定的技能，幫我整理檔案並寫成文章。為了保持「人的味道」，我只會讓 AI 負責技術面的內容，其餘部分則由我親自撰寫，且技術內容我也會再順過一次。
圖文發布： 文章完成後，我會啟動另一個技能產生圖片。確認圖片與文字都沒問題後，系統就會自動發布到 Substack。
這些步驟都已經跑順並設定成技能，但目前仍是單線式的操作。所以最近我在想，是不是可以讓我的 Hermes Agent 更進一步？
我希望它每週自動檢查我在 Threads 上的發文，看看哪幾張我製作的圖卡相對受歡迎，接著直接擷取受歡迎的主題，自動擴展成一份電子報。
理想的流程是：Hermes Agent 每天定時通知我電子報草稿已經寫好了。我去確認一下，如果覺得可以，或是修改完細節後，只要說一聲：「好，就這樣，直接執行吧。」這整個流程就能幫我省下更多時間。
你想跟一群人一起把迴圈搭起來嗎
AI 的世界每天都有新名詞，例如本週提到的迴圈工程，一個人追很容易漏掉。
我現在逐步透過人工以及 AI 自動化的方式，把每天發生的 AI 新知，整理進「社畜進化論｜Raven AI」這個社群。
如果你不想一個人慢慢摸，想有一群人一起把這套東西搭起來，進來看看會比較快。