OpenAI Codex 產品負責人親述：沒有規格和路線圖，我們是怎麼做到產品的？
整理 & 編譯：深潮TechFlow
來賓：Alex，Codex 產品負責人；Romain，Codex 開發者體驗
主持人：Peter Yang
播客來源：Peter Yang
原始標題：How Open Buds's Codex Team Builal with Codex Team (43) | Romain
播出日期：2026年4月5日
重點總結
Alex 是 Codex 的產品負責人，Romain 負責開發者體驗。 他們讓我難得地深入了解了 Codex 團隊的運作方式，包括他們如何使用 Codex 建立產品，以及如何在沒有傳統的產品規格和路線圖的情況下進行產品發布。 Alex 也分享了一些關於產品經理 (PM) 未來發展的獨特見解，以及在招募中真正重要的因素。
精彩觀點摘要
- “當你想構建什麼東西……你可以切換到快速模式甚至是 Codex Spark，你大概在這個瘋狂的思維右邊 1200 個資料（tokens），這速度太瘋狂了。 ——Alex
- “我們團隊的設計師現在寫的代碼量比六個月前的工程師還要多，現在我們的重點已經不再是‘能不能生成代碼’，真正重要的是：我們決定做什麼，以及如何確保產品的高質量 去負責這些系統的落地和維護。 ——Alex
- 「然後在此基礎上，我們思考如何以盡可能可配置的方式將產品打包給高級用戶，讓他們自己去探索和使用。比如，現在已經有用戶實現了 sub-agents（子智能體）。」——Romain
- 「編碼將以一種『智慧代理委託』 (agentic delegation) 的方式進行。你會覺得，在終端中打開多個標籤並讓它們運行幾個小時恰好是一種非常奇怪的互動形式。我們需要一個非常完美的介面，而那個時機恰好是一種非常奇怪的互動形式。我們需要一個非常完美的介面，而那個時機恰好是一種非常奇怪的互動形式。我們需要一個非常完美的介面，而那個時機恰好是一種非常奇怪的互動形式。我們需要一個非常完美的介面，而那個時機恰好是一種非常奇怪的互動形式。我們需要一個非常完美的介面，而那個時機恰好是一種非常奇怪的互動形式。我們需要一個非常完美的介面，而那個時機恰好是一種非常奇怪的互動形式。我們需要一個非常完美的介面，而那個時機恰好是一種非常奇怪的互動形式。我們需要一個非常完美的介面，而那個時機恰好是一種非常奇怪的互動形式。我們需要一個非常完美的介面，而那個時機恰好是一種非常奇怪的互動形式。我們需要一個非常完美的介面，而那個時機恰好是一種非常奇怪的互動形式。我們需要一個非常完美的介面，而那個時機恰好。 ——Romain
- “這幾乎讓每一條傳統的職業晉升階梯都開始變得模糊了。我們每個人其實都是“構建者 (builder)”，大家共同完成構建。如果一個初創公司有興趣，而自 20 人左右 時代人類最核心、最重要的品質。 ——Alex
- "在中期的尷尬」
- >「在中期的尷尬」。 OpenAI，我們要麼規劃短期目標，要麼規劃長期目標，但從不做中期規劃，因為中期規劃太複雜了。 展望一年後的未來，設想那時的模型會變得更加智能；然，中期規劃就顯得有些尷尬，它通常表現為一個詳細的產品路線圖，但我們基本上沒有這種東西。 ——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（程式碼合併請求）太少。 雖然很多改動只是一些小調整，但我確實覺得自己應該多做一些。
現在，我們的
設計師寫的程式碼比 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 團隊有一段時間是 Codex 團隊？ 現在 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：誰在乎呢，誰會在意？ 我真的很高興我們現在生活在一個這些愚蠢的學歷不再那麼重要的時代，只要讓我看看你實際上建立了什麼就足夠了。