OpenAI Codex 產品負責人親述：沒有規範和路線圖，我們是怎麼做出產品的？

整理 & 編譯：深潮TechFlow

嘉賓：Alex，Codex 產品負責人；Romain，Codex 開發者體驗

主持人：Peter Yang

播客源：Peter Yang

原標題：How OpenAI's Codex Team Builds with Codex (43 Min) | Alex & Romain

播出日期：2026年4月5日

要點總結

Alex 是 Codex 的產品負責人，Romain 負責開發者體驗。他們讓我難得地深入瞭解了 Codex 團隊的運作方式，包括他們如何使用 Codex 構建產品，以及如何在沒有傳統的產品規範和路線圖的情況下進行產品發佈。Alex 還分享了一些關於產品經理 (PM) 未來發展的獨特見解，以及在招聘中真正重要的因素。

精彩觀點摘要

實時構建與 Codex Spark 的“思維速度”

• “當你想構建什麼東西……你可以切換到快速模式甚至是 Codex Spark，你就能擁有這種瘋狂的思維速度，來構建任何東西。在左邊是 GPT-5.4，在右邊是 Codex Spark，平均每秒就能有大概 1200 個數據（tokens），這速度太瘋狂了。” ——Romain

關於規格文檔與決策流程

• “我覺得我們在 Codex 團隊寫的規範文檔非常非常少，其實我覺得大量的工作是讓最接近實際的人做出儘可能多的決策，所以我們只有在問題最終變成那種很難裝進一個人腦子裡的問題時才會寫規範。” ——Alex

職業邊界模糊與設計師的進化

• “我們團隊的設計師現在寫的代碼量比六個月前的工程師還要多，現在我們的重點已經不再是‘能不能生成代碼’，真正重要的是：我們決定做什麼，以及如何確保產品的高質量。這也是為什麼對於非常複雜的特性，我更傾向於找到一個穩健的負責人來管理，而不是讓產品經理 (PM) 去負責這些系統的落地和維護。” ——Alex

產品設計哲學：讓模型“隱形”

• “我們對核心功能的設計非常謹慎，確保它們不會成為用戶和模型之間的障礙，而是讓模型更加智能，自動完成更多任務。” ——Alex
• “然後在此基礎上，我們思考如何以儘可能可配置的方式將產品打包給高級用戶，讓他們自己去探索和使用。比如，現在已經有用戶實現了 sub-agents（子智能體）。”——Romain

規劃哲學：拒絕“中期的尷尬”

• “在 OpenAI，我們要麼規劃短期目標，要麼規劃長期目標，但從不做中期規劃，因為中期規劃太複雜了。短期規劃通常指的是從現在起最多八週的目標，八週是我們能設定的最長時間範圍；我們也會制定長期的願景。例如我們可能會展望一年後的未來，設想那時的模型會變得更加智能；然，中期規劃就顯得有些尷尬，它通常表現為一個詳細的產品路線圖，但我們基本上沒有這種東西。我們更多的是結合長期願景，專注於那些能夠推動我們實現目標的具體任務。” ——Alex

“智能代理委託”帶來的界面變革

• “編碼將以一種‘智能代理委託’ (agentic delegation) 的方式進行。你會覺得，在終端中打開多個標籤並讓它們運行幾個小時是一種非常奇怪的交互形式。我們需要一個全新的界面，而那個時機恰好非常完美。” ——Romain

職業階梯的消失與“人才棧坍縮”

• “這幾乎讓每一條傳統的職業晉升階梯都開始變得模糊了。我們每個人其實都是“構建者 (builder)”，大家共同協作完成構建。如果一個初創公司有 PM，而工程師少於 20 人左右，那可能是一個危險信號。興趣和自主性是 AGI 時代人類最核心、最重要的品質。” ——Romain / Alex

招聘標準：作品勝過簡歷

• “當有人通過私信表示對加入我們團隊感興趣時，我的第一反應是看有沒有作品鏈接。如果有鏈接我總是點開，瞭解他們是否真的在構建東西，我更願意看他們的想法以及他們實際構建的東西。我完全不知道這些人上的是什麼大學。” ——Alex

現場演示：用 Codex Spark 在幾秒鐘內構建一個遊戲

主持人 Peter：我今天非常興奮地主持 Alex 和 Romain，他們來自 OpenAI 的 Codex 團隊。他們將演示如何構建 Codex 的新功能，Codex 是什麼能力，以及 Codex 團隊如何不停地發佈產品。你們想不想快速展示一下實際上可以用一次性提示（one-shot）構建什麼樣的東西？

Romain：

當然，讓我分享我的屏幕，其實有非常多東西我可以展示，但也許快速看一眼——比如，這裡是我一直在構建的一個 iOS 應用。如果我想為這個應用創建一個新功能，我可以簡單地通過口述說："嘿，你能為 NASA 的月球返回任務添加一個新屏幕嗎？"然後我用 GPT-5.4 發送這個提示，然後模型就會為這個特定的 APP 創建一個新屏幕。

