OpenAI Codex 產品經理：AI 不是讓你做更快，是讓你做以前不敢做的事

如果你在 OpenAI 的辦公室里從 A 點走到 B 點，不可能聽不到"Codex"這個詞被提及。這不是夸張——Rohan Varma 說，如果 Codex 宕機，OpenAI 公司運營會陷入相當困難的境地。而他就是讓這個工具變得不可或缺的人之一。

Rohan Varma 的路徑有點意思。他是 Cursor 的聯合創始人，一手打造了那個讓全球開發者上癮的 AI 編程工具。2026 年 2 月，他被 OpenAI 挖過去，身份從"創始人"變成了"產品經理"。但他說這個轉換毫無違和感——因為 OpenAI Codex 內部的運作方式跟 Cursor 幾乎是一樣的：團隊極小、速度極快、每個人都在用同一款產品來構建這款產品。

Peter Yang 的 Behind the Craft 播客邀請 Rohan 做了一期實操密集的訪談。Rohan 在訪談中做了多次現場演示——從 Slack 自動觸發自動化、到用 Image Gen 快速生成設計變體、到把任何對話線程變成可復用技能。這不是"AI 時代的 PM 應該怎么做"的理論課，而是一個真實的 AI-native 團隊的產品經理，打開他的日常工作給你看。

本文編譯自 Peter Yang 的 Behind the Craft 播客第 138 期《OpenAI PM Reveals How He Uses Codex to Do Product Work | Rohan Varma》，2026 年 7 月 5 日發布于 YouTube。以下是完整編譯。

1

兩個杠桿：PM 的工作方式變了，角色也變了

Rohan 把 Codex 對 PM 工作的影響拆成兩個層面。第一個層面很好理解——具體怎么做事的"how"變了。信息合成、上下文獲取、文檔撰寫、跨工具協調——這些過去占據 PM 大量時間的事情，現在可以大規模委托給 Codex。

"我們每天從企業客戶、Twitter 反饋、各種渠道收到成百上千個數據點和問題，"他舉例說，"我只用 20 分鐘，就能完全上手一個全新項目。Codex 會自動爬進我們所有的工具——Notion、Linear、Gmail、Google Drive——然后把我來之前所有發生過的事情匯總給我。"

但第二個層面更關鍵：角色本身被重新定義了。當一個團隊里的工程師、設計師、產品經理全都在用 Codex，協作的拓撲結構也跟著改變。OpenAI Codex 團隊的典型配置是——一個產品線只有一兩個工程師，產品經理的角色從"中間人"變成了"兩端校準者"：前端做戰略方向的護欄設定，后端做推向市場的臨門一腳，中間的執行層面完全可以放手讓工程師和 Codex 自行推進。

"以前產品開發是花大量前置時間做規劃，確保工程師只做最重要的事，"他說，"現在完全反過來了——先做一切，再決定哪些值得真正發布。"

1

沒有 PRD，只有"做了再說"

這種"倒置"在 OpenAI 已經滲透到日常。Rohan 舉了一個很具體的例子：Codex 不久前來了一次產品更新，在應用里加入了一個內置瀏覽器。這個功能怎么來的？團隊里一位工程師 Adam 某天早上來上班，對 Rohan 說了一句"你看這個"，然后把東西亮了出來——因為在前端迭代時來回切窗口太煩，他自己用 Codex 做了一個。

"他沒有寫需求文檔，沒有開 alignment 會議，就是覺得煩，然后做了一個。我看了以后說，'這太棒了，我們想辦法發出去。'"一個可以合入產品主干的功能，出生證上連一行 PRD 都沒有。

Rohan 還提到了一個正在硅谷流傳的 meme——"計劃是寫給 agent 看的，不是寫給人類看的"。如果你用 Codex 的 goal 功能，它就會自己迭代、自己完成目標、自己做微調。人類看計劃的時間，不如拿來看實際跑出來的東西。

這背后是一個更深的組織邏輯：人類之間的協作成了瓶頸。傳統模式下，一個項目堆五六個工程師，協調成本開始吃掉速度。而當每個人——尤其是工程師——都用 Codex 大幅提升了單兵作戰能力，產品決策就變成了大量微型決策的集合。"比較理想的狀態是，工程師能自己做出那些微決策，不需要等我。"

