今年爆火的 Harness Engineering 是什么？一文徹底講明白

大家好，我是程序員魚皮。

用 AI 編程的朋友應該都遇到過這些問題：

• 你讓 AI 改下頁面的樣式，結果它沒搞清楚你到底想干嘛，重新開發了整個布局。

• 你前面明明要求單文件的代碼不超過 200 行，結果聊了十幾輪之后，AI 把前面的約束給忘了，寫了個 1000 行代碼的大文件。

• 還有更頭疼的，你讓 AI 修一個項目里的 Bug，結果又出了 3 個新 Bug，項目都跑不起來了，代碼越改越亂。

前兩個問題已經有了不少解決辦法，比如寫好提示詞、給 AI 提供充足的信息，但第三個問題就比較棘手了。

如果你想讓 AI 做好一個完整的項目，你還得給它搭一整套靠譜的工作環境和工作流程。

這就是最近在 AI 圈很火的 Harness Engineering。

寫這期內容前，我看了不少國內外講 Harness 的教程，很多都花了大量篇幅講 AI 發展史和枯燥的理論，看完就忘了。所以我換了個思路，先通俗易懂地講清楚 Harness 是什么，然后帶你實戰怎么用 Harness 做出完整大項目，還會告訴你怎么最快上手 Harness。

點個收藏，我們開始~

一、快速了解 Harness Engineering Harness 是什么？

Harness 這個詞翻譯過來就是「馬具」。如果把 AI 模型比作一匹馬，那 Harness 就是你駕馭這匹馬所需要的一切，比如韁繩、路線規劃、圍欄等等。

我們要做的，就是怎么讓這匹馬跑得更快、更穩，順利完成任務。

具體來說，Harness 就是圍繞 AI 模型搭建的一整套工作環境和工作流程。你給 AI 寫的項目規則文件、配置的各種工具、安排的任務拆分和執行順序、設計的測試檢查流程，這些統統都算 Harness。

為什么它突然火了？

知名的 AI 框架 LangChain 做了個實驗，使用同一個 AI 模型，只優化圍繞模型搭建的 Harness 部分，編碼基準測試的排名直接從 30 名開外沖到了前 5！

OpenAI 團隊也做了類似的嘗試。3 個人的小團隊，全靠 Harness 引導 AI 生成了上百萬行代碼，最終做出的產品已經在內部正式上線使用了。

看到這些成果之后，不少知名 AI 公司和技術大佬紛紛寫了博客來講 Harness，于是把這個概念帶火了。

有了這些知名公司和大佬的背書，現在行業達成了一個共識：AI 編程的瓶頸不在模型有多聰明，而在你圍繞模型搭的這套環境和流程夠不夠好。

Harness 的發展過程

很多人以為 Harness 是 2026 年蹦出來的新東西。其實從 2022 年 ChatGPT 出來的時候，大家就已經在做 Harness 了，只不過當時沒叫這個名字罷了。

為了讓你更好地理解 Harness，我先帶你簡單回顧一下這幾年 AI 工程的發展。

1、提示詞工程（2022 ~ 2024）

簡單來說，就是怎么 通過對話讓 AI 聽懂你的需求。

我們學著給 AI 設定角色、約束輸出格式、用思維鏈讓它一步步思考、給幾個示例讓它模仿。這些技巧雖然簡單，但確實能讓 AI 的輸出質量提升一大截。

2、上下文工程（2025）

在提示詞工程的基礎上更進一步，核心是怎么 在對的時候把對的信息喂給 AI。

比如寫 AGENTS.md 規則文件讓 AI 了解項目背景，用 RAG 讓 AI 能檢索到相關資料，對過長的上下文做壓縮和摘要，甚至給 AI 建立跨對話的記憶機制，讓它不會聊著聊著就斷片兒。

3、Harness Engineering（2026）