但我們也有 Codex Spark 模型，它可以幫助你在短短几秒鐘內對任何東西進行構思和迭代，讓我給你展示一下 Spark 模型快速響應的差異。在左邊是 GPT-5.4，在右邊是 Codex Spark。然後平均每秒就能有大概 1200 個數據，這速度太瘋狂了。所以當你想構建什麼東西，比如一個遊戲——就在我們開始這次對話之前，我實際上去了 Codex 應用，用一個快速提示創建了一個類似 Animal Crossing 的小 2D 遊戲。

當我思路清晰時，我非常喜歡在 Codex 用的另一個功能是，打開 Codex，把對話浮在屏幕頂部，這樣如果我真的在做這個遊戲，我可以繼續迭代併產生更多想法。你有什麼想法嗎，Peter，對於你想在這個遊戲上做什麼改變？

Peter：也許添加一些更多的裝飾、房子、樹木之類的，讓它更生動一些？

Romain：

那麼我將發送這個任務，然後基本上在幾秒鐘內 Codex Spark 就能進行編輯，我們會實時看到變化，然後就好了，我們已經看到新的樹木出現了。

所以這就是為什麼我對 Codex 如此興奮，你真的可以擁有像 GPT-5.4 這樣的前沿模型，它可以承擔非常複雜的任務，比如分析或遷移數百萬行代碼。但如果你靈感湧現又思路清晰的時候，你可以切換到快速模式甚至是 Codex Spark，你就能擁有這種瘋狂的思維速度，來構建任何東西。

對於產品規範，我們只寫大約 10 條要點，僅此而已

主持人 Peter：我真的很好奇你們在團隊裡實際上是如何用 Codex 構建產品的，Alex，你們還寫規範嗎？或者你們讓 GPT 寫一個規範？你們用哪個模型來讓這些東西工作？

Alex：

我覺得我們在 Codex 團隊寫的規範文檔非常非常少，其實我覺得大量的工作是讓最接近實際的人做出儘可能多的決策，所以我們只有在問題最終變成那種很難裝進一個人腦子裡的問題時才會寫規範。順便說一下，現在一個人可以往腦子裡裝很多東西，因為他們可以做很多事情——他們把大部分編碼工作都委託出去了，所以一個人現在可以做很多。但如果它最終變成需要跨幾個人協調的事情，或者也許是一個我們必須做出的非常棘手的決策，那麼也許我們會寫一個規範。但是我們在這些情況下寫的文檔往往非常非常短。我們說的就是像 10 條要點之類的，然後就沒了。

主持人 Peter：好的。你們能給我展示一下這是怎麼工作的嗎？比如你給 Codex 幾條要點，然後也許它先寫出實際的需求？

Romain：

當然可以！不過，我想先給你展示一個更簡單的例子。假設我們在開發一個 iOS 應用，它目前已經完成了一些任務。現在，你對這個項目有一些新功能的想法，但還不確定具體的方向。這個時候，Codex 的強大之處就在於它能夠幫助我們規劃下一步的工作。比如，我只需要按下 Shift+Tab 鍵進入“計劃模式” (Plan Mode)，然後輸入“我們要構建什麼”，Codex 就會自動幫我生成一個初步的計劃。它會分析現有的代碼庫，理解項目的當前狀態，並提出一些潛在的想法。與此同時，我也可以加入自己的想法，引導模型生成一個更加完善的計劃。

在這個過程中，你會發現 Codex 會根據當前的代碼和文件提供一些建議。比如，它可能會問：“我們是否應該繼續完善之前提到的功能？還是應該優化可靠性儀表板？”如果我們決定優化可靠性儀表板，它還會進一步引導我們思考：優化的目標用戶是誰？整個過程就像與一個頭腦風暴夥伴合作一樣。

我經常用這種方式來驅動想法的產生。比如，對於一些簡單的改動，我會直接輸入提示，讓 Codex 生成代碼。

Alex：

而對於那些中等複雜度的改動，我可能會讓它生成一個具體的計劃，或者幫我推理實現的方式。而當我有一個模糊的想法時，我通常會直接打開 Codex，讓它幫我思考如何解決問題。即使我腦海中沒有明確的功能需求，Codex 也能通過提問和探索幫我理清思路。

不過，坦白說，有時候我並不會直接使用 Codex 生成的方案，特別是當改動比較複雜時。我會通過 Codex 的“計劃模式”進行探索，形成一個清晰的思路，然後將這些想法分享給工程師團隊。最終，這個思考的過程比生成的計劃本身更重要。

順便一提，我們團隊的設計師現在寫的代碼量比六個月前的工程師還要多，這在以前是不可想象的。這主要得益於工具的進步，讓設計師能夠更深度地參與到開發中。不過，我也經常被團隊調侃去年提交的 PR（代碼合併請求）太少。雖然很多改動只是一些小調整，但我確實覺得自己應該多做一些。

現在，我們的重點已經不再是“能不能生成代碼”，因為智能體 (Agent) 已經能完成大部分編碼任務，真正重要的是：我們決定做什麼，以及如何確保產品的高質量。這也是為什麼對於非常複雜的特性，我更傾向於找到一個穩健的負責人來管理，而不是讓產品經理 (PM) 去負責這些系統的落地和維護。

設計師寫的代碼比 6 個月前的工程師還要多

主持人 Peter：Codex 的應用程序用起來非常直觀和簡單。與外面一些專業產品相比，我覺得 Codex 的學習曲線低得多。其他一些專業產品雖然功能強大，但需要花費大量時間去學習。我甚至覺得，如果我不在 Twitter 上關注相關的信息，我可能根本不知道該怎麼用它們。

