六月初（6/4），我才剛寫完一篇關於 Anthropic《When AI builds itself》的觀察文，質疑那個「AI 打造自己」的遞迴迴圈到底 Is it good。
結果才過幾天，這個迴圈就有了正式名字——Loop Engineering。
而且還爆了。
發生了什麼事？
6 月 7 日，Google Chrome 工程主管 Addy Osmani 在 Substack 發表了一篇定義性長文。幾乎同時，Peter Steinberger（OpenClaw 創作者，現在在 OpenAI）在 X 上丟了一句話，6.5 million views：
“You shouldn’t be prompting coding agents anymore. You should be designing loops that prompt your agents.” （你不應該再自己去下提示詞給程式編寫 agents了。你應該設計會對 agents 下提示詞的迴圈。）
Anthropic 的 Boris Cherny（Claude Code 負責人）也在演講中講了類似的話：
“I don’t prompt Claude anymore. I have loops running that prompt Claude and figure out what to do. My job is to write loops.” （我不再自己對 Claude 下提示詞了。我有迴圈在跑，由它們去對 Claude 下提示詞、決定該做什麼。我的工作是寫迴圈。）
三個大廠的人同時指向同一件事：別再自己打提示詞了，設計一個系統去幫你打提示詞。
全網炸開。2,200+ 篇討論、GitHub repo、教學文、批評文、還有人開始賣課了。
（嗯，每次新詞一出來，課程就跟著出來，這個 loop 倒是蠻穩定的⋯⋯XD）
所以 Loop Engineering 到底在做什麼？
把過度的包裝剝掉，Loop Engineering（迴圈工程）的核心概念其實很簡單——
你不再一個一個 prompt 地跟 AI 對話。你寫一個程式（可以是 shell script、可以是幾百行 TypeScript），讓這個程式去驅動 AI agent。它自己找任務、自己執行、自己驗證結果、自己決定要不要再跑一輪。
用 Osmani 的話來說：「Loop engineering is replacing yourself as the person who prompts the agent. You design the system that does it instead.」（Loop engineering 就是讓你不再是那個對代理下提示詞的人。你設計一個系統來代替你做這件事。）
聽起來很厲害對吧？
但等一下。仔細想想，這不就是一個 while loop 加一組 checklist 嗎？
while (驗證未通過) {
AI 生成結果
跑驗證
如果沒過 → 回饋錯誤訊息，再跑一輪
}
技術上，就這樣。
為什麼會爆紅？
如果本質這麼簡單，為什麼引起這麼大的討論？我觀察到幾個原因——
第一，痛點夠普遍。 2025-2026 年，大家都在用 AI 寫 code 了。但寫完之後的 review、修正、來回調整還是靠人手動跑。Loop engineering 把這個「AI 寫完之後的苦工」命名了，給了大家一個可以抓住的框架。
第二，成本降下來了。 Loop 天生比單次 prompt 貴很多——每多跑一輪就燒一次 token。2025-2026 年 token 成本大幅下降，讓這種做法在經濟上終於算得過來。
第三，說話的人夠大咖。 Google 的工程主管、Anthropic 的產品負責人、OpenAI 體系的人。三個大廠同時講同一件事，市場當然會聽。
第四，焦慮驅動。 那些覺得自己「只會 prompt」的工程師，突然被告知有個新的「必修技能」。不學就落伍了。這種焦慮最容易推動傳播。
但我個人看法是——大家真正興奮的，其實不是什麼新範式。是終於找到方法，把最煩的雜活丟掉了。
爆紅的情緒底層是解脫感，不是興奮感。
三層結構：Loop 只佔了三分之一
把 Loop Engineering 的實際運作拆開來看，其實是三層：
| 層級 | 做什麼 | 誰來做 |
|---|---|---|
| 第一層 | 定義驗證條件——什麼叫「做對了」 | 人（純人的判斷） |
| 第二層 | 把驗證條件寫成 Unit Test | 人機協作 |
| 第三層 | AI 生成程式碼，用 Unit Test 驗證，不過就重跑 | Loop（自動化） |
Loop Engineering 真正自動化的，只有最底下那層。上面兩層才是真正決定品質的地方，而且越往上越不可自動化。
有沒有覺得這個結構很眼熟？
沒錯，這就是 TDD（Test-Driven Development，測試驅動開發）——先寫測試、再寫程式碼。軟體工程教了幾十年的東西。
差別只是第三層的執行者從人變成了 AI。骨架沒變，變的只是誰在敲鍵盤。
所以 Loop Engineering 與其說是新範式，不如說是 TDD 終於找到了它理想中的執行者——一個可以不厭其煩跑到測試全過為止的 agent。
（TDD 的推動者們等了二十年，大概沒想到最後實現這個夢想的不是工程師的自律，而是 AI 的不知疲倦⋯⋯Orz）
聽起來不錯啊？問題在哪？
問題一：答案只有一種的時候才能跑
Loop 的驗證器（verifier）本質上是一個篩選器——它只認得出符合預定義標準的答案。測試全過、型別正確、效能達標。
但真正厲害的解法，常常是 verifier 根本不會認可的東西。
舉例：一個效能問題，正規解法是優化演算法複雜度。但有經驗的工程師可能直接改資料結構、繞過整個問題，甚至發現「這個功能根本不需要」。這種解法不會通過原本設計的測試，因為它重新定義了問題本身。
Loop engineering 只能在既有框架內搜尋最優解，不能跳出框架。迴圈跑得越順，反而越容易鎖死在正規路徑上。
問題二：AI 改自己的考卷，真的沒問題？
這是更根本的問題。
有人很精準地講了一句話：「A model grading its own homework always gives itself an A.」（一個模型改自己的作業，永遠都會給自己打 A。）
就算用了所謂的「獨立 verifier sub-agent」，底層還是同一家的模型、同樣的訓練資料、同樣的偏見結構。你換一個 Claude 來 review 另一個 Claude 的 code，它們的盲區是高度重疊的。
就像同一間補習班出來的學生互相改考卷，改得出格式錯誤，改不出思路本身的問題。
（咦，我上一篇文章也用了這個比喻⋯⋯看來這個 loop 不只 AI 會跑，我自己也在跑 XD）
更危險的是信心堆疊——跑了五輪 loop 全部通過，人類看到就覺得「驗了這麼多次應該沒問題」。但如果每一輪的驗證都有同樣的盲點，五輪等於零輪。甚至比零輪更危險，因為多了虛假的安心感。
那有什麼修正方向？大概兩條路——
一、用不同家的 AI 交叉驗證。 Claude 寫、GPT 驗。兩家模型的訓練資料不同，盲區重疊的機率降低。但它們在高層邏輯上可能犯同類型的錯，異質性有，但沒有人跟 AI 之間那麼大。
二、把驗證寫成硬程序。 Unit Test、type check、lint——過就是過、沒過就是沒過，不存在模型偏見。但代價是你必須事先知道要驗什麼，寫得出測試的部分才能自動化。
最實際的組合可能是：硬驗證為主幹，異質 AI 補縫隙。但不管怎麼組合，誰來定義「要驗什麼」這個設計決策本身，不能放進 loop 裡面——因為它是 loop 存在的前提。
問題三：大系統才需要，小專案划不來
一個人做一個小專案，直接跟 AI 對話、看一看、改一改，十分鐘搞定。你要先寫驗證條件、再寫測試、再設 loop 讓它自己跑——光是架設這套系統的時間就比直接寫 code 還長。
Loop engineering 有意義的前提是重複執行的成本大於架設系統的成本。
這只有在兩種情況下成立：系統夠大，同樣的驗證流程要跑幾百次；或者團隊夠多人，需要一致的品質標準來取代每個人各自判斷。
說白了，就是企業級的需求。
推這個概念的人都是誰？Google 的工程主管、Anthropic 的產品負責人、大型開源專案的維護者。他們面對的是幾十個工程師同時在提 PR、CI 每天跑幾百次的場景。在那個規模下，loop engineering 是剛需。
但爆紅之後傳播到的受眾大部分不是這種人。獨立開發者、小團隊、剛學 Vibe Coding 的人——他們的瓶頸根本不在驗證自動化，而是在「怎麼跟 AI 把東西做出來」。
對他們推 loop engineering，就像對騎腳踏車的人推自動駕駛系統。
更深的矛盾：Loop 會吃掉自己的使用者
這裡出現了一個結構性的自相矛盾——
Loop engineering 的價值主張是「大型團隊需要它來提升效率」。但它提升效率的方式，就是把人從迴圈裡拿掉。
一個 50 人的工程團隊，每天有大量的 PR review、CI 修復、測試補齊。導入 loop engineering，這些事自動化了，生產力提升了。然後管理層會問一個很自然的問題——既然 loop 在跑了，我還需要 50 個人嗎？
Anthropic 自己公布的數據是工程師日均產出為兩年前的 8 倍。8 倍產出不代表需要 8 倍的人，代表的是同樣的事只需要八分之一的人。
Loop engineering 最需要被導入的地方，正好是它會造成最大衝擊的地方。
而且人力結構的衝擊不是均勻的。
能寫出完整驗證條件的人——要懂系統全貌、知道邊界情況在哪、理解什麼會壞。這是十年以上經驗累積的東西。
被 loop 取代掉的工作——寫功能性 code、修 bug、補測試、處理 PR。這些正好是初階和中階工程師的主要工作內容，也是他們累積經驗的途徑。
所以 loop engineering 把學習的階梯抽掉了。以前你從初階到資深，靠的就是大量寫 code、大量踩坑、大量被 review。這些事現在交給 loop 跑了。初階工程師沒有機會透過實作去理解「為什麼這樣會壞」，他就永遠寫不出好的驗證條件。
而資深工程師呢？他本來管五個人，現在管五個 loop。但 loop 出問題的時候，沒有中階的人可以幫忙排查。所有的判斷壓力集中在他一個人身上。
最後會變成一個斷層：現有的資深工程師撐著整個系統，但沒有下一代接班。等這批人退了或燒光了，就只剩 loop 在跑——而沒有人真正理解 loop 在驗什麼、為什麼這樣驗。
回到那個問題：Is it good？
上一篇文章裡，我指出 Anthropic 的 遞迴式自我改進（recursive self-improvement）本質上是一個「效率的效率的效率」的迴圈——它在迭代「怎麼做得更快」，但沒有在迭代「該不該做」「做完之後世界會怎樣」。
Loop Engineering 就是那個迴圈的工程實踐版。
它把「AI 寫 code → AI review → AI 決定下一輪」這個結構標準化了、命名了、寫成了方法論。然後全網歡慶。
但我在上一篇文章裡拆過「創意」這兩個字——「創」是傷、是割開，「意」是意料之外。Loop engineering 的設計邏輯恰好是把這兩個都消滅。每一輪的驗證都在說：不要意外、不要破壞、跟上一輪一樣但更好。
它不是在做壞事。它是在做一件方向非常特定的好事——讓可定義的目標被更有效率地達成。
問題是，當整個產業都在歡慶這個方向的時候，沒有人在問：這個方向之外的東西怎麼辦？
那些目標不可定義的任務、那些需要重新定義問題的時刻、那些答案不只一個的場景、那些「看起來怪怪的但可能是突破」的離群值——在 loop engineering 的框架裡，這些全部會在第一輪就被 verifier 篩掉。
而且跑得越順暢，越不會有人覺得需要停下來想一想。
簡單來說
Loop Engineering 不是什麼新範式。它是 TDD 找到了不會抱怨的執行者，是 code review 找到了不會請假的 reviewer，是企業級 QA 自動化套了一個比較有吸引力的名字。
在它適合的場景裡——大型系統、多人團隊、目標明確、驗證可自動化——它確實解決了真實的痛點。
但它的適用範圍，比它的聲量窄很多。而它可能帶來的結構性影響——人才斷層、判斷力外化、創新路徑收窄——比它承諾的效率提升深遠得多。
上一篇文章我問的是：「When AI builds itself — Is it good？」
這篇的答案可能是：Loop Engineering 讓那個 “builds itself” 跑得更順了。但 “Is it good” 這個問題，依然沒有被放進任何一個 loop 裡面。
而能問出這個問題的，目前還是人。
那就別急著把問這個問題的位置，也自動化掉了。
（不然到時候 “Is it good?” 會被驗證器 判定為 not a valid test case（不是有效的測試案例）然後直接 skip 掉⋯⋯那就真的 Orz 了）
本文為《“When AI builds its self.” Really? Is it good?》的延伸觀察。
原始討論觸發點：
Addy Osmani「Loop Engineering」(Substack, 2026/6/7)、
Peter Steinberger (X, 2026/6/8)、
Boris Cherny (Anthropic Claude Code)
