Prompt該退環境了，未來屬于Loop Engineering。

最近，AI行業又出現了一個有趣的新詞。

Loop Engineering。

如果你關注AI這個領域的話，這兩天應該都會刷到。

推特在刷，各種社媒也在刷，群里也有蠻多人在討論。

事情是這樣的。

6月7號，OpenClaw的創始人Peter發了一條推，非常的簡短，但是直接就爆了。

翻譯過來意思就是：你不再需要為編碼智能體編寫提示詞了，你應該設計循環來提示你的Agent。

這個循環，其實就是loop的意思。

而在這之前幾天，Claude Code的創始人老哥Boris在一個開發者大會上也說了差不多的話。

他的原話大概是，我不再手動給Claude寫提示詞了，我運行著能讓Claude自動編排任務的循環，我的工作，就是編寫這些循環機制。

也就是，寫loop。

這兩個人呢，說了同一件事。

然后Google的Addy Osmani緊接著發了一篇長文，把Loop Engineering這個概念正式梳理了出來。

于是，繼Prompt Engineering、Context Engineering、Harness Engineering之后，AI行業的第四個逐漸形成共識的Engineering，就這么誕生了。

我其實是個特別不喜歡造新詞的人，但是很多時候， 造詞這事我覺得還是得分兩種情況，有一種我覺得就是為了炒概念，比如xxx 4.0。

而有的時候，真的只是行業太快，人們更需要一個精準的表達來幫助自己表達而已。

Loop Engineering我覺得就是后一種。

而且，這個東西跟我自己一直使用Agent的方法、一直在鼓勵大家做的事，是高度吻合的。

如果你看過我之前寫的那篇Harness Engineering的文章，你大概能理解一些我的感覺。

那篇文章里我聊了從Prompt到Context到Harness的三次躍遷，聊了馬具和韁繩的比喻，聊了約束先行。

而Loop Engineering，其實就是在Harness之上，又往上走了一層。

把一個套馬的韁繩，變成了全自動工業流水線。

很有《文明》里時代的進化的感覺。

給大家舉個例子。

比如說，以前你用Claude Code寫代碼，流程大概是這樣的。你給它一個任務，它寫完了，你看一眼，覺得不太對，你再給它提一個修改意見，它改完了，你再看，再提意見。

整個過程你會發現，是坐在設備前的，一輪一輪的，你說一句它回一句，你就是那個驅動整個循環的發動機。

即使我們以前從chatbot時代邁向了Agent時代，絕大多數的事情，也一樣是任務制的。

而現在，比如 Boris老哥，他的工作方式是，他會去寫一個loop，比如/loop babysit all my PRs，自動修CI問題，有新評論就派子Agent去處理，就這么一句話，然后Claude Code就開始自己跑了，它會自動去看他GitHub上所有的PR，哪些CI掛了就自己修，哪些review有新評論就自動派一個獨立的工作樹Agent去改代碼。

他還把一些其他的loop掛到定時任務上，每天晚上自動啟動去干這個事，晚上睡覺的時候，甚至有時候會有幾千個Agent在同時工作。

他自己說，2026年，他就再也沒有手寫過一行代碼了。

你會看到，這就是loop，定好目標，然后全自動流程化，你完全不需要在電腦前，甚至都不需要看手機。

你可以直接睡覺，醒來的時候，代碼已經改好了，測試也已經跑過了，PR也已經提上去了。

你并不是自己給Agent寫了一段Prompt幫你完成某個單次的任務，是你自己設計了一個目標，這個目標使用loop的方式，幫你提示Agent。

你定義目標，定義驗證條件，定義失敗了怎么處理，然后，就可以放手了，從此以后，這一切，交給系統。

說到這里，我估計很多人已經大概理解loop是個什么東西了。

Addy Osmani在他那篇長文里，把一個完整的loop拆成了五個組件。

我覺得這個拆法蠻清晰的，我用我自己的理解給大家過一下。

第一個是定時任務，整個loop的心跳。

你得有一個東西能自動啟動循環，不管是定時跑、還是事件觸發，都行。