但 Codex 讓我印象深刻的一點是，它不僅簡單易用，還提供了許多高級功能，比如 skills（技能）和 automations（自動化）。你們團隊內部會經常用這些功能嗎？

Romain：

是的，我們用得非常多，實際上我認為 skills 是 Codex 應用中最有趣的功能之一。舉個例子，現在如果你和一個設計師一起使用 Figma，只需要打開 Figma 的 skill，就可以直接從 Figma 文件中提取所有的 React 組件、變量等細節，然後 Codex 會自動生成相應的代碼。再比如如果你正在開發一個應用程序，想要將它分享或者部署到 Vercel、Cloudflare 或 Render，只需通過 skills 下達簡單的指令，Codex 就會自動完成這些任務。

我最近和一個朋友聊天，他告訴我有很多改進產品的想法，於是他對 Codex 說：“把這些任務全部寫到 Linear 上，方便我追蹤。”然後他使用了 Linear 的 skill。接著，他又告訴 Codex：“我要去睡覺了，你繼續完成我們剛才討論的所有任務，並把它們標記為完成。”結果他第二天醒來時，發現所有任務真的都完成了。

Alex：

關於你剛才提到的應用程序的簡單性，我覺得可以分享一下我們是如何思考其設計的。在這個領域裡，開發者普遍熱衷於為自己構建自動化工具，以簡化日常工作。我們認為，產品的一個關鍵特性是它必須高度可配置。對於 Codex 來說，它就像一個開源的工具箱，用戶可以深入其中，根據自己的需求進行定製。

每次我們推出新功能時，總會有用戶在 Twitter 上抱怨這個功能（即使它還沒正式上線）有問題，而問題的原因通常是他們自己修改了代碼或 fork 了它。但在我看來，這恰恰證明了我們的產品成功，因為這些前沿用戶正在與我們共同探索未來，並推動產品的進步。

然而我們也意識到，只有為這些高端用戶構建產品是不夠的，否則，產品最終會變得複雜難懂。我們必須找到平衡點，既要滿足高級用戶的需求，也要讓產品對普通用戶來說簡單直觀。因此我們對核心功能的設計非常謹慎，確保它們不會成為用戶和模型之間的障礙，而是讓模型更加智能，自動完成更多任務。

Romain：

然後在此基礎上，我們思考如何以儘可能可配置的方式將產品打包給高級用戶，讓他們自己去探索和使用。比如，現在已經有用戶實現了 sub-agents（子智能體）。這些功能並不是我們主動設計的，而是用戶自己發現並實驗出來的。通過觀察用戶如何使用這些功能，我們學到了很多東西。

接著我們會思考：如何讓這些功能對其他用戶來說也變得超級簡單？Codex app 就是一個很好的例子。大約在 GPT-5.2 Codex 於去年 12 月發佈時，模型的能力開始逐步穩定，但也越過了一個臨界點。用戶可以開始將更長時間、更復雜的任務委託給模型，而模型可以一次性完成這些任務。

我們開始注意到，有些用戶已經在使用 tmuxing（在終端中運行多個並行任務），這是一種在終端中分割窗口以同時運行多個任務的方式。我們在社交媒體上看到了一些非常有趣的例子，比如有一張 Peter Steinberger 的照片，他的屏幕上有 18 個終端窗口，跨越了三個顯示器，看起來就像一種“創意的開放式爪子”。我們看到用戶以這種非常高級的方式使用 Codex，感到非常興奮。

同時，我們繼續優化基本產品（如 CLI）中的任務委託功能，確保它們運行良好。但我們也意識到，可能只有頂尖的 1% 工程師會使用這種方式工作。於是我們思考：如何讓這些功能看起來更加直觀？這就是為什麼我們開發了 Codex app。

當你第一次打開 Codex app 時，它看起來就像一個簡單的聊天窗口。你可以直接開始使用它，它會正常工作，但隨著時間的推移，你會逐漸發現更多功能，比如側邊欄、運行多個任務的能力，以及在任務之間輕鬆切換的功能。你會覺得自己變得超級高效。然後你可能會注意到“skills”標籤，點進去探索更多功能。我們希望用戶在使用 Codex app 時，能有一種幾乎像玩遊戲一樣的體驗，不斷髮現新的可能性。

Romain：

完全同意。而且，這也正是我們從一開始就有的願景：編碼將以一種“智能代理委託” (agentic delegation) 的方式進行。甚至在我們差不多一年前開始開發 Codex 時，我們就一直在思考這個未來。我們相信，工程師將能夠同時處理多項任務，而模型會負責執行復雜的細節工作。

不過坦白說，當時的模型能力還沒有達到這個水平。我們必須等到 GPT-5.2 Codex 的發佈，以及之後的那個臨界點，看到模型能夠非常徹底、可靠地工作幾個小時甚至幾天。到了那個時候，我們突然意識到，傳統的終端界面已經不再適合這種工作方式。你會覺得，在終端中打開多個標籤並讓它們運行幾個小時是一種非常奇怪的交互形式。於是，我們需要一個全新的界面，而那個時機恰好非常完美。

