Codex產品負責人：小型團隊不再需要PM，招了就危險了

AI應用風向標（公眾號：ZhidxcomAI）
編譯｜畢偉豪
編輯｜漠影

智東西4月17日報道，近日，OpenAI Codex產品負責人Alexander Embiricos與開發者體驗負責人Romain Huet做客Peter Yang的播客，圍繞Codex團隊的產品開發實踐、產品規劃、AI對職業的重塑，以及團隊協作與招聘理念等核心問題展開了深度對話，還提到了前段時間加入OpenAI的龍蝦之父Peter Steinberger。

播客伊始，Romain Huet就用Codex直接進行開發，重點展示了Codex強大的編程能力，在頂尖模型GPT-5.4和編程模型Codex Spark的加持下，Codex不僅可以實現對數百萬行代碼的重型任務處理，還能進入“思考即實現”的快速編程模式。

演示完Codex的具體能力后，Alexander與Romain就Peter Yang提出的一系列問題進行了回答。

談及團隊內部產品開發的規劃，兩位負責人表示Codex完全放棄了中期規劃，僅關注短期以及長期的研發計劃，把時間限制在8周內以及一年以上。

對于AI時代團隊內部的職責分工，Alexander與Romain都認為“人才棧壓縮”已經在Codex內部發生了，Romain認為“崗位邊界正在變得模糊。”，Alexander更是直言有些PM就該直接轉崗。

聊到Codex團隊的招聘文化，Alex和Romain都非常看重“能動性”，不管你畢業于哪所大學，或者有什么樣的頭銜，你首先要有極高的行動力，Codex需要的是能自行發現問題，并可以著手解決的自驅型人才。

下面是智東西整理的播客核心要點：

1.很少寫文檔，10個要點就夠了：Codex團隊極少撰寫長篇技術文檔。只有在面臨無法裝入單個人腦的復雜決策或需要多人協調時，才會產出約10條要點的簡短文檔。大部分決策由最接近問題的人直接做出。

2.設計師比工程師寫的代碼還多：Alexander開玩笑地說，因為Codex太強，每個人都可以做職責以外的事情，Codex團隊的設計師現在寫的代碼，比半年前一名工程師寫的還要多。

3.即使AI工具再好用，也要用心打磨產品：雖然絕大部分代碼是Agent生成的，但Codex團隊依然投入了大量精力去確保產品系統是高質量的，如果這是一個很復雜的功能，一定會有一個專業的人來負責。

4.產品設計哲學：隱形與可配置：Codex應用的設計理念是“不擋路”，即讓模型發揮主導作用。產品通過高度可配置性滿足高級用戶，同時保持界面簡潔直觀，讓新手也能通過側邊欄、技能標簽等逐步發現功能。

5.拒絕中期路線圖：團隊只做短期（8周內）的具體執行計劃或長期的規劃，避免制定難以預測的“中期產品路線圖”，根據模型能力的進化靈活調整產品形態。

6.與社區成員協同開發產品：團隊視社區為合作伙伴，通過開源和測試與用戶共同構建產品，利用社區反饋來驅動開發。

7.職業邊界的模糊化：AI工具導致職業階梯坍塌。設計師能寫代碼，PM能做原型。團隊推崇“人才棧坍縮”，認為做成一件事所需的人越少越好，職業的角色標簽正在失去意義，未來職業發展的核心是“興趣”和“能動性”。

8.招聘核心特質：能動性與作品：團隊招聘不看重學歷，而看重候選人是否具備“能把事辦成”的高能動性、技術創造力以及分享知識的熱情。

以下是播客內容的完整實錄，智東西做了不改變原意的整理：

Peter Yang：好，歡迎各位，今天非常開心請到來自OpenAI Codex團隊的Alexander和Romain。他們會為我們演示如何用Codex開發新功能、Codex到底能做什么，同時聊聊 Codex團隊是如何持續不斷地快速交付的。歡迎二位。

Alexander&Romain：感謝邀請。很高興能來聊天。

Peter Yang：那你們要不要先快速展示一下，Codex能做出些什么東西？

Romain：沒問題。我來共享一下屏幕，讓大家感受一下。其實能展示的東西特別多，我就簡單舉個例子。這是我正在做的一個iOS應用。如果我想給這個應用加個新功能，我只需要口述一句：“你能給NASA的阿爾忒彌斯登月計劃加一個新頁面嗎？”

然后把這個提示詞發給GPT5.4。模型馬上就會給這個iPhone應用生成一個全新頁面。你看應用就在這兒，挺酷的，它正在自動構建這個新功能，馬上就能看到效果。

另外我們還有Codex Spark模型，幾秒鐘之內就能幫你快速構思、反復迭代。我給你看一下它現在的運行效果。對比一下就能看出Spark模型響應有多快。左邊是GPT5.4，我先讓它跑一會兒；右邊是Codex Spark，你看，平均每秒能處理1200個任務。這速度簡直離譜。

