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

「興趣和自主性是 AGI 時代人類最核心、最重要的品質。」

整理 & 編譯：深潮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 就是一個很好的例子。大約在去年 12 月 GPT-5.2 Codex 發布時，模型的能力開始逐步穩定，但也跨過了一個臨界點。使用者可以開始把更長時間、更複雜的任務委派給模型，而模型可以一次性完成這些任務。

我們開始注意到，有些使用者已經在使用 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：**誰在乎呢，誰會在意？我真的很高興我們現在生活在一個這些愚蠢的學歷不再那麼重要的時代，只要讓我看看你實際建構了什麼就夠了。