Alex：

回顧 Codex 的發展歷程，我們經歷了兩個重要的“vibe shift”（趨勢轉折點）。第一個是在去年八月，我們推出了 Codex Cloud 產品。那是一個非常棒的想法，用戶當時非常興奮，不過當時可能還稍微有些早。於是我們在八月發佈了 GPT-5 這個非常出色的交互式編碼模型，並決定專注於解決模型當前能夠處理的問題。我們因此推出了 Codex CLI 和 IDE 插件，用戶量在幾個月內迅速增長了 20 到 30 倍，這真是太棒了。

第二個轉折點是在去年 12 月到今年 1 月之間。那時，我們終於實現了最初的願景——將任務委託給模型。模型的能力達到了一個新的高度，能夠獨立完成更復雜的任務，這標誌著我們進入了一個全新的階段。

我們的規劃分為短期和長期，從不做中期規劃

主持人 Peter：我很好奇 Codex app 是如何開發出來的？你們一年前是否制定了某種年度路線圖，比如“我們計劃在某個時間點推出 Codex app”？還是說，你們更多是觀察市場需求，快速原型化了一些想法？

Alex：

其實都不是。我從我們的研究員 Andre 那裡聽到過一個非常棒的建議：在 OpenAI，我們要麼規劃短期目標，要麼規劃長期目標，但從不做中期規劃，因為中期規劃太複雜了。

短期規劃通常指的是從現在起最多八週的目標，八週是我們能設定的最長時間範圍。在這個時間框架內，我們會設定一個具體的目標，集結團隊全力以赴去完成它。這是 OpenAI 的一個強項——我們非常擅長圍繞一個明確的目標組織團隊。

另一方面，我們也會制定長期的願景。例如，我們可能會展望一年後的未來，設想那時的模型會變得更加智能。比如，我們可能會想象未來的模型可以獨立工作，不再需要借用我們的電腦資源，也不再侷限於一次只能完成一件事。我們希望擁有無限多個模型，它們可以獨立完成任務、自我驗證代碼，甚至能夠自我部署和監控，而我們完全不需要手動提示它們。

然而，中期規劃就顯得有些尷尬。它通常表現為一個詳細的產品路線圖，但我們基本上沒有這種東西。我們更多的是結合長期願景，專注於那些能夠推動我們實現目標的具體任務。

以 Codex app 為例，當時我們的一個戰略目標是將用戶從特定的工作空間 (workspace) 中解放出來。傳統的開發工具（比如 VS Code）通常是綁定到一個特定的工作空間的，比如一個代碼庫的特定檢出點或文件夾。即使使用 git worktree，一次也只能打開一個工作目錄，CLI 也是類似的限制。

但我們的願景是：用戶能夠與雲端的智能代理 (agent) 協作，而這些 agent 可以獨立工作。我們希望用戶能夠同時與多個 agent 進行交互，甚至讓一個 agent 為用戶協調多個 agent 的工作，這種體驗應該是自然且直觀的。

同時，我們也意識到，如果一開始就完全依賴雲端，開發者可能會覺得不夠方便，因為他們需要配置環境，而在模型執行任務時，如果需要手動干預或調整，也會變得麻煩。因此我們決定開發一個本地化的體驗，它既能夠與本地文件夾無縫協作，又能與雲端的智能代理保持連接。

當我們開始開發這個應用程序時，我們有一堆這樣的“願景思考”，這些是一些比較抽象的想法。與此同時，我們的工程師也在進行各種原型設計。他們會說：“我希望我們能有一個應用程序。”於是就開始嘗試開發各種不同的版本。實際上，我們還舉辦了一次“黑客周”活動，多個工程師獨立開發了不同版本的應用程序。你可能也參與了，我記不太清了。

當這個項目真正啟動時，我們唯一需要明確寫下來的就是：為什麼我們認為開發一個應用程序是個好主意。我們並沒有為這個應用程序制定具體的產品規範，我們是通過實際的開發工作逐漸明確了產品的方向。

不過，當時這個項目還是有一些爭議的——我們是否真的需要開發一個應用程序？我們的 IDE 插件已經非常受歡迎了，我們是否應該專注於提升插件的質量？CLI 也很有潛力。那麼，如果我們要開發一個應用程序，它的意義是什麼？我們應該朝哪個方向努力？這就是這個項目開始時我們面臨的一些問題。

Romain：

是的，幸運的是，當時我們已經有了一個非常成熟的 IDE 插件解決方案，並對其進行了深入優化。用戶可以在 VS Code、Cursor、Windsurf 以及其他 IDE 中使用這些插件。我們從 IDE 插件的代碼庫中積累了大量經驗，這為開發 Codex app 提供了一個非常穩健的起點。

Alex：

沒錯。實際上，Codex app 和 IDE 插件在底層共享了大量代碼。它們都連接到同一個核心的 Codex harness，這是一個用 Rust 編寫的開源框架，CLI 也使用了它。我們有意採用分層設計，以便在不同工具之間實現代碼共享和功能擴展。

主持人 Peter：至於決定開發 Codex app 的過程……現在回頭看，這似乎是一個顯而易見的決定，因為使用 Codex app 比打開一堆終端窗口要直觀得多。但當時我們下這個決定的理由主要是：Codex app 對初學者來說更加友好，同時它也是管理多個智能代理協作的最佳界面。