比如你想做個游戲的話，就在咱們開始錄制之前，我打開過Codex應用，隨手發了個提示詞，讓它在界面背后生成一個簡單的2D小游戲，我可以直接接著開發。

我特別喜歡Codex的一點是，我可以把對話窗口懸浮在屏幕最上層。這樣一來，我在做游戲開發的時候，就能一邊干活一邊看它不斷迭代，進而迸發新想法。那我們接下來改點什么呢？Peter，你有什么想法？

Peter Yang：要不加點裝飾，房子、樹之類的，讓畫面更生動一點？

Romain：“你能再加點樹之類的裝飾嗎？”我現在就發指令。幾秒鐘之內，Codex Spark就能完成修改，我們可以實時看到變化。你看，新的樹已經出來了，我們可以繼續玩下去。這速度真的太夸張了。這也是我為什么對Codex這么興奮。

一方面你有GPT5.4這種頂尖模型，可以處理數百萬行代碼的分析、遷移這類極其復雜的任務；另一方面當你靈感迸發、進入心流狀態時，可以切換到快速模式，甚至直接用Codex Spark，擁有近乎“思考即實現”的超快速度，想做什么就能立刻做出來。

一、Codex團隊很少寫文檔，就算寫，10個要點也夠了

Peter Yang：我特別好奇，你們團隊平時到底是怎么用Codex做產品的？Alex，你們現在還寫規格文檔嗎？還是直接讓GPT來寫？用的是哪個模型？如何讓產品研發流程運轉起來？

Alexander：我們Codex團隊真的幾乎不寫規格文檔。很多工作都是讓最貼近一線的人自己做盡可能多的決策。只有遇到那種復雜到一個人腦子裝不下的問題時，我們才會寫一點文檔。而且現在一個人能搞定的事情多太多了，因為大部分編碼工作都可以交給模型。但如果需要跨多人協作，或者要做一個特別棘手的決策，我們可能才會寫一份規格說明。就算寫，也極其簡短，大概就十來條要點，完事。

Peter Yang：能演示一下嗎？比如給Codex幾條要點，它先寫出完整需求，比如M文件那種？

Romain：可以。不過我還想展示一個更簡單的用法?；氐絼偛拍莻€iOS應用，它還在跑任務。假如你對新項目有一些新功能想法，但又不太確定具體怎么做，現在用Codex就很方便。我只要說一句“我們來規劃一下下一步”，Codex就會自動識別出我在做計劃。按一下Shift+Tab，就能進入計劃模式。我可以問 “我們接下來該做什么”，把Codex當作頭腦風暴的搭檔。在計劃模式下，它會分析現有代碼和項目進度，給出建議，我也可以加入自己的想法，引導模型做出合適的規劃。

你看，它已經根據代碼和文件給出了一些思路，還會主動問我要方向：是繼續做剛才的阿爾忒彌斯相關功能，還是先做穩定性優化、做個監控面板？我們就選穩定性優化吧。再問一句 “我們應該為誰優化？”我就可以這樣一步步和Codex協作。

當然我剛才什么都沒輸入，換作亞歷克斯這種產品負責人，一開始就會給很多明確方向，而我這里是讓Codex自己先出主意。

Alexander：我經常這么干，還挺有意思的。修改分好幾種。最簡單的那種，直接發提示詞就搞定。中等復雜度的，你可以先梳理思路，讓模型給出具體方案。我自己常用的一種方式是：只有一個模糊想法，就直接打開Codex，讓它先思考怎么解決問題。

我甚至還沒想好具體功能。它會自己探索，再反問我一些問題。很多時候最后我甚至不會用它給出的方案，因為改動可能太復雜了。

插一句題外話：產品經理到底寫不寫代碼，其實還挺有意思的。遇到復雜改動，我不想自己去落地和維護，但我還是會用計劃模式走一遍流程，自己先建立清晰的認知，然后把這些思考分享給工程師，而不是直接丟一個方案過去。

說回剛才那個題外話，Codex團隊的設計師現在寫的代碼，開玩笑地說，比半年前一名工程師寫的還要多。他們真的超強。當然工具本身起了巨大作用。團隊還吐槽我去年提交的PR太少，具體數字我就不說了，但確實應該多一點，尤其是很多都只是很小的微調。我覺得現在已經不是“能不能生成代碼”的問題了，智能體非常強，你可以把任務交給它。

關鍵在于你決定做什么，我們對產品方向是否達成共識？一方面是如何保證質量極高。有人會很驕傲地說整個應用都是“靠感覺編程的”，Codex絕大多數代碼都是智能體生成的，但我們依然花大量心思思考系統架構，保證質量過硬。所以遇到特別復雜的功能，我通常會安排一個更穩定、更資深的負責人來接手。產品經理的價值之一就是精力分散、四處協調，所以不適合讓產品經理去維護系統代碼。

Peter Yang：是啊，肯定不能讓PM去維護功能代碼，聽起來就不靠譜。

Alexander：我覺得我們準會搞砸。

