https://github.com/KKKKhazix/khazix-skills
大多數講Loop Engineering的文章，都停在了這一層。
講了五個組件，講了/goal和/loop命令，講了怎麼配定時任務，就結束了。
這些我覺得，都是術。
而我更想聊的，是道。
回到前面說的/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的靈魂。
你跟員工說，“把這個功能做好”，那他做出來的東西大概率不是你想要的。因爲你腦子裏的好跟他腦子裏的好不是一個東西。
你跟他說，“這個接口的響應時間降到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，四門古老的學科。
多有意思。
人類社會，其實從來就沒有變過。
以上，既然看到這裏了，如果覺得不錯，隨手點個贊、在看、轉發三連吧，如果想第一時間收到推送，也可以給我個星標⭐～謝謝你看我的文章，我們，下次再見。
>/ 作者：卡茲克
>/ 投稿或爆料，請聯繫郵箱： [email protected]