程序員不許寫代碼！OpenAI硬核實驗：3人指揮AI，5個月造出百萬行

新智元報道

編輯：元宇

【新智元導讀】在OpenAI一項內部實驗中，一個最初僅3人的團隊、5個月、從零到一造出「百萬行代碼產品」，沒有一行代碼是人類程序員完成的，而不手工寫代碼，也是該項目的一條鐵律。

這一次，人類軟件工程被「倒過來」做了！

剛剛，OpenAI官博曝光了他們的一次內部實驗：

一支最初3人的工程師團隊，利用Codex智能體在5個月內從零造出了一個「百萬行代碼產品」。

在整個過程中，人類不寫手工代碼，而是把精力集中在「想清楚要什么、把規則立起來」，其余的一切交給AI。

每人每天平均能推進3.5個PR（Pull Request，代碼合并請求），而PR的執行環節（實現、測試、文檔、CI配置）全程由智能體代勞。

OpenAI為這套工作流賦予了一個十分形象的名字：「駕馭工程（Harness Engineering）」。

https://openai.com/index/harness-engineering/

在實驗里，程序員不再是那個熬夜寫Bug，再熬夜修Bug的「碼農」，而是原來的「執行者」變為「駕馭者」。

這不止是10倍效率提升的「生產力革命」，而是一次對「軟件工程」定義的顛覆，直接宣告了人類「手工代碼時代」的終結。

改變

從一個空的git倉庫開始

這次實驗從AI的第一次提交開始。

2025年8月下旬，當空倉庫里落下第一個commit（提交）時，它就已經不是人類寫的——當時沒有任何既有人類代碼可以充當「錨點」。

更魔幻的：連那個用來指導AI怎么干活的說明書AGENTS.md，第一版也是AI自己寫的。

從第一天起，這個倉庫就是由智能體塑造的。人類不許寫代碼，成了這個項目的一條不可逾越的鐵律。

這不是為了偷懶，而是一種近乎自虐的「刻意練習」，只有切斷了人類「親自上手」的退路，才能倒逼團隊去破解那個在完全無人情況下構建代碼的終極問題。

于是，這個3人小團隊（后擴展到7人），一下子好像成了拿著鞭子的牧羊人，驅趕著一群不知疲倦的Codex智能體在代碼草原上狂奔。

結果令人震撼：5個月，一百萬行代碼。

重新定義工程師的角色

這項實驗的早期進展，比OpenAI的研究人員預想得要慢。

不是因為Codex不行，而是因為環境定義得不夠清晰：智能體缺少實現高層目標所需的工具、抽象和內部結構。

于是，OpenAI工程團隊的主要工作變成了一件事：讓智能體有能力完成有價值的工作。

他們把大目標拆成更小的構建塊（設計、編碼、評審、測試等），提示智能體把這些塊搭起來，再用它們去解鎖更復雜的任務。

當事情失敗時，答案幾乎從來不是「再試一次」，這里唯一的推進方式就是讓Codex去完成工作，人類工程師通常會退一步問自己：

到底缺了什么能力？怎樣把它變得對智能體既清晰可見，又可以被強制執行？

整個過程中，人類幾乎完全通過提示詞與系統交互：工程師描述任務，運行智能體，讓它發起一個PR。

為了推進PR完成，研究人員會讓Codex在本地自審改動，請求額外的本地和云端智能體評審，回應人類或智能體的反饋，然后在一個循環里不斷迭代，直到所有智能體評審者都滿意。

隨著時間推移，幾乎所有評審工作都移交給了「智能體對智能體」。

提升應用程序的可讀性

隨著代碼吞吐量的增加，OpenAI發現：AI編碼的瓶頸變成了人工質量檢查（QA）的能力。

于是，人類的時間和注意力成了真正的約束。

為了突破這一瓶頸，OpenAI的辦法是讓Codex能夠直接讀取應用程序的用戶界面、日志以及應用指標等內容。

他們將Chrome DevTools協議接入了智能體運行時，并開發了處理DOM快照、截圖和導航的技能。

于是，Codex可以自己復現bug、驗證修復、推理UI行為。

OpenAI對可觀測性工具也采取了同樣的做法。

日志、指標、追蹤通過本地可觀測性棧暴露給Codex，并且對每個worktree（工作區）都是隔離、臨時的環境。

任務完成后，這套環境就會被銷毀。

智能體可以用LogQ查日志，用PromQL查指標。

于是，「確保服務啟動在800ms內完成」或者「這四條關鍵用戶路徑里沒有任何一個span超過兩秒」這樣的提示，就變得真正可執行。

做了這些之后，OpenAI研究人員經常看到Codex一次運行連續工作六個小時以上，通常還是在人類睡覺的時候。

給Codex一張地圖

而不是一本1000頁的說明書

讓智能體處理大型復雜任務時，上下文管理是最大的挑戰之一。

OpenAI研究人員早期學到的一個簡單經驗就是：

給Codex一張地圖，而不是一本1000頁的說明書。

一開始，團隊試圖寫一個超大的AGENTS.md文件，把所有規則、邏輯、注意事項都塞進去。結果，這成了一場災難。

