OpenAI工程師不寫代碼了：AI寫得太快，人類檢查跟不上，Agent直接包辦開發

作者 ｜ 木子

OpenAI 最近在一篇 Blog 中說了件挺炸裂的事：他們自己的工程師，已經不怎么寫代碼了。

在一個內部項目里，短短五個月，就產出了 100 萬行代碼，而且沒一行手寫，全都是Codex寫的。

這些代碼并不是什么零散腳本，而是從零開始搭出來的一整套軟件產品內部 Beta 版：從應用邏輯、基礎設施，到工具、文檔和內部開發者工具，幾乎一應俱全。

這種變化，或許能從 OpenAI 內部一直以來的工程師文化中找到一些線索。

一位曾參與 Codex 項目的 OpenAI 工程師 Calvin French-Owen，在離職后寫過一篇博客，雖然他在其中吐槽說，過去一年里 OpenAI 員工規模迅速擴張，帶來了不少混亂。

不過他同時也提到，公司內部依然保留著很強的創業公司氛圍：團隊小、決策快，工程師擁有很高的自主權。

另外，很多科技巨頭是高層定路線、然后團隊執行，但在 OpenAI，通常沒有明確的長期 roadmap，研究員往往自己發現問題、提出想法，小團隊圍繞好點子自然形成并推進項目。

他表示，真正推動進展的好想法可能隨時從任何地方隨時，而不是來自某個宏大計劃。

“OpenAI 非常注重自下而上的方式，尤其是在研究方面。”

比如 Codex，最初其實誕生在 OpenAI 的一個只有十幾人的小團隊里。這個團隊在 7 周內幾乎不眠不休，把 Codex 從想法一路推到了上線。

而現在這個“OpenAI 工程師不寫代碼”一事，其實也要從公司一個團隊，在開發流程中發現的新瓶頸說起。

現在 AI Coding 這件事已經屢見不鮮。但當 Codex 開始大規模生成代碼后，OpenAI 的這研發團隊很快發現一個新問題：

代碼生成已經不慢了，慢的是讓人類來檢查這些代碼。

人的時間和注意力是有限的。在整個開發流程里，最容易卡住的環節反而變成了 QA（質量測試）。

為了解決這個問題，OpenAI 的工程師換了個思路：干脆讓 Codex 模仿工程師，自己去“看”和“用”應用。

那 OpenAI 的工程師現在不寫代碼了，他們到底在做什么？

——設計環境、搭反饋循環、定義架構約束，然后讓 agent 寫。

文章中強調一句話：“人類掌舵，智能體執行”。

他們管這叫Harness Engineering，直譯過來的話就是“AI 駕馭工程”。

工程師變成“能力架構師”

這個項目始于 2025 年 8 月下旬，從向一個完全空白的代碼倉庫提交第一行內容開始。

初始架構，包括代碼倉庫結構、CI 配置、格式化規則、包管理器設置和應用框架——都不是工程師手寫的，而是在一小套模板的指導下，由Codex CLI 調用 GPT-5 自動生成。

甚至連那份告訴 agent “該如何在這個倉庫里工作”的AGENTS.md，也是 Codex 自己寫出來的。

換句話說，這個系統從誕生那刻起，就幾乎沒有人工代碼。整個代碼倉庫，都是被 agent 一步一步搭起來的。

不過，一開始事情并沒有想象中那么順利：起初項目推進速度緩慢，但問題并不在 Codex 的能力，而在環境——規則不清晰、工具不完整、系統約束還沒建立起來。

有網友“一針見血”道：

“最扎心的一句：agent 反復犯錯，不是能力問題，是你腦子里的判斷力沒寫下來。你不寫，它第一百次還犯同樣的蠢。”

于是再遇到開發卡住時，團隊不再想著“再改一段代碼試試”，而是先問一個問題：agent 到底缺什么能力？

再把這種能力變成它能讀懂、能執行、還能被強制遵守的規則。

也就是說，面對當下 agent 自己就能測試、改 bug 的情形，工程師的工作重點從“寫代碼” 變成了另一件事：讓 Codex 更容易把事情做對，給 agent“補能力”。

從這個角度看，工程師的工作其實轉向了更高一層：用一句話來說，就是拆解任務、設計能力、搭建系統，讓 agent 可以穩定地產生正確的代碼。

