近日 OpenAI 在自家的部落格裡面分享了他們過去五個月的秘密實驗：一個由三名工程師組成的小團隊，完全依靠 Codex AI 代理，在未手寫任何一行程式碼的情況下，開發出包含 100 萬行程式碼的完整產品 。這也標示了傳統以軟體工程師（或一整個團隊）進行開發大型專案的概念有了根本性轉變：從「人類編寫程式碼」到「人類駕馭 AI 編寫程式碼」。OpenAI 將這種新模式稱為「Harness Engineering」（駕馭工程），其核心哲學可以用一句話概括：「Humans steer, agents execute」（人類掌舵，代理執行）。
100 萬行程式碼的誕生：一個完全由 AI 生成的產品
這個實驗始於 2025 年 8 月底，OpenAI 團隊從一個空的 Git 儲存庫開始，使用 Codex CLI 配合 GPT-5，僅憑一小組現有模板生成了初始架構：包括儲存庫結構、CI 配置、格式化規則、套件管理器設定和應用框架。甚至指導代理如何在儲存庫中工作的 AGENTS.md 文件，本身也是由 Codex 撰寫的。
五個月後，這個儲存庫包含了約 100 萬行程式碼，涵蓋應用邏輯、基礎設施、工具、文件和內部開發者工具。在這段期間，約有 1,500 個 Pull Request 被打開並合併，而驅動 Codex 的工程師團隊僅從最初的 3 人擴展到 7 人。這意味著平均每位工程師每天產出 3.5 個 PR，且隨著團隊擴大，產能持續增加。
更重要的是，這不只是為了產出而產出。該產品已有數百名內部用戶，包括每日使用的內部重度用戶。整個開發過程中，人類從未直接貢獻任何程式碼：這成為團隊的核心哲學：沒有人工編寫的程式碼。
Harness Engineering：重新定義工程師的角色
「Harness」一詞源自馬具（手綱、鞍等），象徵著人類對馬匹力量的駕馭與控制。在 Harness Engineering 的框架下，工程師不再是被稱為「碼農」的程式碼生產者，而是系統的設計師和環境的建構者。
OpenAI 團隊發現，早期的進展比預期慢，並非因為 Codex 能力不足，而是因為環境定義不夠充分。代理缺乏完成高層次目標所需的工具、抽象概念和內部結構。因此，工程團隊的主要工作變成「讓代理能夠有效工作」，這意味著深度優先的工作方式：將大目標分解為更小的構建模塊（設計、程式碼、審查、測試等），提示代理構建這些模塊，並用它們來解鎖更複雜的任務。
當出現問題時，解決方案幾乎從不是「再試一次」。因為唯一能取得進展的方式是讓 Codex 完成工作，人類工程師總是會深入任務並自問：「缺少什麼能力，我們如何讓它對代理來說既清晰又可執行？」
人類幾乎完全通過提示與系統互動：工程師描述任務，運行代理，並允許它打開 Pull Request。為了推動 PR 完成，他們指示 Codex 在本地審查自己的更改，請求額外的特定代理審查（本地和雲端），回應任何人類或代理給出的反饋，並在循環中迭代直到所有代理審查者都滿意。隨著時間推移，他們幾乎將所有審查工作推向代理對代理的處理。
讓應用程式對 AI 可讀
隨著程式碼產出增加，瓶頸變成了人類 QA 能力。因為固定約束是人類時間和注意力，團隊致力於通過讓應用程式 UI、日誌和應用指標本身直接對 Codex 可讀來增加代理的能力。
例如，他們讓應用程式可以按 Git worktree 啟動，這樣 Codex 可以為每次更改啟動和驅動一個實例。他們還將 Chrome DevTools Protocol 接入代理運行時，並創建用於處理 DOM 快照、截圖和導航的技能。這使 Codex 能夠重現錯誤、驗證修復，並直接推理 UI 行為。
他們對可觀察性工具也做了同樣處理。日誌、指標和追蹤通過本地可觀察性堆疊暴露給 Codex，該堆疊對於任何給定的工作樹都是短暫的。代理可以在完全隔離的應用版本上工作——包括其日誌和指標，這些在任務完成後會被拆除。代理可以用 LogQL 查詢日誌，用 PromQL 查詢指標。有了這些上下文，「確保服務啟動在 800 毫秒內完成」或「這四個關鍵用戶旅程中的任何跨度不超過兩秒」這樣的提示變得可行。
團隊經常看到單個 Codex 運行在單個任務上工作長達六小時以上：通常是在人類睡覺的時候。
架構強制與品味約束
僅靠文件無法保持完全由代理生成的程式碼庫的一致性。通過強制執行不變量而非微觀管理實現，他們讓代理快速交付而不破壞基礎。例如，他們要求 Codex 在邊界處解析數據形狀，但不規定具體如何實現（模型似乎喜歡 Zod，但他們沒有指定那個特定庫）。
代理在具有嚴格邊界和可預測結構的環境中最有效，因此他們圍繞嚴格的架構模型構建應用程式。每個業務領域被劃分為一組固定的層，具有嚴格驗證的依賴方向和有限的可允許邊緣。這些約束通過自定義 Linter（當然也是 Codex 生成的！）和結構測試機械地強制執行。
這種架構通常要等到有數百名工程師時才會採用。但對於編碼代理，這是早期的先決條件：約束是允許速度而不衰減或架構漂移的關鍵。在人類優先的工作流程中，這些規則可能感覺苛刻或限制。對於代理，它們成為倍增器：一旦編碼，它們就同時應用於所有地方。
代碼吞吐量改變合併哲學
隨著 Codex 的吞吐量增加，許多傳統的工程規範變得適得其反。儲存庫以最小化的阻塞合併門檻運行。Pull Request 生命週期短暫。測試不穩定通常通過後續運行解決，而非無限期阻塞進度。在代理吞吐量遠超人類注意力的系統中，修正成本低，等待成本高。
這在低吞吐量環境中是不負責任的。在這裡，這通常是正確的權衡。
完全自主的臨界點
隨著更多開發循環被直接編碼到系統中：測試、驗證、審查、反饋處理和恢復，儲存庫最近跨過了一個有意義的閾值，Codex 可以端到端地驅動新功能。
給定單個提示，代理現在可以：驗證儲存庫的當前狀態；重現報告的錯誤；錄製展示失敗的影片；實現修復；通過驅動應用程式驗證修復；錄製第二個展示解決方案的影片；打開 Pull Request；回應代理和人類反饋；檢測和修復構建失敗；僅在需要判斷時升級給人類；合併更改。
這種行為嚴重依賴於該儲存庫的特定結構和工具，不應假設在沒有類似投資的情況下能夠泛化：至少，目前還不行。
熵與垃圾回收：維護 AI 生成的程式碼庫
完全代理自主也引入了新的問題。Codex 會複製儲存庫中已經存在的模式：即使是不均勻或次優的模式。隨著時間推移，這不可避免地導致漂移。最初，人類手動解決這個問題。團隊曾經每個星期五（一週的 20%）清理「AI slop」。毫不奇怪，這無法擴展。相反，他們開始將所謂的「黃金原則」直接編碼到儲存庫中，並建立了一個定期的清理流程。這些原則是機械的、有主見的規則，保持程式碼庫對未來代理運行清晰和一致。
這就像垃圾回收。技術債務就像高利貸：幾乎總是最好以小的增量持續償還，而不是讓它複合然後痛苦地一次性解決。人類品味被捕捉一次，然後在每行程式碼上持續強制執行。這也讓他們能夠在每天基礎上捕捉和解決不良模式，而不是讓它們在程式碼庫中傳播數天或數週。
觀點：工程師的未來在哪裡？
OpenAI 的 Harness Engineering 實驗顯示了一個令人不安但不可避免的未來：單純的程式碼編寫能力正在快速貶值。當 AI 可以在睡覺時產出 3.5 個 PR，當 100 萬行程式碼可以在五個月內由三名工程師「監督」完成，傳統軟體工程師的價值主張必須重新定義。
但這不意味著工程師會被淘汰。相反，這意味著工程師必須向價值鏈上游移動。未來的工程師不再是「寫程式碼的人」，而是「設計系統的人」：他們定義目標、建立約束、設計反饋循環，讓 AI 代理能夠在這些邊界內自主運行。
這種轉變類似於工業革命時期工匠向工程師的轉變。當機器可以製造零件時，人類的角色變成設計機器和優化流程。同樣，當 AI 可以編寫程式碼時，人類的角色變成設計程式碼應該做什麼、如何組織、以及如何驗證它是否正確。
Harness Engineering 的真正啟示不在於技術細節，而在於組織哲學：當 AI 執行時，人類必須學會更好地掌舵。這需要一套全新的技能：系統思維、抽象設計、品質標準定義、以及對 AI 能力的深刻理解。
對於正在學習編程的學生，對於職業生涯中的工程師，對於整個科技產業，OpenAI 的實驗是一個明確的信號：適應或被淘汰。Harness Engineering 不是未來的願景，而是已經到來的現實。