Peter Yang：嗯，好吧，而且說實話，其他一些專業工具也很棒，但要花大量時間去學習。我感覺如果不刷推特，我甚至都不知道怎么用那些專業產品。而我特別喜歡Codex的一點就是，它用起來極其簡單，非常直觀、好上手，同時又有技能、自動化這類高級功能。你們內部會大量使用這些功能嗎？

Romain：非常高頻地用，我覺得“技能”是Codex最有意思的功能之一。比如和用Figma的設計師協作，開啟Figma技能，就能直接從設計文件里提取細節、React組件、變量，然后Codex會自動生成對應代碼。

再比如你做完應用想部署到Vercel、Cloudflare、Render，這些技能都內置好了，你只要告訴Codex，它就能對接整個生態工具鏈。前幾天我跟朋友聊天，他說自己有一堆產品改進想法，就讓Codex把所有任務同步到Linear里方便跟進，然后睡前跟它說“把剛才討論的任務全部實現并標記完成”，第二天醒來一看，真的全部搞定了。

Peter Yang：這太神奇了。

二、Codex的設計思路，高度可配置性以及新手友好

Alexander：說到應用操作簡單，我可以聊聊我們的設計思路。開發者很喜歡為自己打造工具、實現工作自動化，所以產品的高度可配置性至關重要。Codex的核心框架是開源的，用戶可以深度自定義，我們開發新功能時，甚至還沒在生產環境上線，就有用戶在推特反饋功能異常，因為他們已經自行修改代碼、分支部署來體驗新功能了。

這對我們來說是產品的一大亮點，最前沿的用戶和我們一起走在未來前沿，推動產品進步。

但如果只針對這類極客用戶設計，產品會變得晦澀難懂，就像剛才說的，得天天刷推特才能學會使用。

所以我們的思路是，精心打磨產品的核心基礎功能，認真規劃設計，讓產品盡可能隱形，不干擾模型運行，隨著模型能力提升，實現更多功能；同時為高階用戶提供高度可配置的選項，比如市面上已經有子智能體的相關實現，用戶可以自主體驗、嘗試，我們也從中汲取大量使用反饋，之后再把這些功能簡化，普及給所有用戶。

Codex 應用就是這樣一步步打磨出來的，大概在去年12月GPT5.2版本推出時，模型能力實現了突破，能夠處理更長時間的任務，甚至一次性完成復雜工作。我們看到有用戶在玩“tmuxing”，給非專業人士解釋一下，就是在終端打開多個任務并行，社交媒體上還有人曬出多終端、多顯示器同時操作Codex的畫面。

我們很受鼓舞，在基礎版CLI工具中優化了任務委派功能，又思考如何讓頂尖1%工程師的高效操作變得直觀易懂，于是打造了Codex應用。打開應用就是簡潔的聊天界面，模型會自動執行任務，慢慢還能發現側邊欄、多任務運行、技能面板等功能，探索的過程就像玩游戲一樣順暢。

Romain：我們從一開始就堅信，未來的編程會走向智能體委派模式。差不多一年前啟動Codex項目時，我們就暢想工程師能并行處理多項任務的未來，只是當時模型能力還未達標。直到GPT5.2及后續版本推出，模型才能夠持續穩定地工作數小時甚至數天，這時候終端多標簽頁長時間運行的操作方式就顯得很別扭，于是我們需要全新的交互界面，Codex應用的推出恰逢其時。

Alexander：Codex的發展經歷了兩次重要轉變。第一次是去年8月，我們推出了Codex云產品，創意很好，用戶反響也一直不錯，只是推出時機稍早。同年8月我們還發布了GPT5這款優秀的交互式編碼模型，聚焦解決模型當下能實現的功能，推出了命令行工具和集成開發環境插件，用戶量在幾個月內增長了二三十倍。第二次轉變是去年12月到今年1月，我們終于能朝著模型委托的愿景推進。

三、拒絕中期規劃，只看8周或一年

Peter Yang：深入聊聊Codex應用的開發過程吧。一年前你們有年度路線圖嗎？計劃好什么時候推出應用，還是根據市場情況不斷原型迭代？

Alexander：其實都不是。我在這里的一位研究員安德烈給過我一條很好的建議：在OpenAI，你要么做短期規劃，要么做長期規劃，絕不做中期規劃，因為太難了。

短期最多八周，你要想想，有什么事情是可以激勵團隊圍繞它共同努力、然后把它做出來的？這正是OpenAI擅長的事情，我們非常擅長圍繞一個具體的目標快速組織團隊。

長期則是一種方向感，你會知道，一年后模型會聰明得多，現在回頭看這句話好像很明顯，但當時你會想，我們會有更強的模型，因此不會想把工作權限只開放到本地電腦，那樣一次只能干一件事。我們想要無數個模型同時獨立工作，自我校驗、自動部署、自動監控，甚至不需要我們手動發提示詞。

我們會朝著這個大方向去思考，而中間那段所謂產品路線圖，我們基本沒有。我們只有長期方向，以及能朝著這個方向推進的短期事項。

