OpenAI 的 Harness Engineering 實驗：新手版完整解讀

OpenAI 的 Harness Engineering 文章記錄了一個團隊如何重整工作環境，讓 Codex 能持續完成並驗證開發任務。

五個月、一百萬行程式碼、約 1,500 個 Pull Request，是文章裡最醒目的數字。它們容易讓人把故事簡化成「AI 取代工程師」，也引出作者真正追問的問題：當工程師不再親手輸入每一行程式，時間應該花在哪裡？

本文依據 OpenAI 工程師 Ryan Lopopolo 在 2026 年 2 月發表的 Harness 工程：在智慧體優先的世界中善用 Codex。下文會先說明文章中的實驗，再把做法拆成新手能理解的工程原則。文中數字是 OpenAI 對內部專案的描述與估算，不是獨立驗證的產業基準。

本篇聚焦 OpenAI 的 Codex 開發實驗，以及它能教給新手什麼。

先弄懂 Harness 是什麼

可以把模型想成一位很會照指示做事、但不會自動看見整間辦公室的同事。它需要知道工作目標、可以使用哪些工具、去哪裡找資料、哪些事情不能做，以及怎麼判斷結果對不對。

包住模型的這套工作系統，就是 Harness。它通常包含任務指示、工具、程式碼與文件、執行環境、權限限制、測試、日誌和錯誤處理。把這套系統設計好並持續改善，就是 Harness Engineering（Harness 工程）。只給模型一個更長的提示詞，並不會自動補齊這些東西。

如果把「修改登入頁」交給模型，Harness 要能提供相關程式碼和設計規則，讓模型在隔離的工作區修改，執行測試，必要時開啟頁面實際操作，最後留下可以檢查的結果。模型負責提出和調整做法；Harness 負責提供環境並接住整個工作循環。

OpenAI 這次的實驗，就是試著讓這套系統承擔更多工作。

OpenAI 的實驗實際做了什麼

OpenAI 團隊從空的程式碼庫（repository，管理一個專案程式碼與文件的地方）開始，用 Codex 開發一項內部產品。原文稱已有數百位公司內部用戶，也交給外部 alpha 測試者（早期試用者）。依文章說法，產品程式、測試、持續整合設定（CI，每次修改後自動執行的檢查）、文件與開發工具都由 Codex 產生，人類沒有手動撰寫產品程式碼。人仍負責選擇要做什麼、描述需求、設計工作環境和驗證成果。

文章回顧五個月的進度，提到程式碼庫約一百萬行、約 1,500 個 Pull Request（PR，送交團隊檢查並合併的修改）。團隊從三位工程師擴展到七位。原文還估算每位工程師平均每天合併約 3.5 個 PR，而且團隊擴大後，每段時間能完成的工作量仍增加。團隊估算，完成這項產品所需時間約為手動撰寫程式的十分之一。

這些數字只能說明 OpenAI 對自家內部實驗的觀察。PR 數量也不能單獨證明程式品質。這篇文章沒有證明其他團隊換成 Codex 後也會有相同產量或速度。

更值得看的變化，是工程師開始把大量時間花在模型周圍的系統上。早期進度慢時，他們沒有只反覆換模型或加長提示詞，而是檢查 Codex 缺了什麼工具、文件或執行能力。

這個判斷會在全文反覆出現：遇到失敗，先問工作環境少了什麼。

讓 Codex 看得到、操作得到，也查得到結果

先給一張地圖，再按需要打開文件

大型程式碼庫很難靠一份說明文件完整介紹。OpenAI 起初試過把大量背景都塞進 AGENTS.md（Codex 讀取的專案常駐指示檔），結果重要任務資訊被淹沒，規則也難以持續更新。

後來他們讓 AGENTS.md 擔任地圖，指向分門別類的架構說明（模組如何分工與相依）、產品規格、執行計畫與技術參考。Codex 可以先讀簡短的入口，再依任務打開相關文件。團隊也用檢查規則確認文件是否有索引、連結和更新紀錄，並安排 Codex 定期找出過期內容。

新手可以從較小的做法開始。用一份短的專案指引標出程式碼、測試和重要規則；細節放進相關文件，任務需要時再讀取。

讓工作過程對 Codex 可見

只看程式碼變更，常常無法判斷畫面實際呈現什麼，也難以知道服務為何失敗。OpenAI 會用 Git worktree（讓不同分支各有獨立工作目錄的功能）替每項變更啟動應用程式，避免一項修改干擾另一項。團隊也把日誌、指標（用數字呈現速度或錯誤率）和瀏覽器操作能力接給 Codex。

例如，工程師可以要求「確認這個頁面在特定操作下兩秒內完成」，Codex 便能啟動應用程式、操作頁面、查看執行紀錄，再依結果修改。文章也舉例，用指標檢查服務是否在 800 毫秒內啟動，或重要操作是否超過兩秒。這和只讓模型讀取原始碼後宣稱「應該沒問題」差很多。