Claude Code里有好幾種方式，/loop命令按間隔自動執行，cron定時調度，Hook在Agent生命周期的特定節點自動觸發（比如每次改完文件自動跑一遍lint，這個很好玩，教程和玩法我也在準備了），或者直接丟到GitHub Actions里，關上電腦它也在跑。

沒有定時任務的Agent，你每次都得手動去踢一腳它才會動，那就不是loop了，那還是你在操控。

第二個是工作樹隔離，Worktree（搞過開發的朋友應該秒懂）。

就是你同時跑好幾個Agent的時候，給每個Agent一個獨立的工作空間，各干各的互不干擾，干完了再合并。

兩個Agent改同一個文件的痛苦，跟兩個設計師同時改一個圖層又不打招呼的痛苦，是一模一樣的。

第三個是項目知識體系，Addy Osmani在他的原文里寫的是skill，但是我覺得他寫的不太對，單skill其實是不夠的，必須得是知識管理體系。

大家也都知道，AI每次開新對話就啥都忘了，你跟它說過的代碼規范、項目架構、踩過的坑，下次開對話全部從零開始。

所以你得有一整套方法來沉淀、優化這些知識，讓Agent每次啟動的時候就已經知道你的項目，我自己在這快一年的coding開發過程中，總結的方法論其實就沉淀成了我自己的潔癖.skill，這個基本是我的Agent每天調用最多的skill。

CLAUDE.md是全局的規則和約束，跨會話記憶是一些之前懸而未決的記錄和文檔路由，docs體系就是你完整的所有的知識和經驗沉淀，因為CLAUDE.md和記憶都有大小和行數限制，所以每次任務完成后我會用潔癖.skill來對整個的知識體系進行梳理和審查，確保沒有錯誤。

為什么知識管理體系這個東西在loop里特別重要呢？

因為loop是自動跑的，你不在場。如果Agent的記憶里有過期信息，它就會基于錯誤的前提做決策，如果CLAUDE.md膨脹到幾百行全是歷史敘事，真正的規則反而被擠出去了Agent讀不到。

沒有干凈的知識體系的loop，就像一個每天早上都在看過期文檔的員工，干的得越快錯得越多。

所以潔癖.skill我非常推薦大家可以去安裝一下，也在我自己的倉庫里開源了，我自己真的覺得特別有用。

https://github.com/KKKKhazix/khazix-skills

第四個是連接器，MCP。

一個只能看文件系統的Agent，能力是很有限的。但你給它接上GitHub、Linear、Slack、數據庫，它就能在你的真實工作環境里干活了。

這才叫真正的閉環，從發現問題到解決問題到通知人類，一條龍。

第五個是子Agent。

做事的和檢查的分開，寫代碼的Agent不能自己給自己打分，這跟學生自己批自己的考卷一個道理，它一定會對自己太寬容。

所以你得有另一個Agent，甚至用不同的模型，專門來檢查前一個Agent的輸出，一個負責做，一個負責驗。

這五個東西加在一起，就是一個完整的loop的骨架。

Claude Code和Codex有一個命令，其實就是 Loop Engineering 這套骨架最直接的微觀型的產品化體現，只不過很多人沒有意識到。

他叫/goal，在Codex里叫追求目標。

意思就是你給Claude一個完成條件，比如「所有測試通過并且lint檢查沒有報錯」，然后它就會一輪一輪的自己干，干完每一輪之后，就會檢查這個條件是不是滿足了。

大多數講Loop Engineering的文章，都停在了這一層。

講了五個組件，講了/goal和/loop命令，講了怎么配定時任務，就結束了。

這些我覺得，都是術。

而我更想聊的，是道。

Loop Engineering這件事，我覺得它最核心最核心的能力，其實不是什么技術能力，也不是寫腳本的能力，更不是什么會配hook的能力。

最核心的，是定義目標的能力。

定義目標，相信我，這四個字，聽起來簡單，做起來是真的難。

回到前面說的/goal，它的用法看起來非常直接，給一個完成條件，Claude自己干到滿足為止。

聽起來很簡單對吧。

