OpenAI 的Codex是目前全球最受歡迎、也最強(qiáng)大的 AI 編程智能體之一。自 8 月以來，Codex 的規(guī)模增長了 20 倍，目前每周處理數(shù)萬億個 Token。

Alexander Embiricos是Codex 的產(chǎn)品負(fù)責(zé)人，在這次深度對話中，Alex 不僅揭秘了 OpenAI 內(nèi)部獨特的產(chǎn)品開發(fā)文化，還分享了許多鮮為人知的硬核細(xì)節(jié)：Codex 如何在短短幾個月內(nèi)實現(xiàn) 20 倍增長？Sora 團(tuán)隊如何僅憑2人在 28 天內(nèi)從零打造出Sora的Android 應(yīng)用？以及為什么說阻礙 AGI 到來的最大限制，其實是我們?nèi)祟愖约旱拇蜃炙俣龋?/strong>

Alexander Embiricos的7個“頂級思維時刻”：

1、OpenAI 的組織架構(gòu)非常反直覺，它是絕對的自下而上。在傳統(tǒng)公司，通常是“預(yù)備——瞄準(zhǔn)——開火”，大家要先確立方向再執(zhí)行。但在 OpenAI，我們更傾向于“實證學(xué)習(xí)”——快速發(fā)布產(chǎn)品，看什么管用，然后再根據(jù)反饋調(diào)整。

2、目前的 AI 產(chǎn)品其實很難用，因為你必須時刻想著“這時候我該怎么提示 AI 來幫我”。這就像你雇了個隊友，但他只會等你下指令。我們希望未來的 Codex 能夠具備主動性。它能像一個成熟的同事一樣，理解你的意圖，主動提出建議，甚至在你沒開口前就幫你解決問題。

3、AGI 到來的標(biāo)志，并不是模型變得多聰明，而是生產(chǎn)力曲線出現(xiàn)“曲棍球棒”式的陡峭增長。從這個角度看，目前的限制因素并不是模型能力，而是一個被嚴(yán)重低估的瓶頸：人類的打字速度和多任務(wù)處理能力。

4、現(xiàn)在的模式是：人類寫提示詞——AI 寫代碼 ——人類審查代碼。AI 產(chǎn)出代碼的速度已經(jīng)遠(yuǎn)超人類閱讀和審查代碼的速度。這種人工審查的環(huán)節(jié)成了最大的堵點。

5、為了讓智能體能夠操作計算機(jī)，最好的方式可能就是讓它們寫代碼。

6、未來的工程師更像是 AI 隊友的管理者。你需要學(xué)會如何配置你的 AI，讓它能自我驗證、自我修復(fù)。

7、未來，即使是非技術(shù)用戶使用的 AI 助理，其底層可能都是在運行即時生成的代碼。如果你想構(gòu)建任何類型的 Agent，你首先應(yīng)該構(gòu)建一個 Coding Agent。

今天這篇文章，希望對你有所啟發(fā)~

01

OpenAI 的速度與野心： 自下而上的“實證主義”

問：你加入 OpenAI 大約一年了，之前你自己創(chuàng)業(yè)，也在 Dropbox 工作過。OpenAI 和其他地方最大的不同是什么？

Alexander Embiricos：絕對是速度和野心。作為一個曾經(jīng)的創(chuàng)業(yè)者，這話聽起來可能有點尷尬，但我以前覺得自己的公司已經(jīng)夠快、夠有野心了，但加入 OpenAI 后，我不得不重新定義這兩個詞。

在這里，我們不僅要面對技術(shù)的指數(shù)級進(jìn)步，還要應(yīng)對產(chǎn)品的爆發(fā)式增長。比如 Codex，自從GPT-5發(fā)布以來，我們的規(guī)模在短短幾個月內(nèi)增長了20 倍。這種速度迫使我必須極其“無情”地管理自己的時間。

問：這種速度是如何實現(xiàn)的？是組織架構(gòu)的原因嗎？

Alexander Embiricos：OpenAI 的組織架構(gòu)非常反直覺，它是絕對的自下而上。

在傳統(tǒng)公司，通常是“預(yù)備——瞄準(zhǔn)——開火”，大家要先確立方向再執(zhí)行。但在 OpenAI，因為我們經(jīng)常不知道下一周會出現(xiàn)什么模型能力，也不知道什么技術(shù)能真正落地，所以我們的“瞄準(zhǔn)”非常模糊。我們更傾向于“實證學(xué)習(xí)”——快速發(fā)布產(chǎn)品，看什么管用，然后再根據(jù)反饋調(diào)整。

我們對一年后的未來有大致的愿景（比如 AGI 的安全性），但在戰(zhàn)術(shù)層面，我們非常依賴即時反饋。這種模式能運行的前提是：你必須擁有世界上最頂尖的人才，每個人都具備極強(qiáng)的自我驅(qū)動力。

02

Codex 的本質(zhì)： 不僅僅是代碼補全