具體來說，大致有這幾件事情：

第一件事，就是讓應用對 AI “可讀”。

正如上文提到的，需要人為把 agent 接入 Chrome DevTools 協議，讓它能“觸控”UI。

工程師要做的第二件事情，就是把“隱性知識”全部寫進代碼倉庫， 變成機器可讀的知識。

對 agent 而言，無法在運行時訪問的內容就等于不存在。比如存儲在 Google Docs、聊天記錄或人們頭腦中的知識嗎，這些都無法被系統訪問。

不過，不可以把所有規則和說明一次性塞給 Codex，而是要先給它一個導航，再讓它自己去查細節。

研究研究團隊曾嘗試過直接給 agent 一個巨大的AGENTS.md文件，結果很快發現行不通。

主要原因是，上下文是稀缺資源，說明書越厚，真正重要的信息反而越容易被淹沒；而且這種大文檔很快就會過時，也很難驗證和維護。

他們把這段經驗總結成了一句：

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

該示意圖由 AI 生成

工程師要做的第三件事，是設計“AI 友好”的架構。

AI 在結構清晰、邊界明確的系統里效率最高。對人來說，這些規則可能顯得死板，但對 agent 來說，這是效率倍增器。

所以 OpenAI 的這個團隊設計了一套嚴格架構, 每個業務域必須按固定層級：Types→ Config→ Repo→ Service→ Runtime→ UI。

依賴方向是強制的。任何違反都會被自動阻止。

第四件事，是把“品味”變成規則。

“在 AI 時代，人類最重要的能力是 Taste。”隨著大模型越來越強，這樣的聲音不絕于耳。

這篇 Blog 中，有一個很有意思的概念：taste invariants（品味不變量）。

意思是，工程師的審美，比如：文件大小限制、命名規則、日志結構、API 規范等，都被寫成lint 規則。

這樣 AI 每次寫代碼都會自動遵守：“人類的品味一旦被捕捉，就可以應用到每一行代碼。”

在實際開發中，人類主要通過提示與系統交互：描述任務、啟動 agent，然后讓 Codex 自動生成 Pull Request。

接下來的一整套流程，包括代碼自檢、agent 評審、根據反饋修改、再次提交，基本都由 agent 自己完成，并不斷循環，直到所有評審通過。

第五件事，就是清理 AI 產生的“垃圾”。

文章指出，完全自主的智能體也引入了新的問題。

當代碼幾乎全部由 Codex 生成后，一個新問題也出現了：AI 會不斷復制代碼庫里已有的模式，包括那些不太好的寫法，時間一長代碼風格就會慢慢“漂移”。

一開始，團隊計劃每周抽一天時間手動清理這些“AI 殘渣”，但很快發現這種方式根本不具備可擴展性。

后來他們把工程師的經驗和偏好寫成一套“黃金原則”，比如優先使用共享工具庫、嚴格校驗數據結構而不是“猜著寫”。

然后將這套原則直接編碼進代碼倉庫，讓 Codex 自動掃描問題并發起重構 PR。

這樣就像給代碼庫加了一套“垃圾回收機制”：小問題可以隨時清理，技術債不會越滾越大。

這篇 Blog 在技術圈引起了的廣泛關注和討論，有人認為，這個 Harness Engineering 本質上是一種現代版的控制論：工程師不再直接寫代碼，而是設計系統、規則和反饋回路，讓 agent 自動完成工作。

他表示，這種模式，其實在歷史上已經出現過三次了。

從瓦特蒸汽機的調速器，到 Kubernetes 的控制器，再到今天的 AI agent；真正的變化不是“機器替代人”，而是人的角色，從執行者變成系統的設計者和校準者：

“你不再親自去擰閥門，而是開始掌舵。 每當這種模式出現，背后通常都是因為有人構建出了足夠強大的傳感器和執行器，能夠在那個層級上把反饋回路真正閉合起來。”

Agent 都開始包辦開發流程了

為什么 OpenAI 的工程師可以不再寫代碼了？不妨來看看他們的agent 現在已經能干到什么程度。

前文提到，OpenAI 的工程師換了個思路：干脆讓 Codex 模仿工程師，自己去“看”和“用”應用。

