在早期的 AI 協作模式中，我們非常習慣扮演「肉身除錯機」的角色。AI 吐出一版程式碼或文章，你複製到本機執行一下，發現壞了，於是你把錯誤 Log 複製起來貼回對話框，命令 AI 改一版。AI 改完，你再複製、再執行、再貼回。
這種由人類親自站在迴圈中間，用肉身與時間提供回饋的模式，被稱為 Human-in-the-loop（人類在環）。
然而，到了 2026 年初，隨著大語言模型推理能力的爆發，以 Google 軟體工程負責人 Money、Peter Steinberger 等人為代表的頂尖專家，正式提出了一場顛覆性的範範移轉：Loop Engineering（循環工程）。其核心哲學只有一句話：「你不應該再親手為 coding agent 寫 prompt 了，你應該設計一個自動化的 Loop，讓這個 Loop 去 prompt 你的 agent。」
我們必須將「人類給回饋」這件事徹底標準化，推動從 Human-in-the-loop 到 Agent-in-the-loop（代理在環） 的革命。
自我修正閉環
先跑測試或檢查。
把錯誤訊號轉成 Context。
針對證據修正。
重跑驗收，直到通過或熔斷。
實戰步驟一：理解 Loop Engineering 的核心精神：從人肉點擊到自主迴圈
要擺脫繁瑣的重複微管理，你必須在思維與日常操作上進行兩大翻轉：
將你的審查與除錯邏輯「徹底標準化」：以前 AI 寫錯時，你大腦是怎麼判斷的？你會去看測試有沒有過、去看網頁載入時間有沒有低於兩秒、去核對專有名詞有沒有寫錯。這些大腦判斷對錯的規則，本質上都是可以被翻譯成代碼或明確規則的。Loop Engineering 要求你把這些審核邏輯寫成自動化的測試指令（Unit Tests / Linters）或 AI Judge 評分規則，直接丟給系統去跑。
讓 Agent 在背景自主推動循環：你不再是每一輪對話的「搬運工」。在 Loop Engineering 架構下，你一開始只需對 Agent 下達高階目標，隨後它便會自動開工、自動改程式、自動跑測試、自動閱讀報錯 Log，並根據失敗點在背景不斷自我疊代。它不需要不眠不休地折磨你，而是在背景默默幫你跑完 5 輪、10 輪的自我重修，直到符合你定下的標準，才輕鬆敲你的大門：「報告主管，我自我修復完成了，這是通過所有測試的最終代碼」。
實戰步驟二：設計自我修復與診斷機制：建置自動化的 Test-Read-Fix 閉環
要在你本地的開發環境中真正跑起一個自我修復的 Agent-in-the-loop，請落實以下實作步驟：
建立「測試與斷言」的防線：在動工前，命令 AI 先寫好對應功能的測試腳本（TDD 模式）。這段腳本是確定性的：如果功能正確，腳本執行應回傳 status；如果功能錯誤，應拋出明確的 exception 與錯誤代碼。
配置 Harness 自動化捕捉與重新引導：在你的協作環境（如 Cline 或 Codex 的自定義腳本）中，設定一條自動化規則。當 AI 執行 git commit 或表示完工時，環境會自動觸發測試腳本：
如果成功：放行，完成任務。
如果失敗：系統拒絕 commit，並自動執行：cat error.log | pbcopy（或底層自動讀取），將當前的 traceback 與 stdout 直接餵回給 Agent，並附加指令：「測試失敗，請閱讀此 Traceback，重新修改代碼，並再次執行測試，直到通過為止」。這套 Test-Read-Fix 閉環 能在不干擾人類的情況下，自主幫你把代碼的初稿品質，直接拉升到無痛開箱的 85 分高水準！