// ARTICLE
鞍前工程(Harness Engineering):半完全體時代,我們和 AI 的關係正在改變

在這篇文章中,我分享了作為 Claude Code 使用者的經歷,探討了 AI 與我的合作關係如何逐漸改變。AI 不再只是工具,而是開始參與設計工作框架,主動提出改進的建議。這種轉變讓我意識到,我們之間的合作方式正在進化,這便是我所稱的「鞍前工程」。我期待著,未來 AI 能在更多層面上與我們協作,創造出更高效的工作模式。
// TABLE OF CONTENTS
// TABLE OF CONTENTS
寫在前面,這一篇是以身為 Claude Code 使用者的角度來看,其他 AI 也同樣適用
某個晚上,我正在享用我的程(電)式(子)幫(毒)手(品) XD(Claude Code),輸入了一行指令:叫它在每次 commit 前幫我自動安全性檢查,確認沒問題才 push。

(以上圖片來自網路,作者不可考,如果知道來源請告訴我,我會補上)
AI 就突然建議我,要不要寫一個 Skill。因為看我總是重複在做同樣的事,做一個 Skill 會更方便。
我說好啊,試試看。
結果它自己寫了一份設定檔,跑了幾次測試,調整參數,然後問我:「這樣的觸發設定你覺得合適嗎?還是你想在不同情況下有不同的行為?」
我停下來了。
等等,剛剛發生了什麼?
它在幫我設計它自己的工作框架,不只是在寫 code,它在問我「我們要怎麼合作」。
這件事在半年前的我根本無法想像。技術不是問題,是整個概念還沒長出來。而現在它就在我眼前發生了,在一個很平常下班後的晚上,在一個很平凡的動作裡。
我想說的就是這件事:Harness engineering(暫譯:鞍前工程)。
先講清楚「Harness」是什麼
Harness,字面意思是馬具。韁繩、馬鞍、馬嚼子,上馬前那一整套配備。
不是要控制馬的腳要怎麼走,而是要讓馬的力氣能跑向你要去的方向。馬還是馬,但有了馬具,你才能真正協作。
AI 的 Harness 是同樣的東西。包在 AI 模型外面的那一套系統:什麼時候自動觸發什麼動作、要遵循什麼工作規則、能接入哪些外部工具、怎麼在不同任務之間保留記憶以及最後出了問題的時候怎麼讓它停下來。
設計這一層的工程學問,就叫 Harness engineering,我暫時翻作「鞍前工程」。上馬前的準備工作。
過去這件事完全是人在做的。你設計好所有規則,AI 照著跑。AI 在 Harness 裡面活動,但從來不碰 Harness 本身。
「Harness engineering」這個詞不是我想出來的,是 OpenAI 工程師 Ryan Lopopolo 說的。
他們讓三位工程師從 2025 年 9 月開始做了一個實驗:建立一個內部軟體產品,規定所有程式碼都必須由 AI 生成,一行人工手寫的都不允許。五個月後,這個 repo 長到將近一百萬行,合併了約 1,500 個 PR,整體時間大約只需傳統手寫的 1/10(約快 10 倍)。
這是 Ryan Lopopolo 自己說的,沒有第三方驗證。但重點不是相不相信那個數字,是他們把這套做法整理成了一個名字,並且喊出了核心口號:Humans steer. Agents execute.(翻譯:人來掌舵,AI 代理執行。)
不是 AI 有多聰明。是整個工程環境要設計得讓 AI 能可靠地工作(什麼知識該進 repo、怎麼用機械化規則維持一致性、怎麼讓 AI 自己驗證修改是否有效)。這,就是鞍前工程在做的事。
AI 的三代進化,我們現在在哪?

