Spec 退場，skills 上位：Codex 團隊的產品方法論變了

編譯 | Tina

在 Codex 團隊，spec 這件事已經變得很輕了。很多時候，文檔里只有 10 條要點，后面就直接進入開發。

這種變化，和模型能力抬升有很大關系。前幾年，大家還在反復研究 Prompt，也在努力把 spec 寫得更完整、更結構化，希望模型能更穩定地照著執行?，F在，Codex 團隊討論得更多的是 skills。他們開始把常見任務整理成一組組可以直接調用的能力，再交給模型去跑。

于是，spec 不再占據最前排的位置，skill 正在變成新的入口，開發這件事本身，也在從“描述過程”轉向“組織能力”。

我們翻譯了這期最新播客，里面聊到的不只是他們怎么做產品，更重要的是，OpenAI 內部對 coding agent、skills 和開發方式的理解，已經在跟著模型能力一起變化。

以下是播客翻譯，內容略有刪節：

1 寫 spec？我們大概寫 10 個 bullet 就結束了

Peter Yang：大家好，歡迎來到今天的節目。我今天很高興邀請到 OpenAI Codex 團隊的 Alex 和 Romain。Alex 是 Codex 的產品負責人，Romain 負責開發者體驗。

Alex / Romain：謝謝邀請，很高興來聊。

Peter Yang：我其實很好奇，你們團隊內部到底是怎么用 Codex 做產品開發的。Alex，你們現在還寫 spec 嗎？還是說已經讓 GPT 來幫你寫 spec 了？一般會怎么做，用什么模型？

嘉賓（Alex）：我覺得，在 Codex 團隊里，我們現在寫的 spec 已經非常非常少了。實際上，我們有一個很核心的想法，就是盡量讓那些“最接近底層實現的人”自己做盡可能多的決策。

所以，只有在一種情況下我們才會寫 spec，那就是這個問題已經復雜到很難裝進一個人的腦子里。因為說實話，現在一個人其實已經能在腦子里裝下很多東西了，畢竟他可以把大部分編碼工作委托出去。所以單個人現在能完成的事情，比以前大得多。

但如果這件事發展到需要幾個人一起協調，或者它牽涉到某個特別棘手、特別復雜的決策，那我們才有可能寫一個 spec。不過即便真的寫，這種文檔通常也會非常短。你可以想象一下，大概就是 10 個 bullet（要點） 左右，然后就結束了。

主持人：那你們能不能具體演示一下？比如說，你們先給 Codex 幾個 bullet，然后它再去寫更完整的需求，或者先寫成一個 markdown 文件之類的？

嘉賓（Romain）：可以這么做。不過我還想順便給你看一個特別簡單但很能說明問題的場景。比如現在開發的一個 iOS 應用，只需要語音輸入一句話，比如：“幫我加一個關于 NASA 阿爾忒彌斯登月任務的新頁面”，然后把這個 prompt 發給 GPT-5.4。模型就會直接幫我生成這個 iPhone 應用的新頁面。

假設現在已經快完成一個任務了，然后你腦子里開始冒出一些新功能的想法，但你自己也不完全確定下一步應該往哪里走。

這個時候，用 Codex 很有意思的一點在于，如果我現在開始說“我們來規劃接下來的步驟吧”，你會發現 Codex 能自動理解，我現在是在試圖為接下來要構建的內容做計劃。如果我按一下 Shift+Tab，它就會進入 plan mode。然后如果我說，“我們接下來應該做什么？”我就可以把 Codex 當成一個 brainstorming partner，一起規劃下一步。

在這個模式下，它會看當前代碼，看項目目前的狀態，然后自己提出一些想法。我也可以把自己的想法加進去，慢慢把模型往一個更好的計劃方向引導過去。

所以你現在可以看到，它已經開始基于項目現狀、代碼和文件內容，自己生成一些主意。

所以我就會像這樣去使用 Codex。當然，在這個演示里，我一開始沒有給太多輸入。如果是 Alex 這種產品負責人，肯定會在前面給更多指導。但在這里，我是故意先讓 Codex 自己去提出一些思路。

嘉賓（Alex）：很多改動其實可以分成幾種類型。有一種是特別簡單的，那你就直接進去 prompt 一下，立刻改。還有一種是中等復雜度的，這時你可能會先想一想該怎么做，或者讓它先輸出一個具體計劃。

但我自己還有一種很常見的做法，和剛才這個例子很像。就是當我腦子里只有一個很模糊的念頭時，我會直接打開 Codex，讓它先開始思考“這個問題可能怎么解決”。這時候我甚至還沒有一個明確的 feature 定義。然后它會自己去探索，回來問我一些問題。

而且很多時候，我最后甚至不會真的采用那套方案。因為有些改動可能最后證明會非常復雜。這里稍微岔開一下，其實“PM 應該寫什么代碼”這個問題本身就挺值得討論的。對我來說，如果是一個復雜改動，我并不一定想親自負責把它合進去并長期維護，但我還是會走一遍這種 plan mode 和探索過程。這樣一來，我對這個問題需要怎么做，就會形成一個更好的 mental model。

最后，我會把這種“思考結果”而不是那個 plan 本身交給工程師。我覺得真正有價值的，常常不是那份計劃文檔，而是我通過這個過程形成的理解。

既然剛才岔到了這個話題，那我就順著說一句。我們 Codex 團隊里的設計師，現在寫的代碼，比大概 6 個月前很多工程師寫的還多。我們自己有時會開玩笑說，他們現在真的猛得離譜。當然，這里面工具起了非常大的作用。

