100 萬行程式碼，零行人寫：OpenAI 內部團隊如何用 AI 從零打造生產級軟體

本文整理自 Latent Space Podcast 2026 年 4 月播出的單集。

{{< youtube CeOXx-XTYek >}}

{{< apple-podcast "tw/podcast/extreme-harness-engineering-for-token-billionaires/id1674008350?i=1000760089567" >}}

---

三個人、五個月、一百萬行程式碼

OpenAI 內部有一個小團隊做了一件瘋狂的事。三個工程師，花了五個月，打造出一個超過 100 萬行程式碼的 Electron 桌面應用程式。裡面每一行，包括應用邏輯、測試、CI 設定、文件、內部工具，全部由 Codex agent 撰寫，人類沒有碰任何一行。他們估計這種方式比傳統手寫快了十倍。

這個實驗的主導者 Ryan Lopopolo 是 OpenAI 的技術成員（Member of Technical Staff），負責 Frontier 產品探索，也就是用 OpenAI 的模型探索全新的企業產品形態。他之前在 Stripe 做過資深工程師，在 Brex 帶過 40 人的開發生產力團隊、支援 350 人的工程組織，是那種習慣從系統層面思考問題的人。今年二月，他在 OpenAI 官方部落格發了一篇長文，用一個新詞定義了這種開發方式：Harness Engineering。

這篇文章在開發者社群引爆討論。OpenAI 董事長布雷特．泰勒（Brett Taylor）親自轉發評論，有人把文章連結直接丟給 Codex，結果 agent 讀完就能照著做，效果出乎意料地好。Lopopolo 後來在 Latent Space Podcast 上做了他人生第一次 podcast 訪談，把那些文章裡沒寫完的細節，從 build system 的選擇到 reviewer agent 的調教，全部攤開來講。以下是那些最值得記下來的實戰決策。

Harness Engineering 到底在做什麼

Harness Engineering 很容易被誤解成「怎麼寫更好的 prompt」或「讓 AI 幫忙寫程式碼」。Lopopolo 的定義更精準：把團隊中每個資深工程師腦中關於「什麼叫做好的程式碼」的隱性知識，編碼成 AI agent 能消化的格式。文件、lint 規則、測試、code review agent 的 prompt，這些東西的共同目標只有一個，讓 agent 知道好的軟體長什麼樣。

為什麼這件事重要？因為 agent 犯的每一個錯，背後都指向一個還沒被寫下來的非功能性需求。比方說，agent 寫了一段程式碼沒有加超時設定，上線後導致了告警。Lopopolo 的做法不是只修 bug，而是順手更新可靠性文件，要求所有網路呼叫都必須有 timeout。這樣下次 agent 讀到這份文件時，就不會再犯同樣的錯。這個迴圈不斷重複：發現錯誤、追溯到缺失的規範、寫下規範、agent 變得更好。

他的團隊在程式碼庫裡只放了六個 skill（Codex 的技能模組），加上一份 100 行的目錄檔。其中「品質分數」這個 skill 特別有意思，它本質上是一個 markdown 表格，讓 Codex 定期檢視所有業務邏輯，對照文件中的品質標準，然後主動提出改善項目。在有正式 ticketing 系統之前，團隊就用 markdown 檔追蹤待辦，定時啟動 agent 去消化這些待辦。Lopopolo 觀察到一個有趣的現象：模型天生渴望文字。所以他們做的很大一部分工作，就是想辦法把更多文字注入系統。

還有一個例子更直接。團隊部署 app 給第一批內部使用者後遇到效能問題，請使用者匯出 trace 記錄。值班工程師用 Codex 寫了一個漂亮的 Next.js 本地 DevTool，可以拖曳 trace 檔案進去視覺化分析，花了一個下午。但 Lopopolo 事後意識到，這整件事根本不需要做。直接啟動 Codex 把 trace 丟給它，問同樣的問題，五分鐘就能得到答案。那個下午的工程投資，是因為工程師習慣性地為人類的閱讀體驗做最佳化，卻忘了 agent 根本不需要這個。

從「把 agent 放進框裡」到「讓 agent 成為整個框」

這個實驗跨越了好幾個模型世代，從最早期的 Codex mini 到 GPT-5、5.1、5.2、5.3、5.4。每次模型升級都帶來新能力，也帶來新的挑戰。最明顯的轉變發生在推理模型出現之後。

在 GPT-4 系列的時代，模型不會「思考」，開發者必須把它放進一個精心設計的框架裡，用預定義的狀態轉換來引導行為。但推理模型出現後，整個邏輯反轉了。Lopopolo 的說法是：讓模型和它的 harness 成為整個框，給它一堆選項和足夠的上下文，讓它自己做出聰明的選擇。