在上下文工程的基礎上又往前走了一步。除了關注給 AI 提供什么信息，還要關注給它配什么工具、大任務怎么拆分成小步驟分批完成、出了問題怎么自己檢查和修復、怎么防止代碼質量隨著迭代慢慢下滑。讓 AI 不只是回答問題，而是 持續靠譜地完成整個任務。

你會發現，三者是層層包含的關系。

• 提示詞是最內層，關注的是「怎么給 AI 下指令」

• 上下文包裹著提示詞，關注的是「怎么給 AI 提供信息」

• Harness 把它們全部包在里面，關注的是「怎么讓 AI 持續靠譜地干完一整件事」

業界總結了一個公式：Agent = 模型 + Harness。

也就是說，圍繞 AI 模型搭建的工具、規則、流程、檢查機制，全都屬于 Harness 的范疇。

二、Harness 的五個核心模塊

講到這里，你可能覺得 Harness 挺大、挺抽象的。

但其實沒那么復雜，Harness 要解決的就是 AI 干活時會遇到的幾個核心問題。

接下來我一個個給大家講解。如果你是程序員，或者有做過項目的經驗，你會發現這些方法其實都不陌生。

1、上下文架構：讓 AI 了解項目背景和規矩

AGENTS.md 規則文件、分層文檔、上下文壓縮、漸進式加載

做項目的第一步是什么？

當然是了解需求、項目背景和開發規范。用 AI 做項目也一樣，你得把這些信息喂給它。

我們可以寫 AGENTS.md 這樣的規則文件，告訴 AI 這個項目用什么技術棧、遵循什么代碼規范、有哪些禁止事項。這跟我們傳統做項目時寫需求文檔、方案設計文檔是一樣的。

不過要注意，AI 能處理的上下文空間是有限的。OpenAI 團隊就踩過一個坑，他們試過把幾千行的規則塞進一個大文件，結果 AI 反而更容易忽略里面的關鍵信息。后來他們改成把 AGENTS.md 當成一個 目錄 來用，只寫大概 100 行的摘要和索引，然后在 docs/ 目錄下放詳細的設計文檔。AGENTS.md 里面寫清楚「前端規范看 docs/FRONTEND.md、安全相關看 docs/SECURITY.md」這樣的指引，AI 需要什么就去讀對應的文件。這種 按需加載 的思路，就是上下文架構的核心。

2、執行能力：給 AI 裝上手腳和工具

工具調用、Bash 終端、文件系統、MCP、Browser Use、Skills 技能包

AI 模型本身只能輸出文本。如果你想讓 AI 真正幫你開發項目，就得通過工具調用讓它具備操作電腦的能力，比如給它配一個終端環境來執行命令、給它文件系統來讀寫代碼、給它瀏覽器來測試網頁。

在這個基礎上，還可以通過 MCP 進一步擴展 AI 的操作范圍，比如讀寫數據庫、聯網搜索和抓取最新的內容等等。

還有 Agent Skills，把一整套復雜的工作流封裝成技能包， 讓 AI 能夠快速學會各種專業技能，比如自動生成 PPT、處理 Excel 表格之類的。總之就是讓 AI 能用的工具越多，它能幫你干的活就越多。

3、任務編排：給 AI 安排好工作計劃

Plan Mode、任務拆分、增量開發、文檔沉淀、SubAgents 并行執行

如果你丟給 AI 一個大需求，它可能會嘗試一把梭全部搞定。但 AI 的上下文空間是有限的，可能開發到一半信息就裝不下了，前面定好的方案和約束慢慢被沖淡，最后留下一堆跑不起來的渣渣代碼。

怎么解決這個問題呢？

最基本的做法就是把大任務拆成小任務，每次只做一個功能點。在開始之前可以先用 Plan Mode 計劃模式讓 AI 出方案，人工確認后再動手寫代碼。