而且團隊里之前還會拿我開玩笑，說我過去一年合進去的 PR 實在太少了。具體數字我就不說了，但我自己也承認，確實應該更多一點。尤其你再考慮到，其中很多 PR 其實都只是一些很小的改動?！?/p>

不過我覺得現在整個問題已經變了。重點不再是“你能不能把代碼生成出來”，因為 agent 在這方面已經非常厲害了，你完全可以把任務委托給它。真正越來越重要的，其實是你決定去做什么。也就是說，我們到底有沒有在方向上對齊，我們是否真的清楚這個產品正在變成什么。

而在這之后，另一個同樣關鍵的問題就是，我們怎么確保最后出來的東西是高質量的?，F在有些人會很驕傲地說，整個 app 都是 vibe coded 出來的。對 Codex 來說，其實絕大多數代碼也確實是 agent 生成的。但即便如此，我們仍然花了很多精力和注意力去思考系統本身，去確保它真的有很高的質量。

所以這也是為什么，如果碰到一個特別復雜的功能，我通常會確保它有一個更穩、更長期的 owner 去負責。我不太覺得 PM 應該去擁有這種系統的一部分，因為 PM 的價值很大程度上恰恰在于他們會被各種事情打斷，他們會四處游走、填補空白。所以你未必希望由 PM 來長期維護這些系統。

Peter Yang：對，你肯定不希望一個 PM 去維護某個功能的代碼吧。聽起來就不像個好主意。我覺得我們一定會把這事搞砸。說得很真實。不過說到產品本身，我也確實挺喜歡 Codex 這種感覺的。外面其實也有其他很強的產品，我也挺喜歡，但很多工具真的要花很多時間去學。我甚至感覺，如果我平時不刷 Twitter，我可能根本不知道那些別的 Pro 產品到底該怎么用。但 Codex 有一點我特別喜歡，就是它上手非常簡單。整個 app 非常直覺化，很簡單。但與此同時，它又有一些很高級的能力，比如 skills 和 automations。你們內部會大量使用這些嗎？

嘉賓（Romain）：會，非常多。真的非常多。實際上，我覺得 skills 可能是 Codex app 這個產品界面里最有意思的一類能力。

比如說，你正在和設計師一起工作，他們用的是 Figma。那現在特別棒的一點是，你可以打開 Figma skill，它會直接把 Figma 文件里的細節拉進來，包括 React 組件、變量等等，然后 Codex 會按照這些內容直接把實現寫出來。

再比如說，你正在做一個 app，做完之后你想分享給別人，或者部署到 Vercel、Cloudflare、Render 上。這些 skills 都已經在那里了。你只要直接告訴 Codex 你想做什么，它基本上就能接進這一整套任務生態里。

前幾天我和一個朋友聊天，他跟我說，自己腦子里有一大堆想法，想改進產品。他就直接跟 Codex 說，用那個 skill 把這些任務全都寫進 Linear，這樣我就能一路跟蹤。然后等所有任務都列出來以后，他又說，那我現在要去睡覺了，你繼續把我們剛才討論的這些任務一個個實現并劃掉吧。結果第二天醒來，所有事情真的都做完了。

2 OpenAI 對 Codex 的判斷變了：開放 Harness，把舞臺交給模型

嘉賓（Alex）：回到 Codex 的簡單性問題，我覺得分享一下我們的設計思路可能會很有意思。

我覺得在這個領域做產品，有一件特別有意思的事，就是開發者天然就很喜歡給自己造工具，喜歡自動化工作流程。所以對我們來說，一個非常重要的原則就是，產品必須足夠可配置。

比如 Codex 的 harness 是開源的。用戶真的可以一路往下鉆，改得非常深。甚至經常會出現一種情況，就是我們在做某個功能時，這個功能明明還沒在正式環境里打開，Twitter 上卻已經有人在抱怨這個功能壞了。原因是這些人自己跑去改代碼，或者 fork 了項目，硬是把功能提前弄出來用了。但對我來說，這恰恰是產品最棒的一部分。因為這意味著，最前沿的用戶其實已經在和我們一起生活在未來，他們一邊探索，一邊把我們往那個未來拉過去。

不過另一方面，如果你只為這群人設計產品，最后做出來的東西就會變得幾乎無法理解，用戶真的會像你剛才說的那樣，整天都得泡在 Twitter 里才能知道怎么用。

所以我們的想法一直是，我們會非常謹慎地去定義那些核心原語，也就是產品最基礎、最關鍵的部分。那些地方是需要真正寫下來、認真想清楚的，而不是隨便 vibe coding 一下就算了。

我們會很認真地思考，怎樣讓整個產品盡可能“隱形”，盡量不要擋在模型前面，而是給模型讓路。這樣每當模型變得更強一點，它就能自然地做更多事情。然后在這個基礎上，我們再考慮怎么把它包裝成一個盡可能可配置的系統，交給高階用戶去探索。

比如說，現在社區里其實已經有人在實驗 sub-agents 的實現了。這個東西已經在外面跑起來了，大家在用、在折騰，而且我們也從他們的使用方式中學到了很多。雖然這個功能并不是我們現在在產品里主動推給所有人的，但用戶已經自己發現并開始用了。

然后下一步，我們就會思考，怎么把這些東西進一步做得對其他人也非常簡單。所以 Codex app 本身其實就是這樣一個例子。大概是在 GPT-5.2 Codex 那個時間點，我記得是 12 月左右，模型能力本來一直在穩步提升，但突然之間我們跨過了一個閾值。到那個時候，你已經可以把更長、更復雜的任務委托給模型了，而且它往往還能直接一次做出來。