問：很多人可能還分不清 Codex 和 GitHub Copilot 或 Cursor 的區(qū)別。Codex 到底是什么？

Alexander Embiricos：Codex 是 OpenAI 的編程智能體（Coding Agent）。你可以把它想象成一個非常聰明、但不僅會寫代碼的實習(xí)生。

目前的 AI 編程工具大多只是 IDE 里的插件，幫你補全代碼。但我們的愿景是打造一個真正的軟件工程師隊友（Software Engineering Teammate）。這個隊友不僅能寫代碼，還能參與早期的創(chuàng)意規(guī)劃、后期的代碼驗證和部署。

問：這是一個非常不同的愿景。

Alexander Embiricos：是的。目前的 AI 產(chǎn)品其實很難用，因為你必須時刻想著“這時候我該怎么提示 AI 來幫我”。這就像你雇了個隊友，但他只會等你下指令，甚至不看 Slack，也不檢查 Datadog（監(jiān)控工具）。

我們希望未來的 Codex 能夠具備主動性。它能像一個成熟的同事一樣，理解你的意圖，主動提出建議，甚至在你沒開口前就幫你解決問題。

03

增長爆發(fā)的秘密與“壓縮”技術(shù)

問：Codex 最近增長了 20 倍，這是怎么做到的？

Alexander Embiricos：我們做了一個關(guān)鍵的產(chǎn)品決策。最初的 Codex Cloud 版本非常超前，它是一個完全在云端運行的智能體。雖然愿景很美好，但配置環(huán)境和改變用戶習(xí)慣太難了。

我們意識到，要讓用戶接受這個“云端隊友”，首先得讓他能輕松上手。于是我們推出了本地化版本，直接集成在 IDE 和終端里，讓它在一個安全的沙箱環(huán)境中運行。這種“從用戶現(xiàn)有工作流切入”的策略，極大地降低了門檻，引爆了增長。

問：除了產(chǎn)品策略，技術(shù)層面有什么突破嗎？比如更長的時間、更復(fù)雜的任務(wù)？

Alexander Embiricos：是的，我們發(fā)布了GPT-5.1 Codex Max，不僅速度提升了 30%，更重要的是我們解決了一個核心技術(shù)難題——如何讓模型長時間連續(xù)工作。

現(xiàn)在的用戶經(jīng)常讓 Codex 連續(xù)運行 24 小時來解決復(fù)雜任務(wù)，這會導(dǎo)致上下文窗口（Context Window）爆滿。為了解決這個問題，我們開發(fā)了一項名為“壓縮（Compaction）”的技術(shù)。

Compaction 是一項跨越三層架構(gòu)的復(fù)雜工程：

1. 模型層（Model）：模型本身需要理解“壓縮”的概念。當(dāng)上下文快滿時，它知道需要對之前的狀態(tài)進(jìn)行摘要和清理。

2. API 層：API 需要支持這種動態(tài)的上下文切換和狀態(tài)保存。

3. 宿主環(huán)境層（Harness）：我們運行 Codex 的環(huán)境需要能夠?qū)崟r準(zhǔn)備和調(diào)整輸入給模型的負(fù)載。

只有當(dāng)這三層緊密配合，AI 才能像人類一樣“忘記”無關(guān)的細(xì)節(jié)，只記住關(guān)鍵的上下文，從而實現(xiàn)長時間的持續(xù)工作。這也是為什么我們在 OpenAI 堅持將產(chǎn)品團(tuán)隊和研究團(tuán)隊緊密整合的原因。

04

28天奇跡： Sora Android 應(yīng)用的開發(fā)

問：聽說 Sora 的 App 也是 Codex 幫忙開發(fā)的？

Alexander Embiricos：沒錯，這是我見過的最震撼的加速案例。

Sora 的 Android 應(yīng)用是一個全新的項目。在 Codex 的幫助下，我們僅用了18 天就完成了內(nèi)部測試版，再過10 天就正式公開發(fā)布了。總共只用了 28 天。

問：而且這個 App 上線后迅速成為了 App Store 的第一名。這太瘋狂了，團(tuán)隊有多少人？

Alexander Embiricos：只有2 到 3 名工程師。

這也是 Codex 最擅長的場景之一：代碼移植與復(fù)刻。因為我們已經(jīng)有了 iOS 版本，工程師讓 Codex 去閱讀 iOS 的代碼庫，分析邏輯，然后制定移植計劃并生成 Android 代碼。因為有現(xiàn)成的參考系，AI 的表現(xiàn)簡直是“開了掛”。

05

PM 的新工作流與“一次性代碼”

問：AI 不僅改變了工程師，它對產(chǎn)品經(jīng)理（PM）和設(shè)計師有什么影響？

Alexander Embiricos：它的影響是顛覆性的，我們在見證“人才棧的壓縮”（Compressing the talent stack）。

以前需要跨職能溝通的事情，現(xiàn)在一個人就能搞定。