具體來說，他們不再先設好環境再讓 coding agent 進入，而是直接啟動 Codex 作為入口點，透過 skill 和腳本，讓 agent 自己決定要不要啟動本地的監控堆疊。agent 可以自己設環境變數，讓應用程式指向它選擇啟動的那套本地服務。這在舊模型上根本行不通，因為模型沒有足夠的推理能力來處理這種開放式決策。但到了 5 系列的推理模型，agent 不只能做到，而且做得比人類預設的 scaffold 更有效率。

5.3 版帶來了一個重要變化：背景 shell。Codex 可以在背景啟動一個耗時的 build，然後繼續做別的事，比如一邊跑 build 一邊 review 程式碼。但這也有副作用，agent 變得比較沒耐心，不太願意等阻塞式腳本完成。團隊因此被迫重新打造整個 build system，把 build 時間壓到一分鐘以內。

Build 時間必須在一分鐘以內

一分鐘，這聽起來像是隨意訂的數字，但它其實是整個系統能否運轉的關鍵。如果 build 超過一分鐘，agent 就會失去耐心或另尋出路。團隊把這個限制當作不可妥協的約束，一旦 build 時間開始膨脹，就立刻停下來拆解 build graph，壓回去。

為了達標，他們的 build system 經歷了四次大遷移：從自製的 Makefile，到 Bazel，到 Turbo，最後落腳在 NX。這在人類團隊裡是很難想像的事，畢竟每次換 build tool 都是大工程。但因為這個程式碼庫裡沒有「人的意見」要照顧，唯一的目標就是讓 agent 有生產力，所以能這樣快速迭代。整個程式碼庫是一個 React + Electron 的單一應用，拆成了大約 500 個 NPM 套件。

這種拆法在一般七人團隊看來過於激進，但 Lopopolo 的邏輯不同。如果每個工程師背後有 10 到 50 個 agent 同時運作，那團隊的實際規模更像一萬人的工程組織。在這個尺度下，嚴格的模組邊界、明確的介面定義，不是過度工程，是存活必需。agent 需要清楚知道自己可以動哪些區域，才不會跟其他 agent 踩到彼此。傳統平台團隊會讓 build 時間慢慢漲到上限，花兩三週壓回來，再讓它慢慢漲。但因為 token 便宜而且可以大量平行，agent 能持續做 build 系統的「園藝工作」，隨時維護這些不變性。

Symphony：當人類變成瓶頸

到了 2026 年一月，問題變得很明顯：人類自己成了最大的瓶頸。在 GPT-5.2 上線後，每個工程師每天要處理五到十個 PR。不斷在不同 tmux 視窗之間切換、驅動 agent 往前推，極度消耗注意力。Lopopolo 說他每天結束時都精疲力盡。所以團隊做了一個順理成章的決定：既然瓶頸是人類的同步注意力，那就把人類從迴圈中拿掉。

這就是 Symphony 誕生的背景。它是一個用 Elixir 寫的自動化編排服務，跑在 BEAM 虛擬機上。選擇 Elixir 不是人的決定，是模型的決定。agent 拿到 spec 後選了 Elixir，因為 BEAM 的原生行程監督（process supervision）和 GenServer 非常適合這種任務編排：為每一個執行中的工作啟動一個小 daemon，驅動它走到完成。Lopopolo 自己甚至不會寫 Elixir，但他認為這正好證明了一個觀點：當人類不在迴圈中，agent 就能選最適合問題的工具，不會被人類的技能偏好所侷限。

Symphony 的工作流程是這樣的。agent 接到任務後，自動建立 worktree 和 PR，寫程式碼和測試，等 CI 通過，處理 flaky test，PR 跟上游衝突就自動 rebase，所有檢查過了就放進 merge queue。人類只在最後做一個「合格或不合格」的判斷。如果不合格，Symphony 會完全丟棄整個 worktree 和 PR，從頭來過。而團隊會去追問：為什麼不合格？缺了什麼 context？修好之後，下次就不會再出錯。

Code review 的自動化也走過一段彎路。一開始，reviewer agent 會在 PR 上留各種改善建議，寫程式碼的 agent 太聽話，每個建議都照單全收，結果 PR 陷入不收斂的循環。團隊的解法是調整兩邊的 prompt。reviewer agent 被指示「偏向合併」，只標記 P2 以上的問題。寫程式碼的 agent 則被賦予延後處理或推回 review 意見的權限。這跟真實世界完全一樣：code review 裡很多意見是「知道就好，下次處理」，不是「現在立刻改」。沒有這個 context，agent 就會把每一條意見都當成必須立即執行的指令。

