Harness Engineering又他媽是啥？

Vibe Coding都沒學完，Prompt Engineering課還在賣，Context Engineering墨跡還沒干，現在又來一個？

AI圈造新詞的速度，快趕上模型迭代了。過去一年光「XX Engineering」就冒出來四五個。

但我去讀了OpenAI和Anthropic的原文之后，反應變了。不是「哇好新」，是：等等，這不就是我過去半年一直在干的事嗎？

我寫CLAUDE.md，告訴AI我是誰、什么規則必須遵守。配hooks，在agent關鍵節點注入檢查。建知識庫，給AI準備決策需要的上下文。調skills，定義AI能用什么工具、有什么權限。

做了半年，從來沒覺得這些事需要一個統一的名字。

然后OpenAI發了篇博文說這叫Harness Engineering。Mitchell Hashimoto發了篇博文也說這叫Harness Engineering。Anthropic發了兩篇工程文章，Martin Fowler寫了長文分析，大家都這么叫。

行，那就叫Harness Engineering。

Harness這個詞，英文原意是馬具、韁繩。不是馬本身，是套在馬身上讓它能拉車、能被引導的那整套東西。沒有它，馬就是一匹亂跑的野馬，力氣再大也白搭。

三層關系很好懂：Prompt Engineering是你對馬說的話，向左轉、跑快點。Context Engineering是幫馬看路的一切，地圖、路標、地形。Harness Engineering是韁繩、馬鞍、圍欄和道路本身，讓十匹馬同時安全跑起來的系統。

Prompt管你問什么，Context管你給模型看什么，Harness管整個東西怎么運轉。Context是Harness的一部分，Harness還多管了約束、反饋和質量檢查。

懂了這個，再看最近幾個月的事，很多碎片就拼上了。

先說最硬的一個數據。LangChain的coding agent在Terminal Bench 2.0上，成績從52.8%漲到了66.5%，排名從Top 30跳到Top 5。重點是：模型完全沒換。他們只改了三樣東西：系統提示詞、工具配置、中間件鉤子。

同一個模型，換了套韁繩，成績天差地別。

模型可能已經不是瓶頸了。瓶頸是你給它搭了個什么樣的環境。

然后是OpenAI自己的實驗。Codex團隊3個工程師，后來擴到7個，5個月，用Codex搞出了一個100萬行代碼的beta產品。零行人工手寫。約1500個PR合并，每個工程師每天3.5個PR，估算速度是傳統方式的10倍。

這些數字很炸。但有個問題沒人聊：這100萬行代碼的質量怎么樣？

速度快了10倍，不代表產出好了10倍。每人每天3.5個PR，誰在做代碼審查？六個月后需要改需求的時候，這100萬行好改嗎？AI寫的代碼和人寫的代碼有個關鍵區別：人寫代碼時會無意識地留下結構線索，方便將來的自己理解。AI不會。它只解決眼前的任務，不考慮六個月后維護這段代碼的人會不會罵娘。

所以harness不只是讓AI寫得快，還得讓AI寫得能維護。OpenAI的實驗證明了速度，但長期成本還是個問號。

回到他們怎么做到的。Martin Fowler把harness拆成了三塊。

第一塊：上下文工程。給模型一張地圖，不是一本1000頁的說明書。維護一個持續更新的代碼庫知識庫，加上agent能實時看到的系統狀態。上下文是稀缺資源，塞太多反而擠占干活的空間。

第二塊：架構約束。不光靠AI自己檢查，還有代碼檢查器和結構測試在旁邊盯著。硬規則，不遵守就編譯不過。

第三塊：垃圾回收。專門有個agent周期性運行，不寫代碼不做功能，就干一件事：找文檔里的矛盾和架構違規。一個專職找茬的AI。

Anthropic走了另一條路。他們搞了個三agent架構：規劃者負責把簡單指令擴展成詳細的產品規格，生成者按迭代一次做一個功能，評估者跑端到端測試。

靈感來自生成對抗網絡。訓練一個專門的評估者讓它一直挑刺，比讓生成者自己檢查自己管用得多。誰都不擅長批評自己，AI也一樣。

他們還發現Claude Sonnet 4.5有「上下文焦慮」。不是人焦慮，是模型焦慮。上下文太多，表現反而變差。壓縮不夠，必須定期清空重來。

所以harness不是越大越好。這可能是最反直覺的部分。

到這里你可能想：這不就是給老東西起了個新名字嗎？

說實話，還真有點。

航天工程師60年前就在做類似的事。NASA讓飛船自動執行任務，圍繞自動化系統設計的約束、反饋循環、冗余檢查、異常處理，和今天說的harness沒有本質區別。工業控制領域也一樣，PLC編程里的安全聯鎖機制就是一種harness。