每做完一個功能，最好都沉淀一下文檔，包括當前實現了哪些功能、用了什么技術方案、還有哪些待做的事項。這樣哪怕后面新開一個 AI 對話窗口，也能讓 AI 通過讀文檔快速了解之前做了什么，不用從頭再來。

如果有多個互不依賴的小任務，還可以用 SubAgents 讓它們并行執行，效率更高。我們傳統開發項目時的任務拆分、前后端并行開發，也是同樣的思路。

4、反饋機制：讓 AI 自己檢查自己的工作

Linter 代碼檢查、自動化測試、Browser Use 端到端測試、Agent 互審

AI 寫完代碼之后，可能會自信滿滿地跟你說任務已經完成了，結果你一點運行，全是 Bug。

所以我們得讓 AI 在寫完代碼之后能自己檢查自己的工作。比如跑 Linter（代碼檢查工具）看看有沒有語法和規范問題，跑自動化測試驗證功能是否正確，甚至讓 AI 自己打開瀏覽器實際操作一遍，功能可以正常使用才算是真正完成了任務。

如果測試沒通過，AI 可以自動讀取報錯信息，分析原因并嘗試修復。當然我們也可以人工檢查，把發現的問題、報錯信息和截圖提供給 AI，讓它來修。

甚至還可以讓另一個 AI 來審查代碼，搞一個「多 Agent 互審」的機制，跟我們傳統做項目時多個同事一起 Code Review 是一樣的。

5、架構護欄：防止代碼越改越亂

架構約束 Linter、Pre-commit Hooks、垃圾回收機制、Git 檢查點

AI 生成代碼有個特點，就是它會模仿倉庫里已有的代碼風格，哪怕是爛代碼。比如同樣的頁面代碼寫了好幾遍，也不知道要拆分成可復用的組件，會導致改了一個地方其他重復的地方就漏改了。時間一長，技術債就越滾越大。

怎么防止這個問題呢？

常見的做法是寫一批專門的 Linter 來強制執行架構層面的約束。注意這跟前面反饋機制里提到的 Linter 不太一樣，前面那個查的是代碼風格和語法問題，這里的 Linter 查的是架構規則，比如 UI 層不能直接調用數據庫層、模塊間的依賴必須是單向的。AI 一旦違反就會被自動攔住，還可以通過 Pre-commit Hooks（代碼提交前的檢查鉤子）在提交時自動攔截不合規的代碼。

OpenAI 還搞了一套叫「垃圾回收」的機制，定期讓 AI 掃描代碼庫，檢查有沒有偏離架構規范的地方，自動提交修復 PR，持續償還技術債。

另外建議每完成一個功能就用 Git 提交一次代碼。Git 是一個版本控制工具，能記錄代碼的每個歷史版本，相當于給項目打了一個存檔點，萬一后面改出了問題，可以隨時恢復到之前的狀態。

看到這里你會發現，寫規則文件、配備工具、拆分任務、執行測試、定架構規范…… 這些其實都是程序員做項目時常用的方法，換到 AI 編程場景里，就是 Harness。

Harness 不是什么新技術，它本質上是把我們已有的工程經驗，系統地應用到 AI 上。

所以有做項目經驗的朋友，你們積累的工程能力到了 AI 編程時代一樣實用。我也建議大家平時多做完整的項目、多積累工程經驗，越懂工程的人越能駕馭 AI。

三、Harness 項目實戰

概念講完了，接下來我用一個實際項目帶大家看看，Harness 在真實開發中到底是怎么落地的。

這個項目是我在 編程導航 全程直播帶做的 AI 編程全棧項目「萬能視頻下載總結器」。我用 AI 從零開發了一個能從各大平臺下載視頻、并用 AI 總結視頻內容的網站，還做了 SEO / GEO 優化和 Stripe 國際支付。

回過頭看，整個開發過程其實就是一套完整的 Harness 實踐。

下面我按照企業做項目的階段來講，看看每一步用了哪些 Harness 方法。

