迴圈工程（Loop Engineering）是什麼？我拿 2026 年的檢查清單審自己那條剪片產線，7 項對到 5 項

團隊裡負責校對的那一棒把逐字稿的 cloud 改成 Claude、低落改成 B-roll，我核准了。剪輯那一棒跑完，字幕上還是 cloud 跟低落。

整輪校對，一個字都沒有進成品。

原因不是剪輯故意無視。是沒有人告訴它前面有校對這件事，那支程式的字幕一直都是把剪好的影片重新辨識一次生出來的，它從頭到尾沒讀過任何外部逐字稿。以前不會出事，因為以前沒有校對那一棒。

這件事發生在 2026 年 8 月 5 日。我當時的修法是加一份交接合約，寫清楚每一棒收誰的什麼、交出什麼。三週後我才意識到，那份合約本身就是整套設計裡最脆弱的一環。

—

事情的起點是有人問我：你那條剪片產線，算不算 loop engineering。

我先去查這個詞現在的主流說法是什麼，查完發現它是真的在流行，但還沒有一篇公認的聖經級文獻。目前是大廠開了主題頁、兩篇原文帶起討論、加上一堆二手整理的狀態。我讀的四個來源裡，有一份 2026 年的完整指南、一篇 7 月 2 日的 arXiv 論文、一篇入門短文，還有一個大廠主題頁（那頁在我這邊回 403，只拿到搜尋摘要，算二手）。

先講主流怎麼定義。

迴圈工程的標準流程是六步：推理、行動、觀察、更新狀態、驗證、重複或停止。它接在提示詞工程（2022 到 2024）與脈絡工程（2025）後面，2026 年成為主流說法。核心差別是人的位置：從對話框裡下指令的人，變成設計迴圈的人。

六步裡真正決定成敗的是第五步。有一句被引用很多的話是：迴圈的好壞只等於它拿到的回饋的好壞。換模型不會救一個爛迴圈，驗證方式設計不對，模型再強也只是更快地跑向錯的答案。

驗證方式的高下很明確。程式判的檢查最強，測試、型別檢查、編譯器、量出來的數字，這種驗證不給面子也不會被說服。另一個模型當評審次之，前提是評審要有自己乾淨的視野。最弱的是叫模型自己檢查自己，實測上它抓不到自己的錯。

另外還有一份六個失敗模式的清單：脈絡塞爆、原地打轉、鑽分數漏洞、假裝做完、錯誤滾雪球、燒錢失控。

—

我把驗證員階梯加上這六項，湊成 7 項，拿去逐項審我自己那條產線。

那條產線是剪口播影片用的，9 棒接力，從前置、逐字稿辨識、語意校正、流量操盤、剪輯、中場審查、運鏡、B-roll 到動畫。審查卡在第 5 棒，跑的是程式，回傳 0 是過、1 是退回。

用 7 項迴圈工程檢查清單審 9 棒剪片產線的結果：5 項對上（驗證員是程式判的、避開原地打轉、避開假裝做完、避開錯誤滾雪球、每輪成本受控），2 項沒對上（沒有硬性次數上限、迴圈不會跨場學習）。脈絡塞爆那一項不適用，因為這是程式管線不是長對話。

先講對上的五項。

驗證員站在階梯最頂端。中場審查量的是能量剩幾成、字幕一秒鐘要看幾個字，門檻是 6.5 警告、8.5 退回，拿我自己的片子校出來的，不是抄來的數字。這一項是整條產線最值錢的地方，因為它不需要任何人有判斷力，只需要它會算。

原地打轉被規則堵住了。退回不限次數，但每次退回必須換一招沒用過的，而且用過哪幾招會寫進紀錄檔。這條看起來比「不限次數」不重要，實際上反過來，大部分迴圈就是死在同一招修兩次。

假裝做完被結構擋掉。過不過是回傳碼決定的，不是哪一棒自己說了算，沒有那份審查紀錄就不准往下走。