AI圈不是發明了harness engineering，是終于意識到自己需要學幾十年前就有的工程紀律。

但命名還是有價值的。當一群人各自在做類似的事，沒有共同的詞來說，經驗就傳不開。這個詞出來之后，突然大家都能聊到一起了。就像Vibe Coding，你可以笑它，但它確實讓一種做法變成了可以討論的東西。

Harness Engineering也一樣。價值不在于發明了什么，在于讓一群人意識到：自己工作的重心變了。

我自己去年8月搭了Claude Code自動化寫作工作流。從那以后寫文章輕松太多，平時做做選擇，噴一噴不滿意的地方就好了。但讓這套系統好用的，不是模型有多強，是我圍繞它搭的那一圈東西。

CLAUDE.md從一個簡單的規則文件，變成了一個路由器。它就干一件事：判斷當前任務屬于哪個工作區，然后指向對應的規則。寫公眾號時不會被iOS開發的規則干擾。

Hooks是另一層。在agent執行關鍵操作前后注入腳本。編輯文件之前自動跑linting，生成代碼之后自動做類型檢查。這不是prompt里寫的「請注意代碼規范」，是物理上攔住它，不合格就不讓過。建議和約束，完全兩回事。

Skills解決了模塊化的問題。每個skill是獨立的能力包：一個管小紅書配圖，一個管飛書同步。平時不占context，需要時才調。

路由器、hooks、skills、知識庫，加在一起就是一個harness。沒人告訴我這叫什么，它自己長出來的。

這個生長方式，和Mitchell Hashimoto說的一樣。

他是HashiCorp聯合創始人，Terraform創造者，今年2月寫了「My AI Adoption Journey」，首次給這個實踐命名。方法極其樸素：每次agent犯錯，就工程化一個方案，讓它再也犯不了同樣的錯。他拿自己的終端模擬器Ghostty舉例，配置文件里每一行都對應著agent過去犯過的一次錯。文件是活的，一直在長。

我的CLAUDE.md也是這么長出來的。被AI搞煩了就加一條，規則太多了就砍一輪。活的系統。

如果你想開始，三條就夠。

給地圖不給說明書。CLAUDE.md應該像地圖：項目結構、文件關系、關鍵約束。不要把每步都寫死。AI需要方向感，不需要僵化步驟。

每次犯錯加一條規則。空文件開始，agent犯一個錯就加一條。三個月后那個文件就是你的harness。高度定制，因為全是你場景里真實出過的問題。

讓AI查AI。Anthropic的Evaluator思路。別讓AI自己查自己。最簡單的做法：寫完后開一個新對話，把結果貼進去：「找出所有問題」。你會驚訝第二個AI能發現多少第一個漏掉的。

最后聊一個我想了很久的問題。

Martin Fowler在文章里說：如果太早把人類從「in the loop」移到「on the loop」，將來可能沒人真正懂得怎么回事，也就沒人能設計好的harness。

這句話值得多讀兩遍。

現在設計harness的人，都是寫過很多年代碼的老手。Mitchell Hashimoto能給Ghostty寫好harness，因為他理解終端模擬器的每個細節。OpenAI那3個工程師能駕馭100萬行代碼，因為他們知道什么架構是好的、什么會在三個月后爆炸。

但下一代呢？新手程序員從第一天起就不寫代碼，只寫CLAUDE.md，他能設計出好的harness嗎？

Martin Fowler把這叫「經驗工程」。怎么在AI寫所有代碼的時代培養新人。

我自己是個有意思的樣本。

我從來沒手寫過代碼，所有產品都是AI寫的。小貓補光燈上了AppStore付費榜Top 1，累計用戶超百萬。我的harness從零開始，在和AI互動中一點一點長出來，沒有任何編程經驗可以遷移。

但我得對自己誠實。

我能設計harness，不是因為我天生懂系統設計。是因為我在和AI協作的上千小時里，觀察到了它的行為模式。它什么時候偷懶，什么時候幻覺，什么時候需要硬約束而不是溫柔提醒。這些判斷力不來自寫代碼的經驗，但來自另一種經驗：和AI反復較勁的經驗。

問題是，這種經驗能教嗎？我自己說不清楚。

我知道CLAUDE.md該怎么寫，但讓我教別人為什么這么寫，我會卡住。很多決定是直覺做的，直覺來自踩坑，踩坑來自大量重復，大量重復來自時間。這和老程序員說「你寫幾萬行代碼自然就懂了」其實是一回事。

所以問題可能不是「寫代碼的經驗」能不能被替代。而是：不管你積累的是什么經驗，足夠多的經驗本身就是設計harness的前提。沒有捷徑，換了個賽道而已。

也許Martin Fowler擔心的不是「沒人寫代碼了」，而是「沒人愿意花夠多時間踩夠多坑了」。

這個我也不確定。留給你想。