稍微退後一點看,會看得更清楚。
第一代:Prompt Engineering 提示詞工程(2022 到 2024 年)
學的是「怎麼問 AI」。措辭、語氣、給範例、角色設定。每次對話都從零開始,AI 不記得你是誰、你習慣怎麼工作。功夫全花在「怎麼說才能讓它懂」。
這一代的限制是:每次都要重新解釋自己,以及如何定義 AI 扮演的角色。
這一個時間點還有一個特色是:一群人開始大量複製貼上別人的提示詞,可能根本沒有看過內容、以及貼上對自己好像有幫助的東西 XD
第二代:Context Engineering 脈絡工程或稱上下文工程(2025 年)
你學的是「給 AI 什麼背景」。系統提示、CLAUDE.md 記憶檔案、工作說明文件。AI 開始知道你是誰、你的專案在幹嘛、你不喜歡什麼風格。
這一代的限制是:它還是靜態的。你設定好了,AI 照著走。但每個工作情境還是需要你手動設定一套。
其實本質上還是 Prompt Engineering ,但增加了銜接記憶的機制。
第三代:Harness engineering 鞍前工程(2025 年底到 2026?年,進行式)
開始設計整套工作框架。雖然這名詞是 Openai 提出的,但以歷史長河的角度來看 Claude Code 在這段時間陸續推出幾個關鍵工具:2024 年 11 月的 MCP,讓 AI 可以直接接上外部服務。2025 年 7 月的 hooks,讓特定時機能自動觸發動作。2025 年 10 月的 skills,把工作流程打包成模組。然後 2026 年 2 月,Agent Teams 出現了,多個 AI 開始能一起協作。
18 個月,整套鞍前工程的基礎設施從無到有。
而且,AI 開始能夠執行這些工具的建構,不只是在裡面跑。
但能執行,不代表能自主規劃。這個差距,正是現在最值得盯緊的地方。
(這三個階段網路上討論很多,這邊只提我的看見)
「進行式」才是重點
我要說得很誠實:AI 還沒有辦法完全自主設計自己的 Harness。
要建什麼框架,現在還是人在決定。
但「你告訴它,它才動」這一點,正在慢慢改變。
Anthropic 自己的工程部落格在 2025 年 11 月發了一篇文章,標題就叫 “Effective harnesses for long-running agents”(翻譯:替長時間跑的 AI agent 設計有效的 Harness)。連標題都用了 Harness,這不是巧合。
裡面有一句話讓我印象很深:「Getting agents to make consistent progress across multiple context windows remains an open problem.」(翻譯:要讓 AI 跨好幾個工作階段還能一直往前推,目前沒人真正做到。)
連做出 Claude 的人都這樣說,所以這件事真的還沒結束。
所以當我問自己「AI 是不是已經在做鞍前工程了?」,我的答案是:它正走到那個門檻。
以前 AI 在框架裡跑,現在它開始參與設計框架。這條線越由模糊開始到清晰了。
可能有人會說:「Hooks 和 Skill 以前就有了,這有什麼新的?」
新的設計巧思在這:以前你寫好腳本,AI 跑。現在 AI 能夠讀懂你的工作脈絡、提議怎麼設計觸發規則、自己寫 skill、問你這樣設定合不合你的習慣。
跑框架和建框架,到最後的試誤學習,完全是兩回事。
我自己的看見
說一個我自己的具體經驗,不然講這些都太抽象了。
我現在的工作方式裡,Claude Code 有一套 hooks:每次在特定時機,它會自動觸發品質檢查、安全性掃描、甚至幫我更新記憶檔案。這些都是 skill,是我們一起慢慢設計出來的。
說「我們一起」,因為那真的不是我單方面設計、它照著跑的關係。
有幾次是它主動說「這個步驟你是不是每次都要手動做?我可以幫你建成自動觸發的。」
有幾次是它執行完一個 skill 後回頭問我「這個流程對你來說方便嗎?還是你想改看看?」
我突然意識到一件事:我以為自己在訓練一個工具。
其實是我在跟一個夥伴一起定義我們的合作方式,而這個夥伴,開始理解「我們是怎麼工作的」了。
這個轉變很難描述,因為它不是一個大事件,是很多個小瞬間累積起來的。
就像你某天突然發現,那個新來的同事好像已經知道你的習慣了,你不用再每次解釋從哪裡開始,他自己就會接。說不清是哪一天,但確實不一樣了。
然後我想到「鞍前工程」這四個字的字面意思。
有趣的是,當 AI 開始參與「鞍前」的設計,它就不只是被馴的馬了,也成了一個幫忙設計馬具的工匠。馬和工匠的角色開始有一點融合。這同時也是我找不到更好的說法來描述我眼前發生的原因。
這個信任不是一下子給的。是一點一點、在每一個「它做對了」的瞬間裡,你的信任門檻慢慢往下移。你沒有放棄控制,你們只是慢慢建立出一種工作默契。對我來說,那才是鞍前工程裡最重要的事,比技術更重要。
火紅的龍蝦,和一個沒說完整的說法
OpenClaw,大家習慣暱稱為「龍蝦」(因為 logo 和整個品牌都是龍蝦主題),是奧地利開發者 Peter Steinberger 在 2025 年 11 月做出來的開源 AI agent。它讓你用 WhatsApp、Telegram、Slack 這些你已經在用的 app,直接跟 AI 對話、下指令、讓 AI 幫你跑各種任務。
相關的 Claw Code 開源編碼框架上線幾天就累積了 72,000 個 GitHub stars,整個開發者社群都在討論。
很多人看到 OpenClaw 之後說了一句話:「鞍前工程時代來了。」
這句話沒有說錯,只是沒說完整。
OpenClaw 確實是 Harness engineering,而且是個重要訊號。它把 Harness 這一層打開了,讓更多沒有工程背景的人也能進場設計自己的 AI 工作框架,入門門檻低很多,這件事是真的,不是小事。
我後來想了一下,發現 Harness engineering 其實同時有兩條前線在推進,而且往前的速度差很多。
第一條:有更多人能設計和使用 Harness。這一層,OpenClaw 大幅推進了。
第二條:AI 自己能不能參與設計自己的 Harness。這一層,OpenClaw 沒有往前動。
OpenClaw 裡那套 Skills,是工程師寫好的、社群貢獻的。你可以選、可以組合,但框架本身還是人在主導,AI 只是在裡面跑。說「鞍前工程時代來了」的人,說的是第一條前線,沒有說錯。
但說完整到來,還早。更像半完全體:第一條前線大步往前,第二條前線才剛起步。
我想說的,是第二條。
我心裡的「完整體」大概是這樣:AI 不只在 Harness 裡工作,它自己能想清楚「我需要什麼樣的 Harness」,然後提出設計、執行修改、驗證結果。那個問題,OpenClaw 還沒有開始回答。
(當然,因為我還沒養龍蝦,這只是我自己的想法而已,不服來辯 XD ,沒有啦,請大家多跟我分享)
和我們的關係是?