錯誤滾雪球那一項，是我事後回頭看才發現當初做對的。

—

審查閘原本排在第 6 棒，2026 年 8 月 8 日我把它往前移到第 5 棒。

移的理由是實跑量出來的。第 6 棒是運鏡，做的是推鏡跟運鏡的排程，它根本不動時間軸：影片進去 34.57 秒，出來還是 34.57 秒。既然這道閘管的是長度跟位置，不動長度的東西就沒有理由排在它前面。

審查閘從第 6 棒前移到第 5 棒的實測理由：運鏡不改長度（影片進出都是 34.57 秒），排在閘前每次退回都要白重排一次，每次約 40 秒；那次審查退回兩輪就白燒兩次。更危險的是退回只重跑出問題的那一棒，運鏡不會跟著重跑，審查員讀到的是過期資料，會拿舊檔案審完回報通過。

第二個理由比省時間重要得多。退回的規則是只重跑出問題的那一棒，不整條重跑。但運鏡吃的是剪輯的產出，剪輯被退回重做之後，運鏡不會跟著重跑，它的排程檔就過期了。而審查員只讀那個檔、不比對影片，會拿舊資料審完，然後回報通過。

那就是清單上的假裝做完，而且是最難發現的一種：沒有人說謊，是資料本身過期了。

移到閘後，這個競態從結構上就不存在，剪輯定案了才排運鏡。這也是我對「閘要放哪」的答案：放在最後一個改起來還便宜的位置。過了那個點，時間軸鎖死，後面只能疊不能改。

第五項是燒錢，只能算半對。退回只重跑出問題的那一棒，所以每一輪的成本壓得很小。但那是省每一輪的錢，不等於限制總輪數。

—

沒對上的兩項，都不好看，但寫出來比較有用。

第一項是沒有硬性的次數上限。我的規則寫的是不限次數，靠「修法清單上的招全試完」當停止條件。清單有限，所以不會真的無限打轉，但那是間接的。主流的說法是停止條件要直接而且要疊好幾層：驗證員判過、總輪數上限、花費或時間上限、無進展偵測。我只有第一層跟半層。

那份指南裡提到一個被廣傳的事故，一個文件處理的代理人整夜卡在重試，八小時燒掉 437 美金才被發現。這個事故我沒查到原始出處，當警示看就好，但它指的那個洞我確實有。

第二項是迴圈不會跨場變聰明。退回紀錄是每支影片各自一本，剪下一支從零開始。哪一招最常有效、哪一招從來沒救過，這些資料現在是丟掉的。主流清單裡有一種迴圈是會把失敗寫成教訓存起來、下一輪帶著教訓再做的，我有做到單場的版本，跨場的沒有。補法很清楚：做一份全域統計，讓修法清單照命中率自動排序。

—

最後講一件那四份資料都沒講清楚的事。

它們都很強調要有驗證員、要有回饋、要有停止條件，但沒有講「宣告層不等於執行層」。

開頭那個 cloud 沒有變成 Claude 的事故，我當時的修法是寫一份交接合約，白紙黑字寫清楚每一棒收誰的什麼。合約寫完的當下感覺問題解決了。實際上沒有：宣告會被忽略，那天就是實例，因為出事的那一棒根本不知道有另一棒的存在。

真正解決它的不是那份合約，是後來配上去的機器稽核，由第 5 棒的審查自動跑，對不上就退回。

所以我會在那六步後面自己加一條：任何寫成規則的東西，都要有一個不靠人記得的檢查在後面接著。規則是宣告，檢查才是執行。這一條在迴圈工程的文章裡我沒看到，但它是我這條產線上最貴的一個教訓。

—

拿別人的清單審自己的東西，最大的收穫不是拿到分數，是發現有些事我做對了卻不知道為什麼。閘的位置我當初是為了省 40 秒才移的，審完才知道它同時擋掉了整份清單上最貴的那個失敗模式。