所以 Rohan 的日常工作重心也偏移了。他花更多時間跟企業客戶和團隊在一起，花更少時間在"信息合成"和"文檔維護"上。"Codex 處理手動部分，PM 就花更多時間跟用戶在一起——這本來才是 PM 應該做的事。"

1

做一次，然后讓它自己去自動化自己

整場訪談最有沖擊力的部分，是 Rohan 當場演示的幾個工作流。核心模式可以概括為一句話：先手動做一次，然后讓 Codex 自己去自動化這個流程。

他展示了自己是怎么處理用戶反饋的。OpenAI 用 Slack 非常重，大量反饋散落在各個頻道里。Rohan 的做法是——先在 Codex 里開一個線程，手動把"從 Slack 收集反饋 → 歸類 → 錄入 Linear 看板"這個流程走通。走通之后，他只說了一句話："現在設定自動化，每周做一次。"

Codex 不僅能設置自動化，還能自己修改自己設定的自動化。"我可能會加一句——做完以后給我發一條 Slack 消息。Codex 就會去更新那個自動化的配置。"Rohan 說自己大概有五六套這樣的自動化在跑，覆蓋了信息收集、反饋歸類、狀態更新等各種循環性工作。

但更讓人頭皮發麻的是"一次性觸發式自動化"。他演示了一個場景——他給同事 Alex 發了一條消息，然后在 Codex 里設定："當 Alex 回復我最后那條私信時，草擬一封回復客戶的郵件。"Codex 會在后臺持續監控那條 Slack 私信，一旦觸發條件滿足，自動草擬郵件，然后刪除這個自動化本身。

"Codex 知道怎么使用自己，"Rohan 說，"你不需要把需求拆分得很細。你說'當 Alex 回了消息，發封郵件'，它自己會用底層能力——每幾分鐘檢查一次 Slack、構建合適的觸發條件、完成后自我清理。你不需要想它怎么做到的。"

Peter Yang 半開玩笑地說："所以你可以設一個自動化，讓 Codex 假裝成 Rohan 在 Slack 長帖里回復？"Rohan 笑了："對，我們團隊里有人在用 @Codex 標簽觸發自動化來冒充自己回復。"

1

Image Gen 不是讓你把頭發染藍的

"Image Gen 給我帶來了一種近似 AGI 時刻的感覺。"Rohan 說這句話的時候沒有在開玩笑。

他的論點是：人們普遍把圖像生成理解為"把我頭發染成藍色"或者"給我生成一張貓的圖片"這類消費級應用。但在產品工作中，它的真正威力是快速原型探索。

他現場演示了——截了一張 Codex 的"選擇項目"界面的截圖，然后告訴 Image Gen："基于這個 UI，生成四五個不同的設計變體方案。"幾秒鐘內，Codex 吐出五套截然不同的交互方案。不是文字描述，是視覺上可以直接討論的 mockup。

"這比寫五個 React 假頁面來探索方案快太多了，"他說，"我越來越覺得，產品創意的第一輪迭代不應該用代碼做，應該直接用 Image Gen 做。"

他通常會先用 Image Gen 跑一輪視覺探索，選出一兩個方向，然后下一個指令："把第一個方案做成真正的原型，放到 Codex Sites 上，這樣我可以分享給團隊。"

這套流程里還有一個被反復使用的魔法：技能創造器。在 Codex 里，你可以在任何對話線程結束后，調用 skill creator，告訴它"把剛才整個交互過程變成一個可復用的技能，以后我提類似需求時你知道我的偏好"。Rohan 用它來固化設計語言："你跟 Codex 交互了二十分鐘調出一個滿意的設計，然后你對它說'把這個線程變成技能，確保以后產出的設計保持一致'——然后它真的會記住你的審美偏好。"

Peter Yang 提到一個擔心——如果不加審查地讓 AI 反復更新技能，會不會把技能文件"slop 化"？Rohan 承認這是一個需要解決的問題。目前的做法很原始——"跑一下看看效果，覺得還行就繼續用"。但他透露團隊正在探討如何在不同版本迭代中自動評估技能產出的質量。

1

"一次性軟件"和自我更新的文檔

Rohan 提出了一個概念——disposable software。當用 Codex 創建一個軟件的邊際成本趨近于零，你就會開始做一些以前"不值得做"的東西。