于是我們開始看到，很多人其實已經在用 tmux 了。對不了解這個詞的人來說，tmux 本質上是一個“終端復用器”，可以在一個終端里同時管理多個會話、窗口和分屏，讓你并行跑很多任務。

然后我們開始在社交媒體上看到一些很瘋狂的畫面，比如 Peter Steinberger 的那張圖——十幾個終端 pane 鋪滿三塊顯示器，用 Codex 同時跑一堆事情。

我們當時一方面很興奮，一方面也繼續確保這種“委托執行”的能力在最基礎的 CLI 產品里是可靠的。但后來我們意識到，這可能是最頂尖那 1% 工程師的工作方式。問題變成了，我們怎么把這種體驗做得足夠直觀？

于是 Codex app 就出現了。你打開它時，感覺非常簡單，像一個聊天窗口。它能幫你做事情。接著你慢慢開始發現，原來還有一個側邊欄，原來我可以同時跑多個任務，原來我切換這些任務特別容易。然后你會開始覺得，自己變得特別高效。接下來你又會發現，啊，原來這里還有一個 skills 標簽。我們希望把這個體驗做得有點像玩游戲一樣，你是在一步一步發現下一個能力。

嘉賓（Romain）：完全是這樣。而且我覺得，從一開始我們就一直有一個很清晰的愿景，那就是未來的 coding，會越來越變成一種“把任務交給 agent 去完成”的模式。

哪怕是一年前我們剛開始做 Codex 的時候，我們其實就在設想這樣一個未來：工程師會同時并行處理很多事情。

只是那時候，模型的能力還沒有真正到位。后來我們看到了 GPT-5.2 Codex 以及之后的模型拐點，模型開始能夠非常細致、非?？煽康剡B續工作好幾個小時，甚至幾天。到了那個階段，你再回頭看，發現如果還只是讓用戶在終端里開一堆 tab，然后讓它們跑上幾個小時，那其實是個挺奇怪的交互方式。

所以我們才需要一個新的產品形態。而我覺得，后來變成 Codex app 的這個界面，恰好就在那個時間點成熟了，時機剛剛好。

嘉賓（Alex）：對，Codex 的歷史里其實有過兩次很明顯的“氛圍切換”。

第一次大概是在 8 月。當時我們推出了 Codex 的云端產品。這個想法本身非常好，大家當時很興奮，現在其實也還是很興奮。不過從時間點上看，它有點偏早了。

大概也是在 8 月前后，我們發布了 GPT-5 的交互式編程模型。我們當時的想法是，好，那就先去解決“模型現在已經能解決的問題”。于是我們推出了 Codex CLI 和 IDE 擴展，之后增長就開始爆發。我記得那幾個月里，規模大概漲了 20 到 30 倍，這當然非常棒。

第二次變化則發生在 12 月到 1 月左右。到了那個時候，我們終于可以重新回到最初那個愿景，也就是把工作真正委托給模型去做。

3 我們只做短期和長期規劃，從不做中期規劃

Peter Yang：我們不妨再深入一點聊聊 Codex app 的開發過程。你們當時有沒有那種年度路線圖？比如一年前就已經寫好，“到某個時間點我們要發布 Codex app”？還是說你們更多是看到市場開始往這個方向走，然后做了一堆原型？這個產品到底是怎么做出來的？

嘉賓（Alex）：都不是。其實我之前從 OpenAI 一位研究員 Andre 那里聽到過一個特別好的建議。他跟我說，在 OpenAI，你要么做短期規劃，要么做長期規劃，但不要做中期規劃。

因為中期規劃太難了。所謂短期，通常就是從現在開始到未來八周以內，八周基本已經是上限了。你要想的是，有沒有一個足夠具體的目標，能讓團隊圍繞它真正集結起來，把它做出來。這一點我們在 OpenAI 其實很擅長，就是圍繞一個明確目標把團隊組織起來。

而另一種規劃方式，就是去把握一種更長期的“感覺”。比如你會想，一年以后，模型一定會聰明得多。現在我這么說聽起來已經很顯然了，而且事實上這個變化甚至沒用到一年，但如果回到當時，你可能會這樣想：

未來我們會有非常強的模型，我們不會再想把自己的電腦“借給它們”去做事，因為那樣一次只能做一件事。我們真正想要的，是幾乎無限多個模型同時獨立工作，它們自己驗證結果，甚至自己部署代碼、自己監控運行狀態，可能到最后我們甚至都不需要再一條條去 prompt 它們。

所以你會先去想象這樣一種未來的整體氣質和方向。至于夾在中間的那一層，反而很尷尬。所謂中間層，通常就是產品路線圖，而我們基本上并沒有那種傳統意義上的 roadmap。

我們真正擁有的，是長期方向，以及一些我們認為能把我們推向那個方向的具體事情。比如就 Codex app 來說，我們當時有一個戰略目標，就是讓自己從某個“特定工作區”里解耦出來。

這個說法有點抽象。我具體解釋一下。假設你在用 IDE，比如 VS Code，那也是我最喜歡的 IDE。你打開 VS Code 的時候，通常只能對應一個特定 workspace，也就是某一份具體 checkout 出來的代碼，一整個具體的文件夾。