每個工作目錄都有自己的應用程式和觀測資料，完成後再拆除。這讓 Codex 能把日誌和指標對應到自己正在修改的版本，減少其他工作造成的干擾。

接入工具前，先確認它能讓 Codex 觀察到哪個原本看不見的結果，以及回傳資訊是否足以支援下一個判斷。

用規則守住架構邊界

架構可以先理解成模組如何分工、彼此可以怎麼呼叫。文件能說明這些規則，但文件無法單獨阻止錯誤依賴。OpenAI 把程式分成固定層次，並用自訂程式檢查與結構測試，禁止不合法的依賴方向。

團隊會定義必須遵守的邊界，例如某一層可以呼叫哪些元件、資料進入系統前要在哪裡解析、日誌格式要如何保持一致。至於在邊界內怎麼實作，則留給 Codex 選擇。

這種方式比逐步規定程式該怎麼寫更容易擴大使用。檢查器能同時套用到許多變更，而且失敗訊息可以直接告訴 Codex 哪一條規則沒通過。

新手不用先寫一套大型架構規範。先找出常見、代價高的錯誤，再把能明確判斷的規則交給測試或檢查工具。

自主性來自一連串可回饋的步驟

文中描述的 Codex 工作循環，已經超過「產生程式碼」：檢查目前狀態、重現問題、記錄畫面、修改程式、重新操作應用程式、開啟 PR、讀取審查意見，再處理建置失敗。只有碰到需要人判斷的問題時，才升級給人。

Codex 要能獨立完成更多步驟，必須有可用的工具、清楚的驗收條件和隔離環境。沒有工具，它就不能操作應用程式；沒有驗收條件，它不知道何時算完成；沒有隔離環境，一項測試也可能干擾其他工作。每個步驟都要把結果交給下一步。

你可以把這看成一個循環：Codex 執行一小步，系統回報實際結果，Codex 再決定下一步。測試失敗、頁面錯誤和審查意見都會告訴它該往哪裡修正。

把重複的清理工作改成系統規則

Codex 會沿用程式碼庫裡既有的模式，即使那些模式本來就不一致。文章說，團隊早期每週五會花一整天（約一週工時的 20%）清理「AI 殘渣」，也就是重複、偏離規範或品質不一致的程式碼。但這種人工整理無法隨產量一起擴大。

後來團隊把部分品質原則做成檢查工具，也安排 Codex 定期搜尋偏差並提出小型重構。人類仍需決定哪些規則有價值；只要規則能清楚描述，系統就能更穩定地在每次工作裡執行。

對新手來說，先記下反覆發生的失敗。例如，Codex 每次都忘記跑某一組測試，就把測試放進固定的驗收流程；常常把 API 回應猜錯，就先要求程式在邊界解析資料，再把錯誤型別交回給模型。重複提醒同一件事，通常表示流程缺了可執行的規則。

哪些做法不能直接照搬

OpenAI 文章最重要的提醒之一，是這套流程高度依賴當時的程式庫結構和內部工具。團隊刻意採用較少阻擋的合併流程；測試偶爾失敗時，他們會重跑不穩定的測試（flaky test，也就是同一份程式有時通過、有時失敗的測試），避免它長時間阻塞流程。作者也指出，這在低產量團隊可能是不負責任的做法。

這些速度數字也來自特定的產品、團隊和工作方法。它們不是換上某個模型就能得到的保證。若你的產品會處理付款、個資或正式客戶資料，審查與驗證不會因為程式碼產量增加就變得不重要。

新手可以學它們設計環境、寫清楚規則和收集回饋的方式；不要只複製它們的快速合併和有限人工介入。

新手可以從一件小工作開始

挑一項低風險、可重複的任務，例如替一個元件補測試。先把成功條件寫成可以檢查的結果：測試要通過，原有功能不能變，而且差異只能出現在指定目錄。

接著，準備 Codex 需要的專案地圖、工具與權限。讓它在隔離的工作區完成修改，並要求它執行測試和檢查實際輸出。最後親自確認結果是否符合條件。

如果 Codex 反覆在同一處出錯，不要只在下次提示詞裡重複提醒。看看是文件找不到、工具回報不清楚、測試沒涵蓋，還是權限配置錯了。找出原因後，把修正放進工作環境，讓下一次執行也能受益。

我會用一句話總結這篇文章：工程師仍然要做工程，只是工作的重心逐漸從逐行撰寫程式，移到設計 Codex 能理解、能操作、也能驗證的工作系統。

下一篇會把這些原則放到 Codex app 的實際工作流程裡，逐項探討工程師如何設計專案指示、工具連接、權限、隔離工作區和驗收回饋。這篇 OpenAI 的文章說明原理；Codex app 那篇則回答如何把原理落到每天的工作方式。

來源

• OpenAI：Harness 工程：在智慧體優先的世界中善用 Codex，2026 年 2 月 11 日。