Harness Engineering（AI駕馭工程）入門篇：OpenAI最新編程標準，教你輕鬆做到Lv.1

OpenAI 工程師在五個月內用 AI 代理產出了 100 萬行程式碼，而人類從頭到尾沒有親手寫過一行 code。這背後的方法論叫做「Harness Engineering（駕馭工程）」，靠著駕馭 AI 工具，重新定義軟體工程師的角色。 （前情提要：Claude Code 新增雲端定時任務：不用開電腦，AI 自動幫你審 PR、升級依賴） （背景補充：Cursor 用 Kimi K2.5 訓模型卻沒說，開發者抓包、刪推、官方急轉彎全紀錄）   如果你最近有在關注 AI 與軟體開發的交會點，你一定會注意到一個新詞正在矽谷瘋傳：Harness Engineering。這個由 OpenAI 內部團隊提出的概念，描述了一種全新的軟體開發模式。在這種模式裡，工程師不再親手寫程式碼，而是設計一套「駕馭系統」，讓 AI 代理（Agent）在這個系統裡自主完成從寫 code 到提交 PR 的所有事情。 這聽起來像科幻小說？其實已經發生了，OpenAI 已經用這種方式，在五個月內從零打造了一個包含百萬行程式碼的完整產品，而且這不是實驗室裡的 demo，是每天有數百名員工在使用的真實產品。 本篇是「Harness Engineering」系列教學的「入門篇」，會用最白話的方式，把 OpenAI 工程師 Ryan Lopopolo 發表的這篇重量級文章，從頭到尾解釋給你聽。 先搞懂為什麼需要一個新名詞？ 在過去兩年裡，我們已經經歷了好幾波 AI 輔助開發的浪潮，從最早的 GitHub Copilot（像自動補完般幫你接下一行 code），到後來的 Cursor、Claude Code 這些更聰明的 AI 程式助手，再到現在的「AI 代理」（Agent），可以自己開一個分支、跑測試、提交 Pull Request。 但隨著 AI 代理越來越強，一個根本性的問題浮現了！ 模型本身已經不是瓶頸，模型周圍的系統才是 什麼意思？想像你僱了一個超級能幹的新員工。他寫 code 的速度是你的十倍，但他第一天上班，你只丟給他一句「去做那個功能」，沒有給他看架構圖、沒有告訴他團隊的 coding style、沒有讓他跑過測試環境。結果會怎樣？他會非常努力地寫出一堆不符合規範、跟現有系統格格不入的程式碼。 這就是目前大多數人使用 AI 代理的狀態，模型很強，但環境本身沒準備好。 Harness Engineering 就是在解決這個問題。它不是在改良模型本身，而是在設計「模型周圍的一切」，讓 AI 代理能在一個精心設計的環境裡，可靠、高效、持續地產出高品質程式碼。 一個很古老的比喻：瓦特的離心變速器 OpenAI 在文章裡用了一個非常巧妙的歷史類比，1788 年，蘇格蘭工程師詹姆斯·瓦特（James Watt）發明瞭離心變速器（centrifugal governor），這是一個安裝在蒸汽引擎上的機械裝置。在那之前，工人必須持續手動調整蒸汽閥門，來維持引擎的穩定轉速。 變速器改變了工作的模式，工人只需要設定目標轉速，機械結構會自動維持運作。 Harness Engineering 的核心哲學跟這個一模一樣： Humans steer, agents execute.（人類掌舵，代理執行。） 工程師不再是「手動調整閥門」的人（也就是一行一行寫 code 的人），而是「設計變速器」的人（設計讓 AI 能自主穩定運作的系統）。這個從「操作員」到「設計師」的轉變，就是 Harness Engineering 的核心。 OpenAI 的實驗 讓我們先看看 OpenAI 這個實驗的具體成果，因為這些數字本身就很有說服力： 時間: 五個月（從 2025 年 8 月開始） 程式碼量: 約 100 萬行（涵蓋應用邏輯、基礎設施、工具、檔案、內部開發工具） 人類手寫的程式碼: 零行 團隊人數: 從 3 人逐步擴充套件到 7 人 合併的 Pull Request 數: 約 1,500 個 每位工程師每天產出: 平均 3.5 個 PR AI 代理單次自主工作時長: 超過 6 小時 產品狀態: 已有數百名內部使用者每天使用 這裡有幾個關鍵數字值得特別注意。 首先「零行手寫程式碼」不是形容詞，是這個團隊要追求的核心。他們不是「大部分用 AI 寫，偶爾手動修一下」，而是從立項之初就定下一條規則：人類永遠不直接寫程式碼。 這條規則逼著團隊必須認真投資在代理的基礎設施、上下文管理和工作流程設計上。如果你永遠不能「自己動手修一下」，你就必須把系統做到讓 AI 自己能修。 再來「3.5 個 PR / 人 / 天」這個數字。在傳統軟體開發中，一個工程師一天能合併一個 PR 就算不錯了。3.5 倍的產出意味著每個工程師的有效產能大約是傳統的 3 到 10 倍。換算下來，這個 7 人團隊的產出大約等於一個 21 到 70 人的傳統團隊。 第三是關於「布魯克斯定律」（Brooks’s Law） 軟體工程界有一條經典定律：「在一個已經落後的專案裡加人，只會讓它更慢。」 因為人多了，溝通成本會呈指數增長。但 OpenAI 的實驗打破了這個魔咒。當團隊從 3 人擴充套件到 7 人時，整體產出呈近線性增長，並沒有出現傳統的溝通瓶頸。 為什麼？因為工程師之間的「溝通」很大一部分被轉移到了檔案系統和代理指令裡。AI 代理不會開會、不會在 Slack 上聊天、不會去搞辦公室政治浪費時間。它們讀檔案、跑測試、提交 PR，效率取決於系統設計的品質，而不是人與人之間的溝通成本。 Harness Engineering 的正式定義 好，看完OpenAI提出的數字，讓我們正式定義這個概念。 Harness Engineering（駕馭工程）是一門設計基礎設施、約束條件和回饋迴圈的學科，目的是讓 AI 代理能可靠且大規模地運作。 「Harness」這個英文字本身就很有畫面。它的原意是「馬具」，就是那套套在馬身上的韁繩、馬鞍和控制裝置。AI 模型是那匹強大但不可預測的馬，Harness 就是韁繩、馬鞍...