即便你在用 git worktree，本質上你一次也只能打開其中一個 worktree。所以歸根結底，你一次基本上只能處理一件事。CLI 也是一樣。但因為我們從一開始就有那個愿景，我們希望用戶是和云端那些被他們委托出去、獨立運行的 agents 一起工作的，所以我們知道，產品最終必須走到這樣一個狀態：你同時和多個 agent 對話，甚至只和一個 agent 對話，但這個 agent 背后其實正在替你編排多個 agent，這件事要變得非常自然。

不過我們也學到了一件事：如果你一開始就從云端切入，對開發者來說其實不太容易獲得價值。因為他們常用的工具不在那里，你還得先做環境配置。而且一個任務如果模型只完成了一半，你很難拿到“部分成果”。很多時候，模型做到一半時，你是需要插手去修正方向的，或者稍微撥一撥它。

所以我們就在想，我們需要一種本地體驗，這種體驗要脫離某個特定文件夾的束縛，但同時又要讓你在自己電腦上的各個文件夾之間工作時感覺非常自然。

于是，當我們開始做這個 app 的時候，上面先有一層這種比較抽象、甚至有點玄的方向思考。同時，工程師那邊其實已經有很多原型了，都是各種“我真希望我們已經有個 app 了”的實現。有人做這種版本，有人做那種版本。我們甚至還辦過一次黑客周，當時有好幾個人各自獨立做了不同版本的 app。你可能當時也做過一個，我有點記不清了。

所以，這個項目真正開始的時候，唯一真正需要寫下來的，其實只是我們為什么認為“做一個 app 是個好主意”。至于 app 本身并沒有一份非常具體的 spec。后來當然也逐漸在開發過程中生成了一些文檔，但一開始其實爭議還挺大。

當時大家真的在爭論：我們到底該不該做一個 app？畢竟 IDE 擴展已經非常受歡迎了，我們是不是應該只專注把 IDE 擴展繼續做好？CLI 也很重要，CLI 看起來就是這個領域很核心的東西。那如果我們真的要做 app，意義到底在哪里？它應該走向哪里？這些問題一開始其實都沒有標準答案。

嘉賓（Romain）：不過幸運的是，當時我們的 IDE 擴展已經做得相當成熟了，打磨得很多。你可以在 VS Code、Cursor、Windsurf 等環境里使用它。所以我們其實把 IDE 擴展代碼庫里很多成熟經驗帶了過來，作為一個已經很穩固的起點。

嘉賓（Alex）：對。實際上，app 和 IDE 擴展共享了不少代碼。更準確地說，它就是直接和 IDE 擴展共享同一部分代碼。

而在底層，不管是 app 還是 IDE 擴展，調用的都是同一個 Codex 核心 harness。這個 harness 是用 Rust 寫的，是開源的，CLI 也是基于它。所以這里面有大量共享，也有非?？桃庠O計過的分層結構。

Peter Yang：不過話說回來，現在回頭看，做 app 這件事好像已經很顯然了。畢竟直接用 Codex app，肯定比開一堆終端窗口輕松得多。但在當時，決定去做這個 app，背后的核心理由其實是：它對新手更友好，而且你真的可以像玩一樣去上手。它是同時管理多個 agent 的最佳界面？

嘉賓（Romain）：對。我覺得我們的思考方式一直都非?！癆GI 導向”。我們一直在想，我們正朝著什么樣的未來滑過去。

不過如果調整一下順序，其實更準確的說法是：我們先知道自己必須做出一種界面，讓“把任務委托給多個 agent”這件事顯得非常自然。因為我們知道，模型遲早會準備好支撐這種方式。事實上，我們已經看到有人開始在不同 agent 之間做任務委托了。

所以我們需要一個界面，在里面這種事情必須很自然，而且未來擴展到云端時也要非常順暢。同時整個體驗必須符合人機工學，不能讓用戶覺得自己是在很別扭、很費勁地折騰“如何同時委托多個 agent”，而應該讓人感覺，這本來就該是最自然的工作方式。

嘉賓（Romain）：而且順便說一句，這種體驗吸引的絕不只是初級開發者。恰恰相反，哪怕是在 OpenAI 內部，那些最高產、最資深的工程師，現在也在把 app 當成主要工作方式。比如 Peter，從 OpenClaw 來的，還有 Greg Brockman，他們現在都在主要用這個 app 來構建東西。

所以這件事本質上真的是“agent 式委托”愿景在落地。并不是說最厲害的工程師都會永遠留在終端里，事實上他們也在轉向 app。

嘉賓（Alex）：對，希望如此。我們一直提 Peter，是因為他剛加入 OpenAI，我們真的特別興奮。畢竟他做過 OpenClaw，創造力也非常強。我不知道我之前有沒有跟你說過，去年 10 月的時候，我曾經在舊金山跟他一起散步。

當時我沒有直接告訴他我們在考慮做 app，但我已經開始試探性地聊這種新界面的想法，也就是讓“任務委托”變得更自然的界面。他當時的態度基本上是，他絕對不會用這種東西。

結果到了上周末，他居然在 Twitter 上發，說這個 app 其實挺不錯的。簡直太陽打西邊出來了。他現在居然開始喜歡了。

Peter Yang：我也和 Peter 聊過。如果你們真的讓他開始用 app，那絕對是一個重大成就，因為他平時可是會同時開二十個終端窗口的人。這真的很夸張。Alex，你之前有很長一段時間好像一直是 Codex 唯一的 PM，對吧？那 Codex 團隊現在大概多少人？五十？一百？

嘉賓（Alex）：差不多就在那個范圍吧。大概是這樣。我們去年 5 月的時候好像才八個人左右，是吧？

嘉賓（Romain）：對，差不多。