Alex：

我認為，我們團隊的思考方式深受 AGI（通用人工智能）願景的影響。我們一直在思考：未來的工作方式會是什麼樣子？

其實我會換個角度說，我們很清楚我們需要一個界面，讓用戶能夠自然地將任務委託給多個智能代理。我們知道未來的模型將具備這種能力——事實上，我們已經看到用戶在嘗試跨智能代理進行任務委託了。我們需要一個界面，讓這種協作方式顯得順理成章，同時能夠無縫擴展到雲端。

我們希望這個界面符合人體工程學設計，讓用戶覺得與多個智能代理協作是一種直觀自然的體驗，而不是需要複雜的操作或技巧才能實現。

Romain：

是的，而且這個應用程序的受眾不僅僅是初學者，實際上即使是最資深、最有經驗的工程師，包括 OpenAI 內部的頂尖工程師，比如 Peter、OpenClaw 和 Greg Brockman，他們現在都開始將 Codex app 作為主要的開發工具。這表明我們關於智能代理委託 (agentic delegation) 的願景正在逐步成為現實。

Alex：

是的。我們提到 Peter 是因為他剛剛加入 OpenAI，我們對此感到非常興奮。去年十月，我在舊金山的 Fort Mason 和他散步時，提過開發一個新界面的想法。我說我們希望有一種新的界面，讓任務委託 (delegation) 變得更加自然，當時他告訴我，他永遠不會使用這樣的東西。

但是上週末，他發了一條推文說：“其實這個應用程序還挺好用的，我現在喜歡它了。”

Alex 作為 Codex 產品經理 (PM) 的日常工作內容是什麼

主持人 Peter：Alex 你之前有一段時間是 Codex 團隊裡唯一的產品經理 (PM)，對吧？現在 Codex 團隊有多少人？大概是 50 到 100 人之間嗎？

Alex：

差不多，大概就在這個範圍內。我們在五月份的時候大概只有 8 個人，我不記得確切的數字了。但從那以後我們的團隊增長得非常快，現在大概是在 50 到 100 人的範圍內。

主持人 Peter：那麼平時你是如何分配時間的？你的日常工作是什麼樣的？還是說你根本沒有一個典型的工作日？

Alex：

我最近也在思考這個問題，因為我發現自己很難回答。我意識到，我的工作模式其實是分階段的，這只是我個人的方式，並不一定適合所有人。

比方說，在我們發佈 Codex app 的時候，我完全處於執行模式。那時候，我的全部精力都放在產品的質量上，確保我們沒有遺漏任何細節，把每一件小事都落實到位，這種模式下我會花很多時間使用 Codex 工具。

我們會用 Codex 來獲取反饋，比如瞭解 Slack 上的討論內容，以及用戶的反饋。我會讓 Codex 總結這些信息，然後將它們記錄到 Linear 上。除此之外，我還會用 Codex 來分析代碼質量，並直接用它來進行小的代碼修改。因為有時候直接用 Codex 處理一些小問題，比去找其他人協調任務並讓他們優先處理要快得多，尤其是在我們目標是在兩週內發佈應用程序的情況下。

在這個過程中，當然還有很多人性化的工作，比如為團隊加油打氣、激勵大家，同時也要對我們正在開發的產品保持批判性。其實我發現自己是否處於執行模式，可以通過我是否頻繁使用 Twitter 來判斷。我也不知道為什麼，但當我需要與人交流時，我就會更多地使用 Twitter。

然後還有另一種模式，比如現在，我的腦海中非常清楚：我們已經達到了一個新的階段。我們現在有了非常強大的模型，比如 GPT-5.4 表現非常出色。我們的應用程序體驗也超出了預期，已經覆蓋了所有平臺，包括 Windows。所以現在我覺得，是時候真正回到雲端了，並在那裡投入更多精力。

當我們進入這種階段時，我會花更多時間去思考接下來該做什麼，以及瞭解當前的狀態，這是一種協調模式。在這種模式下，我花在 Codex 上的時間會變少，更多地是用 Codex 來進行溝通，而不是寫代碼。所以，我至少有這兩種工作模式，當然可能還有更多。

主持人 Peter：你們需要進行多少跨職能的對齊工作？

Alex：

我們在團隊內部幾乎不需要進行太多的跨職能對齊工作，我們有點故意把自己看作是一個像“海盜船”一樣的團隊。即使在 Codex 團隊內部，現在也只有我和最近加入的兩個新的產品經理。我們有一些負責人，雖然直到最近大家基本上都直接向我彙報，但我們基本上是以一種模糊的方式一起推進項目，所以團隊內部的對齊工作並不多。

不過，現在越來越明顯的是，構建 Codex 的一個重要部分是開發這個 coding agent。而且大家現在也越來越清楚，coding agent 不僅僅可以用來寫代碼，它在其他任務中也非常有用。

比如，我們發現用戶使用 Codex app 不僅僅是為了寫代碼。他們用它來完成整個軟件開發生命週期中的各種任務，而且現在整個 OpenAI 的大多數員工都在使用 Codex app，即使是非技術人員，我也經常看到他們在使用這個應用程序。