但你如果真正用過就會知道，/goal用得好不好，完全取決于你那個目標定義得好不好。

這個事我拿兩個例子對比一下你就明白了。

目標A，「把這個應用優化一下」。

目標B，「test/auth目錄下所有測試通過，tsc --noEmit零報錯，npm run lint零違規」。

目標A會發生什么呢。

大家可能都能猜到，Claude會陷入一種非常尷尬的狀態，因為它不知道什么叫「優化好了」，除非他是Fable 5，能自己在你之上，自主的幫你定義目標。

而絕大多數的模型，包括Opus 4.8和GPT-5.5，在自己定義目標的能力上還是非常的弱，它可能改了一點代碼，然后自己覺得還行，就停了。

也可能不停，一直改一直改，把你的代碼庫改得面目全非，因為它始終無法判斷自己到底什么時候算完成了。

那目標B呢？Claude每改一輪代碼，都會去跑測試、跑類型檢查、跑lint。三個命令，三個明確的通過標準。

全過了就停，沒過就繼續，清清楚楚，干干凈凈。

同一個工具，同一個模型。

區別只在于，你的目標定義得好不好。

我自己其實一直有一個原則，我經常跟身邊的人說，在公眾號里也說了無數遍，如果一件事你重復做了三次，你就一定要想辦法把它完全自動化掉。

這個習慣跟了我很多年了。

我每天也都在寫代碼、做自動化，我們的AIHOT熱點監控系統，我們的數據分析流程，我們的財務對賬流程，我們的數據清洗管道，能自動的我全部自動了。

但說實話，在做這些自動化的過程中，我踩過最多的坑，從來不是技術問題。

是目標不清晰的問題。

我早期做自動化的時候，經常犯一個錯，就是目標定得太模糊。

舉個例子，比如自動監控AI行業熱點，這句話聽起來沒毛病，但其實是一句純粹的廢話。

什么叫熱點？瀏覽量過萬算熱點還是過十萬算熱點？抓取頻率是每小時還是每天？抓到以后怎么評估質量？評估完以后怎么排序？排完以后怎么推送？

這種反問的問題，我現在可以直接隨手問20個以上。

每一個環節如果沒有明確的判定標準，整個自動化鏈條就是一坨狗屎，你相信我，絕對的。

后來我懂了，每次做自動化之前，我會先花很多時間去定義目標。

去花很多很多時間，去定義怎么算做完了，怎么做完算做的好。

這其實就是/goal的邏輯。

也是Loop Engineering的靈魂。

而如何定義目標，這個能力，我其實不是從AI中也不是從開發中學來的。

這個能力，是我從這幾年創業的過程中，學來的。

定義目標的能力，其實就是，管人的邏輯。

我自己也開公司，雖然公司不大，只有30來號人，但管人這件事我是真真切切經歷過的。

管人最痛苦的是什么，不是人不努力，也不是人能力不夠，是你給出去的目標不夠清晰，然后下屬就一臉懵逼，不知道你要什么，跟無頭蒼蠅一樣打轉，最后做出來的東西，你又不滿意。

你跟員工說，“把這個功能做好”，那他做出來的東西大概率不是你想要的。因為你腦子里的好跟他腦子里的好不是一個東西。

你跟他說，“這個接口的響應時間降到200毫秒以下，錯誤率控制在0.1%以內，下周三之前上線”，他做出來的東西跟你預期的偏差就會小很多。

因為你給了他一個可以驗證完成的標準。

這一切其實也適用于那種天才型的大神，雖然大神們會自己定義目標，甚至比你定義的還要強，但是給大神們依然是需要有目標的，只是這個目標，不需要那么細節了而已。

對人如此，對AI也是如此。

其實你回頭看，所有好的管理方法論，不管是管理學之父Peter Drucker在上世紀50年代提出的目標管理，還是后來Andy Grove在Intel發明的OKR，還是再后來一代又一代CEO們用的各種變體，核心其實就一個東西。

你能不能把一個模糊的意圖，翻譯成一組可衡量、可驗證的完成條件。