嘉賓（Alex）：具體數字我現在也記不太清了，但從那之后我們確實增長得非?？?。所以現在大概在五十到一百人之間。

4 模型變強之后，Codex 用 Skill 接管一切

Peter Yang：那你平時一天到底怎么過？你典型的一天是什么樣？還是說根本沒有什么“典型的一天”？

嘉賓（Alex）：有意思的是，我最近也在想這個問題，因為我發現自己其實不太會回答。我后來意識到，我的工作狀態其實會切換到不同模式里。

先說明，這不是給別人的建議，只是我個人的工作方式。比如，在我們發布 app 之前，我就處在一種非常純粹的執行模式里。那種狀態下就是全力盯執行， obsess 質量，確保我們沒有漏看任何角落，把每一個小細節都落下來。

在這種模式里，我其實會花很多時間待在 Codex 里。一方面是因為我們確實會大量用 Codex 來理解當前發生了什么。比如我會用 Codex 去看 Slack，到底大家反饋了什么；我會讓 Codex 把這些內容總結出來，接著跟進，再發到 Linear 里。所以，光是理解當前質量狀態這件事，我們就會大量用 Codex。

另一方面，我也會用 Codex 去理解代碼層面的事情，然后直接用 Codex 做修改。因為現在如果只是一個小改動，而不是重新造一個系統，通常直接讓它幫我做完、我再測試、發一個 PR，往往比我去找別人溝通、再讓對方從一萬件事里給這個任務排優先級要更快。尤其是在我們當時目標是兩周內把 app 發出去的情況下，更是如此。

除了這些之外，當然還有很多非?！叭恕钡牟糠?，比如打氣、動員大家，但同時也要對我們正在做的東西保持批判。所以這是一種我很明確能感知到的工作模式。很有趣的是，如果我處在這種模式里，你會發現我會更常上 Twitter。我也不知道為什么，但只要你問我這種偏社交層面的事情，我通常就會在那段時間更常刷 Twitter。

但我還有另一種模式。比如現在，對我來說一個特別強的感受是，我們已經到了這樣一個階段：模型非常強，GPT-5.4 非常驚人；與此同時，app 這個產品形態也比我們預期的更受歡迎，而且現在我們已經覆蓋了包括 Windows 在內的所有平臺。

所以現在我腦子里的重點就變成，好，該重新回到云端了，我們應該在那邊投入更多。這種階段下，我就會花更多時間去思考“下一步到底該做什么”，去理解整個局面現在是什么狀態。

這更像是一種協調模式。在這種模式里，我反而會少花一些時間在 Codex 里寫代碼，而更多把 Codex 用在溝通上。所以至少對我來說，我能明顯感覺到自己有這兩種模式?？赡苓€不止兩種，但最明顯的至少是這兩類。

Peter Yang：那你平時需要做多少跨職能對齊？

嘉賓（Alex）：Codex 團隊本身非常棒。我們在團隊內部其實做得很少這種跨職能對齊。我們多少有點故意把自己當成一艘“海盜船”式團隊。

哪怕在 Codex 團隊內部，現在也只是我，再加上最近剛加入的兩位 PM，還有幾個 lead。其實直到不久之前，大家基本都是什么都一起扛。我們的工作方式更像是一群人混在一起快速推進，而不是做很多正式對齊。

所以在團隊內部，這種對齊并不多。但現在越來越明顯的一點是，構建 Codex，很大一部分其實是在構建一個 coding agent。而現在大家都已經能看出來了，或者說這件事對所有人來說應該已經很明顯了，coding agent 不只是對寫代碼有用，它對很多其他類型的工作也同樣有用。

我們已經看到很多人用 Codex app 做的不只是寫代碼。他們在整個軟件開發生命周期里的各類任務上都在用。再進一步，現在 OpenAI 里其實絕大多數人都在用 Codex app，甚至不只是技術崗位的人。我在公司里到處都能看到這個 app。

所以，當你意識到 Codex 不只是服務于寫代碼的人，而是要在更廣泛場景里變得有用時，就確實需要更多跨職能對齊了。因為 OpenAI 還有 ChatGPT，而且那是一個被非常非常多人使用的產品，所以我們必須認真思考這件事該怎么做。

嘉賓（Romain）：而從開發者體驗這邊看，我們現在也幾乎已經成了 Codex 團隊的延伸。我們現在大部分精力都放在 Codex 上，但原因有幾個。

一方面當然是因為這是個很令人興奮的產品，而且開發者真的很喜歡用 Codex，我們也會繼續把它做得更好。另一方面，像 Alex 說的那樣，我們自己其實也有不同模式。比如在準備發布的時候，我們會和 Codex 團隊一起沖到最前線，準備發布資產、準備各種材料、思考怎么把 Codex 的價值最大化地呈現出來。等到產品發出去之后，我們又會進入另一種狀態，去教育開發者如何以各種不同方式使用 Codex。

但還有另一層原因，讓這件事對我們來說特別重要。那就是當你把視角放到更大的 OpenAI 平臺上時，你會發現，現在已經有數百萬開發者在基于 OpenAI API 構建東西了。他們在使用模型，也在使用各種不同模態的能力，從圖像生成到 Sora，再到 speech to speech。

而且你知道嗎？現在對開發者來說，最好的構建入口已經變成 Codex 了。如果你把時間撥回到一年前，甚至只是回到去年夏天我們剛推出 GPT-5 的時候，當時我們還需要寫很多很多指南，去教大家怎么 prompt GPT-5。因為它是一個推理模型，和 GPT-4 那種模型差別挺大。