第一，是讓 agent 能“看見”應用界面（UI）。

他們把 Chrome DevTools 協議接入到 agent 的運行環境里。這樣一來，Codex 就可以像開發者在瀏覽器里調試一樣操作頁面、讀取日志、抓取 DOM、截屏觀察界面......

這一步其實非常關鍵，因為LLM 本身是看不見 UI 的。

接入 DevTools 之后，Codex 就相當于有了“眼睛”和“手”：

可以通過截圖和 DOM 觀察頁面，通過 console 和 network 監聽運行狀態，還能自己點擊、輸入、導航。

該示意圖由 AI 生成

有了這些能力，agent 就可以自己復現 bug、自動跑 UI 測試、驗證修復是否生效。

這樣一來，Codex 就不只是寫代碼，還開始像一個自動化 QA 工程師一樣工作：自己測試自己寫的代碼，并反復修復，直到系統通過測試。

換句話說，原本需要人工完成的大量測試和調試工作，被自動化了。

就像下面這張圖里展示的那樣：最核心的一步是 “Loop Until Clean”——不斷測試、修復、再測試，直到系統沒有錯誤。

第二點，只能操作 UI 還不夠，還得讓 agent 看見系統內部發生了什么。

為此，OpenAI 給 Codex 接入了一整套可觀測系統（Observability）。

應用在運行時會產生三類關鍵數據，也是工程師排查問題時最常用的信號：

• Logs（日志）
• Metrics（性能指標）
• Traces（調用鏈）

這些數據會先被一個叫Vector的組件統一收集，再送到本地的可觀測系統里。

這樣一來，Codex 就能像工程師一樣查系統狀態：哪個服務報錯了？哪個接口變慢了？請求卡在哪一層？

當發現問題后，Codex 會自己修改代碼、提交 Pull Request、重啟應用、重新運行任務，再觀察系統指標有沒有改善。

整個過程會形成一個自動反饋循環：發現問題 → 修改代碼 → 再運行 → 再觀察。

一直重復，直到問題消失。

換句話說，Codex 不只是看代碼，還能像運維一樣查日志、看性能數據，判斷系統哪里出了問題，再修改代碼驗證修復效果。

這篇博文中提到，給定一個提示，Codex 驅動的 agent 就可以：

agent 不再只是一個寫代碼的工具，而是開始承擔完整的軟件開發流程。

整個開發流程大致為：Codex 寫代碼 → 啟動應用 → 像用戶一樣操作頁面 → 檢查結果 → 如果不對就改代碼再跑。

不過需要說明的是，這套流程之所以能跑通，很大程度上依賴他們為這個代碼倉庫專門設計的結構和工具鏈。

如果沒有類似的工程投入，這種“全自動開發流程”目前還很難直接照搬。

目前來看，這套“agent 寫代碼、人類設計系統”的模式，在 OpenAI 內部運行得還不錯；但很多問題仍在探索階段：比如 AI 生成的代碼庫長期會不會失控，人類判斷力該如何嵌入系統。

不過可以預見的是，軟件工程的重點可能會逐漸從“寫代碼”，轉向設計環境、規則和反饋機制；讓像 Codex 這樣的 agent，可以更穩定地參與構建和維護復雜的軟件系統。

https://openai.com/zh-Hans-CN/index/harness-engineering/

https://x.com/odysseus0z/status/2030416758138634583

https://calv.info/openai-reflections

聲明：本文為 AI 前線整理，不代表平臺觀點，未經許可禁止轉載。

會議推薦

2026，AI 正在以更工程化的方式深度融入軟件生產，Agentic AI 的探索也將從局部試點邁向體系化工程建設！

QCon 北京 2026 已正式啟動，本屆大會以“Agentic AI 時代的軟件工程重塑”為核心主線，推動技術探索從「AI For What」真正落地到可持續的「Value From AI」。從前沿技術雷達、架構設計與數據底座、效能與成本、產品與交互、可信落地、研發組織進化六大維度，系統性展開深度探索。開往 2026 的 Agentic AI 專列即將啟程！匯聚頂尖專家實戰分享，把 AI 能力一次夯到位！

今日薦文

你也「在看」嗎？