1、方案設計階段

動手寫代碼之前，我做了一件很重要的事：先自己想清楚核心方案。

這個項目需要什么樣的前端界面？需不需要后端？核心的視頻下載能力怎么實現？

我是自己先思考，并且通過 AI 在全網調研了一番，然后決定用 yt-dlp 這個開源項目作為下載功能的核心實現、技術棧以 Python 為主。

然后我把這些思考寫成文檔，關聯給 AI，讓它在我的方案基礎上補充細節。

注意，我特意 開啟了 Plan Mode，讓 AI 先出方案找我確認，而不是上來就直接寫代碼。

AI 生成了一個技術方案文檔，我仔細看了一遍，發現它把一些后續才做的功能也納入計劃了，于是我就跟它說「先完成核心的視頻下載功能」，一步步來。

這就是 任務編排 和 上下文架構 在方案階段的應用。先規劃再執行，給 AI 提供充足的背景信息，約束它不要一上來就一把梭。

2、編碼開發階段

確認方案之后，AI 就進入了開發環節。這個階段我做了幾件很關鍵的事。

首先是 給 AI 裝上聯網能力。我配置了 Firecrawl MCP 讓 AI 能抓取網頁內容，又配置了 Context7 MCP 讓 AI 能獲取最新的技術文檔。

這樣 AI 在開發過程中遇到不確定的 API 用法，就可以自己去查最新文檔，而不是用過時的寫法。

核心的視頻下載功能做完后，我 讓 AI 沉淀了一總結文檔，記錄當前的功能、架構和實現細節，然后提交到 Git。

這一步很關鍵，因為后面要做新功能的時候，我會新開一個對話窗口，把這些文檔關聯給 AI，它就能快速找回記憶，不用從頭再來。

為什么新功能要新開對話呢？

因為在同一個 AI 對話框中聊久了上下文會越來越臟，AI 的表現會下降。新開對話相當于給 AI 一個干凈的環境，然后用文檔幫它找回需要的信息就好了。

這些操作本質上都是在做 上下文架構 和 執行能力 的建設，給 AI 裝好工具、維護好上下文信息。

3、測試驗證階段

AI 不僅能寫代碼，還能 自己打開瀏覽器測試。

在這個項目里，AI 通過 Cursor 內置的 Browser Use 功能，自己啟動瀏覽器、輸入視頻鏈接、點擊解析按鈕，然后檢查結果是否正常顯示，比人工測試方便太多了。

不過 AI 的自測也不是萬能的，遇到解決不了的問題，還是要人工出馬。

比如我通過人工測試發現 B 站視頻下載報了 403 錯誤，就把報錯信息直接貼給 AI，讓它自主分析和修復。AI 很快發現是防盜鏈的問題，然后自己搞定了。

有時候 AI 會卡在同一個問題上反復修不好。比如 Markdown 渲染出了問題，我跟 AI 說了好幾輪都沒修對。

后來我換了個角度去描述這個問題，跟它說：你不應該改后端 Python 代碼么？如果后端 SSE 返回的內容丟失了，前端解析出來肯定是錯的吧？

AI 這才恍然大悟，改了后端邏輯就修好了。

還有個小技巧，就是不要每次測試都走完整的「輸入鏈接、解析、總結」流程，太慢了。我讓 AI 自己模擬一段 Markdown 數據直接測試渲染效果，這樣反饋要快得多。

這些都是 反饋機制 的體現，給 AI 提供反饋信號讓它自我修復，AI 搞不定的時候人工介入糾偏。

Harness 不是完全放手不管，而是把人的精力用在最關鍵的地方。

4、功能擴展階段

核心的視頻下載功能跑通后，我又加了 3 個小需求：優化 Markdown 排版、思維導圖全屏加下載、字幕文件下載。

這三個需求相互獨立，所以我在提示詞里引導 AI 合理規劃任務 并行開發，AI 用了 SubAgents 同時執行多個子任務。