比如做Codex應用，其中一個戰略目標就是脫離特定工作區。有點抽象，我解釋一下：像VS Code這類編輯器，你打開時會進入一個特定工作區，也就是一份代碼副本、一個固定文件夾。就算用Git多工作樹，一次也只能打開一個，本質上一次只能做一件事。命令行也是一樣。

但我們的愿景是讓用戶在云端向多個智能體委派任務，它們獨立運行。所以我們需要一個界面，讓你可以自然地和多個智能體對話，或者由一個主智能體統籌多個子智能體。

同時我們也發現，直接從云端起步對開發者不太友好，工具不全、環境要配置，任務做到一半想介入調整也不方便。所以我們需要一個本地體驗，不綁定某個文件夾，又能直觀地操作電腦上的各個目錄。

開發應用時，我們腦子里有這些大方向，再加上工程師們平時隨手做的各種原型：“我想要一個這樣的應用”。還有一次黑客周，好幾個人獨立做了不同版本的應用原型。

所以項目啟動時，唯一落于紙面的只有“為什么我們應該做這個應用”，沒有任何詳細規格。后續開發過程中才慢慢形成文檔，甚至內部還有過爭議：我們真的需要做獨立應用嗎？編輯器插件已經很火了，不如專注優化它？命令行不也挺好？如果做應用，核心定位是什么？方向在哪？很多事情最開始就是這樣的。

Romain：是的，幸運的是，當時我們有一個很棒的IDE擴展解決方案，而且我們對它進行了相當深入的打磨。因此，你可以在諸如Good Cursor、Windsurf等工具中使用它。于是，我們從這個IDE擴展中汲取了許多寶貴的經驗和代碼基礎，從而獲得了一個功能強大且已相當穩固的優秀起點。

Alexander：是的，實際上，這款應用與IDE擴展共享代碼。在底層，這款應用和IDE擴展與同一個用Rust編寫的開源核心Codex框架進行連接，CLI工具也同樣使用這個框架。這些基礎組件之間有著大量的共享，而且這種分層設計也是經過精心考量的。

不過，現在回頭看，做應用的決定是顯而易見的，因為用Codex應用比開一堆終端窗口簡單太多。它對新手友好，上手像玩一樣，也是同時管理多個智能體的最佳界面。

我想說，我們非常注重通用人工智能（AGI），因此我們總是在琢磨：未來正朝著哪個方向發展呢？所以，我其實想把順序顛倒一下。更準確地說，我們需要一個界面，讓委派多個智能體變得自然順暢。因為我們知道模型遲早會發展到那一步，甚至我們已經看到有人在這樣做了，我們需要一個界面既能適配云端，又足夠舒適好用，不用你絞盡腦汁才能并行調度多個智能體，而是理所應當就該這么工作。

Romain：對了，其實這種工具的吸引力并不僅限于那些初級開發者。恰恰相反，即便是最資深、最頂尖的工程師，從Peter Steinberger到Greg Brockman，如今也都開始把這款應用當作主要的開發方式。這充分體現了那種“Agent委派”的愿景正在逐步成為現實。而且，這可不只是給新手準備的，那些最資深的工程師只會留在終端里的說法已經過時了，事實上，他們也正紛紛轉向使用這款應用。

Alexander：是啊，咱們聊聊Peter吧。他們剛加入OpenAI，我們簡直激動壞了。不過我好像沒跟你說過，去年十月份的時候，我跟他一起在舊金山散步。當時我其實沒明說我們正琢磨著開發一款應用，但心里多少有點兒在試探這個想法，我說，就是那種能讓人輕松搞定任務分配的新界面。結果他直接告訴我，他這輩子都不會用這種東西。可到了上周末，他居然發推特說：“這應用還挺不錯的呢！”天哪，真是太陽打西邊出來了，他現在居然還挺喜歡！

Peter Yang：是啊，我也這么覺得，能讓他用上這個應用，那可太厲害了，畢竟他是那種同時開了差不多20個終端窗口的人。

Alexander：沒錯，但我想說，我得跟他再聯系一下。他可能兩種都用，誰知道呢。

四、Codex內部PM的工作方式：兩種模式隨時切換

Peter Yang：那么，Alex，有一段時間你幾乎是唯一的PM對吧？那Codex大概有多少人呢，你知道的，50到100人左右？

Alexander：差不多就在這個區間。今年5月的時候我們才八個人左右，之后增長非?？?，現在大概50到100人。

Peter Yang：你平時時間都怎么分配？典型的一天是怎樣的？還是根本沒有固定節奏？

Alexander：我最近還在想這個問題，發現自己都不知道怎么回答。我意識到自己有好幾種工作模式。這不是什么建議，只是我個人狀態。比如在應用上線前那段時間，我是純執行模式：死磕質量，摳每一個細節，排查所有死角。這種模式下我會大量使用Codex：用它梳理Slack信息、匯總用戶反饋，讓它總結后同步到Linear；用它理解代碼、做修改。