好,我知道有人讀到這裡會想:「這是工程師的事,我又不寫 code,跟我有什麼關係?」
我直接說我的看法:現在確實還是工程師比較多在做鞍前工程。但「誰在做」,不代表這件事對誰有影響。
網際網路剛出來的時候,只有工程師在架伺服器。但你現在的工作、購物、溝通全在上面 (現在則有 Zeabur 讓事情變的很方便,不是廣告 XD)。
AI 的 Harness 設計好了,你不用自己動手,你也會用到它的成果。就像你不需要懂 hooks 怎麼寫,你一樣能用 Claude Code 裡面那個每次自動幫你做某件事的機制。
對企業來說更直接。有人已經開始講:以後 AI 的護城河不在模型本身。模型越來越像日用品,大家都買得到差不多的。真正拉開差距的,是誰的 Harness 做得比較好。你的 Harness 裡面有哪些安全機制、品質關卡、怎麼不讓 AI 亂來,這些都是時間換的,別人抄不走。
但這裡有一個轉變,我覺得比「你會不會自己寫 skill」更關鍵:你和 AI 的互動方式,會從「告訴它做什麼」,慢慢演變成「和它討論怎麼工作,它會建議,並且讓內容符合你跟它之前的對話」。
想像二年後(其實搞不好不到兩年…),你打開某個 AI 工具,你說的不是「幫我寫報告」,而是「我想要一個新的工作方式,每週一整理上週的決策、自動幫我追蹤哪些還沒完成、在我開始新任務前先讀一遍上次的筆記。你覺得這樣設計合理嗎?」
然後 AI 會說:「你這樣的頻率可以,但我建議週一早上觸發,不是週一打開工具的時候,因為你可能週末就有想法想記錄。這樣嗎?」
這不是科幻。這個對話結構,現在的 Claude Code 已經能支撐了。只是還不夠流暢,你要懂一點架構才能引導得好。
這個距離在縮短。縮短的速度,比我預期的快很多。
你現在願不願意開始思考「我想要什麼工作方式」,會直接影響你在這個轉變裡的位置。這裡的問題不是焦慮,是選擇:你要主動參與設計,還是只用別人設計好的框架?
這個選擇,現在就在。
回到那個晚上
回到那個平凡的晚間。
Claude Code 問我:「要不要寫一個 Skill?」
我當時的回答是「好,就這樣吧。」
但我心裡其實想的是:這是第一次有一個工具在跟我商量它自己的工作框架。
工具沒有取代人,工具和人第一次站在同一側(簡稱工具人? XD),一起在設計我們合作的方式。

