工程實作：當 Codex 成為主力開發者，人類工程師在做什麼？
作者：Ryan Lopopolo | 2026 年 2 月 11 日
今天重新又讀了下這個文章，分享給大家
過去五個月，OpenAI 的一個團隊做了一件聽起來有點瘋狂的事：從零開始交付一款軟體產品的內測版本，全程沒有一行代碼是人手寫的。
這不是玩具專案。這個產品有真實的內部日活用戶和外部 Alpha 測試者，經歷了完整的交付、部署、故障和修復流程。從應用邏輯、測試、CI 配置、文檔、可觀測性到內部工具，每一行代碼全都出自 Codex 之手。據估算，完成這些工作只花了手工編碼所需時間的 1/10。
人類掌舵，智能體幹活。
這是團隊刻意選擇的限制——正是為了搞清楚，當工程師不再寫代碼，而是去設計環境、明確意圖、構建反饋迴路的時候，軟體工程會變成什麼樣。
從一個空倉庫開始
2025 年 8 月底，第一次 commit 推進了一個空的 Git 倉庫。
初始架構——倉庫結構、CI 配置、格式化規則、包管理器設置和應用框架——全部由 Codex CLI 配合 GPT-5 在一套現有模板的指導下生成。就連那份告訴智能體"怎麼在這個倉庫裡幹活"的 AGENTS.md 文件，也是 Codex 自己寫的。
五個月後，這個倉庫已經積累了大約 一百萬行代碼，涵蓋應用邏輯、基礎設施、工具鏈、文檔和內部開發者工具。期間大約合併了 1500 個 Pull Request，背後只有三名工程師在推動 Codex 運轉。平均算下來，每人每天處理 3.5 個 PR——而且隨著團隊擴充到七人，這個吞吐量還在增加。更重要的是，這不是為了刷數字：產品已經在數百名內測用戶中跑起來了，其中不乏每天都在用的重度用戶。
整個開發過程中，人類從未直接貢獻過任何代碼。這成了團隊的核心信條：不手寫代碼。
工程師的角色變了
沒有手工編碼這回事之後，工程師的注意力全部轉向了系統設計、架構決策和槓桿效應。
早期進展比預想的慢，但原因不是 Codex 能力不行，而是環境描述不夠清晰。智能體缺少推進高層目標所需的工具、抽象層和內部結構，自然就卡住了。這時候工程師的主要任務，就變成了"幫智能體把活幹起來"。
實操起來，這是一種深度優先的工作方式：把大目標拆成小模塊（設計、編碼、評審、測試等），提示智能體逐個構建，再用這些模塊去解鎖更複雜的任務。遇到卡點，解法幾乎從來不是"再試一次"，而是反問自己：還缺什麼能力？怎麼讓這個能力對智能體來說既清晰又可執行？
人類和系統的交互幾乎全靠 Prompt：工程師描述任務，跑起智能體，等它開 PR。為了推動 PR 走完流程，會讓 Codex 在本地自審自己的改動，請求其他智能體做專項評審，響應人類或智能體給出的反饋，循環往復直到所有評審方都滿意（這實際上就是一個 Ralph Wiggum 循環）。Codex 直接調用標準開發工具（gh、本地腳本、內嵌技能）來收集上下文，不需要人工手動粘貼內容進 CLI。
人類可以審 PR，但不是必須的。隨著時間推移，絕大多數評審工作已經切換成智能體對智能體的模式來處理了。
讓應用本身變得"可讀"
隨著代碼產出越來越多，人工 QA 成了新的瓶頸。人類的時間和注意力是固定的，所以團隊一直在想辦法讓應用的 UI、日誌、指標這些東西直接對 Codex 可讀，從而擴大智能體的自主能力。
比如，讓應用支持基於 git worktree 啟動，這樣 Codex 就能為每次變更單獨跑一個實例。再比如，把 Chrome DevTools 協議接入智能體運行時，並封裝了處理 DOM 快照、截圖和導航的技能。這讓 Codex 能夠自己復現 Bug、驗證修復，直接對 UI 行為進行推理。
可觀測性工具也做了同樣的事。日誌、指標和追蹤數據通過一個本地可觀測性棧暴露給 Codex，這個棧對每個 worktree 來說都是臨時的，任務完成後連同日誌和指標一起銷毀。Codex 可以用 LogQL 查日誌，用 PromQL 查指標。有了這些上下文，"確保服務啟動在 800ms 內完成"或"這四個關鍵用戶旅程中任何 span 都不得超過兩秒"這類 Prompt 就真的能落地了。
單次 Codex 運行在一個任務上持續工作超過六個小時的情況很常見，通常都是趁人睡覺的時候跑的。
把代碼倉庫當成"記錄系統"
上下文管理是讓智能體在大型複雜任務中有效運轉的最大挑戰之一。團隊學到的最早的一條經驗很直接：給 Codex 的應該是一張地圖，而不是一本 1000 頁的說明書。
他們試過"一個巨大的 AGENTS.md"方案，結果可想而知——失敗了，原因有好幾個：上下文本來就是稀缺資源，一個巨型指令文件會擠掉任務、代碼和相關文檔；當什麼都"重要"的時候，智能體最終會在局部做模式匹配，而不是有意識地導航；而且這種文件會迅速腐爛，變成陳舊規則的墳場，人類一旦停止維護，它就悄悄成了麻煩的來源。
所以 AGENTS.md 不再是百科全書，而是目錄。
倉庫的知識庫存放在一個結構化的 docs/ 目錄裡，作為記錄系統使用。一份簡短的 AGENTS.md（大約 100 行）被注入上下文，主要充当地圖，指向其他地方更深層的真實信息來源。
AGENTS.md
ARCHITECTURE.md
docs/
├── design-docs/
│ ├── index.md
│ ├── core-beliefs.md
│ └── ...
├── exec-plans/
│ ├── active/
│ ├── completed/
│ └── tech-debt-tracker.md
├── generated/
│ └── db-schema.md
├── product-specs/
│ ├── index.md
│ ├── new-user-onboarding.md
│ └── ...
├── references/
│ ├── design-system-reference-llms.txt
│ ├── nixpacks-llms.txt
│ ├── uv-llms.txt
│ └── ...
├── DESIGN.md
├── FRONTEND.md
├── PLANS.md
├── PRODUCT_SENSE.md
├── QUALITY_SCORE.md
├── RELIABILITY.md
└── SECURITY.md設計文檔有索引和目錄，包括驗證狀態和一套核心理念。架構文檔提供域和包分層的頂層地圖。一份質量評分文檔對每個產品領域和架構層打分，並持續追蹤差距。
計劃被當成一等公民來對待。小變更用輕量臨時計劃，複雜工作則記錄在執行計劃裡，附帶進度和決策日誌，全部提交進倉庫。活躍計劃、已完成計劃和已知技術債務都做了版本控制並集中存放，智能體不依賴外部上下文就能獨立運轉。
這實現了漸進式披露：智能體從一個小而穩定的入口開始，被引導著去找下一步需要的信息，而不是一上來就被淹沒。
這套規則被嚴格執行。專屬 linter 和 CI 任務會驗證知識庫的更新狀況、交叉鏈接和結構正確性。一個定期運行的"文檔園丁"智能體會掃描那些不再反映真實代碼行為的過時內容，並發起修復用的 PR。
為智能體的可讀性優化
隨著代碼庫增長，Codex 的設計決策框架也在演變。
由於整個倉庫都由智能體生成，團隊首先針對 Codex 的可讀性做優化。就像工程團隊會努力讓代碼對新入職的工程師友好一樣，人類工程師的目標是讓智能體能夠直接從倉庫推理出完整的業務領域。
從智能體的視角看，它在運行時上下文裡訪問不到的東西，對它來說就不存在。存在 Google Docs、聊天記錄或人大腦裡的知識，系統根本看不到。倉庫本地的、經過版本控制的產物——代碼、Markdown、Schema、可執行計劃——才是它能看到的全部。
團隊意識到，需要把越來越多的上下文推進倉庫。那次讓團隊在架構模式上達成共識的 Slack 討論？如果智能體找不到它，那它對這件事的了解程度，就跟一個遲到三個月入職的新員工一樣——什麼都不知道。
這個框架也明確了很多取捨。團隊傾向於選擇那些可以完全內化在倉庫推理中的依賴和抽象。對智能體來說，通常被稱為"無聊"的技術——因為其可組合性、API 穩定性和在訓練集中的出現頻率——往往更容易建模。有時候，讓智能體重新實現部分功能子集，比繞過公共庫中不透明的上游行為要便宜得多。比如，團隊沒有引入通用的 p-limit 風格包，而是用上了自己的帶併發的 map 輔助函數：與 OpenTelemetry 儀表緊密集成，100% 測試覆蓋率，行為完全在掌控之中。
用架構約束代替微觀管理
光靠文檔，撐不起一個完全由智能體生成的代碼庫的連貫性。通過強制執行不變量，而不是對實現過程微觀管理，才能讓智能體快速交付而不動搖基礎。
比如，要求 Codex 在邊界處解析數據形狀，但不規定具體用哪個庫（模型似乎偏好 Zod，但沒有強制指定）。
智能體在有嚴格邊界和可預測結構的環境裡效率最高，所以團隊圍繞一個嚴格的架構模型來構建應用。每個業務域被劃分為一組固定的層，依賴方向嚴格驗證，只允許有限的幾條邊。這些約束通過自定義 linter（當然也是 Codex 生成的）和結構測試來機械地強制執行。
規則如下：在每個業務領域內（比如應用設置），代碼只能"向前"依賴於一組固定的層（Types → Config → Repo → Service → Runtime → UI）。橫切關注點（認證、連接器、遙測、功能標誌）通過單一的顯式接口進入：Providers。其他任何方式都不被允許，並通過自動化來強制執行。
這種架構通常要等團隊擴張到數百人時才會認真推進。對於編碼智能體來說，它是一個早期的先決條件：有了約束，速度才不會下降，架構才不會漂移。
在實踐中，還有一小組"品味不變式"作為補充。比如通過自定義 lint 靜態強制執行結構化日誌記錄、命名約定、文件大小限制以及特定平台的可靠性要求。由於這些 lint 是定制的，錯誤信息裡可以直接注入修復指令，方便智能體理解。
在以人為主的工作流裡，這些規則可能顯得迂腐。有了智能體，它們就變成了倍增器：一旦編碼進去，就能立刻應用到所有地方。
團隊也清楚地劃出了哪裡要管、哪裡不用管。類似於領導一個大型工程平台組織：在中央層面強制執行邊界，在本地層面允許自主權。邊界內，智能體可以在解決方案的表達方式上有很大自由。
生成的代碼不總是符合人類的風格偏好，這沒關係。只要輸出是正確的、可維護的，對未來的智能體運行而言也清晰易讀，就算過關。
人類的品味會持續反饋進系統。評審評論、重構 PR 和面向用戶的 Bug，會被記錄為文檔更新，或直接編碼進工具。文檔不夠用時，規則就轉化為代碼。
吞吐量改變了合併理念
隨著 Codex 的吞吐量上來了，很多傳統工程規範變得不再適用。
這個倉庫運行時盡量減少阻塞性合併門。PR 生命週期很短。測試的偶發失敗通常通過後續重跑解決，而不是無限期地卡住進展。在一個智能體吞吐量遠超人類注意力的系統裡，糾錯成本低，等待成本高。
低吞吐量環境下這樣做是不負責任的。在這裡，這通常是正確的選擇。
"智能體生成"到底意味著什麼
說整個代碼庫由 Codex 智能體生成，這裡說的是意義上的整個代碼庫。
智能體產出的東西包括：產品代碼與測試、CI 配置和發布工具、內部開發者工具、文檔和設計歷史、評估框架、評審評論和回復、管理倉庫本身的腳本，以及生產儀表板定義文件。
人類始終在場，但工作的抽象層次和過去完全不同。團隊優先處理工作、把用戶反饋轉化為驗收標準，並對結果做驗證。當智能體卡住時，這被視為一個信號：識別缺失的東西——工具、指導與約束、文檔——然後反饋進倉庫，修復依然由 Codex 自己來寫。
智能體可以直接使用標準開發工具，會拉取評審反饋、行內回復、推送更新，經常還會自己壓縮並合併自己的 PR。
自主程度在不斷提升
隨著越來越多的開發環節被直接編碼進系統——測試、驗證、評審、反饋處理和恢復——這個倉庫最近跨過了一個重要門檻，讓 Codex 可以端到端地驅動一個新功能。
給定一個 Prompt，智能體現在可以完成整套流程：驗證代碼庫當前狀態、復現已報告的 Bug、錄製一段演示故障的視頻、實施修復、運行應用驗證修復、錄製第二段視頻展示解決方案、開 PR、響應智能體和人類反饋、檢測並修復構建故障、僅在需要判斷時才交予人工處理，最後合併變更。
這個能力在很大程度上依賴這個倉庫特定的結構和工具，不應該假設它能無條件泛化到其他場景——至少現在還不行。
熵與垃圾回收
完全自主的智能體也帶來了新問題。Codex 會復現倉庫裡已有的模式——包括那些不夠理想的模式。隨著時間推移，這不可避免地導致漂移。
最初，人類是手動處理這個問題的——團隊過去每周五要花 20% 的時間清理"AI 殘渣"。這顯然不可擴展。
後來，團隊開始把他們稱為"黃金原則"的內容直接編碼進倉庫，並建立了循環清理流程。這些原是帶有意觀意見的機械規則，旨在保持代碼庫對未來智能體運行的可讀性和一致性。比如：傾向於使用共享的工具包而不是手寫輔助函數，這樣不變量可以集中管理；不使用"YOLO 式"探測數據，而是在邊界處做驗證，或依賴類型化的 SDK，避免智能體基於猜測的結構來構建。
團隊會定期跑一批後台 Codex 任務，掃描偏差、更新質量評分，並發起有針對性的重構 PR。大多數都能在一分鐘內審完並自動合併。
這套機制類似於垃圾回收。技術債務就像高息貸款：持續小額償還，總比讓它越堆越高再一次性硬啃要好得多。人類的品味一旦被捕捉進系統，就會持續作用於每一行代碼。這樣每天都能發現並解決不良模式，而不是讓它在代碼庫裡擴散好幾周。
還在持續學習的事
到目前為止，這套策略在 OpenAI 內部的發布和採用中表現良好。為真實用戶打造真實產品，幫助團隊把投入錨定在現實中，也指引著他們走向長期可維護性。
還不清楚的是：在一個完全由智能體生成的系統中，架構連貫性會如何隨時間演變？人類判斷力在哪些方面能發揮最大作用，又該怎麼把這種判斷力編碼進去讓它發揮更大作用？隨著模型能力不斷增強，這套系統將來會演化成什麼樣？
有一點是清楚的：構建軟體依然需要紀律，只是紀律更多體現在支撐結構上，而不是代碼本身。保持代碼庫連貫性的工具、抽象和反饋迴路，變得越來越重要。
當前最棘手的挑戰集中在設計環境、反饋迴路和控制系統上——幫助智能體實現目標：大規模構建和維護複雜、可靠的軟體。
隨著像 Codex 這樣的智能體在軟體生命週期中占比越來越高，這些問題只會變得更加關鍵。