今年年初從公司離職之后，我開始自己做項目。一個體育AI平臺、一個黑膠唱片收藏小程序，都是從零開始。沒有研發團隊了，就我一個人，設計、開發、測試全包。

我不是程序員出身。做了三年AI產品經理，PRD寫了一堆，代碼真正自己動手寫的很少。離職之后決定試試用AI輔助開發，畢竟天天給別人設計AI產品，也該自己吃一下狗糧了。

剛開始那段時間挺痛苦的。打開Cursor，跟Claude說”幫我寫一個唱片收藏頁面”，它刷刷刷生成一大坨代碼，看著像那么回事。一跑，頁面出來了但數據沒存進去。補一句”數據要存到數據庫”，它又生成一版，這次數據存了但字段對不上。再補一句”字段用這個Schema”，它改了，但把之前寫好的樣式搞丟了。改來改去，一個下午過去了，一個頁面還沒弄完。

體感上，我大概有30%的代碼是AI寫的，剩下70%要么是自己寫的，要么是AI寫了之后我改得面目全非的。跟那些”AI幫我一天做了一個App”的說法差距太大了。我一度懷疑是不是自己太菜。

轉折發生在三月底。我在社區里看到有人聊一個概念：Harness Engineering。

harness這個詞特別形象。套在馬身上的那整套裝備——韁繩、嚼子、胸帶——就叫harness。不是讓馬跑得更快，是讓馬往你想讓它去的方向跑，同時確保你不會摔下來。

我看了一晚上相關的東西，有點坐不住了。突然意識到自己之前的問題不是AI不夠聰明，是我從來沒給AI搭過一套像樣的harness。說白了就是：我一直在換馬，沒想過換韁繩。

然后我拿黑膠唱片小程序這個項目做了個實驗。花了一周時間，用Harness Engineering的思路重新來過。

先說我之前的工作方式。打開Claude Code或者Cursor，直接跟它說”幫我做收藏管理功能”。它開始寫，寫完我看一眼，發現不對——它把唱片字段設計成了五六個通用字段，但我的Schema有二十多個專業字段：廠牌、版次、母帶編號、壓片國家這些。AI不知道這些，它只能猜。補一句糾正，它改了這里又漏了那里。一來一回，半小時過去了，生成了三四個版本，最后可能還是得我自己上手改一半。

Harness Engineering解決的就是這個問題：你不用每次都告訴AI該怎么做，你把”該怎么做”寫進環境里，讓它隨時能自己查到。

我做的第一件事是寫CLAUDE.md。

但寫完之后效果立竿見影。AI開始生成代碼的時候，不再瞎猜了。它知道這是微信小程序不是H5網頁，知道唱片有”首版””再版””限量版”的區分，知道標簽篩選要支持多維交叉，知道花費統計要按幣種分。這些事情以前每次對話都得說一遍或者等它寫錯了再糾正，現在它直接就知道了。

第二件事是拆任務的方式變了。

以前我會直接說”幫我做收藏管理功能”，這是一個大任務。AI接到這種大任務，會試圖一口氣搞定，然后在中間某個地方翻車。Harness Engineering的做法是：寫spec。就是開始干活之前先寫一份簡單的任務規格——目標是什么、邊界是什么、驗收標準是什么、依賴什么、不能改什么。

我后來養成了一個習慣：每個稍微復雜一點的功能，先花五分鐘寫一個spec。這五分鐘絕對不是浪費。因為spec寫清楚了，AI一次成功率極高；spec沒寫清楚，AI生成三四版還在原地打轉。

有一次我偷懶沒寫spec，直接讓它做標簽篩選功能。它做完之后我一看——把標簽設計成了扁平的單層結構，所有標簽混在一起。但我的設計是四維分層的：風格標簽、廠牌標簽、年代標簽、版本標簽，互相獨立，支持交叉篩選。AI不知道這個設計意圖，它按自己的理解做了一個”夠用”的方案。如果我在spec里寫一句”標簽四維分層，參考CLAUDE.md中標簽體系定義”，這個返工根本不會發生。五分鐘省兩小時，這筆賬太劃算了。