所以這種認知讓我們意識到，我們需要思考如何讓 Codex 不僅僅對開發者有用。這就需要更多的跨職能對齊，因為作為 OpenAI，我們還有 ChatGPT，很多用戶都在使用它，因此我們需要非常慎重地考慮如何將這些產品更好地結合起來。

Romain：

從我的角度來看，我們的開發者體驗團隊現在有點像是 Codex 團隊的延伸。我們的大部分精力都花在 Codex 上，主要有幾個原因。

首先，這是一款非常令人興奮的產品，開發者們非常喜歡使用 Codex，我們希望讓它變得更加出色。正如 Alex 所說，我們的工作模式也分為幾個階段，我們會與 Codex 團隊一起投入到產品發佈的準備工作中，比如準備發佈所需的素材，以及教開發者如何最大化地利用 Codex。發佈之後，我們還會引導開發者探索 Codex 在不同場景中的應用。

另一個讓我們感到非常有趣的地方是，如果你看整個 OpenAI 的平臺，今天已經有數百萬開發者在使用我們的 API，構建從圖像到語音等各種模態的應用程序。

現在最好的開發方式已經變成了以 Codex 作為入口點。如果你回到一年前，或者甚至去年夏天我們剛剛推出 GPT-5 的時候，我們還需要編寫很多指南，教大家如何為 GPT-5 編寫 prompt。GPT-5 是一個推理能力非常強的模型，與 GPT-4 有很大的不同。而現在，我們嘗試讓開發者即使在這些用例中，也能通過 Codex 和 skills 來完成任務。

比如，如果你需要更新一個集成系統，我們會建議你使用 Codex 和它的技能功能。結果是 Codex 幾乎可以完全幫助你完成任務。因此我們的團隊也非常注重跨職能協作，並將 Codex 視為整個 OpenAI 開發者平臺的基石。

Alex：

我覺得我們 Codex 團隊在工作方式上有一個很有趣的特點——對我來說，最棒的部分就是和社區的互動。無論是在線上，還是在現實生活中的活動現場，我們都非常注重與社區的聯繫。

在產品發佈時，我們的工作非常以發佈為導向——明確什麼時候發佈什麼內容；同時，我們也非常以反饋為導向——每當社區提供反饋時，我們會迅速採取行動，修復問題並與他們溝通。所以我們的團隊一直保持高度的在線狀態，我覺得這是非常重要的。

比如說，當我們發佈 Codex app 的時候，我們和 Dom 以及他的團隊合作得非常緊密。他們幫助我們組織了一次大規模的 alpha 測試，邀請了大量用戶參與，共同開發產品。通過他們的反饋，我們不僅改進了應用程序，還完善了 skills 和文檔等相關資源。

我覺得這正是我們 Codex 團隊的獨特優勢所在：因為我們是開源的，我們對自己所做的一切都保持高度的透明，而社區也對這種做法給予了巨大的支持和回饋。

主持人 Peter：我們來聊聊 Peter（OpenClaw 的創始人），我是 OpenClaw 的早期用戶。你們是如何將 Peter 整合到團隊中的？這個個人智能體 (personal agent) 的願景，是不是和他目前的工作有關？你們是怎麼規劃的？

Alex：

有兩方面可以說。首先，Peter 是 Codex 非常重度的用戶。實際上，OpenClaw 很大程度上是用 Codex 構建的。他通過自己的使用體驗向團隊提供了大量反饋，這些反饋極大地幫助我們改進了 Codex，雖然這只是他的“兼職”，但他真的非常投入，我們對此感到特別興奮。

其次，我現在不能透露太多細節，但可以說的是，他正在幫助我們構建下一代個人智能體 (personal agent)，並將其直接集成到 ChatGPT 中。

Romain：

我覺得 Peter 的工作中最讓我著迷的一點是，當大家在使用 OpenClaw 的時候，可能已經隱約看到了未來的可能性，但讓我感到震撼的是 Peter 很早以前就看到了這個願景。

如果你回顧整個 2025 年，他在去年開發了 40 多個開源項目，而這些項目都圍繞著一個核心願景：通過命令行界面訪問他的日曆、推文和 Gmail 等個人工具。他通過這些項目，實際上將 skills 和命令行工具的願景變成了現實。而我們今天使用的編程智能代理 (coding agent) 正是基於這個願景構建的。

未來，這個智能代理將不僅僅是一個編程工具，它會變成任何類型的個人智能體 (personal agent)。因此，Peter 在這個過程中為我們提供了非常寶貴的反饋，因為他已經開發了許多現在成為開源生態系統核心部分的工具。

主持人 Peter：

我覺得像 Peter 這樣的人，能夠構建出如此出色的開源社區，真的令人欽佩。他的工具非常好用，以至於讓我都不想打開其他任何應用程序了。我只想和我的小機器人聊天。

Alex：

你把它連接到什麼系統上了？你是把它連接到所有東西上了嗎？

主持人 Peter：

沒錯，我把它連接到了很多服務上。比如它可以訪問我的銀行信息、YouTube 賬戶、語音助手、日曆以及 Google 服務。當我躺在床上的時候，我的妻子會問我：“你在和誰說話？”我會回答：“我在和我的 OpenClaw 機器人聊天。”