現在很多小改動，不是新系統，只是維護現有功能的那種，直接提交一個測試通過的PR，比你去跟別人溝通、讓他們在一堆任務里優先處理要快得多，畢竟我們還要趕兩周內上線。

除此之外就是大量人際工作：鼓舞團隊、同時也對產品保持挑剔。有意思的是，這種模式下我推特會刷得特別勤，也不知道為啥。

另一種模式是現在這個階段：我們有GPT5.4這樣超強的模型，應用受歡迎程度超出預期，還全平臺支持Windows。我就會想：是時候重新投入云端建設了。這種階段我更多是思考方向、梳理現狀，更多用Codex做溝通，而不是寫代碼。

我至少有這兩種模式，可能還有更多。

五、跨職能協作極少，像海盜船一樣運轉的團隊

Peter Yang：跨團隊對齊工作多嗎？

Alexander：Codex團隊真是太棒了。我們Codex團隊的跨職能協作和對齊工作其實很少。我們更傾向于把自己定位為一支刻意帶點“海盜船”風格的團隊。

你知道，在Codex團隊內部，最近才出現了第二位PM，我本人也是其中之一，還有幾位最終負責人。我們現在更像是一條海盜船一樣，聚在一起、渾然一體地工作。因此，彼此之間的協調配合并不算特別多。不過，我越來越覺得，構建Codex的一大關鍵就在于打造編程智能體本身。如今，這一點已經越來越清晰，或者說，現在恐怕對每個人來說都已再明顯不過了：編碼智能體其實是一種非常通用的工具，不僅能用于編碼工作，還能廣泛應用于其他各類任務。

我們看到，人們使用Codex應用程序的場景遠不止于編寫代碼。他們正將其應用于軟件開發生命周期中的各項任務。如今，實際上絕大多數OpenAI用戶都在使用Codex應用程序，甚至在技術團隊之外，我們也隨處可見這款應用的身影。正是這種認知讓我們意識到：我們必須思考該如何讓Codex的用途超越供程序員寫代碼這一范疇，從而實現跨職能的更廣泛協作。畢竟，作為OpenAI，擁有ChatGPT，一款被無數人廣泛使用的工具。因此，我們必須審慎思考，如何更好地發揮ChatGPT的作用。

六、擁抱開源，以社區為核心，和開發者一起研發產品

Romain：另外，從我們這邊來看，開發者體驗團隊現在某種程度上可以說是Codex團隊的延伸，我們目前將大部分精力都投入到Codex項目中，原因也很簡單。首先， Codex本身是個令人興奮的產品，開發者們非常喜歡使用它，也希望能進一步提升它的表現。正如Alex所指出的，我們有多種不同的工作模式，比如與Codex團隊并肩作戰，共同籌備產品的發布、準備相關素材，以及探討如何最大化利用Codex。此外，在產品發布之后，我們還會努力向開發者們普及如何以各種各樣的方式高效地使用Codex。

但對我們而言，另一個非常有趣的視角是：當你放眼更廣闊的OpenAI平臺時，如今已有數百萬開發者基于其API進行開發，他們所使用的模型涵蓋多種模態，從Imagen到Sora，再到語音轉語音。如今，構建的最佳途徑竟然是以Codex作為入口。

舉個例子，如果我們把時間倒回一年前，甚至去年夏天剛推出GPT5時，我們不得不花大量精力撰寫各種指南，教大家如何向GPT-5發出提示。沒錯，它是一款推理模型，與GPT-4模型截然不同。如今，我們致力于向開發者們傳授如何使用Codex及其相關技能。比如，如果你的某個集成需要更新，你大可直接選用Codex和相應的技能。它一定會幫你搞定這一切。因此，我們現在已實現了高度跨職能協作，并且將Codex視為開發者平臺一切工作的核心基石。

Alexander：關于我們合作方式的一個有趣之處在于，我覺得在Codex工作最棒的地方，其實是它的社區，無論是線上互聯網上的交流，還是偶爾在現實生活中舉辦的各類活動中，我們都牢牢錨定著這個核心。比如，在產品發布方面，我們特別注重“發布導向”，總是在思考：“我們為什么要推出這款產品？”

同時，我們也非常重視反饋，時刻關注社區的反饋何時到來，然后迅速采取行動加以改進并及時溝通。因此，我們整個團隊都相當活躍地在線上互動。舉個例子，就拿Codex Atlantic項目來說吧，我們與DOM及其團隊合作得非常緊密。實際上，DOM幾乎全程都在幫助我們協調工作，尤其是針對早期的廣泛Alpha測試階段，他和一群用戶密切配合，共同收集反饋、打磨功能，同步提升應用的各項技能，甚至還包括文檔編寫等等。

所以，我認為這正是我們Codec團隊的獨特優勢所在：因為我們是開源的，而正因為是開源的，我們在所有事情上都自然而然地展現出極高的透明度。我想，這種開放的態度也正得到了社區的熱烈回饋。

Peter Yang：是的，和用戶一起在社區中研發，每天都能和他們聊天，正是做PM最棒的部分。

