OpenAI Codex 產品負責人Alexander Embiricos 最新訪談
OpenAI內部開發流程發生根本性轉變，Embiricos透露 OpenAI 的工程師們如今基本上不再打開編輯器了，工作模式已從與 AI 結對程式設計全面轉向任務委託；他首次披露了 OpenAI 一個看似矛盾的商業策略——透過建立 agents.md 等開放標準，並將其最先進的模型提供給直接競爭對手，從而玩一場關於智能分發的更宏大遊戲
以下是這次訪談中一些你可能感興趣的點
1. AI 會自動化程式設計嗎？一個關於Computer一詞的詞源的回答
當被問及是否同意馬斯克「編程將是首批被大規模自動化的職業之一」的論斷時，Embiricos 給予了肯定的答覆，但附帶了一個歷史注腳。
「我完全同意，程式設計是大型語言模型表現出色的首批領域之一，但程式設計被自動化究竟意味著什麼？」
為了解釋他的觀點，他邀請聽眾進行一次思想實驗，回到程式設計語言演進的早期。「例如，當我們不再編寫組合語言，轉向更高級的語言時，我們說過程式設計被自動化了嗎？並沒有。」他指出，「我們只是能夠編寫多得多的程式碼，结果是對程式碼的需求反而激增，需要更多的軟體工程師。」
他進一步追溯了Computer這個词的起源。在解碼德國「恩尼格瑪」密碼機的布萊切利園（Bletchley Park），最初的Computer指的是一群從事計算工作的人類，他們手動打孔、操作機器、進行表格計算。同樣，最早的試算表軟體的設計靈感，也來自於一個辦公室裡坐滿員工，像網格一樣排列，每個人完成自己的計算，再把結果遞給下一個人。
「所有這些具體的任務都已經被自動化了，」Embiricos 總結道，「但每一次這樣的自動化發生，對最終產出的需求都會迎來一次爆炸性增長。结果是你實際上需要更多的人來做這類工作，即使具體的任務內容已經改變。」
基於此，他給出了一個與直覺相反的預測：「我認為五年後我們會有更多的工程師，而不是更少。」
2. 人才棧的壓縮：工程師、設計師與（或許不再需要的）PM 的未來
Embiricos 認為，未來的變化不僅在於工程師數量的增減，更在於工作角色的融合與定義。
「我們有時會改變詞語的含義，就像Computer這個词現在指代的是機器一樣，」他說，現在我們有了軟體工程師這個词，我堅信未來會有更多的『構建者』（Builders）。」
他觀察到的一個核心趨勢是「人才棧的壓縮」（Compression of the Talent Stack）。「在過去，你有很多分工明確的崗位，比如後端工程師和前端工程師。但現在，至少在我們的 Codex 團隊裡，這種情況已經少了很多，大家的工作都變得更加全棧。」
這種壓縮意味著，未來的工程師可能是一個集設計、產品思維和編碼能力於一身的超級個體。當你提到工程師時，你可能想是一個比以往任何時候都更加全能的人。」Embiricos 解釋道。
而對於他自己所处的 PM角色，他則半開玩笑地表達了悲觀的看法。「我傾向於認為 PM 這個角色實際上是被人為地未定義的，你的目標就是適應團隊或業務的任何需求。」他坦言，一個優秀的產品經理可以幫助團隊退後幾步，預見未來的風險，成為團隊最棒的啦啦隊長和質量把關人。但所有這些我剛才描述的事情，一個強大的工程負責人或一個懂產品的設計師也完全可以做到。
3. 通往 AGI 的真正瓶頸：人類的懶惰與想像力
談話轉向了一個更為宏大的話題：AGI 的瓶頸。Embiricos 拋出了一個觀點：「人類的打字速度和驗證工作是通往 AGI 的關鍵瓶頸，而不是模型算力或架構。」
為了證明這一點，他進行了一次簡單的現場互動。「你今天大概會用多少次 AI？」他問道。當得到30多次的回覆後，他緊接著追問：「那假設對你來說是零成本的，你認為 AI 每天能幫你多少次？」
答案是顯而易見的：幾乎是無限次，AI 可以全天候地在每一件事上運行。「我听到 OpenAI 內外的工程師說，『我一直讓 Codex 運行著，如果開會時它沒在工作，我就是在浪費時間。』」Embiricos 分享道，「這非常酷，但也需要大量精力去管理這些智能體。」
這就是問題的核心。「即使是我自己，我知道我應該在所有事情上使用 AI，但我太懶了，懶得去輸入那麼多提示詞，我的創造力也有限，想不出所有 AI 能幫我的方式。」他說，「我認為 AI 應該每天幫助我們成千上萬次，但我們不應該期望大多數人為了從 AGI 中受益，而需要花費如此多的精力去學習如何使用這個工具。它應該是不費力的。」
他認為，理想的未來是，使用 AI 不再需要絞盡腦汁地想出完美的提示詞，AI 應該能主動連接到你上下文並適時地提供幫助。
4. 個體賦能 vs 企業級自動化
Embiricos 強調，實現 AI 普惠的最佳路徑是為個體構建工具，而非自上而下的企業級自動化。這一觀點立即引發了關於企業落地現實問題的討論，尤其是數據安全、權限管理和對現場實施工程師的依賴。
「如果你試圖一步到位，實現某個宏大的工作流自動化系統，那你必然要處理所有這些安全和合規的障礙。」他承認道，「你需要現場實施工程師去打通所有數據系統。但我的觀察是，當我們自上而下地做這些事時，最終會極大地低估 AI 幫助這家公司的潛力。」
他提倡一種雙軌並行的策略。「你可以一邊進行企業級的部署，但同時，你必須把 AI 交到那些真正在一線工作的人手中。」他using一個例子來闡述：「想像一下，你是一名客服，AI 正在自動化你工作中相當一部分內容，但你從未聽說過 ChatGPT，也不被允許使用它。在這種情況下，你對這個東西沒有任何直覺。反之，如果在使用公司自動化工具的同時，你個人也一直在工作中使用 ChatGPT，你就會對它的工作原理有更深的理解，你會感覺自己更有掌控力，更能引導自動化的方向，而不是感覺它像一個完全不可控的天外來物。」
他進一步指出，所有企業軟體最終都會彙集到個體使用者的操作界面上。「無論如何，一切最終都會落到一個運行在你本地電腦上的智能體可以與之交談的界面上，比如你的瀏覽器或文件系統。」他隨後透露了一個關鍵信息：「這就是為什麼 OpenAI 正在構建我們自己的瀏覽器『Atlas』。透過端到端地嚴格控制，我們可以為企業提供安全的、智能體化的瀏覽體驗，這是一種在现场實施工程師尚未完成全面部署前，就能以智能體方式訪問各種系統的途徑。」
5. 智能體開發的三階段
那麼，如何跨越這個人類瓶頸？Embiricos 提出了一個三階段發展路徑。
第一階段：精通軟體工程。 「首先，讓智能體在軟體工程和編碼領域表現出色，因為 LLMs 正好擅長這個。」這是當前正在發生的階段，為智能體打下堅實的基礎。
第二階段：賦能探索者。 「接下來，我們要認識到，讓一個智能體變得更通用，使用電腦是其核心能力，而編碼是智能體使用電腦的最佳方式。」他解釋說，這意味著要將為工程師打造的靈活工具，開放給任何願意探索和修補的非編碼人員。「我們已經看到有人用 Codex 應用來處理各種非編碼任務了。」這個階段的核心是，不為特定工作流過度封裝產品，而是提供一個開放的工具，讓早期用戶去創造性地發現它的用途。
第三階段：無縫產品化。 「最後，一旦我們看到哪些用法是有效的，我們就可以構建你所說的那種高度產品化的體驗。」在這個階段，AI 功能將被封裝成針對特定場景、開箱即用的產品，普通用戶無需任何學習成本就能直接受益。
「我認為，我們將在未來幾個月內，以極快的速度跑完這整個一、二、三階段的旅程。」他預測道。
6. GPT-5.2 Codex 如何改變了 OpenAI 的一切
Embiricos 詳細描述了 OpenAI 內部工作流程的一次階躍式變革，這次變革的催化劑是 GPT-5.2 Codex 的發布。
「在 GPT-5.2 Codex 之前，我們使用的 AI 編程功能主要是像 Tab 自動補全，或者與模型進行『結對編程』（Pair Programming）。」他回憶道，「在那種模式下，你仍然需要坐在電腦前，手放在鍵盤上，AI 只是幫你處理一些小任務。」
然而，從去年 12 月的 GPT-5.2 Codex 開始，一切都變了。「我們突然切換到了一個全新的模式：我可以直接將整個任務完全委託給它。我會和它一起制定一個計劃，確認好它要執行的規範，然後我就讓它自己去烹飪了。」
這種工作方式的轉變是顛覆性的。「這是一種截然不同的工作方式。所以我們開發了上週發布的 Codex 應用，就是為了創造一種在人體工程學上更適合委託任務的用戶體驗。」
他給出了一個內部數據：「我認識的大多數人基本上已經不再打開編輯器了。絕大多數代碼是由 AI 編寫的。人類現在可能只是去定義模块間的接口，或者與 AI 協作制定計劃，但代碼本身，已經不再由人類編寫了。」
7. IDE 的終結？
既然工程師不再親手編寫代碼，傳統的整合開發環境（IDE）的地位也變得岌岌可危。
「如果你說的 IDE 是指一個非常強大的編輯器，那麼我們特意沒有在 Codex 應用中內置編輯功能，因為我們想讓它的使用方式非常明確。」Embiricos 解释道。新的工作重心不再是編輯代碼，而是管理和審查。
他強調了兩項正在變得越來越重要的技能：
計劃審查（Plan Review）： 「在委託模式下，你想要做什麼的規範或計劃，變得比以往任何時候都重要。」他介紹，Codex 現在有一個突出的「計劃模式」，智能體會先提出一個詳細的執行方案，並向用戶提問以確認關鍵決策，這就像一個新員工在動手前向團隊提交一份設計文檔一樣。
自動化代碼審查（Automated Code Review）： 為了解決 AI 可能產生大量低質量代碼（所謂的「AI Slop」）的問題，OpenAI 內部形成了一個慣例：讓 Codex 審查自己生成的代碼。「Codex 在這方面做得非常好，我們特意訓練模型擅長代碼審查，它能提供信噪比極高的反饋。」如今，在 OpenAI，幾乎所有的代碼在提交時都會由 Codex 自動進行審查。
「一個有趣的現象是，」他補充道，「人們有時會透過讓 Codex 去審查另一個模型生成的代碼，來體會我們模型的強大之處。看完之後，他們通常會覺得，『好吧，我應該直接用 Codex 來寫代碼。』」，這是在諷刺claude code
8. 建立一個開放的護城河：agents.md 的悖論與公開競爭
在如今這個 AI 工具層出不窮、用戶可以輕鬆切換的時代，如何建立產品的「護城河」？Embiricos 坦言，OpenAI 採取了一種反直覺的策略：主動擁抱開放
他解釋說，目前的編碼任務大多是封閉的或片段式的，這意味著用戶可以轻易地在不同工具間切換。然而，真正的粘性將來自未來。「當智能體開始與 Sentry、Google Docs 等其他系統交互時，它們會變得更有粘性。因為讓企業信任並授權一個智能體去連接這些系統，是一個具有粘性的決策。」
儘管如此，OpenAI 的核心策略仍然是開放。「我們的 Codex 核心框架是開源的，我們一直在努力讓用戶更容易切換到其他工具。」他舉例說，OpenAI 創立了一個命名為 agents.md 的文件約定，用於存放給智能體的指令。「我們沒有叫它 codex.md，就是希望所有智能體都能使用它。現在除了參熟人（指 Claude），几乎所有智能體都採納了。」
這種策略對於傳統的風險投資邏輯來說是難以理解的。「這對我這個風險投資人來說太難理解了。」主持人插話道。
「我完全理解，」Embiricos 回應道，「OpenAI 是一個非常有趣和不尋常的工作場所。從我們的角度來看，我們的工作是『智能的分發』（Distribution of Intelligence）。」
他解釋了這種資敵行為背後的邏輯：「我們把所有的精力投入到訓練這些模型中，然後我們把模型提供給我們的競爭對手。因為我們玩的是一個非常長期能夠的遊戲，如果競爭變得更激烈，我們也能從中學習，這對我們實際上是有幫助的。」
儘管如此，他依然充滿自信：「我們擁有巨大的分發優勢（ChatGPT）、模型能力優勢和對新模型的優先使用權。我們在爭取勝利，但同時也在玩一個更長遠的遊戲。」
9. 誰是工作的引力中心？
Embiricos 認為，未來的市場格局不會是百花齊放，而是少數幾家巨頭佔據主導。他用自己在 Dropbox 工作時的親身經歷，講述了一個關於「引力中心」的深刻故事。
「我曾效力於 Dropbox，在 Slack 崛起之前，我們曾思考，用戶是應該在 Dropbox 裡直接評論文檔，還是去 Slack 裡討論文檔？」他回憶道，從最優的角度看，在視頻的特定時間戳上或文檔的特定段落旁評論，顯然更高效。然而，我們看到的是，Slack 成為瞭人們交流的絕對『引力中心』。沒人想去文檔裡評論，我只想 Slack 你。即便效率更低，但巨大的引力把所有交互都拉向了 Slack。」
他預測，AI 智能體領域也將發生同樣的故事。「我不認為一家公司會需要 12 種不同的智能體，讓員工去搞清楚該和哪一個對話。那樣他們永遠無法形成使用習慣。」他斷言，「未來會有一個你可以和它談論任何事的超級助理。它會成為工作的引力中心，人們會圍繞它分享最佳實踐，舉辦黑客松。最終，市場上只會剩下少數幾個這樣的平台。」
10. 給投資者的建議：SaaS 並未消亡，但關係與記錄是新的護城河
對於「SaaS 已死，模型層將通吃一切」的論調，Embiricos 提出了自己的框架。
「我的問題是：這家 SaaS 公司是否與終端用戶建立了關係？如果答案是肯定的，我認為它就不會消失。」他進一步補充，「或者，這家 SaaS 公司是否掌握了某個極其重要的記錄系統？那它可能也不會消失。」
他認為，在兩種情況下，SaaS 公司的價值甚至比以往更重要。但他也發出了警告：「反過來說，如果這家 SaaS 公司只是一個膠水層，既不擁有用戶關係，也不掌握核心記錄系統，那我就會對它感到更擔憂。」
他還指出，AI 時代對創始人的要求也發生了變化。「過去有一段時期，你只要能做出好產品就能獲得投資，可以忽略客戶、市場或分發策略。我認為那是一個反常時期。現在，構建好產品相對容易了，你必須回歸本源，去投資那些真正思考過分發、擁有深厚領域知識、知道為特定客戶構建什么的創始人。」
11. 快速問答
過去12個月，你改變最大的想法是什麼？
「我曾以為我們會透過多模態（視頻、音頻）與 AI 交互。我完全錯了。我意識到，基於程式碼讓智能體操作電腦，才是當前正確的路徑。這徹底改變了我對如何將 AI 帶給普通人的思考。」
在 Codex 最艱難的產品決策是什麼？
「最痛苦的決定是取消 Codex Cloud 的無限使用。我們知道拖得越久越難收回，但當時正專注於其他更有市場的產品。當我們最終設定了合理的用量限制後，雖然只有極少數用戶反對，但他們的反面聲音在社交媒體上傳播得很廣。我學到的慘痛教訓是：你不能讓任何東西無限免費太久。」
5年後再看今天，工程或產品領域有哪些做法會顯得很可笑？
「第一，手動編輯代碼。第二，可能更有爭議，是手動管理部署和監控。我認為很多創業公司會誕生於一個全新的、完全由 AI 管理的技術棧之上。未來，你創業的方式可能就是先雇佣一個智能體，讓它去構建，然後你再把聯合創始人加進這個與智能體協作的平台裡。」
智能體的護欄應該由誰提供？
「兩者都會有。我們正在投入巨大努力構建護欄，比如我們是唯一關心編碼智能體操作系統級沙盒的公司，並且正在開源我們為 Windows 構建的方案。但我們提供的方案不會是萬能的，一定會有第三方為特定的企業需求提供定制化的護欄。」