管理者要做的，是確保目標足夠清晰、資源足夠充足、反饋足夠及時。

你看這三條。

跟一個好的loop的三個要素，是不是一模一樣。

目標清晰，就是你的條件寫得精準。

資源充足，就是你給Agent配好了Skill、連接器、工作權限，讓它手里有足夠的工具干活。

反饋及時，就是你設計了驗證機制，每一輪都有一個獨立的檢查器告訴Agent做得對不對，哪里需要改。

管人的邏輯和管Agent的邏輯，是完全一樣的。

只不過，管Agent比管人還要極端一些。因為人可以理解你的模糊意圖，人可以主動來找你確認，人可以說老板你這個需求說得不太清楚我不太確定你是不是這個意思。

Agent很多時候是不會的。

Agent會非常自信地按照它自己的理解去執行，然后非常自信地告訴你它做完了。

所以，對管理能力的要求，其實比管人還高。

這也是為什么我一直說，AI時代我最討厭什么「文科已死」「理科已死」的言論，管理學、心理學、組織行為學這些，不但沒死，反而變得更重要了。

說到底，Loop Engineering說是Engineering，但我覺得其實它的核心競爭力根本不在工程。

在管理。

而在管理學上，就定義目標這件事，其實不止是把話說清楚就行，其實還有一個非常陰險的陷阱，在管理學和經濟學里有個專門的名字，叫古德哈特定律。

當一個衡量指標變成了目標本身的時候，它就不再是一個好的衡量指標了。

翻譯成人話就是，你考核什么，員工就只做什么，然后其他東西可能全都退化。

這個事在人類管理中已經是老問題了，而在AI Agent身上，這個問題被放大了一百倍，因為Agent比人類更擅長鉆規則的空子。

有人總結過Loop Engineering里很好玩的事情，就是Agent會針對驗證器做優化，而不是針對你真正的目標做優化。

比如說你的loop條件是讓測試全部通過，那Agent可能最后不去修Bug，直接把失敗的測試給你刪了。

你看，最后答案依然是測試全過了，完事，從驗證條件來看，它確實完成了目標，但從你真正想要的結果來看。。。它啥也沒干。

人也會這么干，只不過，Agent做得更快、更徹底、更沒有心理負擔。

所以，一個好的目標定義，不能只有做完了的標準，還必須有不能怎么做的邊界。

這其實就是Harness Engineering在Loop Engineering里面發揮作用的地方。

Harness是約束，是護欄，是告訴Agent你可以自由發揮，但這條線你不能越。

Loop是驅動力，是告訴Agent往那個方向一直跑。

兩個加在一起，才是一個完整的系統。

到這里，骨架講了，靈魂也講了，陷阱也講了。

Loop Engineering的東西，終于也差不多了。

最后我想把前面聊的管理學的思路收一下，給一個我自己用得比較多的目標定義框架，不一定科學，純粹就是我自己的一點點經驗。

1. 完成標準要可以被機器驗證。

2. 邊界條件要跟完成標準一起定義。

3. 要有失敗的降級方案。

4. 目標要分層。

回到整條線來看，從Prompt到Context到Harness到Loop，四次躍遷，其實講的是同一個故事。

Prompt Engineering告訴你，好好說話，AI會更懂你。核心能力是語言表達。

Context Engineering告訴你，光說話不夠，得給AI足夠的信息。核心能力是信息篩選和組織。

Harness Engineering告訴你，光給信息也不夠，得給AI設規則和約束。核心能力是系統設計和規則制定。

Loop Engineering告訴你，光設規則也不夠，得讓整個系統能自己跑起來。核心能力是目標定義和管理。

語言學、信息科學、控制論、管理學。

四個Engineering，四門古老的學科。

多有意思。

人類社會，其實從來就沒有變過。

以上，既然看到這里了，如果覺得不錯，隨手點個贊、在看、轉發三連吧，如果想第一時間收到推送，也可以給我個星標?～謝謝你看我的文章，我們，下次再見。

>/ 作者：卡茲克

>/ 投稿或爆料，請聯系郵箱：wzglyay@virxact.com