Romain：是的，現在確實如此，就像各個城市的Codex大使們一樣。許多城市和國家都在各自舉辦活動，面向本地社區開展教育與推廣。我當然希望能走進每一座城市，但現實條件限制我們無法做到。不過，看到這種熱情與干勁，真是令人驚嘆！社區很喜歡舉辦這類活動，比如黑客松之類的，大家一起進行創造，真是太棒了！

Peter Yang：是啊，讓我當大使吧，我來辦幾場活動。

Alexander：聽起來不錯。好吧，你簽吧。

Peter Yang：那么，咱們來聊聊Peter吧。我算是早期OpenClaw的用戶，雖然它還有點小瑕疵，但對我而言卻派上了大用場，前幾天，它甚至記住了我們之前的對話，給我做了一段長達三分鐘的、超級直白又充滿激勵的“加油打氣”演講。那簡直是我聽過的最醍醐灌頂的一次AI對話了。所以你們是怎么把Peter融入團隊的呢？而且，這種個人Agent的構想，是不是也屬于你們正在做的事情的一部分呢？你們怎么看待這一點。

Alexander：我能說的有兩點，我的意思是，我在這里能透露的畢竟有限，第一點是，他可是Codex的超級、超級重度用戶。要知道，OpenClaw很大程度上就是基于Codex打造的，他一直在用反饋來激勵團隊，在努力推動Codex的持續改進。這算是他的副業，但他真的干得熱火朝天，我們對此感到無比興奮。至于另一件事，目前我還不能透露太多，不過他正全力協助我們打造下一代個人智能助手，而且還是那種能媲美ChatGPT的！

Peter Yang：那也說得通。

Romain：我覺得Peter所做的事情最令人著迷的地方在于，顯然我認識Peter已經有一段時間了，當人們剛開始玩OpenClaw的時候，每個人都曾瞥見過未來的模樣。但真正讓我令人驚嘆的是，彼得其實很早就有了這個愿景。

如果把時間倒回2025年，你會發現，他去年一共構建了超過40個開源項目，而這些項目無一例外都圍繞著同一個愿景：我需要一個命令行界面來訪問我的日歷；我需要一個命令行界面來訪問我的推文和Gmail。通過打造所有這些項目，他實際上讓這一愿景得以實現了，也即我們如今用來篩選信息的“技能”和“命令行工具”這個思路，這就是我們所使用的Coding Agent方式。而且，這絕不僅僅局限于傳統的Coding Agent上，未來還可能發展成各種各樣的個人智能體。

因此，彼得在這一過程中為我們提供的反饋將顯得尤為出色，因為他所打造的這些工具如今已成為開源生態系統的一部分。

Peter Yang：是啊，我真的覺得他就是個普通人，但他卻打造了一個超棒的開源社區。而且，真的，這讓我完全不想再打開別的應用了。我剛剛才跟我的小機器人聊了幾句，差別太大了！

Alexander：等等，你都連了些什么？你是不是把所有東西都連上了？

Peter Yang：我不得不這么做，我真的連接上了各種各樣的東西。它存著我的銀行信息，還有我的YouTube賬號信息，甚至還有我激活過的語音助手、我的谷歌服務等等。比如我躺在床上，我老婆突然問我：“你在跟誰聊天呢？”我就回答：“哎呀，就是打個電話唄，你知道的。”但說實話，市面上有不少騙子，居然要收5000美元才幫你搞定OpenClaw的配置。所以啊，如果你們能把這玩意兒做得更親民、更大眾化，那可真是大賺特賺，絕對會非常火。

Romain：是的，我們正在努力，以后再跟你匯報進展。

七、Builder時代，職業職能邊界正在模糊，有些PM應該轉行

Peter Yang：好吧，那我們來總結一下，聊點刺激的，Alex，可能是我記錯了，但我記得你好像說過，大多數團隊其實不再需要那么多PM了，或者類似這樣的話。你覺得呢我們需要PM嗎？

Romain：我覺得這些工具最讓我驚嘆的地方在于，從我的角度來看，這甚至已經不僅僅是需不需要PM的事情了。幾乎可以說，每條職業發展路徑之間的邊界都在變模糊，就像以前團隊里有工程師，PM和設計師，有某種“黃金比例”的搭配。

但如今，如果你是個工程師，你的效率更高了；如果你是位設計師，你能憑借自己的獨特優勢，向技術層面邁進。再比如，如果你以前只負責撰寫戰略文檔，現在呢，你甚至可以直接動手做原型。當然這并不意味著你要對面向數十億用戶的那個功能全程負責，但至少，你能通過親手打造，讓團隊看到你的想法。我覺得，這一點真的讓我著迷。職業階梯之間的所有界限都變得模糊了，我們都在變成Builder。

Alexander：是的，這一點我很有共鳴。好吧，我想我想起來了，我記得好像在網上說過這樣的話，如果一家初創公司工程師人數不到20人左右就招PM，那它就可能存在“紅燈”風險。也許我當時還說了點類似你剛才說的，就是這些角色之間的界限越來越模糊了這些。