Ghost Libraries：依賴套件的終結

泰勒看了 Lopopolo 的文章後公開表示：軟體依賴套件即將消失。Lopopolo 完全同意。他們的做法是把中小型依賴直接內化到程式碼庫中，讓 agent 只保留自己實際需要的部分，剝掉所有泛用但用不到的功能。他估計目前能處理幾千行等級的依賴，一個下午就搞定。

內化依賴還有一個額外好處：安全性。當程式碼在自己的 repo 裡，Codex 的安全掃描可以直接深入檢查並修改，不用像傳統流程那樣推 patch 到上游、等新版發布、確認跟所有 transitive dependency 相容。整個摩擦力大幅降低。當然，Lopopolo 也承認這有風險：你失去了開源社群「多雙眼睛」帶來的安全審查效果，得靠自己重新建立信心。

更有意思的是他們分享 Symphony 的方式。沒有發布 npm 套件或 GitHub repo，而是寫成一份 spec，社群稱之為 Ghost Library（幽靈函式庫）。任何 coding agent 讀了這份 spec，就能在本地重組出整個系統。他們甚至有一套自動產生 spec 的流程：讓 Codex 以原始程式碼為參考寫出 spec，啟動另一個 Codex 照 spec 實作，再用第三個 Codex 比對實作和原版的差異來更新 spec。這個迴圈反覆跑，直到 spec 能高保真地重現系統。軟體不再是以套件的形式流通，而是以「規格書」的形式傳播。

模型的極限，與人類角色的重新定義

Lopopolo 很直接地說，目前模型在兩件事上還不行。第一是從全新的產品概念到原型，當眼前是一片空白、沒有既有畫面可參考時，他需要花最多時間引導 agent。第二是最複雜的重構，那種要拆解 monolith、重新定義介面邊界的工作，他必須頻繁介入。但他的態度是：不要跟模型對賭。這些限制每隔一兩個月就會被新模型推開一點，你的 harness 只要不跟模型能力打架，就能隨著模型一起變強。

他對自己現在角色的描述很有畫面感。他說自己像在帶一個 500 人的工程組織，不可能也不應該對每一行程式碼有深度意見。他做的是 post-merge code review：看一個代表性樣本，推斷哪裡 agent 在掙扎、哪裡已經跑得很順，然後把注意力集中到最需要幫助的地方。他不在意某段業務邏輯怎麼寫，在意的是它有沒有用團隊定義的 Command base class，因為那個 class 內建 tracing、metrics 和 observability，用了它就免費獲得這些能力。

團隊每天有一個 45 分鐘的站會。不是傳統的進度報告，而是「同步理解現狀」。因為大家都不太清楚程式碼庫現在長什麼樣，必須花時間把各自觀察到的趨勢和問題攤出來。他們甚至把所有工程師的 Codex session log 收集起來，每天跑一輪 agent 分析，找出團隊層級的改善機會，再寫回程式碼庫，讓所有人免費受益。PR 留言、build 失敗、每一次 agent 走岔路，全都是訊號，代表某個地方缺少 context。把這些 context 補回去，就是 Harness Engineering 的日常。

不要跟模型對賭

Lopopolo 在訪談尾聲提到一個核心張力：該把力氣投在 harness 上，還是投在模型訓練上？他的答案是建一個「on-policy harness」。意思是，你的防護機制不應該是在模型外面再包一層限制架構，強迫它照你的方式輸出。所有 guardrail 都應該內建在模型本來就會產生的東西裡，也就是程式碼本身。測試是最自然的 guardrail，跑測試本來就是寫可靠軟體的一部分。這樣不管模型怎麼升級，你的 harness 都不會跟它打架。

他每天部署超過 10 億個 token 的算力，團隊只有幾個人。Codex 應用程式在訪談時已突破 200 萬週活躍使用者，週成長率 25%。這些數字背後的訊息其實很簡單：coding agent 不是未來式，是現在式。Harness Engineering 這個新學科要回答的核心問題是，當程式碼變得可拋棄、agent 可以大量平行運作時，工程師的價值到底在哪裡？

答案是品味。你知道好的軟體長什麼樣，能把這個知識編碼成 agent 理解的格式，能在系統出問題時追溯到缺失的規範並補上。這不是寫程式碼的能力，是設計系統的能力。Lopopolo 用了一個詞來形容這件事的本質：把工程師腦中的隱性知識「蒸餾」出來。當這些知識不再只存在於人的腦中，而是被寫成文件、測試、lint 規則，它就變成了整個團隊（包括所有 agent）都能共享的資產。這才是 Harness Engineering 真正在做的事。