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

這種變化，和模型能力抬升有很大關(guān)系。前幾年，大家還在反復(fù)研究 Prompt，也在努力把 spec 寫得更完整、更結(jié)構(gòu)化，希望模型能更穩(wěn)定地照著執(zhí)行。現(xiàn)在，Codex 團隊討論得更多的是 skills。他們開始把常見任務(wù)整理成一組組可以直接調(diào)用的能力，再交給模型去跑。

于是，spec 不再占據(jù)最前排的位置，skill 正在變成新的入口，開發(fā)這件事本身，也在從"描述過程"轉(zhuǎn)向"組織能力"。

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

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

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

Peter Yang：我其實很好奇，你們團隊內(nèi)部到底是怎么用 Codex 做產(chǎn)品開發(fā)的。Alex，你們現(xiàn)在還寫 spec 嗎？還是說已經(jīng)讓 GPT 來幫你寫 spec 了？一般會怎么做，用什么模型？

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

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

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

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

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

假設(shè)現(xiàn)在已經(jīng)快完成一個任務(wù)了，然后你腦子里開始冒出一些新功能的想法，但你自己也不完全確定下一步應(yīng)該往哪里走。

這個時候，用 Codex 很有意思的一點在于，如果我現(xiàn)在開始說"我們來規(guī)劃接下來的步驟吧"，你會發(fā)現(xiàn) Codex 能自動理解，我現(xiàn)在是在試圖為接下來要構(gòu)建的內(nèi)容做計劃。如果我按一下 Shift+Tab，它就會進入 plan mode。然后如果我說，"我們接下來應(yīng)該做什么？"我就可以把 Codex 當(dāng)成一個 brainstorming partner，一起規(guī)劃下一步。

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

所以你現(xiàn)在可以看到，它已經(jīng)開始基于項目現(xiàn)狀、代碼和文件內(nèi)容，自己生成一些主意。

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

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

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

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

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

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

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

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

而在這之后，另一個同樣關(guān)鍵的問題就是，我們怎么確保最后出來的東西是高質(zhì)量的。現(xiàn)在有些人會很驕傲地說，整個 app 都是 vibe coded 出來的。對 Codex 來說，其實絕大多數(shù)代碼也確實是 agent 生成的。但即便如此，我們?nèi)匀换撕芏嗑妥⒁饬θニ伎枷到y(tǒng)本身，去確保它真的有很高的質(zhì)量。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

我們真正擁有的，是長期方向，以及一些我們認為能把我們推向那個方向的具體事情。比如就 Codex app 來說，我們當(dāng)時有一個戰(zhàn)略目標(biāo)，就是讓自己從某個"特定工作區(qū)"里解耦出來。

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

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

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

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

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

所以，這個項目真正開始的時候，唯一真正需要寫下來的，其實只是我們?yōu)槭裁凑J為"做一個 app 是個好主意"。至于 app 本身并沒有一份非常具體的 spec。后來當(dāng)然也逐漸在開發(fā)過程中生成了一些文檔，但一開始其實爭議還挺大。

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

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

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

而在底層，不管是 app 還是 IDE 擴展，調(diào)用的都是同一個 Codex 核心 harness。這個 harness 是用 Rust 寫的，是開源的，CLI 也是基于它。所以這里面有大量共享，也有非常刻意設(shè)計過的分層結(jié)構(gòu)。

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

嘉賓（Romain）：對。我覺得我們的思考方式一直都非常"AGI 導(dǎo)向"。我們一直在想，我們正朝著什么樣的未來滑過去。

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

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