從Prompt到Harness：AI工程的三次進化
整理版優先睇
AI工程從Prompt進化到Harness：與其優化AI本身，不如優化AI運行嘅環境。
呢篇文章出自一個關注AI工程實踐嘅作者，佢由2023年以嚟一直跟進提示工程嘅發展，直到2026年發現一個新趨勢——Harness Engineering。作者想解決嘅問題係：點解傳統嘅prompt優化同context優化已經唔夠用，同埋點樣先可以令AI智能體可靠地生成生產級代碼。
文章引用咗OpenAI一個七人團隊嘅真實實驗——佢哋用Codex智能體，零行手寫代碼，五個月內提交咗1500個PR，完成咗超過一百萬行代碼嘅完整產品。呢個案例證明咗Harness Engineering嘅威力。作者仲提到Mitchell Hashimoto同Martin Fowler嘅分析，令呢個概念快速成為嚴肅嘅工程學科。
整體結論係：AI編程已經進入第三個時代，Harness Engineering係包裹喺AI智能體周圍嘅成個運行環境，包括知識庫、架構約束同熵管理。相比獨立優化prompt或context，呢種系統化方法先可以真正釋放AI嘅生產力，同時防止代碼庫腐化。
- Harness Engineering 係 AI 編程嘅終極進化階段，重點唔係優化 prompt，而係工程化 AI 運行嘅環境。
- OpenAI 實驗證實：一個細團隊用 Codex 智能體，五個月內零手寫代碼完成一百萬行嘅生產級產品。
- Harness 包含三層：增強的知識庫、架構約束強制執行、熵管理（垃圾回收）。
- 核心認知轉變：限制解空間反而令智能體更高效，因為 token 唔再浪費喺死衚衕。
- 即時可行動：你而家用嘅 CLAUDE.md、pre-commit hook、手動 code review 已經係 harness 雛形，只係需要系統化。
由Prompt到Harness：三個時代嘅演進
2023年，所有人都在學點樣寫prompt。2025年，前沿嘅人開始講context engineering。2026年，一個新詞出現咗：Harness Engineering。呢三個階段唔係互相取代，而係一層疊一層：Harness包含context，context包含prompt。
Prompt Engineering（2023-2024）核心係點問——用角色扮演、few-shot、chain of thought嚟優化輸入文字，但好快遇到天花板，因為模型睇唔到成個項目嘅全貌。
Context Engineering（2025）由Andrej Karpathy提出，重點係點樣畀模型睇到完整嘅背景材料——文檔、代碼庫、工具定義、歷史對話，甚至實時運行指標。RAG同MCP成為標配。
呢個概念由HashiCorp聯合創始人Mitchell Hashimoto喺2026年2月正式命名，幾日後OpenAI發佈咗實證報告，Martin Fowler跟進分析，arXiv論文做咗形式化定義，短短幾周就成為有工程實踐支撐嘅學科方向。
OpenAI 實驗：零行手寫代碼嘅產品開發
OpenAI一個小團隊——三名核心工程師——用Codex智能體從零構建咗一個內部軟件產品。五個月、大約1500個PR、超過一百萬行代碼，冇一行係人手寫嘅。呢個數字震撼之餘，真正值得關注嘅係人類做咗啲咩令AI可以寫咁多代碼。
佢哋嘅harness包含三層，每一層都係為咗系統性地消滅錯誤，而唔係個案修復。
- 1 第一層：增強的知識庫。 唔係簡單嘅README，而係一整套持續更新嘅項目文檔——架構約定、命名規範、模塊邊界、數據結構定義。智能體每次開工前都會讀呢啲文件，類似CLAUD.md或.cursorrules嘅高級版，仲可以訪問生產環境嘅可觀測性數據同瀏覽器。
- 2 第二層：架構約束的強制執行。 唔靠「請遵守我哋嘅架構」呢種prompt，而係用確定性工具——自定義linter、結構化測試、pre-commit hook。智能體生成嘅代碼必須通過呢啲門檻先可以合入，冇得商量。呢層最關鍵，因為限制解空間反而令智能體更高效。
- 3 第三層：熵管理。 佢哋發現AI代碼太快會產生熵——文檔同代碼不一致、架構邊界模糊、命名風格漂移、死代碼累積。所以專門跑「垃圾回收」智能體，定期掃描並修復不一致，用AI清理AI造成嘅混亂，形成自我維護嘅生態系統。
Harness 核心哲學：將教訓編碼入環境
Mitchell Hashimoto講過：「每次你發現智能體犯咗一個錯誤，你就花時間將解決方案工程化入系統，令佢永遠唔會再犯同樣嘅錯。」呢個就係harness嘅核心哲學：將經驗教訓編碼入環境本身，而唔係編碼入prompt。Prompt係一次性嘅囑咐，harness係永久性嘅制度。
一個關鍵發現：模型唔能夠可靠咁評估自己嘅輸出，就好似人類對自己寫嘅代碼有盲點一樣。AI生成嘅代碼可能通過功能測試，但違反咗架構約定、引入咗性能退化，或者連續PR之後整體一致性崩塌。
Harness借鑑咗GAN嘅思路：生成器同評估器分離。一個智能體寫代碼，另一個智能體審查，審查者有唔同嘅指令、關注點同檢查清單。再加上linter同測試作為最後防線。
呢個模式意味住一個根本轉變：你唔再試圖造一個完美嘅AI程序員，而係造一個有組織架構嘅AI編程團隊——有人寫、有人查、有制度兜底。
對你嚟講：你已經喺度做緊
如果你而家用Claude Code、Cursor或者Copilot寫代碼，你可能已經喺無意識咁做harness嘅初級版：寫嘅CLAUD.md或.cursorrules係知識庫層；設嘅pre-commit hook同lint規則係約束層；偶爾手動檢查AI代碼有冇偏離架構係熵管理層（只係手動嘅）。
三個時代唔係替代關係，而係嵌套關係。你學過嘅嘢都冇浪費，只係需要一個更大嘅框架去組織佢哋。
- 即時行動：整理你嘅CLAUDE.md，將常用嘅架構規則、命名慣例、模塊邊界寫清楚，等智能體每次開工都睇到。
- 完善pre-commit hook同lint設定，加入團隊特定嘅架構檢查，例如ArchUnit或自定義規則。
- 每星期跑一次「熵掃描」，用AI檢查文檔同代碼嘅一致性，清除死代碼同重構漂移咗嘅部分。
2023 年，所有人都在學點樣寫 prompt。
2025 年，前沿嘅人開始講 context engineering。
2026 年，有個新詞出現咗：Harness Engineering。
呢個唔係營銷概念。佢嚟自一個真實嘅工程實驗——OpenAI 一個七人團隊，用 Codex 智能體寫咗一個完整嘅生產級產品。零行手寫代碼，1500 個 Pull Request，一百萬行代碼，歷時五個月。
呢篇文章講嘅就係：佢哋係點樣做到，同埋呢件事對所有用 AI 寫代碼嘅人有咩意義。
三個時代
Prompt Engineering（2023-2024）：你點樣問
呢個係最早嘅階段。你學識咗用「請扮演一個高級工程師」開頭，學識咗 few-shot、chain of thought、角色扮演。你精心雕琢每一個詞，測試唔同嘅措辭，蒐集別人分享嘅「萬能 prompt」。
核心問題係：點樣用一段文字令模型俾出最好嘅回答。
佢有效，但係有天花板。因為你只係優化緊一個變量——輸入嗰段文字。模型嘅上下文窗口得咁大，你嘅 prompt 寫得再好，模型睇唔到項目嘅全貌，佢嘅回答就係無根之木。就好似你見工一個候選人，淨係俾佢睇一道題，但係就指望佢理解你整個系統嘅設計哲學。
Context Engineering（2025）：你俾模型睇啲乜
Andrej Karpathy 喺 2025 年提出咗一個關鍵觀點：與其優化 prompt，不如優化送俾模型嘅上下文。唔單止你嘅問題，仲包括相關文檔、代碼庫結構、工具定義、歷史對話、甚至即時嘅運行指標。
呢個就係由「點樣問老師一個好問題」進化成「點樣俾老師一份完整嘅背景材料」。
呢個轉變帶嚟咗實實在在嘅能力躍升。RAG（檢索增強生成）變成咗標配，MCP（Model Context Protocol）令模型可以動態連接外部工具同數據源，長上下文窗口令你可以將整個代碼庫塞俾模型。
但係當 AI 智能體開始真正自主執行任務時——自己讀代碼、自己行命令、自己提 PR、自己決定下一步做乜——齋俾好嘅上下文就唔夠啦。因為上下文解決嘅係「睇到」嘅問題，唔係「行為」嘅問題。一個智能體可以睇到你所有嘅架構文檔，但佢照樣可能寫出違反架構嘅代碼。睇到規則同遵守規則，係兩回事。
Harness Engineering（2026）：整個系統點樣運作
2026 年 2 月，HashiCorp 聯合創始人 Mitchell Hashimoto 俾咗呢個實踐一個名：「Engineer the Harness」——工程化嗰個套喺 AI 出面嘅繮繩。
幾日之後，OpenAI 發佈咗嗰篇報告。再幾日，Martin Fowler 跟進咗分析文章。一篇 arXiv 論文對佢做咗形式化定義。呢個概念喺幾星期內由一個口頭說法變成咗一個有嚴肅工程實踐支撐嘅學科方向。
Harness 唔係 prompt，唔係 context，而係包裹喺 AI 智能體周圍嘅整個運行環境：佢用得嘅工具，唔可以掂嘅嘢，犯錯點樣被糾正，人類點樣監控佢，同埋最關鍵嘅——佢嘅錯誤點樣被系統性消滅，而唔係淨係個案修復。
OpenAI 嘅實驗：零行手寫代碼造產品
呢個係目前最有說服力嘅案例。
OpenAI 嘅一個細團隊——三個核心工程師——用 Codex 智能體由零開始構建一個內部軟件產品。五個月，大約 1500 個 PR，超過一百萬行代碼。冇一行係人手寫嘅。
呢個數字本身已經夠震撼。但真正值得關注嘅唔係「AI 寫咗幾多代碼」，而係「人類做咗啲乜令 AI 可以寫咁多代碼」。
佢哋嘅 harness 包含三層：
第一層：增強嘅知識庫。 唔係簡單嘅 README，而係一整套餐持續更新嘅項目文檔——架構約定、命名規範、模塊邊界、數據結構定義。智能體每次開始工作前都會讀呢啲文件，就好似新員工入職第一日先讀公司 wiki。類似於 CLAUDE.md、.cursorrules 呢啲設定檔案嘅高級版本。而且，佢哋令智能體都可以訪問生產環境嘅可觀測性數據同瀏覽器——唔單止讀代碼，仲可以睇到代碼跑起嚟嘅樣。
第二層：架構約束嘅強制執行。 呢個係最關鍵嘅一層。佢哋唔靠「請遵守我哋嘅架構」呢種 prompt 黎約束智能體，而係用確定性工具——自定義 linter、結構化測試（類似 Java 入面嘅 ArchUnit）、pre-commit hook。智能體生成嘅代碼必須通過呢啲門檻先至可以合入。唔通過就彈返轉頭，冇得商量。
點解呢一層咁重要？因為佢哋發現咗一個反直覺嘅事實：限制解空間反而令智能體更高效，而唔係更低效。 當智能體可以生成任何代碼時，佢會浪費大量 token 探索死路。當 harness 定義咗清晰嘅邊界——淨係可以用呢啲模式、淨係可以依賴呢啲模塊、介面一定要係咁樣——智能體反而收斂得更快，產出質量更高。
呢個就好似寫十四行詩：格律嘅約束唔係枷鎖，而係令詩歌成其為詩歌嘅嘢。
第三層：熵管理。 呢個係最有趣嘅部分。佢哋發現，AI 寫代碼時間長咗會產生「熵」——文檔同實際代碼唔一致、架構邊界逐漸模糊、命名風格走樣、死代碼積累。人類代碼庫都有呢個問題，但 AI 生成嘅代碼因為速度太快，熵嘅積累速度都快好多。
於是佢哋專門行「垃圾回收」智能體，定期掃描項目，揾出唔一致嘅地方並修復。本質上，呢個係用 AI 嚟清理 AI 造成嘅混亂——一種自我維護嘅生態系統。
Mitchell Hashimoto 嘅原話：「每次你發現智能體犯咗一個錯誤，你就花時間將解決方案工程化入個系統度，令佢永遠唔可以再犯同樣嘅錯。」
呢個就係 harness 嘅核心哲學：將經驗教訓編碼入環境本身，而唔係編碼入 prompt。 Prompt 係一次性嘅囑咐，harness 係永久性嘅制度。
點解 Prompt 唔夠用
一個核心發現：模型唔可以可靠咁評估自己嘅輸出。
呢個同人類嘅盲點一樣——你寫咗一段代碼，你自己覺得冇問題，但 code review 時同事一眼就睇出咗 bug。AI 都係咁。佢生成嘅代碼可能通過咗功能測試，但違反咗你團隊嘅架構約定；可能風格一致，但引入咗微妙嘅性能退化；可能單睇每個 PR 都冇問題，但連續一百個 PR 之後，系統嘅整體一致性已經偷偷咁崩塌咗。
Anthropic 嘅研究都證實咗呢點：模型喺自我評估上存在系統性盲區。
Harness 嘅解決方案借鑑咗 GAN 嘅思路：生成器同評估器分離。 一個智能體寫代碼，另一個智能體審查。審查者有唔同嘅指令、唔同嘅關注點、唔同嘅檢查清單。再加上確定性工具（linter、測試）作為最後一道防線。
呢個模式意味住一個根本性嘅轉變：你唔再試圖造一個完美嘅 AI 程序員，而係造一個有組織架構嘅 AI 編程團隊——有人寫、有人查、有制度兜底。
對你嚟講有咩意義
如果你而家用 Claude Code、Cursor 或者 Copilot 寫代碼，你可能已經無意識咁做緊 harness engineering 嘅初級版本了：
- 你寫嘅 CLAUDE.md 或 .cursorrules？嗰個係 harness 嘅知識庫層。
- 你設定嘅 pre-commit hook 同 lint 規則？嗰個係 harness 嘅約束層。
- 你偶爾手動檢查 AI 生成嘅代碼係咪偏離咗架構？嗰個係 harness 嘅熵管理層（只係手動嘅）。
三個時代唔係替代關係，而係嵌套關係。Harness 包含 context，context 包含 prompt。你學咗嘅嘢都冇浪費，只係需要一個更大嘅框架嚟組織佢哋。
但核心認知嘅轉變係：停止優化 AI 本身，開始優化 AI 運行嘅環境。
呢個就好似管理團隊。你唔會透過反覆教一個實習生「請寫好代碼」嚟提升團隊產出——你會建立代碼規範、CI/CD 流程、code review 制度、架構文檔、新人入職手冊。好嘅管理者唔創造依賴，而係創造系統。
AI 智能體，就係你嘅新隊友。能力極強，產出驚人，但係需要體系化嘅工程環境嚟保證質量。
Harness，就係嗰套工程環境。
而而家，呢個學科先啱啱開始。
2023 年，所有人在學怎麼寫 prompt。
2025 年，前沿的人開始講 context engineering。
2026 年，一個新詞出現了：Harness Engineering。
這不是營銷概念。它來自一個真實的工程實驗——OpenAI 的一個七人團隊，用 Codex 智能體寫了一個完整的生產級產品。零行手寫代碼，1500 個 Pull Request，一百萬行代碼，歷時五個月。
這篇文章講的就是：他們是怎麼做到的，以及這件事對所有用 AI 寫代碼的人意味着什麼。
三個時代
Prompt Engineering（2023-2024）：你怎麼問
這是最早的階段。你學會了用"請扮演一個高級工程師"開頭，學會了 few-shot、chain of thought、角色扮演。你精心雕琢每一個詞，測試不同的措辭，蒐集別人分享的"萬能 prompt"。
核心問題是：怎麼用一段文字讓模型給出最好的回答。
它有效，但有天花板。因為你只在優化一個變量——輸入的那段文字。模型的上下文窗口就那麼大，你的 prompt 寫得再好，模型看不到項目的全貌，它的回答就是無根之木。就像你面試一個候選人，只給他看了一道題，卻指望他理解你整個系統的設計哲學。
Context Engineering（2025）：你給模型看什麼
Andrej Karpathy 在 2025 年提出了一個關鍵觀點：與其優化 prompt，不如優化送給模型的上下文。不只是你的問題，還包括相關文檔、代碼庫結構、工具定義、歷史對話、甚至實時的運行指標。
這就是從"怎麼問老師一個好問題"進化成了"怎麼給老師一份完整的背景材料"。
這個轉變帶來了實實在在的能力躍升。RAG（檢索增強生成）成了標配，MCP（Model Context Protocol）讓模型可以動態連接外部工具和數據源，長上下文窗口讓你可以把整個代碼庫塞給模型。
但當 AI 智能體開始真正自主執行任務時——自己讀代碼、自己跑命令、自己提 PR、自己決定下一步做什麼——光給好的上下文就不夠了。因為上下文解決的是"看見"的問題，不是"行為"的問題。一個智能體可以看見你所有的架構文檔，但它照樣可能寫出違反架構的代碼。看見規則和遵守規則，是兩件事。
Harness Engineering（2026）：整個系統怎麼運作
2026 年 2 月，HashiCorp 聯合創始人 Mitchell Hashimoto 給了這個實踐一個名字："Engineer the Harness"——工程化那個套在 AI 外面的繮繩。
幾天後，OpenAI 發佈了那篇報告。再幾天，Martin Fowler 跟進了分析文章。一篇 arXiv 論文對其做了形式化定義。這個概念在幾周內從一個口頭說法變成了一個有嚴肅工程實踐支撐的學科方向。
Harness 不是 prompt，不是 context，而是包裹在 AI 智能體周圍的整個運行環境：它能用什麼工具，不能碰什麼東西，犯錯了怎麼被糾正，人類怎麼監控它，以及最關鍵的——它的錯誤如何被系統性地消滅，而不只是被個案修復。
OpenAI 的實驗：零行手寫代碼造產品
這是目前最有說服力的案例。
OpenAI 的一個小團隊——三名核心工程師——用 Codex 智能體從零構建了一個內部軟件產品。五個月，大約 1500 個 PR，超過一百萬行代碼。沒有一行是人手寫的。
這個數字本身已經足夠震撼。但真正值得關注的不是"AI 寫了多少代碼"，而是"人類做了什麼讓 AI 能寫這麼多代碼"。
他們的 harness 包含三層：
第一層：增強的知識庫。 不是簡單的 README，而是一整套持續更新的項目文檔——架構約定、命名規範、模塊邊界、數據結構定義。智能體每次開始工作前都會讀取這些文件，就像新員工入職第一天先讀公司 wiki。類似於 CLAUDE.md、.cursorrules 這些配置文件的高級版本。而且，他們讓智能體也能訪問生產環境的可觀測性數據和瀏覽器——不只是讀代碼，還能看到代碼跑起來的樣子。
第二層：架構約束的強制執行。 這是最關鍵的一層。他們不靠"請遵守我們的架構"這種 prompt 來約束智能體，而是用確定性工具——自定義 linter、結構化測試（類似 Java 裏的 ArchUnit）、pre-commit hook。智能體生成的代碼必須通過這些門檻才能合入。通不過就打回，沒有商量。
為什麼這一層如此重要？因為他們發現了一個反直覺的事實：限制解空間反而讓智能體更高效，而不是更低效。 當智能體可以生成任何代碼時，它會浪費大量 token 探索死衚衕。當 harness 定義了清晰的邊界——只能用這些模式、只能依賴這些模塊、接口必須長這樣——智能體反而收斂得更快，產出質量更高。
這就像寫十四行詩：格律的約束不是枷鎖，而是讓詩歌成其為詩歌的東西。
第三層：熵管理。 這是最有意思的部分。他們發現，AI 寫代碼時間長了會產生"熵"——文檔和實際代碼不一致、架構邊界逐漸模糊、命名風格漂移、死代碼累積。人類代碼庫也有這個問題，但 AI 生成的代碼因為速度太快，熵的積累速度也快得多。
於是他們專門跑"垃圾回收"智能體，定期掃描項目，找出不一致的地方並修復。本質上，這是用 AI 來清理 AI 造成的混亂——一種自我維護的生態系統。
Mitchell Hashimoto 的原話："每次你發現智能體犯了一個錯誤，你就花時間把解決方案工程化進系統裏，讓它永遠不能再犯同樣的錯。"
這就是 harness 的核心哲學：把經驗教訓編碼進環境本身，而不是編碼進 prompt。 Prompt 是一次性的囑咐，harness 是永久性的制度。
為什麼 Prompt 不夠用了
一個核心發現：模型不能可靠地評估自己的輸出。
這和人類的盲點一樣——你寫了一段代碼，你自己覺得沒問題，但 code review 時同事一眼就看出了 bug。AI 也是如此。它生成的代碼可能通過了功能測試，但違反了你團隊的架構約定；可能風格一致，但引入了微妙的性能退化；可能單看每個 PR 都沒問題，但連續一百個 PR 之後，系統的整體一致性已經悄悄崩塌了。
Anthropic 的研究也證實了這一點：模型在自我評估上存在系統性盲區。
Harness 的解決方案借鑑了 GAN 的思路：生成器和評估器分離。 一個智能體寫代碼，另一個智能體審查。審查者有不同的指令、不同的關注點、不同的檢查清單。再加上確定性工具（linter、測試）作為最後一道防線。
這個模式意味着一個根本性的轉變：你不再試圖造一個完美的 AI 程序員，而是造一個有組織架構的 AI 編程團隊——有人寫、有人查、有制度兜底。
對你意味着什麼
如果你現在用 Claude Code、Cursor 或者 Copilot 寫代碼，你可能已經在無意識地做 harness engineering 的初級版本了：
- 你寫的 CLAUDE.md 或 .cursorrules？那是 harness 的知識庫層。
- 你設的 pre-commit hook 和 lint 規則？那是 harness 的約束層。
- 你偶爾手動檢查 AI 生成的代碼是否偏離了架構？那是 harness 的熵管理層（只是手動的）。
三個時代不是替代關係，而是嵌套關係。Harness 包含 context，context 包含 prompt。你學會的東西都沒浪費，只是需要一個更大的框架來組織它們。
但核心認知的轉變是：停止優化 AI 本身，開始優化 AI 運行的環境。
這就像管理團隊。你不會通過反覆教一個實習生"請寫好代碼"來提升團隊產出——你會建立代碼規範、CI/CD 流程、code review 制度、架構文檔、新人入職手冊。好的管理者不創造依賴，創造系統。
AI 智能體，就是你的新隊友。能力極強，產出驚人，但需要體系化的工程環境來保證質量。
Harness，就是那套工程環境。
而現在，這個學科才剛剛開始。