就像設計師能做更多工程，工程師也能做更多設計，項目經理也能做更多開發。但你知道，工程師們往往也需要高度專注。所以，他們之所以不像我剛才說的那樣，比如對任務進行優先級排序，或者從事項目管理這類其他工作，很大程度上可能就是因為，他們更需要花時間寫代碼。

不過現在，寫代碼已經變得特別簡單了，你只需讓Codex這樣的智能助手去分析反饋并確定優先級就行了。這樣一來，你就能騰出更多時間。因此，我覺得每個人都能勝任彼此的工作，就像Scott Belsky提出的“人才堆棧坍縮”這一理念一樣。

我喜歡那個想法，我覺得它正在成為現實。我認為，房間里需要的人越少，事情反而越順利，每一個決策也越純粹。那么問題來了：究竟還剩下哪些適合PM的場景呢？

我覺得，其實有不少PM應該考慮轉崗，比如，如果你一直想成為一名工程師，但可能你更擅長管理團隊，卻不太擅長技術本身，那現在或許可以轉去做一名工程經理，這也沒什么不好。又或者，對于那些代碼能力較弱的PM來說，擔任一名編碼助理或許更合適。甚至，也許換個更清晰的角色對你而言反倒更自在。同樣，現在某個PM可能更想成為一名設計師，這樣可以更貼近實際的開發工作一些。

但我覺得，歸根結底，關鍵還是興趣。我認為，興趣與能動性是人類在擁有AGI的世界中依然至關重要的兩種最基本特質。因此，對我而言，這是我最終會思考的問題。

舉個例子，如果你本質上更熱衷于寫代碼，而之前做PM的工作只是因為“有人需要這么做”，那么現在你干脆卸下PM的頭銜，轉而成為一名工程師，從工程的角度去干同樣的事兒，設計也一樣。

但如果你本質上最感興趣的，其實是花大量時間與用戶打交道,哪怕這會讓你暫時遠離開發工作，又或者你喜歡深入洞察用戶需求，琢磨市場趨勢，甚至嘗試預見未來的發展方向等等。同時，如果你所在的團隊規模足夠大，已經有足夠多的工程師了，那或許還能為產品經理留出一席之地。不過總的來說，我覺得關鍵還是在于：你到底最感興趣的是什么。

我再補充一點：我仍然認為，每個問題都需要一位對此負責的人，但我并不覺得這個人非得是PM不可。

Romain：是的，我覺得這很大程度上取決于你剛才提到的產品性質。因為我們很幸運，能參與Codex項目，它其實是一款面向開發者的構建工具，而我們自己恰恰就是最優秀的用戶。而且，得益于開源模式，我們還能與社區緊密合作。不過，就算退回到更早的階段，比如我還在Stripe工作時，當時Stripe員工人數達到250人，卻連一名PM都沒有，甚至完全沒用過任何AI工具，因為當時的Stripe就是一個API，而我們所有人都是工程師，都清楚一個真正出色的API應該是什么樣子。于是，我們干脆就直接打造了那個我們夢寐以求的API。我們希望Stripe能變得優雅，只需寥寥幾行代碼就能搞定一切。

但如果你從事的是其他的領域，所處行業的垂直領域、業務空間或問題領域不同時，卻依然想保持那種以客戶為本的執著，那么你可能需要更多PM去投入時間，去花時間與客戶互動。我們很幸運能夠參與Codex項目，就像在打造一款我們自己一直夢寐以求的工具。

Alexander：比如，咱們舉個例子：在某個領域，工程師們對此缺乏直觀的把握。就像PM其實只是一個標簽，指那種既能設計廣告、寫代碼、又對用戶特別感興趣的家伙，你懂我的意思吧？其實，這同樣也可能是個工程師，他對用戶的需求同樣敏銳而深刻。所以我覺得，這些標簽現在多少有點失去原有的意義了，不過目前這樣也還行，畢竟現在就是有點亂糟糟的。

Peter Yang：這正是我在團隊中發現的。我發現，那些最優秀的工程師并不會來問我：“我們接下來該做些什么？”他們自己會去跟用戶交流，弄清楚該開發什么，然后我們再一起討論。感覺就像大家對這些事情都達成了共識一樣。

Romain：你知道嗎？Codex團隊就是這樣工作的。如今你在Codex應用中用到的許多功能，其實都源自工程師們從底層出發提出的絕妙創意，因為他們自己也想用這些功能。

Alexander：是啊，不過我想說的是，有一種工程師的特質特別吸引我，他們超愛和用戶打交道，總琢磨著該開發些什么。當然，也有一類工程師，他們的能力同樣出色，甚至可以說是極其頂尖，他們超級高效，特別擅長構建系統、縝密地思考架構設計，卻對跟用戶打交道毫無興趣。

我覺得，這兩種類型的工程師其實都有很大的發展空間。我看待人工智能時代的一個觀點就是：我們每個人都可以更坦誠地做自己，做真實的自己。人工智能以及你身邊的團隊會幫你填補那些你不太想花精力去做的事。