但現在我們的做法已經變了。哪怕是這些使用場景，我們也會盡量教開發者直接使用 Codex 和 skills。比如說，如果你有一個集成需要更新，那你大概率就應該直接用 Codex 配合相應的 skill，而 Codex 通常也確實能幫你把這件事處理掉。

所以從這個角度說，我們的工作也變得非?？缏毮埽驗槲覀円呀洶?Codex 看成整個開發者平臺的基石。

嘉賓（Alex）：還有一點我覺得很有意思，就是我們彼此協作的方式。說真的，我覺得在 Codex 工作最棒的一部分，其實就是社區。包括線上互聯網社區，也包括線下活動里遇到的人。很多事情我們其實都是圍繞這個核心來組織的。

比如我們非常看重發布節奏，什么時候發新東西；也非?？粗胤答仯鐓^什么時候開始給出反饋，我們就盡快修、盡快溝通。所以我們整個團隊都非?！霸诰€”，一直在緊盯社區動向。

就拿 Codex app 的發布來說，當時我們和 Dom 團隊合作得非常緊密。他基本上是在幫我們協調一個范圍相當廣的 alpha 測試，覆蓋了很多用戶。我們是和這些用戶一起做產品，一邊拿反饋，一邊補 skills，一邊完善 app 用到的能力，同時還要準備文檔等等。

所以我覺得，這其實是 Codex 團隊一個很獨特的優勢。歸根結底，還是因為我們是開源的。正因為我們是開源的，很多事情最后就自然演變成，我們對自己在做的事情非常開放。而社區也確實會回報這種開放。

現在我們甚至已經有 Codex ambassadors，分布在很多很多城市和國家，他們會自己組織本地活動，去教各自社區的人怎么用這些東西。我當然很希望自己能去每一座城市，但這顯然不現實。所以看到社區自己這么有能量、這么有熱情，主動去辦活動、辦 hackathon、一起構建東西，真的特別棒。

5 “龍蝦”將被整合進 ChatGPT

Peter Yang：接下來我們聊聊 Peter。我算是 OpenClaw 的早期用戶。它確實有點糙，有點小毛病，但它真的已經幫我做了很多事情。比如前幾天，因為它會記住我們之前的對話，它居然給了我一段大概三分鐘、非常粗魯但又特別提氣的“精神喊話”。說實話，那可能是我從 AI 那里聽過最有洞見的一段話。所以我很好奇，你們現在是怎么把 Peter 整合進團隊里的？還有，這種“個人 agent”的愿景，是不是也屬于他現在在做的事情？你們是怎么理解這件事的？

嘉賓（Alex）：這里面其實有兩層。我能講的范圍有限，不過第一點是，他本身就是 Codex 的超級、超級重度用戶。OpenClaw 本來就是大量基于 Codex 做出來的，所以他現在會不斷給團隊帶來反饋，也會實際上參與很多幫助 Codex 變得更好的工作。某種程度上，這是他的“副業”，但他確實在做，我們也非常興奮。

至于另一部分，我現在還不能說太多。但大方向上，確實是在幫助我們構建下一代個人 agent，而且是把它做進 ChatGPT 里。

嘉賓（Romain）：我覺得 Peter 最讓我著迷的一點是，當然，我認識他已經有一段時間了，而且很多人在第一次玩 OpenClaw 的時候，都已經看到了一點“未來的樣子”。

但真正厲害的地方在于，Peter 很早就看到了這個愿景。如果你回頭看整個 2025 年，他去年做了 40 多個開源項目，但這些項目其實都圍繞同一個愿景展開：我需要一個命令行接口來訪問我的日歷，我需要一個命令行接口來訪問我的推文和 Gmail。

他通過持續做這些項目，實際上把一種愿景具體化了。這個愿景就是圍繞 skills 和命令行工具，把今天我們用于 coding agent 的這套東西搭起來。而未來它顯然不會只停留在 coding agent，它會變成各種類型的個人 agent。

所以，Peter 會非常適合在這個過程中持續給我們反饋，因為這些今天已經進入 open core 生態的工具，本身很多就是他一路親手搭起來的。

Peter Yang：我的感受也是這樣。Romain 說得對，他就一個人，卻搭起了這么一個很棒的開源社區。而且說真的，它已經讓我越來越不想打開別的 app 了。我現在就是直接和我那個小 bot 說話就行，這完全不一樣。

嘉賓（Alex）：等等，你都把它連到什么上了？你是全都接上了嗎？

Peter Yang：差不多吧，我接了很多很多東西。它能看到我的銀行信息、YouTube 信息，還接了語音、日歷、Google 的各種東西。有時候我躺在床上跟它說話，我老婆還會問我你在跟誰講話，我就說，我在跟我的 OpenClaw bot 講話。它會一直給我想法。不過確實，外面現在也有很多人在靠“幫人搭 OpenClaw”收費，開價甚至到 5000 美元。所以如果你們真能把這件事做成面向大眾市場、普通人也能順暢用的產品，那會非常非常大。

嘉賓（Alex）：對，我們正在做。之后再向你匯報。

6 傳統職業階梯，已經越來越說不通了

Peter Yang：好。那我們差不多收個尾，聊點更有火藥味的話題吧，Alex。也許是我記錯了，但我好像見過你說，很多團隊現在其實已經不需要那么多 PM 了。我們把這個問題說得更刺激一點。你怎么看，兄弟？我們到底還需要 PM 嗎？

嘉賓（Romain）：我覺得這些工具最驚人的地方在于，它帶來的變化甚至不只是“需要 PM 還是不需要 PM”這么簡單。