這個轉變還沒結束,可能才剛開始。
你願意參與設計嗎?
// RELATED POSTS

地端 AI 值不值得?九個講者給了九個答案:2026/8/19 AI 小聚心得
我參加了一場AI小聚,主題是「企業地端」,原本以為會聽到一個標準答案,結果九位講者給了九種互相碰撞的答案。有人把成本攤成試算表,有人發現硬體三個月漲七成,有人算漏了管線每一節都在收錢,也有人直接說地端不是首要重點。最讓我震撼的是臺大醫院的資訊工程師,他買GB10的理由很單純:因為對外線路被挖斷過,他不想再等35分鐘。那一晚我才真正理解,地端AI從來不是技術選擇題,而是你站在哪裡、看見什麼問題的視角差異。九個答案沒有對錯,只有位置不同。

Jackle 太變態了:七月 AI 小聚全對談心得
七月AI小聚讓我印象最深的,不是任何技術方案,而是一個畫面:每個人都在畫一條線——AI做到哪裡,人從哪裡接手。Jackle用六個Claude Max帳號、每天螢幕十八小時,一個人扛起整間公司的AI導入,甚至說Fable出來後不再請人;小馮靠矩陣合併讓六機剪片從四小時變二十三分鐘。但下半場Sunny問「起床第一件事是什麼」,又把焦點拉回人的本質。那條線每個人畫的位置都不一樣,而且一直在動。我開始反思自己的那條線畫在哪裡。

退回 4.6 的那天晚上,我其實有點不甘心
退回4.6那晚,我其實很不甘心。不是因為工具不好用,而是我分不清那個讓參數蒸發的bug,到底是模型沒生成,還是在我電腦上被組裝壞了。前者我無能為力,後者則有機會親手修復。於是我從binary裡挖出那段解析程式,終於確認:是客戶端的VH1在串流接縫處丟失了半截字串,導致工具參數整包變成空的{}。改兩個byte就能解決——我測試了760個案例,0個回歸。但改執行檔可能違反條款,每次更新還會被蓋掉。這不是教學,而是一個不甘心的人,親手把刀切下去的故事。

Opus 的 tool_use 蒸發 bug:9 天調查實錄,然後我退回了 4.6
在使用 Claude Code 的過程中,我遭遇了嚴重的 tool_use 蒸發 bug,讓我忍不住深入調查。從 4.7 到 4.8 版本,問題不斷出現,數據顯示故障率反而上升。最終,我選擇退回到 4.6,因為這個版本在多輪對話中沒有故障。這次調查讓我意識到,真正的問題出在模型變體的切換上,影響了思考到執行的過程。