不過，現在有很多“投機者”會收取高達 5000 美元的費用來幫助別人設置 OpenClaw。所以如果你們能讓它變得更大眾化、更容易上手，那將是一個巨大的突破，你們確實在朝著正確的方向努力。

傳統的職業晉升階梯已經不再適用

主持人 Peter：我記得你們曾說過類似“現在大多數團隊已經不需要那麼多 PM 了”這樣的話？

Romain：

我覺得這些工具最讓我感到驚歎的一點是，這不僅僅是關於 PM 或者是否需要 PM 的問題。這幾乎讓每一條傳統的職業晉升階梯都開始變得模糊了。以前我們有明確的分工：設計師負責設計，工程師負責開發，PM 負責管理，可能還有一個特定的比例，就像某種“黃金比例”。

但是現在，如果你是一個工程師，你的生產力顯著提高了。如果你是一個設計師，你能夠通過這些工具獲得超能力，變得更加技術化。如果你是一個 PM，以前只能寫策略文檔，而現在你可以直接原型化。這並不意味著你需要為數十億用戶負責某個功能，但你確實可以用這些工具真正去構建一些東西，向團隊展示你的願景。

所以，我覺得最讓我著迷的是，現在所有職業階梯之間的界限都在模糊。我們每個人其實都是“構建者 (builder)”，大家共同協作完成構建。

Alex：

我記得我在網上某個地方說過，如果一個初創公司有 PM，而工程師少於 20 人左右，那可能是一個危險信號，也許我確實說過類似的話。

我覺得就像你說的，現在所有這些角色都在逐漸融合。設計師可以做更多的工程工作，工程師可以涉足設計，PM 也可以參與構建。但工程師通常需要專注於寫代碼，因此他們以前不會處理任務分揀或其他 PM 的項目管理部分。

不過現在，這些事情變得非常容易了。你可以直接讓 agent，比如 Codex，去分析反饋和優先級，這樣工程師就能騰出更多時間專注於自己的工作。我覺得現在每個人都能做其他人的工作。

Scott Belsky 提出過一個想法，叫“人才棧的坍縮 (collapse the talent stack)”。我喜歡這個觀點，我覺得這確實正在發生。房間裡需要的人越少，事情就會進展得越順利，每個決策也會更加清晰。

所以問題就變成了：PM 還能做什麼？我覺得有很多 PM 其實應該考慮轉崗。比如說如果你是一個 PM，一直想成為工程師，但你更擅長管理人，而工程能力不強，那麼現在也許你可以成為一名工程經理 (engineering manager)。有了智能代理，對你來說這可能是一個更加明確的角色。類似地有些 PM 可能更傾向於成為設計師，更接近實際的構建工作。

我認為最終還是取決於個人的興趣。對於我來說，興趣和自主性是 AGI 時代人類最核心、最重要的品質。所以，如果你更感興趣的是寫代碼，而你之前只是因為需要有人做 PM 的工作才從事這個角色，那麼現在你完全可以轉型為工程師，從工程的角度繼續完成同樣的事情。設計領域也是一樣。

但如果你真正感興趣的是和用戶互動，即使這會讓你遠離實際的構建工作，比如嘗試理解用戶需求、洞察市場趨勢等，那麼在一個團隊足夠大的情況下，PM 仍然有發揮作用的空間。

Romain：

我再補充一點，我仍然認為每個問題都需要一個人類來負責這個問題領域，但我不認為這個人必須是 PM，我覺得這很大程度上取決於產品的性質。

我們在這裡非常幸運，因為我們在為 Codex 工作，這是一個面向開發者的工具。我們自己就是最好的用戶。而且因為它是開源的，我們可以直接與社區互動，進行聯合開發。

但如果你回到十年前，比如我在 Stripe 工作的時候，當時公司有 250 人，卻沒有一個 PM，甚至沒有任何 AI 工具。為什麼？因為 Stripe 是一個 API 產品，我們所有人都是工程師，對什麼是一個優秀的 API 有著非常直覺的理解。我們當時構建的正是我們夢想中的 API，一個只需要幾行代碼就能實現的優雅解決方案。

但如果你所處的是一個不同的領域，比如工程師對用戶的需求沒有那麼多直覺，那麼你可能就需要更多的 PM 來與客戶溝通，理解他們的需求。尤其是當你服務的行業或領域與工程師的直覺不完全匹配時，PM 的作用會更加重要。不過我們在 Codex 團隊中非常幸運，因為我們正在構建的正是我們自己也想要使用的工具。

Alex：

在這種環境下，PM 的角色可能只是一個標籤，指代的是那個對用戶最感興趣、最關心用戶需求的人，這個人完全可以是一個非常貼近用戶的工程師。所以，我覺得這些職業標籤正在逐漸失去傳統的意義，雖然有點混亂，但這並不是壞事。

主持人 Peter：

我在自己的團隊中也有類似的發現。我覺得最好的工程師不會問我“接下來我們應該構建什麼”，他們會主動去和用戶交流，自己弄清楚需要開發什麼，然後再跟我討論，這種方式讓大家的目標非常一致。

Romain：

這其實就是我們 Codex 團隊的工作方式，今天在 Codex app 中使用的許多功能，實際上都是工程師從下到上 (bottom-up) 提出的絕妙創意，因為他們自己也需要這些功能。