在我看來，幾乎所有職業階梯之間的邊界都開始模糊了。以前會覺得，設計師在這邊，工程師在那邊，PM 在另一邊，然后它們之間可能有某種人數配比，像一種理想結構。

但現在，如果你是工程師，當然你會變得更高效；如果你是設計師，你也突然獲得了一些“超能力”，可以變得更技術化；如果你是 PM，而你以前主要做的是寫戰略文檔，那現在你已經可以直接做原型了。

這并不意味著你一定要負責那個面向十億用戶的功能，但你完全可以通過“親手做出來”的方式，把那個愿景的一個切片展示給團隊看。所以我覺得最迷人的地方就在這里，所有職業階梯之間的線都在變模糊，而我們都正在變成 builder。

嘉賓（Alex）：這個我很有共鳴。我試著回憶一下我到底說過什么。我印象里，好像我在網上說過一句，大意是如果一家創業公司工程師還不到 20 個，卻已經配了 PM，那可能是個危險信號。

但我想表達的，其實和你剛才說的很像?，F在所有角色的邊界都在混在一起。設計師可以做更多工程工作，工程師可以做更多設計，PM 也可以做更多構建工作。

而且過去很多工程師之所以不去做任務分診、項目管理這類 PM 工作，很大程度上只是因為他們必須把時間花在寫代碼上。可現在寫代碼已經容易多了，你完全可以讓像 Codex 這樣的 agent 去分析反饋、做優先級排序，這樣一來，每個人都會多出更多時間。

所以我覺得，現在大家某種程度上都能做彼此的一部分工作。Scott Belsky 不是有個說法叫“人才棧坍縮”嗎？我很喜歡這個說法，我覺得它確實正在發生。

我一直有一個很強的看法，就是做任何事情時，房間里需要的人越少，事情通常就做得越好，決策也越純粹。

那接下來的問題就是，既然如此，PM 還剩下什么？我覺得，很多 PM 其實應該轉型。比如說，如果你是個 PM，但你骨子里一直更想當工程師，只是以前也許你很擅長協調人，但工程能力還不夠強，那現在也許你就該直接去做工程經理。因為有 coding agent 在，這件事完全可以成立，而且對你來說，這可能反而是一個更干凈、更自然的角色。

同樣的邏輯也適用于另外一種 PM，也許他其實更想做設計，那現在也許就該更靠近設計、更靠近構建。但說到底，我覺得最關鍵的還是興趣。興趣和主動性，可能是 AGI 時代對人來說最根本、最重要的兩種品質。

所以我最后其實會把問題想得很簡單。如果你骨子里就是更喜歡寫代碼，只是因為“總得有人做 PM”你才做了 PM，那現在你就應該把原來的自己刪掉，直接變成工程師，用工程師的方式做同樣的事。設計也一樣。

但如果你真正最感興趣的，是大量和用戶待在一起，哪怕這會讓你離構建稍微遠一點，或者你特別喜歡去提前觀察市場、看未來會往哪走，那在一個足夠大的團隊里，如果工程師已經夠多了，我覺得 PM 這個角色依然可能有空間。不過歸根結底，還是要看你到底最想做什么。

再補一句，我仍然認為每個問題域都需要一個真正對它負責的人類，但我不再認為那個人一定非得是 PM。

Peter Yang：我在自己團隊里也有同樣感受。我覺得最好的工程師，從來不會跑來問我“Peter，我們下一步做什么”，他們會自己去和用戶聊天，自己搞清楚該做什么，然后再回來跟我討論。感覺現在很多團隊都在往這個方向走，大家其實都在同一頁上。Codex 團隊應該也很像這樣吧？

嘉賓（Romain&Alex）：今天大家在 Codex app 里用到的很多功能，應該都是工程師自己從下往上提出來的，因為他們自己就想要這個功能。確實有很多是這樣來的。不過我也想說，我非常喜歡合作的一種工程師畫像，是那種特別喜歡和用戶待在一起、喜歡思考該做什么的人。

但與此同時，也有另外一種同樣極其強的工程師畫像，他們快得驚人，搭系統特別強，思考也特別透徹，但對和用戶聊天這件事完全沒興趣。我覺得這種人當然也同樣有很大空間。

這也正是我對 AI 世界的一個基本看法。我們每個人都可以變得更“徹底做自己”。你明白我的意思嗎？就是，你就做你自己。AI 和你身邊的團隊，會把那些你不想做的部分補上。

Peter Yang：這個說法真好。不過我還是覺得，“builder”這個標簽非常重要。因為我感覺每個 PM 都被默認期待去當 leader，而傳統職業階梯的邏輯就是，你最后要變成 VP 之類的人，然后你就再也沒有時間親手做東西了。你每天都在參加產品評審，一整天只是給一點這個反饋、給一點那個反饋。我覺得很多 PM 其實并不想變成那樣。至少我自己不想。我更想在產品真的發布的時候，依然離用戶很近。

嘉賓（Alex）：完全同意。說實話，我其實從來不把 PM 看成一個領導崗位。我更愿意把它理解成一個“填補空白”的崗位。有時候這個角色確實會需要一些領導力，但即便如此，那種領導力更多也只是幫助大家對齊，而不是說你是那個天才戰略家，提出了唯一正確的方向。

不過有一件事我可以很確定地說，OpenAI 最好的 PM 都非常非常深入一線。也正因為如此，如果你是以一個資深領導崗位的身份加入 OpenAI，其實會很有挑戰，因為這里依然非常需要你深入細節。