"我經常會讓 Codex 直接做一個一次性的小 app，"他說。一個常見的例子是，Slack 積壓了太多消息，他就讓 Codex "掃描我所有未讀的 Slack 消息，找出最重要的需要回復的，然后生成一個本地網頁，按優先級排列展示給我看"——整個過程可能不超過一分鐘，用完就扔。

如果某個一次性工具被反復用到，他會再加一個自動化——"每兩小時更新一次這個頁面"。于是這個臨時生成的小工具就變成了一個動態儀表盤，維護成本是零。

這個思路在團隊層面被放大成了更有趣的東西。OpenAI 團隊每個項目都有對應的 Slack 頻道。Rohan 開始為每個頻道建一個 Codex Site——一個自動從 Slack 對話中提取上下文、持續自我更新的項目全景頁面。

"以前大家都知道一個鐵律——任何文檔從你發出的那一刻就過時了，"他說，"但現在我們可以做出真正保持實時更新的文檔。來了一個新同事，打開那個 Site 就能看到項目當前的全部狀態。我自己也用它來快速 catch up。"

文檔不再是人寫的，是 AI 從真實工作流里"蒸餾"出來的。

1

線程編排器：讓 Codex 管理 Codex

整場訪談中，Peter Yang 反復追問 Rohan 一個邊界問題：你到底能同時跑多少個 Codex 線程？有沒有像 Peter Steinberger（OpenClaw 創始人）那樣讓 Codex 真正進入到"系統管理系統的系統"層面？

Rohan 承認自己還沒到那個級別。但他揭示了一個最近的重大功能更新：Codex 現在可以控制其他 Codex 線程。"你可以有一個高層的'編排器線程'，它可以喚起、管理、等待其他子線程的結果。"這是一種新的編程范式——不是人寫代碼協調多個 agent，而是 agent 之間的自組織。

他日常通常在跑五六個 Codex 線程，但他的心態是"委托制"。"我不會坐在那里等 Codex 出結果。我在開會前丟給它一個任務——比如為明天跟某團隊的會議準備一版 slide deck——然后我就去開會了。開完會回來，打開 Codex，看到結果已經在那里了。"

他拿 Codex 的"PR 看護"功能做了一個更形象的類比：以前一個 pull request 從提交到合并，你需要盯十次——CI 掛了改一下、同事評論了回一下、又掛了再修一下。現在你只需要說"看護好這個 PR，CI 過了、人類評論處理完了、一切就緒之后在 Slack 上 ping 我"。然后你只在最后一步介入——"好了，可以合并了。"

"如果一個人能管一個小團隊，你不會要求這個人的每個動作你都要實時跟蹤，"Rohan 說，"Codex 也一樣——最好的委托就是，它做完了回到你面前，你在中間不需要想它。"

1

無關 PM，關乎"杠桿感"

Peter Yang 在結尾問了一個送分題：PM 這個職業是不是會變得更好玩？

Rohan 的答案比預期更普適。"不只是 PM，是每一個角色。AI 帶來的不是'把同一件事做快一點'，而是用同樣的時間做更多完全不同的事。"他在 OpenAI 和 Cursor 兩家公司都看到了同一個現象——不是"工作效率提升了 50%"，而是"我們做了以前根本不可能去碰的事情"。

他用了一個詞來描述自己的感受——"不受約束"。Codex 連接了他所有的工具：Slack、Linear、Notion、Gmail、Drive、Figma plugin、內部自定義插件。在這個信息密度和工具密度下，"我想不出上一次說'這不可能'是什么時候了。現在的問題是——不是能不能做，是做哪個。"

他給的一個最具體的建議也很簡單：每次遇到問題，先問自己——Codex 能不能做？ 第一次試可能不行，那就問第二個問題："Codex 缺了什么信息是我有而它沒有的？"然后想辦法把那個信息給它。"這個過程一旦形成閉環，你就在持續不斷地把更多事情推給 Codex，同時也讓 Codex 在持續不斷變得更懂你的上下文。"

Peter Yang 在結尾說了句大實話："模型的能力早就超越了大多數人的野心。"

Rohan 接得很快："對。你應該把目標定得比合理的上限再荒謬 10 倍。它大概能完成 90%。然后你重新設定——比剛才那個又荒謬 10 倍。"

點個“愛心”，再走 吧