程序員不許寫代碼！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/