每完成一個功能，我就讓 AI 提交代碼并更新文檔，作為檢查點。萬一后面改出了問題，可以隨時回滾。

后來給項目做 SEO 優化的時候，我還用了一個 SEO Audit 技能，讓 AI 自動分析網站并生成優化方案。

做完 SEO 之后，還要做 GEO 優化，我直接復用了 SEO 的對話上下文，這樣 AI 已經了解了項目背景和代碼，不用重新再讀一遍，省了不少時間。

上面這些操作涵蓋了 任務編排（并行開發）、架構護欄（Git 檢查點）和 執行能力（Skills 擴展）幾個方面，都是 Harness 的重要實踐。

四、怎么快速上手 Harness？

Harness 本身并不復雜，也沒什么需要專門去啃的理論。上面項目里的很多操作，都是你現在立刻能用的 Harness 技巧。

我按照做項目的流程，給大家總結幾條實用的 Harness 方法：

1）做項目之前先寫好 AGENTS.md 規則文件，把項目背景、技術棧、代碼規范都告訴 AI

2）先讓 AI 出方案并人工確認，再動手寫代碼

3）用 MCP 和 Skills 給 AI 配好工具，讓它能聯網查資料、獲取最新的信息

4）做完功能一定要讓 AI 自己跑測試驗證，確保能正常運行

5）每完成一個功能就讓 AI 沉淀文檔并提交代碼，作為 AI 的「存檔點」

Harness 工具

如果你缺乏做項目的經驗、或者覺得自己搭建 Harness 太麻煩，也可以直接使用一些現成的開源工具。

比如 Spec Kit 工具使用的是 SDD（Spec-Driven Development）規范驅動開發的思路，它會先引導你把需求拆解成詳細的規范文檔，然后讓 AI 按照文檔一步步開發，每個階段都有明確的驗收標準。

還有 Superpowers 這種 Agent Skills 框架，它內置了一整套開發工作流，包括強制 TDD（Test-Driven Development）測試驅動開發，就是先寫測試再寫代碼，還有兩階段代碼審查、子代理協作等，相當于直接給 AI 裝了一套完整的項目管理流程。

雖然這些工具可以幫你快速起步，但從長遠來看，理解 Harness 的思路比掌握某個工具更重要。

畢竟工具一直在變化，但「怎么系統地駕馭 AI」這個思路是通用的。想要真正掌握 Harness，最好的辦法還是在實戰項目中去體會。

我在 編程導航 帶大家做過幾套 AI 編程全棧項目，除了上面提到的萬能視頻下載總結器，還有 AI 熱點監控工具、GitHub 文檔翻譯器、AI 闖關學習小程序等，其實都是 Harness Engineering 的完整實戰。每個項目都是從需求分析開始，到方案設計、AI 編碼開發、測試驗證、功能擴展，走完一整套流程。如果你想跟著實戰項目邊做邊學 AI 編程和 Harness，可以來看看。

最后嗶嗶

以前做項目，工程師的核心工作是寫代碼。現在 AI 能幫我們寫越來越多的代碼了，但這也意味著我們得花更多精力在需求分析、方案設計、任務拆解、質量把關這些事情上。

能不能用好 AI，取決于你自己的工程能力有多強。

所以我一直建議大家多做完整的項目，從零到一走完全流程，這個過程中積累的工程經驗，就是你駕馭 AI 最好的 Harness。

本文已收錄到我免費開源的 ，上千張圖、幾十萬字，完全免費開源，從零基礎快速學會 AI 編程，再到做出自己的產品、跑通變現全流程，一次拿捏。

可以點我頭像，然后私信「AI編程」獲取：

我是魚皮，持續分享 AI 編程干貨。學會的話記得點贊收藏和關注，也歡迎在評論區聊聊：你在用 AI 編程時踩過什么坑？是怎么解決的？