因為AI的注意力也是稀缺資源。

給它一本1000頁的說明書，它會迷失在細節里，漏掉關鍵約束，或者把目標搞錯。

而且，這種單體大文檔維護起來簡直是噩夢，很快就會變成「陳舊規則的墳場」。

于是，團隊迅速調整策略，他們把AGENTS.md變成了一張「尋寶地圖」。

這個文件只有大約100行，它不包含具體知識，只是一個目錄，就像一個導航地圖，指向倉庫深處更深層的真實來源。

設計文檔被編目并索引，包括驗證狀態以及一套定義「以智能體為先」操作原則的核心信念。

└── SECURITY.md

真正的知識庫在結構化的docs/目錄里，是系統的唯一事實來源。

這就是「漸進式披露」：智能體從一個小而穩定的入口開始，被教會下一步去哪找，而不是一開始就被信息淹沒。

OpenAI的研究人員還用工具強制執行這一點。

通過專門的lint和CI任務校驗知識庫是否最新、是否交叉鏈接、結構是否正確。

架構文檔給出領域劃分和包分層的頂層視圖。質量文檔為每個產品領域和架構層打分，持續追蹤差距。

為了保證AI不讀到過時的信息，團隊甚至專門安排了一個「文檔園丁」智能體。

它的工作只有一個：定期掃描文檔，發現那些與代碼實現不一致的陳舊描述，然后自動發起修復PR。

讓智能體「看得懂」

既然倉庫完全由智能體生成，OpenAI研究人員的一個目標，就是讓智能體只靠倉庫本身，就能理解完整業務領域。

從智能體視角看，任何它在運行時上下文中訪問不到的知識，都等于不存在。

比如放在Google Docs、聊天記錄、人類大腦的知識，對系統來說都是不可見的。

它能看到的只有倉庫里版本化的工件，如代碼、Markdown、schema、可執行計劃。

如果智能體找不到這些上下文知識，它們就會和剛入職的新同事一樣，對于實際業務進展一無所知。

因此，必須把越來越多的上下文推回倉庫。

當然，給Codex更多上下文，并不是要塞給它更多零散指令，而是把信息組織好、結構化，讓它可以推理。

自動化圍欄

讓程序員成為代碼世界的「牧羊人」

光有文檔，還不足以讓一個完全由智能體生成的代碼庫保持一致。

AI畢竟是概率模型，它會產生幻覺，會偷懶，會寫出「看似能跑實則一團糟」的代碼。

怎么解決？

智能體在邊界清晰、結構可預測的環境中效率最高。

OpenAI通過強制執行「不變量」，而不是微觀管理實現細節，讓智能體可以高速前進而不破壞基礎。

這就好比為Codex這樣日行千里的AI烈馬，套上了韁繩和馬鞍。

OpenAI圍繞一個嚴格的架構模型構建系統。每個業務領域都有固定層級，并且依賴方向被嚴格驗證，只允許有限的合法邊界。

規則很簡單：在每個業務領域內（如App Settings），代碼只能沿著固定層級「向前」依賴：

Types→Config→Repo→Service→Runtime→UI

橫切關注點（認證、連接器、遙測、功能開關等）只能通過一個顯式接口：Providers。

其他依賴一律禁止，并通過自定義lint（也是Codex生成）和結構測試強制執行。

這種架構通常是公司規模到幾百人時才會認真設計的。但在有編碼智能體的情況下，這是前提條件。

此外，OpenAI的研究人員還定義了一組「品味不變量」，如：

• 強制結構化日志

• schema和類型的命名規范

• 文件大小上限

• 平臺級可靠性要求

在這個過程中，必須明確區分的是哪些地方必須嚴格，哪些地方可以放權。

這好比管理一個大型工程平臺：邊界集中管控，內部高度自治。

AI生成的代碼未必符合人類審美，但只要正確、可維護、對智能體可讀，就OK。

在這個過程中，人類的品味不會消失，而是被持續「編碼」進系統。

評審意見、重構PR、用戶bug都會轉化為文檔更新，或直接升格為工具規則。

當文檔不夠用時，就需要把規則寫進代碼。

扔掉鍵盤

勇敢去駕馭AI

OpenAI的這項實驗宣告了：大量以CRUD為主的崗位，正在被重塑。

如果一個從零開始的系統，可以在5個月內，由3個人（不寫一行代碼）構建出百萬行規模，傳統軟件公司里那些龐大的開發團隊，還有存在的必要嗎？

在這個即將到來的新時代，工程師的定義將被徹底改寫。

你需要的是強大的「架構能力」，能夠定義系統的邊界，設計模塊之間的約束，構建那個讓AI不跑偏的「圍欄」。

同時，你還需要精準的「表達能力」，學會用最清晰的語言（無論是自然語言還是結構化文檔）向AI描述你的意圖。

拒絕AI編程，堅持手搓代碼的人終將被浪潮吞沒，只有那些懂得駕馭AI的程序員，才有可能成為AI時代的贏家。

參考資料：

https://openai.com/index/harness-engineering/