Alex：

不過我想說的是，有一種工程師的類型是我非常喜歡合作的。他們喜歡和用戶交流，思考應該構建什麼功能。這些人通常在構建系統方面也非常出色，速度快、能力強，思路清晰，但也有一些工程師對與用戶互動完全沒有興趣，他們只想專注於構建系統，我覺得這些人也有巨大的發展空間。

再次強調，這就是我對 AI 時代的看法——我們都可以更加“做自己”。AI 和團隊會幫助你完成那些你不想做的事情，從而讓你專注於自己的興趣和優勢。

主持人 Peter：

我確實覺得“構建者 (builder)”這個標籤非常重要。我覺得很多 PM 都想成為領導者，但傳統的職業晉升階梯是，你成為 VP 之類的職位後，反而沒有時間構建東西了。你每天都在產品評審中，只是給出一些反饋，而沒有時間真正去開發，我覺得很多 PM 並不想這樣，我希望自己能夠一直貼近用戶，真正發佈產品。

Alex：

我完全同意。我其實並不認為 PM 是一個領導角色，我更傾向於把它看作是一個“填補空白的角色”。有時候，這個角色可能需要承擔一定的領導責任，但即使如此領導力更多的作用是幫助團隊達成一致，而不是單純依賴某個人提出一個天才的解決方案。

有一點我可以肯定：在 OpenAI，最優秀的 PM 都會深入到具體的細節中去。而且我認為以高級領導職位加入 OpenAI 是一件非常具有挑戰性的事情，因為這裡的文化依然強調對細節的關注。因此，最好的方式是直接從一開始就深入到細節中去。

Codex 團隊在招聘時看重什麼？（答案並不是你的簡歷）

主持人 Peter：你當你們為 Codex 團隊招聘時，除了要求候選人是 Codex 的重度用戶以外，你們還看重哪些品質？

Alex：

我之前提到過，我非常看重候選人的“自主性 (agency)”。我們希望找到那些會主動做事的人，這是最重要的品質之一。

在 OpenAI，尤其是 Codex 團隊，我們的文化並不是那種“你加入後，我們會給你列出 12 個逐步增加難度的任務”的類型。我們的風格更像是：“歡迎加入！現在，開始你的探索吧。”

因此，我們更傾向於尋找那些自我驅動的人——他們有行動力，有自己的想法，知道自己想要做什麼，並且不害怕挑戰現有的想法。因為說實話，有些現有的想法可能本身就是錯誤的，可能只是我們當初的一個偶然決定。

我理想中的隊友是那種願意主動承擔額外責任的人，甚至願意負責一些未知的領域。這些品質是我們特別看重的。至於具體的技能，我們通常會優先考慮那些技術能力強、與工程相關的候選人。

Romain：

我完全同意。在我的開發者體驗 (DevX) 團隊中，我通常會尋找那些擁有高自主性的人。他們需要在技術上非常強大，特別是在使用像 Codex 這樣的工具時表現出色。但除此之外，我還特別看重那些對與開發者和構建者 (builders) 一起工作、分享知識充滿熱情的人。

比如，這周我們剛剛宣佈，Thomas 將加入我的團隊，他是那個開發了開源 Codex monitor 的人。他不僅非常有創造力，還是 Codex 的重度用戶，並且熱衷於分享自己如何利用 Codex 構建工具的經驗。

我們需要這樣的人才，因為我們正在努力將數百萬開發者引領到 Codex 所代表的光明未來。我相信智能代理編程 (agentic coding) 正在徹底改變我們對軟件開發、應用程序和產品構建的傳統思維方式。我們的目標是向全世界展示這種可能性，並幫助開發者學習如何利用這些工具實現自己的創意。這就是我在尋找的品質。

Alex：

我補充一下，在我看來 DevX 團隊的理想候選人可以簡單描述為“非常優秀的工程師，同時擅長利用社交媒體與社區互動”。

Romain：

你說對了一部分。不過我想補充一點：我們希望候選人對社區有很強的責任感，而且還要考慮到全球範圍內不同地區的社交媒體使用習慣。比如，在一些地方，開發者可能更傾向於使用 LinkedIn 或其他平臺，而不是 Twitter。所以我們需要擴展這個定義：候選人需要在全球範圍內的社交媒體上有良好的表現。我們特別看重那些喜歡與社區互動、熱衷於教學和分享知識的人

主持人 Peter：

其實，一個人的自主性甚至在面試之前就能看出來。比如，他們是否在線上發佈過作品？是否有自己的 side projects？

Alex：

當有人通過私信表示對加入我們團隊感興趣時，我的第一反應是：“有鏈接嗎？”如果有鏈接，我幾乎都會點開看。我會好奇地檢查他們的作品，瞭解他們是否真的在構建東西。

當然有些人會附上一封申請信，說明他們為什麼對這個職位感興趣，甚至附上他們的簡歷，但我更願意看他們的想法以及他們實際構建的東西。我前幾天還意識到一個有趣的事情——我完全不知道這些人上的是什麼大學。

主持人 Peter：誰在乎呢，誰會在意？我真的很高興我們現在生活在一個這些愚蠢的學歷不再那麼重要的時代，只要讓我看看你實際構建了什麼就足夠了。