所以你得同時找到一種方式，一邊承擔高層職責，一邊還能真的下沉到一線。我個人會覺得，在這里最好的加入方式，永遠還是直接下到一線。

7 Codex 團隊招人時到底看什么？看的不是你的簡歷

Peter Yang：最后最后一個問題。你們終于又招了一個 PM，那你們在招 Codex 團隊成員的時候，除了要求他本身就是 Codex 的重度用戶之外，還會看重哪些特質？你們到底在找什么樣的人？

嘉賓（Alex）：這個問題我們倆都可以答。我先說吧。其實我前面已經講過一次了，我還是會回到那個詞上：主動性。

說到底，“會主動做事的人”就是最重要的，放在 OpenAI 是這樣，放在 Codex 團隊尤其如此。我們是有意不把團隊做成那種你一加入，就有人跟你說：“來，這是 12 個任務，難度逐級遞增，你按順序做吧”的地方。在這里更像是，你來了。好，歡迎加入。就這樣，結束了。接下來就看你自己了。

所以我特別看重那種會自我啟動、會主動做事、有能量、腦子里有想法，知道哪些事情值得推進的人。還有一種特質也很重要，就是他們不會因為現有想法已經存在，就不敢提出不同意見。因為說實話，我們現在很多已有決策，可能本來就是在某些偶然情況下做出來的，它們大概率本來也未必是對的。

再往理想化一點說，如果一個人能夠主動吸收那些額外出現的職責范圍，能夠愿意去接那些本來還不明確、還沒定義清楚的責任，我會覺得這幾乎就是完美隊友了。

所以這大概是我認為最核心、最上層的一些標準。如果你只是問，什么角色在這里最合適，那我的回答基本還是，任何偏技術的角色，尤其工程方向。

嘉賓（Romain）：我同意。對我這邊，也就是 developer experience 這塊來說，我通常在找的也是高主動性的人，當然還得非常技術化，最好本身就很會用像 Codex 這樣的工具。

但除此之外，我還特別看重一種熱情，就是你是不是發自內心地愿意花時間和開發者、和 builder 待在一起，并且愿意分享自己的知識和經驗。

比如這周我們剛剛宣布，Thomas 要在這個月加入我的團隊。他就是那個做了開源 Codex Monitor 的人。這件事讓我很高興，因為他是那種非常有創造力、非常高產、也特別會用 Codex 的人，但同時他也很喜歡分享自己到底是怎么用 Codex 構建東西的。

而我們真正想做的，其實是把數百萬開發者一起帶進 Codex 所代表的這個新未來。我覺得，agentic coding 正在徹底改變我們過去一直以來對軟件、應用和產品構建方式的理解。

這里面有太多潛力，可以向全世界展示一件事：任何人都可以構建任何東西，而且我們可以一路教他們怎么做到。所以，這大概就是我在找的人。

嘉賓（Alex）：你看看我理解得對不對。在我腦子里，DevX 這個崗位的定義差不多就是：一個非常強的工程師，同時還特別會玩 Twitter。

嘉賓（Romain）：你說對了一半，另一半我得加個星號。這里所謂“會玩 Twitter”，更準確地說，其實是“擅長和我們的社區溝通”。

因為你如果去世界上一些地方，就會發現很多開發者根本沒那么常用 Twitter。比如在歐洲，還有一些其他地區，大家更多用 LinkedIn，或者別的平臺。所以我們得稍微補充一句，這里真正重要的是，你得在全球范圍內都能把社交溝通這件事做好。

所以可以概括成：一定得擅長社交媒體。這點肯定是重要的。我自己也真的很喜歡花時間去教學、去做教育性的事情。

Peter Yang：而且我感覺，一個人有沒有主動性，其實在正式面試之前就已經能看出來了，對吧？比如他有沒有一直在網上發布東西，有沒有 side project。

嘉賓（Alex）：完全是這樣。所以如果有人私信我，說有興趣一起合作，我第一反應其實是：里面有沒有鏈接？只要有鏈接，我基本都會點。

當然，我可能會先看一眼這鏈接是不是很離譜，但說實話，我幾乎都會點。我就是會很好奇。然后如果他在消息里順手附了一段自己的想法，我通常也都會認真看。

至于接下來這句話聽起來會不會有點刻薄，我也不確定，但如果對方發來的是一大段“為什么我對這個崗位感興趣”的說明，再附上一份簡歷，那這種內容我反而比起“他的想法”和“他做過什么”要少看得多。我真正更想看的，是你想了什么，你做了什么。

而且前幾天還有人問我這個問題，我那時候才突然意識到，我根本不知道很多人是從哪所大學畢業的。

Peter Yang：誰在乎啊，真的。誰在乎這些。我其實很高興我們活在這樣一個時代，很多過去那種很蠢的 credential 已經沒那么重要了。誰在乎名校，誰在乎學歷。你直接給我看你做了什么就行。

https://www.youtube.com/watch?v=9qXc-THAvc0

聲明：本文為 InfoQ 翻譯整理，不代表平臺觀點，未經許可禁止轉載。

會議推薦

QCon 全球軟件開發大會·2026 北京站將于 4 月 16 日 -18 日正式舉辦。本屆大會以“Agentic AI 時代的軟件工程重塑”為主題，聚焦 100+ 重磅議題，匯聚來自阿里、騰訊、字節跳動、小米、百度等一線科技企業與創新團隊的技術專家，圍繞 AI 工程化、系統架構與研發模式演進展開深入探討。更多詳情可掃碼或聯系票務經理 18514549229 進行咨詢。