第三件事是利用好工具鏈。

還有一個很實用的規則：讓AI每次改完代碼自己做一輪檢查。我寫了一條”完成修改后檢查是否引入了硬編碼值或TODO”。這是我之前的痛點——AI為了讓代碼跑通，經常會塞一個hardcoded的配置進去，比如直接把我的測試用唱片數據寫死在代碼里。你不仔細看根本發現不了。

第四件事，也是我覺得影響最大的：分清楚哪些事讓AI自己跑，哪些事自己盯。

Claude Code有一個設計叫權限系統——哪些操作AI可以自己做，哪些需要人確認。Harness Engineering的理念是：不是所有任務都需要同等程度的監督。寫一個展示組件和設計數據庫Schema，風險完全不一樣。

我把工作分成了三檔。低風險的——列表頁面、詳情頁面、簡單的UI組件——讓AI直接跑，我不一個個看。中等風險的——數據存取邏輯、標簽篩選算法、統計計算——AI寫完我review一遍。高風險的——Schema設計、數據遷移、核心交互邏輯——我自己主導，AI輔助。

以前我的瓶頸不是AI寫得慢，是我看得慢——AI每生成一段代碼我都逐行對，因為不確定它會不會在某個不起眼的地方埋雷。分級之后，低風險的跳過，精力集中在高風險的部分。一天能推進的工作量翻了不止一倍。

一周下來體感是這樣的：前兩天幾乎沒有代碼產出，全在搭harness——寫CLAUDE.md、定spec模板、配規則。第三天開始干活，效率立刻就不一樣了。到第五天已經進入一種節奏：我把功能拆成一個個明確的包，扔給AI，它去做，我來驗收。大部分一次過，偶爾要調整，但很少需要推翻重來。

后面兩天在做一些邊邊角角的體驗優化，我突然有一種挺奇妙的感覺——我好像不是在”寫代碼”了，是在”管理一個寫代碼的Agent”。我的工作從”實現”變成了”設計”和”驗收”。對一個產品經理出身的人來說，這個狀態其實反而更自然。

這個體驗讓我想到一件事。

我之前在公司做企業AI產品的時候，花了很多時間想怎么讓AI輸出更好——調提示詞、優化知識庫、升級模型。但Harness Engineering給了我一個完全不同的視角：與其讓模型更聰明，不如讓模型”知道自己在干什么”。一個知道項目結構、知道數據Schema、知道任務邊界的”普通”模型，比一個什么都不知道的”強”模型有用得多。

這不就是我之前做企業AI產品時一直在解決的同一個問題嘛？只不過換了個場景。

在AI Coding里，harness是CLAUDE.md、spec和工具鏈規則。在企業AI產品里，harness是領域知識庫、工作流引擎和人機協作界面。做合同審核產品的時候，我給AI搭的那套——分章節生成、溯源標注、人工復核節點——本質上就是一套產品級的harness。當時不知道這個詞，但干的事是一樣的。

所以我現在越來越覺得，Harness Engineering不只是一個開發者的話題。它對產品經理也有實際意義。

當然了，90%這個數字有點討巧。UI組件、列表頁面這種可能95%以上是AI寫的，核心的篩選邏輯和數據結構設計可能只有50%。平均下來是個大致的感覺，不是精確統計。而且我這個項目功能比較明確——之前做了完整的用戶調研和產品設計，AI只需要”實現”不需要”想”，這會讓AI Coding率偏高一些。

但不管怎么說，從30%到90%，中間的差距不是模型升級帶來的——用的是同一個Claude。差距全在harness上。

如果你現在也在用AI寫代碼但感覺效率卡在一個瓶頸上，先別急著換模型或者學更高級的提示詞技巧。先看看你的harness——你的CLAUDE.md寫了沒有？任務拆分清晰嗎？你有沒有在讓AI”蒙著眼睛干活”？