多數公司用 AI 的方式，還停在派任務。開一個對話、講一句、看它做完、再講下一句。滿意了關掉視窗，明天再開一次、再講一次。省下來的時間是真的，但省的方式很像請了一位很強的臨時工，每天教一次，每天從頭教。
換一種做法，時間才會累積：不再告訴系統「現在做這件事」，而是一次寫清楚三件事，什麼叫做完、什麼時候該啟動、能碰到哪裡為止。然後讓它自己跑、自己檢查，撞到邊界才回頭找你。業界把這種設計方式叫迴圈工程（Loop Engineering）。名字聽起來遠，做起來很近。
舉個現場。一家做居家用品的公司，行銷每週一早上要看三個競爭對手有沒有出新內容、有沒有調價、有沒有換主打訴求。過去是有人開電腦、開三個分頁、複製貼上、整理成一封信寄給老闆，一小時起跳。改成迴圈之後，那件事變成一段寫死的規則：每週一早上八點啟動，比對那三個網址與上週的紀錄，只列出有變動的部分，每一條都附原始連結，沒有變動就回一句「本週無異動」，連續三次抓不到資料就停下來說一聲。
沒有人再去開那三個分頁。有人在做的，是每季回頭看一次那段規則還對不對。
01一段跑得動的迴圈，只有三個零件
第一個零件是目標，什麼叫做完。
這是最多人寫錯的地方。多數人下指令的方式是描述過程：「幫我看一下競品有沒有更新，整理給我。」聽起來很清楚，實際上沒有終點。整理到什麼程度算好？漏掉一家算不算失敗？沒有答案，系統就只能猜，猜錯了你再補一句，補到最後你花的時間跟自己做差不多。
工程圈把這件事講得很直白：不要告訴 AI 怎麼走，告訴它到哪裡才算完成。判準也很好用。陌生人拿到成果，能不能自己判斷這件事做完了沒。答得出來，才叫目標；答不出來，那還是一句願望。
第二個零件是觸發器，什麼時候啟動。
按時間跑，每週一早上、每月五號結帳前；或按事件跑，客戶來信進了某個信箱、某張表新增了一列。這一格看起來最技術，其實是最不技術的：它問的是你公司裡哪些事有固定節奏。做了十年生意的老闆，這題答得比誰都快。
第三個零件是邊界，能碰到哪裡為止。
邊界有兩半。一半是範圍：能讀哪些資料、能改哪些檔案、絕對不准動哪一區。另一半是停止規則：失敗幾次就停、最多跑幾輪、花超過多少就回報。這一半最常被略過，也最貴，下一節會專門講。
目標、觸發器、邊界。三格寫滿，那件事就從「你每次要交代」變成「它自己會跑」。三格缺一，它就會跑偏，或者一直燒錢。
02不是寫程式的人，才最需要這件事
這幾年談迴圈的文章幾乎都出自寫程式的場景，這是它推廣不開的主因。老闆看兩段就覺得「這不是我的事」。
實際上最好落地的，反而是那些每週重複、有明確產出、沒人想做的營運雜事。有一份整理了二十五個迴圈工作流的清單，跟寫程式無關的佔了大半：
- 每週固定比對三個競爭對手的頁面，只回報有變動的部分。
- 把進來的信分成「要老闆看」「照舊回覆」「先擱著」三類，附上判斷理由。
- 結帳前把該備的資料撈齊、把對不上的項目挑出來，人只處理那幾筆。
- 發票到期未付就草擬提醒信，寄不寄由人按。
四件事的共同點很明顯：重複、有終點、對錯看得出來，而且沒有人喜歡做。另一份整理把適用條件寫成四條：會重複、驗收能自動判定、成本扛得住、手上有工具接得到資料。四個缺一個，就先別急著設。
「這不就是排程加自動化的新名字嗎」這個質疑在工程社群裡一直有人提，而且不算冤枉。定時任務、工作流、回饋機制，這些東西存在很久了。真正變新的只有一件事：以前每一步要做什麼都得由人事先寫死，現在中間那段可以交給模型判斷，人只負責把終點與界線寫下來。所以與其爭名字，不如看你手上那件事，中間那些判斷，是不是原本非得有人坐在那裡不可。
03會踩剎車，才叫做得起來
迴圈最強的地方是它會一直跑。最危險的地方，也是它會一直跑。
官方文件把定義寫得很乾脆：迴圈就是系統一輪一輪重複執行，直到觸發停止條件。整句話的重量全壓在後面那四個字上：停止條件。少了它，兩種代價會找上門。
第一種是錢。沒有設上限的迴圈會燒穿預算，實測上多跑四倍用量是常態，多個系統互相呼叫時甚至到十五倍。這筆帳不會有人通知你，只會出現在月底帳單上。
第二種更難察覺：系統會陷入「看起來有進展、其實原地打轉」的狀態。同一份檔案改了七遍，每一遍都回報「已優化」，七遍加起來沒有比第一遍好。更麻煩的版本是它把一個錯誤方向越做越完整，完成度很高，方向從頭到尾是錯的。
所以動手之前先設三道閘門：
完成條件要機器判得出來 「客戶名單全部比對完、零筆缺漏」是條件，「整理得不錯」不是。
硬上限 最多跑幾輪、最多花多少，到頂就停。
無進展偵測 連續幾輪都碰同一批資料卻跑不出新結果，就強制停下來回報。
三道都不難寫。難的是承認：一個沒有剎車的系統，強大跟危險是同一件事。
04三種事，永遠不要讓它自己做完
還有一個更早的問題：這件事該不該設成迴圈。
有經驗的估算是，真正適合自動循環的任務只佔三到四成。快速問答、創意發想、主觀取捨、需要現場判斷的決定，這些都不該塞進迴圈。技術上做得到，但這些事沒有一個陌生人也認得出來的終點。定義不了完成，就繼續用對話的方式做，那不丟臉。
適合的那部分裡，還要再分一次顏色：
綠燈 只讀寫自己的資料，可以整段放手。監看、比對、整理、彙總都在這一區。
黃燈 系統草擬、人按送出。提案初稿、回覆草稿、報表註解。
紅燈 永遠不要獨自執行：動到錢的、動到正式環境的、直接對外送出的訊息。
紅燈那三樣沒有例外可談。那三件事一旦出錯，賠的成本跟省下來的時間完全不對稱。前面談過那隻管不動的龍蝦，問題從來不在牠會不會做事，在有沒有人替牠畫過這條線。
你的角色，從派工變成定義迴圈
另一篇談過模型外面那一層：權限、驗收、記憶、編排。那才是你真正擁有的東西。這裡談的是同一件事的動詞版本，那一層具體怎麼被用起來。
答案是少下指令。
過去 老闆的時間花在交代事情、追進度、確認做完了沒。
現在 那些時間該花在更前面一步：把哪些事值得跑、跑到哪裡算完、撞到什麼要回頭問人，一次寫清楚。
這件事聽起來像技術活，做起來全是管理判斷。哪些工作有固定節奏、哪些錯誤賠得起、誰有權簽字放行，沒有一題是模型能替你答的。而寫下來的那份規則，跟提示詞不一樣：它不隨模型改版蒸發，換工具的時候帶得走，新人接手看得懂。
也別把它當成永久建物。節奏會變、資料源會改、模型會多出原生能力，當初為了補洞寫下的規則就該退役。定期回頭看一次那幾段規則還對不對，是這件事的維護成本。比你想的低，但不是零。
設計能被信任，技術能被理解。迴圈跑得動不算本事，跑得動又剎得住才算。
為品牌築根，為數位開路。