Peter Yang：不過我確實覺得“Builder”這個標簽特別重要。我感覺每個產品經理都想成為領導者，可問題是，傳統的職業發展路徑就是：你一路升到副總裁之類的職位，然后就沒時間真正去Builder了，整天就忙著做產品評測，一會兒這兒提個反饋，一會兒那兒給點意見。我覺得很多產品經理其實不想這樣，我也不知道你是不是也這么想，但反正我就是想離用戶更近一點，多去實際交付產品。

Alexander：完全同意，我其實并不認為產品經理是個理想的領導崗位。我覺得它更像是一種填補空白的職位。偶爾確實可能需要一些領導力，不過即便如此，這種領導力也多半只是幫助大家步調一致，除非你真是個天才，能想出正確的戰略。嗯，有一點我可以肯定：像OpenAI那些最優秀的PM，都深入到了一線場景。我覺得，以高級領導者的身份加入OpenAI，其實是非常有挑戰性的，因為保持深入一線、親歷親為依然至關重要。所以，你得想方設法擠出時間來，我認為在這里深入一線，從細節出發總是更好的選擇。

八、招聘要求和企業文化：能動性優先，熱愛創造和分享

Peter Yang：最后一個問題，你們終于又招了一位PM，我聽說他叫Rohan，對吧？除了Codex的重度用戶之外，你們在招募Codex團隊成員時，還特別看重哪些素質呢？

Alexander：我覺得咱們倆都來說說這個吧。我之前就說過，能動性非常重要。那些真正能動手去做事的人是最重要的，在OpenAI，尤其是Codex團隊就是如此。我們不是那種“加入進來后，先給你12個任務，按難度遞增順序完成就行”的團隊。相反，我們會更像是歡迎你加入，然后就完了，看你自己了。所以我喜歡那些能夠自我定位、積極行動的人，他們總是充滿干勁和點子，樂于提出新想法，也并不介意與現有的觀點唱反調。

畢竟，那些舊有的決定很可能只是我們偶然做出的?，F在我描述的這種人，簡直就是完美的隊友。他們能欣然接受任何新增的工作內容或責任，哪怕這些任務尚不明確，我覺得，這樣的人才是最理想的。

Romain：是的，我同意。就我所在的DevX開發者體驗部門而言，通常那些能動性高的人顯然都非常精通技術，比如能熟練掌握Codex這類工具。不過，我特別喜歡熱衷于與開發者和建造者共度時光，樂于分享他們的知識的人。比如，就在本周，我們剛剛宣布，那位做了開源Codex Monitor的Thomas本月將加入我的團隊。這真是太棒了！因為他不僅創意十足、產出豐富，還特別熱愛分享自己使用Codex構建項目的經驗。

我們需要吸引數百萬開發者，共同邁向Codex那充滿希望的未來。我認為，AI編程正在徹底改變我們思考軟件開發、應用開發以及產品構建的方式。而這一切背后蘊藏著巨大的潛力，足以向全世界展示：任何人都能輕松打造出各種各樣的東西，同時還能在過程中毫無保留地傳授經驗。這正是我所追求的，一種讓所有人共同成長的未來。

Alexander：如果我理解有誤，請告訴我。在我看來，DevX的職位描述就像一位非常優秀的工程師，同時也愛玩推特。

Romain：是的，你說對了一半，另外，我還想補充一點，那就是，對于我們來說不止推特很重要，當你前往世界某些地區旅行時，會發現一些開發者并不太活躍于這些平臺，比如在歐洲和其他一些地方，他們更傾向于使用領英或其他平臺。因此，我們確實需要多留意一下這種全球化的思維方式。我們很看重一個人是否喜歡社交，是否樂于花時間教學和分享。

Peter Yang：而且我覺得，在他們進入面試流程之前，就能大致判斷出一些情況，比如，他們是不是常常在網上發布內容，比如開源項目之類的。

Alexander：是的，每當有人私信我，表示有興趣跟我合作時，我就會看看這上面有沒有他的作品鏈接。如果有鏈接，我基本都會點進去看看，說實話，我非常好奇，如果有些關于他想法的介紹，我通常也會仔細讀一讀。這話聽起來有點奇怪，但如果對方只是簡單地解釋一下他們為什么對這個職位感興趣，再附上他們的簡歷之類的東西，我反而沒那么愿意去細看，我更愿意花時間琢磨他們的創意和他們做過的東西。另外，前幾天有人問過我這個問題，我才意識到，自己根本不知道大家都是從哪所大學畢業的！

Peter Yang：是啊，誰在乎呢。我非常興奮我們生活在這個學歷越來越不重要的世界，反正也沒人在乎，你只需要展示自己做過的東西就好。真的特別感謝你們，我超愛Codex，這周末我要親手去做一些好玩的東西。

Romain：玩得開心，等你的反饋！

Alexander：謝謝你，Peter。

Peter Yang：好的，伙計們，再見。