• 一次性代碼（Throwaway Code）的興起：以前我想分析數(shù)據(jù)，需要找數(shù)據(jù)分析師?，F(xiàn)在我直接把數(shù)據(jù)丟給 Codex，讓它寫一個臨時的交互式數(shù)據(jù)查看器。用完就扔，但這極大地加速了決策。

• 設(shè)計師即工程師：我們的設(shè)計師想做一個復(fù)雜的硬幣動畫，手寫代碼太難了。于是他讓 Codex 寫了一個“動畫編輯器”，用這個編輯器調(diào)好了動畫，再生成最終代碼注入到倉庫里。這就是我們所說的“氛圍編程（Vibe Coding）”。

現(xiàn)在，我們的產(chǎn)品營銷經(jīng)理甚至直接在 Slack 里用 Codex 修改文檔和代碼字符串。界限正在消失。

06

為什么要開發(fā) Atlas 瀏覽器？

問：你們還發(fā)布了一個叫Atlas的瀏覽器。為什么要涉足瀏覽器領(lǐng)域？

Alexander Embiricos：這源于我們對“上下文（Context）”的執(zhí)著。

如果 AI 要成為真正的隊友，它必須知道你在做什么。現(xiàn)在的 AI 助手往往需要你把上下文復(fù)制粘貼給它，這太低效了。瀏覽器是大多數(shù)工作的發(fā)生地。

通過構(gòu)建 Atlas，我們不需要去 Hack 操作系統(tǒng)或依賴不穩(wěn)定的截圖技術(shù)，我們可以直接在渲染引擎層面理解用戶看到的內(nèi)容。

這就好比玩游戲時，你走到一個物體面前按“X”鍵，游戲會自動根據(jù)上下文做出正確的反應(yīng)（開門、撿槍等）。我們希望 Atlas 能實現(xiàn)這種“上下文行動（Contextual Action）”——當(dāng)你看著數(shù)據(jù)儀表盤發(fā)愁時，AI 能自動分析出為什么指標(biāo)下跌了，而不需要你專門去問它。

07

AGI 的真正瓶頸：人類的手速

問：作為一個在 OpenAI 工作的人，我必須問這個問題：你覺得我們離 AGI 還有多遠(yuǎn)？

Alexander Embiricos：我不從時間的角度看，我從“加速曲線”的角度看。我覺得目前的限制因素并不是模型能力，而是一個被嚴(yán)重低估的瓶頸：人類的打字速度和多任務(wù)處理能力。

Lenny：這個觀點太獨特了。

Alexander Embiricos：現(xiàn)在的模式是：人類寫提示詞 -> AI 寫代碼 -> 人類審查代碼。AI 產(chǎn)出代碼的速度已經(jīng)遠(yuǎn)超人類閱讀和審查代碼的速度。這種“人工審查”的環(huán)節(jié)成了最大的堵點。

所以，AGI 到來的標(biāo)志，并不是模型變得多聰明，而是生產(chǎn)力曲線出現(xiàn)“曲棍球棒”式的陡峭增長。這需要我們解決“審查瓶頸”，讓 AI 學(xué)會自我驗證，讓人類只需要在關(guān)鍵節(jié)點把關(guān)，而不是逐行檢查代碼。

08

未來的 AI 智能體：萬物皆代碼

問：你對未來的 AI 智能體（Agents）有什么看法？

Alexander Embiricos：我有一個大膽的觀點：為了讓智能體能夠操作計算機(jī)，最好的方式可能就是讓它們寫代碼。

現(xiàn)在很多人試圖讓 AI 像人一樣通過點擊鼠標(biāo)、識別圖像來操作電腦，這效率很低且不穩(wěn)定。代碼是目前人機(jī)交互最精確、最可組合的語言。

未來，即使是非技術(shù)用戶使用的 AI 助理（比如幫你訂票、分析財報），其底層可能都是在運行即時生成的代碼。如果你想構(gòu)建任何類型的 Agent，你首先應(yīng)該構(gòu)建一個 Coding Agent。

09

給年輕人的建議：還要學(xué)編程嗎？

問：在 AI 如此強(qiáng)大的今天，年輕人還需要學(xué)編程嗎？

Alexander Embiricos：絕對需要，但學(xué)習(xí)的重點變了。

1. 做一個實干家：有了 AI 的加持，一個初級工程師現(xiàn)在的產(chǎn)出能力可能相當(dāng)于以前的高級工程師。不要只滿足于完成作業(yè)，去構(gòu)建真實的產(chǎn)品。

2. 系統(tǒng)思維至上：具體的語法細(xì)節(jié)（比如怎么寫個循環(huán)）確實不重要了，但理解系統(tǒng)架構(gòu)、理解模塊間的通信、理解什么是好的軟件設(shè)計，這些依然至關(guān)重要。

3. 成為 AI 的“配置者”：未來的工程師更像是 AI 隊友的管理者。你需要學(xué)會如何配置你的 AI，讓它能自我驗證、自我修復(fù)。