OpenAI 的 PM 說：PM 不是領導崗，20 人以下的團隊不需要 PM
整理版優先睇
OpenAI Codex 團隊嘅 PM 話：PM 唔係領導崗，20 人以下嘅團隊唔需要 PM
呢篇文章係整理自 Peter Yang 嘅播客，訪問咗 OpenAI Codex 嘅產品負責人 Alex 同 DevX 負責人 Romain。Codex 係 OpenAI 增長最快嘅產品之一，團隊由去年 5 月得 8 個人，到而家差唔多 100 人，但大部分時間只有 Alex 一個 PM。佢哋嘅做法好反傳統：唔寫 PRD、唔做中期路線圖、設計師同 PM 都自己寫代碼提 PR。Alex 仲大膽話 PM 唔係一個好嘅領導崗位，而係一個「填補空隙」嘅角色，如果團隊細過 20 人就有 PM，係一個 red flag。
文章核心講咗幾個重點：AI 令寫代碼嘅門檻幾乎跌到零，職業標籤正在失去意義，而團隊最緊要嘅係知道「應該做啲乜」而唔係「識做啲乜」。Codex 團隊唔睇簡歷學歷，只睇你做過啲乜，仲用開放式合作吸納 power user。佢哋嘅開發週期係最多 8 周嘅短期衝刺加長期方向感，中間嘅路線圖根本冇用。Alex 話技術迭代太快，中間嗰段根本規劃唔到。
總結嚟講，呢篇文章話俾我哋知：當 AI 將執行門檻降低，每個人都可以更專注做自己最擅長嘅事。PM 如果唔係真係醉心用戶研究，不如轉做工程師；設計師如果識得用 AI，都可以寫 code。而家嘅競爭力唔再係識唔識寫 code，而係知道點樣用 tools 解決問題。
- PM 唔係領導崗，而係 fill in the gaps 嘅角色，喺團隊細過 20 人時唔應該存在
- Codex 團隊唔寫 PRD、冇中期路線圖，只用最多 8 周嘅短期目標加長期方向感
- AI 令設計師同 PM 都可以自己寫 code 提 PR，職業標籤變得模糊
- 招人唔睇簡歷學歷，只睇你做過啲乜作品，例如 open source 貢獻
- 啟示：與其追求 title，不如專注做自己真正擅長同想做嘅嘢，AI 幫你壓縮技能棧
播客影片：OpenAI Codex PM 同 DevX 負責人對話
Peter Yang 嘅播客，訪問 Alex 同 Romain，深入討論 Codex 團隊嘅運作同 PM 角色。
PM 唔係領導，係補位
Alex 話：PM 唔係一個好嘅領導崗位，而係一個 fill in the gaps 嘅崗位。
佢將自己嘅工作分成兩種模式：執行模式同協調模式。執行模式係發佈前嘅衝刺期，佢會用 Codex 幫手總結用戶反饋、創建 ticket，甚至自己寫 code 提 PR。協調模式係戰略轉型期，佢會停止寫 code，專注評估產品狀態同各方溝通。
- Alex 喺執行模式會做啦啦隊長同批評者，留意 Twitter 活動頻率可判斷狀態
- 團隊得 8 人時 Alex 係唯一 PM，擴到近 100 人先請多兩個 PM，因為內部非技術團隊開始用 Codex
冇 PRD 冇路線圖，得 8 周衝刺同 long-term 方向
Codex 團隊幾乎唔寫產品需求文檔，最長嘅 spec 就係 10 條 bullet points
Alex 話只有三種情況先會寫：問題太複雜一個人頂唔順、需要多人協調、或者有個好棘手嘅決策。寫出嚟嘅都只係短篇對齊文檔，唔係傳統 PRD。
佢哋冇中期路線圖，因為技術迭代太快，中間嗰段根本規劃唔到
OpenAI 研究員 Andre 嘅建議：要做近期規劃（最多 8 周）或者諗長遠方向，但永遠唔好做中期計劃。近期係一個具體能令團隊興奮嘅目標，長期係方向感，例如「一年後模型會聰明好多」。
- 1 短期：最多 8 周嘅集中衝刺目標
- 2 長期：一年後嘅方向感，例如模型能力提升
- 3 中間：冇路線圖，因為外界變化太快
AI 壓縮技能棧，職業標籤開始模糊
設計師寫嘅 code 比半年前工程師寫嘅仲多，因為 AI 生成咗絕大部分代碼
Codex 嘅 Figma Skill 令設計師可以直接從 Figma 拉組件，AI 自動轉成可運行 code，然後自己提 PR。Alex 話呢個現象推論到更大結論：職業標籤正在失去意義。
- Alex 話：如果創業公司工程師唔夠 20 人就有 PM，係一個 red flag
- PM 唯一有存在價值嘅情況係對用戶研究真係有興趣，但如果工程師都鍾意同用戶傾，都可以代替
Peter Yang 話：寧願留喺離用戶近、能動手做嘢嘅位置，好過升 VP 日日開評審會
唔睇簡歷唔睇學歷，只睇你做過啲乜
Alex 話：我都唔知團隊入面嘅人上邊間大學，我淨係想睇你做過啲乜
如果有人 send 私信想加入，如果有連結佢一定會 click 開；如果只係一段話話自己好有興趣、之前做過乜，佢話讀嘅機會低好多。
一個真實例子：Thomas 係開源社區活躍貢獻者，自己做咗一個開源 Codex monitor 工具，Romain 直接請佢入 DevX 團隊。
未來嘅工作方式：agentic delegation 同速度為王
AI 編程緊由「寫代碼」變成「調度代碼」，即係 agentic delegation
團隊做咗獨立 App 嚟管理多個 AI agent，因為 IDE 綁死喺一個工作區，而 agent 可以連續工作幾小時。
GPT-5.2 之後模型跨過閾值：能可靠完成更長任務，由打字員變成實習生
Romain 現場 demo 話 Codex Spark 每秒 1200 tokens，改啲裝飾幾秒就見到效果。反饋速度由「諗到改動」到「睇到結果」淨係幾秒，所以仲邊有人寫需求文檔。
Alex 最後話：我哋非常相信 AGI，所以一直諗我哋滑向緊嘅未來係點。你可以唔信 AGI，但 AI 改變做產品同寫 code 嘅方式已經發生緊，速度比大多數人預期快。
OpenAI Codex 團隊入面有個現象：設計師寫嘅代碼，比半年前工程師寫嘅仲要多。
呢個唔係笑話。Codex 嘅產品負責人 Alex 講嘅原句係：我哋團隊嘅設計師而家寫嘅代碼，比六個月前工程師寫嘅仲要多。 佢補咗一句 我哋鍾意咁樣講笑，但笑話背後係事實。因為 AI 生成咗絕大部分代碼，設計師可以直接喺 Figma 拉組件，畀 Codex 自動實現，然後提 PR。
產品經理都一樣。Alex 自己就係嗰個提 PR 嘅 PM。佢覺得一個小改動，與其揾工程師排期，不如自己花十分鐘搞掂。
呢個團隊由舊年 5 月嘅 8 個人，長到將近 100 人，中間大部分時間只得 Alex 一個產品經理。佢哋唔寫產品需求文檔，唔做中期路線圖，設計師同 PM 都喺度寫代碼。聽落好瘋狂，但 Codex 係 OpenAI 增長最快嘅產品之一。
最近 Peter Yang 嘅播客請咗 Alex 同 Codex DevX 負責人 Romain，傾咗 43 分鐘。我將入面最有料嘅部分拎出嚟，傾下呢個團隊到底搞緊乜，同埋對我哋所有做產品、寫代碼嘅人意味住乜。
先講背景。Alex 係 Codex 嘅產品負責人，長期以來係成個團隊唯一嘅 PM。Romain 負責 DevX（開發者體驗），之前喺 Stripe 做過。
Codex 團隊由舊年 5 月大概 8 個人，到而家 50 到 100 人之間。直到最近先再請咗 2 個 PM。呢個意味住喺團隊快速膨脹嘅大部分時間裏便，Alex 一個人扛住產品方向。
點解得？Alex 自己嘅解釋好直接：因為我哋做嘅嘢，工程師自己就係用戶。
呢個同 Stripe 嘅邏輯一樣。Romain 提到 Stripe 曾經有 250 個員工，一個產品經理都冇。原因好簡單，做支付 API 嘅工程師，自己就係嗰個想要好用支付 API 嘅人。佢哋自然懂用戶需求。
Codex 團隊都係咁。工程師唔需要 PM 嚟話畀佢哋用戶要乜，因為佢哋自己就係最重度嘅用戶。功能方向係自下而上湧出嚟嘅，工程師見到需求、自己做出嚟、用咗覺得好就推。Alex 講：我覺得一個房入面做決定嘅人越少，決定就越純粹。
但 Alex 補充咗一個重要限定：PM 只係喺產品服務嘅用戶同團隊唔同嘅時候先真正被需要。而家 Codex 開始被 OpenAI 內部非技術團隊大量使用，呢個時候就需要有人去理解嗰啲工程師冇辦法直覺感受到嘅需求。呢個都係點解最近先擴充咗 PM 團隊。
10 條 bullet 就係最長嘅 spec
Codex 團隊幾乎唔寫產品需求文檔。Alex 講：我哋喺 Codex 團隊寫嘅 spec 極少，就係 10 條 bullet 呢種級別，然後就開工。
幾時會寫？得三種情況：問題太複雜一個人個腦裝唔曬、需要多人協調、或者有一個特別棘手嘅決策要做。就算寫咗，都係一個簡短嘅對齊文檔，唔係傳統意義上嘅 PRD。
產品決策係點做？去中心化。工程師直接同用戶傾，自己發現需求，自己做功能。對於更大嘅方向（例如使唔使做獨立 App），通常係先搞一個禮拜 hack week，幾個工程師各自做原型，睇邊個方向行得通。
最違反常識嘅一點：佢哋冇中期路線圖。
Alex 話佢收到一個建議，嚟自 OpenAI 嘅一個研究員 Andre：喺 OpenAI，你要唔做近期規劃，要唔諗長遠方向，但永遠唔好做中期計劃。 因為技術迭代太快，中間嗰段根本規劃唔到。
近期係乜？最多 8 個禮拜。一個具體嘅、可以令團隊興奮並集中衝刺嘅目標。
長期係乜？一種方向感。例如 一年後模型會聰明好多，向住嗰個方向滑就得。
中間呢？Alex 話：中間嗰段就係產品路線圖，我哋基本上冇呢樣嘢。
PM 唔係領導，係邊度缺就補邊度
Alex 對 PM 呢個角色有一個好唔 politically correct 嘅睇法：我唔覺得 PM 係一個好嘅領導崗位，我覺得佢係一個 fill in the gaps 嘅崗位。
佢將自己嘅工作分成兩種模式。
執行模式：喺發佈前嘅衝刺期。佢會大量用 Codex 嚟總結 Slack 入面嘅用戶反饋、創建 Linear ticket、理解代碼庫嘅變化，甚至自己寫代碼提 PR。同時做啦啦隊長，幫團隊打氣，又做批評者，挑產品嘅刺。佢話：如果你發現我最近 Twitter 特別活躍，即係話我喺執行模式。
協調模式：喺戰略轉型期。例如團隊要開始做雲基礎設施方向，佢就由寫代碼切換到思考、評估產品狀態、同各方溝通。
關於自己寫代碼，Alex 講咗一句好實在嘅話：對於一個小改動，與其同工程師溝通然後等佢喺一萬件事入面排優先級，不如直接發一個 PR，自己測試好。 但佢刻意避免擁有複雜系統。如果係需要長期維護嘅功能，一定會交畀專職工程師。佢話：PM 唔應該擁有複雜代碼，因為佢哋會搞衰。
團隊仲攞佢 PR 數量少嚟開玩笑。Alex 笑着話：團隊笑我舊年冇提幾個 PR，我話確實應該多啲，尤其考慮到其中好多仲係特別細嘅改動。
設計師點解會寫代碼
回到開頭嗰個現象：設計師寫嘅代碼比半年前工程師仲要多。
具體點做？Codex 入面有一個 Figma skill。設計師可以直接喺 Figma 文件度拉出細節、變數同 React 組件，Codex 會自動將設計轉成可運行嘅代碼。然後設計師自己提 PR。
重點係：AI 將寫代碼嘅門檻拉到幾乎為零。你唔需要精通 React 先至寫到 React 組件，知道自己想要咩效果就得，餘下嘅交畀 AI。
Alex 將呢個現象推到更大嘅結論：職業標籤正在失去意義。
佢畀 PM 嘅建議好刺激：
如果你做 PM 其實係因為一路想做工程師，但你管人叻過寫代碼，咁你而家應該去做工程管理。如果你對寫代碼更加有興趣，只係因為總要有人做 PM 先做咗 PM，咁你而家應該 Delete 自己，轉做工程師。做設計都一樣。
佢仲掟咗一個更加刺激嘅觀點：如果一個創業公司工程師唔夠 20 人就有 PM，我覺得呢個係 red flag。
只有當你對用戶研究真正有興趣嘅時候，PM 呢個角色先至有存在價值。但佢話，一個鍾意同用戶泡埋一齊嘅工程師同樣可以做呢件事。
諗下，過去十年好多人選擇做 PM，係因為佢睇落係通往管理層嘅捷徑，唔需要寫代碼亦唔需要做設計。但當 AI 令到每個人都可以做全棧工作嘅時候，純粹嘅協調者就多餘咗。
Peter Yang 喺播客入面都講咗類似嘅感受：當你升到 VP，你每日都喺度開評審會，根本冇時間做嘢。 佢寧願留喺離用戶近、可以動手做嘢嘅位置上。
18 個終端窗口嘅故事
講一個好有畫面感嘅故事。
Peter Steinberger，開源社區嘅大佬，2025 年做咗 40 幾個開源項目，係 Codex 最狂熱嘅用戶之一。舊年佢嘅桌面係咁：3 塊顯示器，18 個終端窗口同時跑住唔同嘅 AI agent。每個窗口係一個獨立任務，佢好似指揮交通咁喺窗口之間切換。
Alex 同 Peter 喺舊金山 Fort Mason 散步嘅時候，提咗一個想法：我哋不如做個 App，將管理多個 agent 呢件事做得更加絲滑？
Peter 嘅反應係：佢話佢永遠唔會用嗰種嘢。
幾個禮拜後 App 做出嚟，Peter 試咗一下，出咗條推：呢個 App 其實都幾好。地獄結冰咗，我而家鍾意佢喇。
但呢個故事背後有一個更大嘅變化：AI 編程正在由 寫代碼 變成 調度代碼。
Codex 團隊將呢個轉變叫做 agentic delegation（代理委託）。簡單講就係你同時管理多個 AI agent，每個獨立完成唔同嘅任務。呢啲 agent 可以連續工作幾小時甚至幾日，你嘅角色更加似一個項目經理，分配任務、檢查結果。
呢個都係佢哋點解要由 CLI 同 IDE 插件轉向獨立 App 嘅原因。IDE 嘅問題在於：佢將你綁死喺一個工作區。你打開一個 VS Code 窗口就係一個代碼庫，想並行處理唔同項目嘅任務，你要開幾個窗口，體驗好割裂。
獨立 App 解放咗呢個限制。你可以喺一個界面入面同時跑多個代碼庫嘅任務，好似管理聊天對話咁管理 agent。側邊欄列住所有正在跑嘅任務，㩒一下就可以切換。
轉折點出現喺舊年 12 月。GPT-5.2 發佈嘅時候，模型終於跨過咗一個門檻：可以可靠地一次性完成更長嘅任務。喺呢個之前，AI 更加似一個打字員，你講一句佢做一句。GPT-5.2 之後，佢更加似一個實習生，你畀佢一個完整嘅需求佢可以獨立完成。
呢個變化直接改變咗工具嘅形態。當你嘅 AI 由 問一句答一句 變成 畀個任務跑半日，你就唔需要一個令你睇住屏幕嘅編輯器。你需要嘅係一個任務管理面板。
1200 tokens 每秒係咩體驗
Romain 喺播客入面做咗一個現場 demo。
佢先叫 GPT-5.4 幫一個 iOS App 加一個新頁面，關於 NASA Artemis 登月任務嘅內容。然後搞咗一個對比測試：GPT-5.4 同 Codex Spark（一個專門優化速度嘅模型）並排跑。
即使畀 GPT-5.4 先跑一段時間，Codex Spark 都可以輕鬆超過佢。平均速度係 每秒 1200 tokens。
然後 Romain 切到一個 2D 小遊戲，將 Codex 嘅聊天窗口直接疊喺遊戲畫面上。Peter Yang 話：加啲裝飾啦，樹啊屋仔咁。 Romain 打咗一句 prompt，幾秒鐘後，新嘅樹同裝飾就出現咗喺可以玩嘅遊戲畫面入面。
衝擊力在於反饋速度。由 諗到一個改動 到 見到佢行起嚟 只係隔幾秒鐘，做產品嘅方式就徹底唔同咗。試一下仲快過描述，邊個仲寫需求文檔。
唔睇簡歷唔睇學歷，只睇你做咗啲乜
講到請人，Alex 嘅態度好明確。
當有人 send 私訊畀佢想加入團隊嘅時候：如果訊息入面有連結，我一定會㩒入去睇。 如果只係一份簡歷，寫住對呢個崗位有幾有興趣、之前做過啲乜，佢話 我讀嗰啲嘢嘅概率比讀佢嘅想法同作品低好多。
關於學歷，佢講咗一句好直接嘅話：我都唔知團隊入面嘅人上邊間大學。 然後總結：我好慶幸我哋活在一個呢啲無聊嘅 credentials 唔再重要嘅世界。畀我睇你做過啲乜就得。
呢套邏輯放喺成個 AI 時代都成立：當工具將執行門檻拉低到接近零，唯一仲有區分度嘅就係你做過啲乜、做得點樣。學歷同簡歷本質上係喺你冇辦法展示能力嘅時候用嚟代替能力嘅信號。而家，你可以直接展示能力喇。
一個真實嘅例子：Thomas，一個開源社區嘅活躍貢獻者，自己做咗一個 開源 Codex monitor 工具。Romain 直接請佢入咗 DevX 團隊。佢做咗一個有用嘅嘢，鍾意分享佢點樣做，咁就夠曬。
呢種請人邏輯同社區驅動嘅產品開發係一脈相承嘅。Codex 嘅核心 harness 係開源嘅，所以總有一批 power user 喺代碼度挖來挖去，甚至揾到仲未發佈嘅實驗功能，用咗之後走去 Twitter 度投訴佢唔好用。
Alex 覺得呢種混亂好好：你最前沿嘅用戶，同你一齊活喺未來，並且將你拉向嗰個未來。
團隊嘅做法係：畀 power user 自由實驗，觀察佢哋點玩，然後將嗰啲高級玩法簡化，做成所有人都用到嘅產品功能。例如 sub-agents 呢個功能，而家已經喺代碼入面但產品層面未主動暴露。等社區驗證夠咗，再正式推出。
每個人都可以成為更純粹嘅自己
講到 AI 會唔會搶走大家嘅飯碗，Alex 同 Romain 嘅態度出奇一致：佢哋唔擔心。
佢哋嘅講法係：AI 喺 collapse the talent stack（壓縮人才棧）。以前做一個產品，要配齊工程師、設計師、產品經理。而家一個人藉助 AI 就可以由頭做到尾。
但呢個唔代表所有人失業。Alex 話呢個代表人可以回歸自己真正想做嘅嘢。想寫代碼嘅 PM 可以去寫代碼，想做設計嘅工程師都可以去做設計。工具唔再係樽頸。
佢用咗一個好好嘅講法：呢個有 AI 嘅世界，令我哋每個人都可以成為更加有態度嘅自己。
但佢哋都唔係盲目樂觀。Alex 明確講咗一個風險：代碼質量。
網上有人驕傲咁話自己嘅 App 全部都係 vibe coded（靠感覺畀 AI 寫），冇經過任何結構化嘅設計。Codex 團隊堅決唔會咁做。雖然 AI 生成咗佢哋絕大部分代碼，但核心架構係工程師精心設計嘅，唔係 AI 隨便寫嘅。
每個複雜功能都有一個 robust stable owner，專職工程師嚟負責。PM 同設計師可以提 PR 做小改動，但唔可以 own 複雜系統。Alex 講得好直接：PM 唔應該擁有複雜代碼，因為佢哋會分心，然後搞衰。
呢啲事同你有咩關係
講咗咁多 OpenAI 內部嘅故事，你可能想講：嗰啲係 OpenAI，佢哋有最好嘅模型，最好嘅工程師，我哋公司唔同。
冇錯，但有幾個嘢係通用嘅。
半年前需要工程師寫嘅代碼，而家設計師都搞得掂。工具變強咗，你嘅競爭力唔再係 會做，而是 知道應該做啲乜。
職業身份會越來越模糊。當一個人可以同時做產品設計同代碼實現，PM、設計師、工程師嘅邊界就冇咁清楚。與其糾結自己嘅 title，不如諗清楚自己最擅長、最想做嘅係乜。
OpenAI 請人唔睇簡歷睇作品。呢個邏輯會擴散到更多公司。你花喺做 project 上面嘅時間，回報率遠遠高過花喺優化簡歷措辭上面嘅時間。
仲有一個關於工作方式嘅啟發：冇中期路線圖，只有 8 個禮拜衝刺同長期方向感。當外部環境變化太快嘅時候，花三個月做一份詳細規劃不如花精力喺短期可以驗證嘅事情上。
Alex 喺播客最後講咗一句：我哋非常相信 AGI，所以我哋一路喺度諗，我哋正在滑向嘅嗰個未來係咩樣。
你可以唔信 AGI，但 AI 改變做產品同寫代碼嘅方式，呢件事已經發生緊。速度比大多數人預期嘅快。
來源視頻：https://www.youtube.com/watch?v=9qXc-THAvc0
OpenAI Codex 團隊裏有個現象：設計師寫的代碼，比半年前工程師寫的還多。
這不是段子。Codex 的產品負責人 Alex 說的原話是：我們團隊的設計師現在寫的代碼，比六個月前工程師寫的還多。 他補了一句 我們喜歡這麼開玩笑，但笑話背後是事實。因為 AI 生成了絕大部分代碼，設計師可以直接從 Figma 拉組件，讓 Codex 自動實現，然後提 PR。
產品經理也一樣。Alex 自己就是那個提 PR 的 PM。他覺得一個小改動，與其找工程師排期，不如自己花十分鐘搞定。
這個團隊從去年 5 月的 8 個人，長到了將近 100 人，中間大部分時間只有 Alex 一個產品經理。他們不寫產品需求文檔，不做中期路線圖，設計師和 PM 都在寫代碼。聽起來很瘋狂，但 Codex 是 OpenAI 增長最快的產品之一。
最近 Peter Yang 的播客請了 Alex 和 Codex DevX 負責人 Romain，聊了 43 分鐘。我把裏面最有料的部分拎出來，聊聊這個團隊到底在搞什麼，以及對我們所有做產品、寫代碼的人意味着什麼。
先說背景。Alex 是 Codex 的產品負責人，長期以來是整個團隊唯一的 PM。Romain 負責 DevX（開發者體驗），之前在 Stripe 幹過。
Codex 團隊從去年 5 月大概 8 個人，到現在 50 到 100 人之間。直到最近才又招了 2 個 PM。這意味着在團隊快速膨脹的大部分時間裏，Alex 一個人扛着產品方向。
為什麼能行？Alex 自己的解釋很直接：因為我們做的東西，工程師自己就是用戶。
這跟 Stripe 的邏輯一樣。Romain 提到 Stripe 曾經有 250 個員工，一個產品經理都沒有。原因很簡單，做支付 API 的工程師，自己就是那個想要好用支付 API 的人。他們天然懂用戶需求。
Codex 團隊也是這樣。工程師不需要 PM 來告訴他們用戶要什麼，因為他們自己就是最重度的用戶。功能方向是自下而上冒出來的，工程師看到需求、自己做出來、用了覺得好就推。Alex 說：我覺得一個房間裏做決定的人越少，決定就越純粹。
但 Alex 補充了一個重要限定：PM 只在產品服務的用戶跟團隊不同的時候才真正被需要。現在 Codex 開始被 OpenAI 內部非技術團隊大量使用了，這時候就需要有人去理解那些工程師沒法直覺感受到的需求。這也是為什麼最近才擴了 PM 團隊。
10 條 bullet 就是最長的 spec
Codex 團隊幾乎不寫產品需求文檔。Alex 說：我們在 Codex 團隊寫的 spec 極少，就是 10 條 bullet 這種級別，然後就幹了。
什麼時候會寫？只有三種情況：問題太複雜一個人腦子裝不下、需要多人協調、或者有一個特別棘手的決策要做。就算寫了，也就是個簡短的對齊文檔，不是傳統意義上的 PRD。
產品決策是怎麼做的？去中心化。工程師直接跟用戶聊，自己發現需求，自己做功能。對於更大的方向（比如要不要做獨立 App），通常是先搞一週 hack week，好幾個工程師各自做原型，看哪個方向跑得通。
最反常識的一點：他們沒有中期路線圖。
Alex 說他收到一個建議，來自 OpenAI 的一個研究員 Andre：在 OpenAI，你要麼做近期規劃，要麼想長遠方向，但永遠不要做中期計劃。 因為技術迭代太快了，中間那段根本規劃不了。
近期是什麼？最多 8 周。一個具體的、能讓團隊興奮並集中衝刺的目標。
長期是什麼？一種方向感。比如 一年後模型會聰明得多，朝那個方向滑就行。
中間呢？Alex 說：中間那段就是產品路線圖，我們基本上沒有這個東西。
PM 不是領導，是哪裏缺補哪裏
Alex 對 PM 這個角色有一個很不 politically correct 的看法：我不覺得 PM 是一個好的領導崗位，我覺得它是一個 fill in the gaps 的崗位。
他把自己的工作分成兩種模式。
執行模式：在發佈前的衝刺期。他會大量用 Codex 來總結 Slack 裏的用戶反饋、創建 Linear ticket、理解代碼庫的變化，甚至自己寫代碼提 PR。同時做啦啦隊長，給團隊打氣，也做批評者，挑產品的刺。他說：如果你發現我最近 Twitter 特別活躍，說明我在執行模式。
協調模式：在戰略轉型期。比如團隊要開始做雲基礎設施方向了，他就從寫代碼切換到思考、評估產品狀態、跟各方溝通。
關於自己寫代碼，Alex 說了一句很實在的話：對於一個小改動，與其跟工程師溝通然後等他在一萬件事情裏排優先級，不如直接發一個 PR，自己測好了。 但他刻意避免擁有複雜系統。如果是需要長期維護的功能，一定會交給專職工程師。他說：PM 不應該擁有複雜代碼，因為他們會搞砸的。
團隊還拿他 PR 數量少來開玩笑。Alex 笑着說：團隊調侃我去年沒提幾個 PR，我說確實該多一點，尤其考慮到其中很多還是特別小的改動。
設計師怎麼就寫代碼了
回到開頭那個現象：設計師寫的代碼比半年前工程師還多。
具體怎麼做的？Codex 裏有一個 Figma skill。設計師可以直接從 Figma 文件里拉出細節、變量和 React 組件，Codex 會自動把設計轉成可運行的代碼。然後設計師自己提 PR。
重點是：AI 把寫代碼的門檻拉到了幾乎為零。你不需要精通 React 才能寫 React 組件，知道自己想要什麼效果就行，剩下的交給 AI。
Alex 把這個現象推到了更大的結論：職業標籤正在失去意義。
他給 PM 的建議很刺激：
如果你做 PM 其實是因為一直想做工程師，但你管人比寫代碼強，那你現在應該去做工程管理。如果你對寫代碼更感興趣，只是因為總得有人做 PM 才做了 PM，那你現在應該把自己刪掉，轉成工程師。做設計也一樣。
他還扔了一個更刺激的觀點：如果一個創業公司工程師不到 20 人就有 PM 了，我覺得這是個 red flag。
只有當你對用戶研究真正感興趣的時候，PM 這個角色才有存在價值。但他說，一個喜歡跟用戶泡在一起的工程師同樣能做這件事。
想想看，過去十年很多人選擇做 PM，是因為它看起來是通往管理層的捷徑，不需要寫代碼也不需要做設計。但當 AI 讓每個人都能做全棧工作的時候，純粹的協調者就多餘了。
Peter Yang 在播客裏也說了類似的感受：當你升到 VP，你每天都在開評審會，根本沒時間做東西了。 他寧願留在離用戶近、能動手做東西的位置上。
18 個終端窗口的故事
講一個很有畫面感的故事。
Peter Steinberger，開源社區的大佬，2025 年做了 40 多個開源項目，是 Codex 最狂熱的用戶之一。去年他的桌面是這樣的：3 塊顯示器，18 個終端窗口同時跑着不同的 AI agent。每個窗口是一個獨立任務，他像指揮交通一樣在窗口之間切換。
Alex 和 Peter 在舊金山 Fort Mason 散步的時候，提了一個想法：我們要不做個 App，把管理多個 agent 這件事做得更絲滑？
Peter 的反應是：他說他永遠不會用那種東西。
幾周後 App 做出來了，Peter 試了一下，發了條推：這個 App 其實還挺好的。地獄結冰了，我現在喜歡它了。
但這個故事背後有一個更大的變化：AI 編程正在從 寫代碼 變成 調度代碼。
Codex 團隊把這個轉變叫做 agentic delegation（代理委託）。簡單說就是你同時管理多個 AI agent，每個在獨立完成不同的任務。這些 agent 可以連續工作幾小時甚至幾天，你的角色更像是一個項目經理，分配任務、檢查結果。
這也是他們為什麼要從 CLI 和 IDE 插件轉向獨立 App 的原因。IDE 的問題在於：它把你綁死在一個工作區。你打開一個 VS Code 窗口就是一個代碼庫，想並行處理不同項目的任務，你得開好幾個窗口，體驗很割裂。
獨立 App 解放了這個限制。你可以在一個界面裏同時跑多個代碼庫的任務，像管理聊天對話一樣管理 agent。側邊欄列着所有正在跑的任務，點一下就能切換。
轉折點出現在去年 12 月。GPT-5.2 發佈的時候，模型終於跨過了一個閾值：能可靠地一次性完成更長的任務。在這之前，AI 更像是一個打字員，你說一句它做一句。GPT-5.2 之後，它更像一個實習生，你給它一個完整的需求它能獨立跑完。
這個變化直接改變了工具的形態。當你的 AI 從 問一句答一句 變成 給個任務跑半天，你就不需要一個讓你盯着屏幕看的編輯器了。你需要的是一個任務管理面板。
1200 tokens 每秒是什麼體驗
Romain 在播客裏做了一個現場 demo。
他先讓 GPT-5.4 給一個 iOS App 加一個新頁面，關於 NASA Artemis 登月任務的內容。然後搞了一個對比測試：GPT-5.4 和 Codex Spark（一個專門優化速度的模型）並排跑。
即使給 GPT-5.4 先跑一段時間，Codex Spark 也能輕鬆超過它。平均速度是 每秒 1200 tokens。
然後 Romain 切到一個 2D 小遊戲，把 Codex 的聊天窗口直接疊在遊戲畫面上。Peter Yang 說：加點裝飾吧，樹啊房子什麼的。 Romain 打了一句 prompt，幾秒鐘後，新的樹和裝飾就出現在了可以玩的遊戲畫面裏。
衝擊力在於反饋速度。從 想到一個改動 到 看到它跑起來 只隔幾秒鐘，做產品的方式就徹底不同了。試一下比描述還快，誰還寫需求文檔。
不看簡歷不看學歷，只看你做了什麼
聊到招人，Alex 的態度很明確。
當有人給他發私信想加入團隊的時候：如果消息裏有連結，我一定會點開看。 如果只是一份簡歷，寫着對這個崗位有多感興趣、之前做過什麼，他說 我讀那些東西的概率比讀他的想法和作品低很多。
關於學歷，他說了一句很直白的話：我都不知道團隊裏的人上的哪個大學。 然後總結：我很慶幸我們活在一個這些無聊的 credentials 不再重要的世界。給我看你做過什麼就行。
這套邏輯放到整個 AI 時代都成立：當工具把執行門檻拉低到接近零，唯一還有區分度的就是你做過什麼、做得怎麼樣。學歷和簡歷本質上是在你沒法展示能力的時候用來代替能力的信號。現在，你可以直接展示能力了。
一個真實的例子：Thomas，一個開源社區的活躍貢獻者，自己做了一個 開源 Codex monitor 工具。Romain 直接把他招進了 DevX 團隊。他做了一個有用的東西，喜歡分享他怎麼做的，這就夠了。
這種招人邏輯跟社區驅動的產品開發是一脈相承的。Codex 的核心 harness 是開源的，所以總有一批 power user 在代碼裏挖來挖去，甚至找到還沒發佈的實驗功能，用了之後跑到 Twitter 上抱怨它不好用。
Alex 覺得這種混亂很好：你最前沿的用戶，跟你一起活在未來，並且把你拉向那個未來。
團隊的做法是：讓 power user 自由實驗，觀察他們怎麼玩，然後把那些高級玩法簡化，做成所有人都能用的產品功能。比如 sub-agents 這個功能，現在已經在代碼裏了但產品層面還沒主動暴露。等社區驗證夠了，再正式推出。
每個人都能成為更純粹的自己
聊到 AI 會不會搶走大家的飯碗，Alex 和 Romain 的態度出奇一致：他們不擔心。
他們的說法是：AI 在 collapse the talent stack（壓縮人才棧）。過去做一個產品，得配齊工程師、設計師、產品經理。現在一個人藉助 AI 就能從頭做到尾。
但這不意味着所有人失業。Alex 說這意味着人可以迴歸自己真正想做的事情。想寫代碼的 PM 可以去寫代碼了，想做設計的工程師也可以去做設計了。工具不再是瓶頸。
他用了一個很好的說法：這個有 AI 的世界，讓我們每個人都能成為更有態度的自己。
但他們也不是盲目樂觀。Alex 明確說了一個風險：代碼質量。
網上有人驕傲地說自己的 App 全是 vibe coded（靠感覺讓 AI 寫的），沒有經過任何結構化的設計。Codex 團隊堅決不這麼幹。雖然 AI 生成了他們絕大部分代碼，但核心架構是工程師精心設計的，不是 AI 隨便寫的。
每個複雜功能都有一個 robust stable owner，專職工程師來負責。PM 和設計師可以提 PR 做小改動，但不能 own 複雜系統。Alex 說得很直接：PM 不應該擁有複雜代碼，因為他們會分心，然後搞砸。
這些事情跟你有什麼關係
講了這麼多 OpenAI 內部的故事，你可能想說：那是 OpenAI，他們有最好的模型，最好的工程師，我們公司不一樣。
沒錯，但有幾個事情是通用的。
半年前需要工程師寫的代碼，現在設計師也能搞定。工具變強了，你的競爭力不再是 會做，而是 知道該做什麼。
職業身份會越來越模糊。當一個人能同時做產品設計和代碼實現，PM、設計師、工程師的邊界就沒那麼清楚了。與其糾結自己的 title，不如想清楚自己最擅長、最想做的是什麼。
OpenAI 招人不看簡歷看作品。這個邏輯會擴散到更多公司。你花在做項目上的時間，回報率遠高於花在優化簡歷措辭上的時間。
還有一個關於工作方式的啓發：沒有中期路線圖，只有 8 周衝刺和長期方向感。當外部環境變化太快的時候，花三個月做一份詳細規劃不如花力氣在短期能驗證的事情上。
Alex 在播客最後說了一句：我們非常相信 AGI，所以我們一直在想，我們正在滑向的那個未來是什麼樣子。
你可以不信 AGI，但 AI 改變做產品和寫代碼的方式，這件事已經在發生了。速度比大多數人預期的快。
來源視頻：https://www.youtube.com/watch?v=9qXc-THAvc0