北京
整理｜冬梅
2 月初，OpenAI 正式發布了其最新一代編程智能體GPT-5.3-Codex，這是目前 OpenAI 在 AI 編程領域的最新旗艦模型，標志著該公司在“智能體變成實際協作者”這條路線上的一次重要升級。官方發布中指出，GPT-5.3-Codex 在原有 GPT-5.2-Codex 能力基礎上進行了全面提升，包括更強的推理能力、更高的效率和更廣的工作流支持，同時提升了用戶交互體驗和長期任務處理能力，目標是讓智能體像人類同事一樣在整個開發流程中協作。
在權威評測上，新版本在多個行業相關 benchmark 上表現卓越，例如在軟件工程綜合評測 SWE-Bench Pro 和系統操作評測 Terminal-Bench2.0 上大幅領先前代，在 OSWorld 和其他能力指標上也表現顯著，更重要的是整體推理速度提升約 25%。官方強調，這些改進不僅體現在代碼生成能力，還包括調試、審查、架構設計等工程師真實需要的工作流環節。
在 Reddit、技術論壇等開發者社區中，GPT-5.3-Codex 的反饋呈現出明顯的兩極分化。一部分開發者分享了正面的經驗，例如模型在 CLI 與 IDE 插件中帶來的更流暢操作、新版計劃模式提供的更清晰步驟反饋等，這與官方提出的“交互式協作和實時指導”方向一致。
但也有不小比例的用戶發出了批評：有用戶指出目前 GPT-5.3-Codex尚未通過 API 向所有開發者開放，部分平臺（如通過 API key）無法直接調用最新模型，這讓許多開發者難以在自定義環境中集成。
另一些用戶反映新模型在某些編輯器里表現尚不成熟，例如在 Zed 編輯器中體驗不佳，偶爾中斷或無法按預期編輯文件，甚至有人因此重新回退使用老版本。
還有開發者表示，他們并不總是能獲得“官方宣傳的強大師任務表現”，尤其在 Web 生成等任務上出現停滯，并認為其它競爭模型（如某些 Claude 系列）在某些日常任務上體驗更順暢。
近日，OpenAI Codex 的產品負責人 Alexander Embiricos 做客了一檔訪談節目，談及了 Codex 的產品方向，目標并不只是“讓 AI 寫得更好”，而是將 AI 打造成一種貫穿軟件工程全生命周期的主動型工程隊友——能夠理解任務、制定計劃、執行實現、完成交付，甚至參與審查。
與許多模型負責人不同，Alexander 的視角明顯更偏向“工作流”和“真實使用場景”。
在加入 OpenAI 之前，Alexander 曾聯合創立協作工具公司 Multi 并成功退出，長期關注的不是技術極限，而是工具是否真的被人全天候使用、是否改變了人的工作方式。也正因為如此，這場對話沒有圍繞參數規?；蚧鶞蕼y試展開，而是反復回到一個更具現實沖擊力的問題：當工程師開始把完整任務交給 AI，軟件工程這件事，正在發生什么變化？
在對話中，Alexander 明確否定了“AI 會減少工程師數量”的判斷。他認為，未來五年工程師和創造者只會更多，而不是更少。原因并不復雜：歷史上，“計算機”“程序員”這些詞本身就被多次重定義，而“軟件工程師”也正站在下一次重定義的門檻上。
真正發生變化的，是人才棧的壓縮。在 Codex 團隊內部，傳統的前端、后端、基礎設施等分工正在迅速模糊，每個人都被要求具備更強的全棧能力，甚至同時參與設計與產品判斷。在這樣的背景下，“工程師”不再只是執行者，而更像是問題定義者與結果把關者。Alexander 甚至半開玩笑地表示，某些情況下，產品經理這個角色是否仍然必要，都是一個值得重新討論的問題。
他的判斷很清晰：分工會被壓縮，但人類作為創造者的地位不會被削弱。
如果說對未來的判斷仍帶有主觀色彩，那么 Alexander 描述的OpenAI 內部變化，則更像是一種已經發生的事實。
他反復提到一個關鍵節點：GPT-5.2 Codex 的發布。在那之前，AI 更多扮演的是“輔助工具”的角色——自動補全、結對編程，人仍然需要坐在編輯器前，驅動整個過程。但從 GPT-5.2 Codex 開始，工作方式發生了本質變化：工程師不再“和 AI 一起寫代碼”，而是把整個任務直接委托給 AI。
在 OpenAI 內部，許多工程師幾乎不再打開傳統 IDE，而是全天候運行Codex。會議期間如果沒有讓 Codex 同步處理任務，反而會被認為是在浪費時間。Alexander 沒有給出一個精確比例，但他的判斷非常明確：現在 OpenAI 內部，絕大多數代碼都是由 AI 寫出來的。這并不意味著工程師“無事可做”，而是他們的注意力，已經從實現細節，轉移到任務拆解、計劃評估和結果審查上。
在對話的最后，Alexander 回答了一位頂尖高校學生的提問：如何在未來五年成為 AI 生態中有價值的工程師？他的態度出人意料地樂觀——這是一個前所未有適合做工程師的時代。工具極其強大，理解復雜系統和代碼庫的成本被大幅壓縮。但正因為“構建變得容易”，真正稀缺的東西反而更加清晰：主動性、審美，以及對質量的執念。
他的建議只有一句話：去構建高質量的東西。一個有思想、有完成度的項目，比任何標準化簡歷都更有說服力。
以下為完整對話內容，經 AI 前線編輯整理：
主持人：我的第一個問題可能有點奇怪，但我還是想問下。我對人們的動機特別著迷：你行動的動力更多是來自對失敗的恐懼，還是對勝利的興奮與渴望？
Alexander：我是個追求極致的人。比起害怕失敗，勝利的渴望絕對更能驅動我。不過我得跟你坦白一件事：在加入 OpenAI 之前經營創業公司時，曾經歷過至暗時刻——實際上那段日子黑暗時刻比比皆是——我突然意識到過去幾個月自己一直在拼命避免失敗。那一刻恍然大悟：天啊，原來這就是我如此痛苦的原因，很可能也是公司止步不前的根源。所以我得不斷自我調整，重新聚焦于爭取勝利的初心。但說到底，比成功欲望更強烈的，大概是我天生熱愛創造，特別是為人們打造新事物。想到今年就無比振奮，因為將有無數尚未存在的精彩之作被創造出來，交付到眾人手中。
主持人：馬斯克曾預言編程會成為首批被大規模自動化的職業之一。基于你的職位和日常觀察，你認同這個觀點嗎？
Alexander：我完全認同編程會是最早被大語言模型深度滲透的領域之一。不過說到“編程被自動化”這個說法，其實值得細品——這就像當年我們不再寫匯編語言，轉向高級語言編程時，能說編程被自動化了嗎？并非如此。
我們只是得以用更高效率編寫更多代碼，結果反而是市場對代碼的需求激增，需要更多軟件工程師來創造價值。這種自動化更像是工具進化帶來的職能轉變，就像“計算機”這個詞的起源：據說在布萊切利公園破譯德國恩尼格瑪密碼時，需要專人打孔卡、操作機器、做大量表格運算——這些繁瑣的機械操作后來被自動化了。甚至最早的電子表格軟件，靈感就源于辦公室里格子間工位排成矩陣，人們各自計算后將表格傳給下個人的場景。這些具體操作確實被技術取代了，但每次這樣的變革后，對最終成果的需求都會呈指數級增長，即便具體的工作形態已徹底改變，整個行業反而需要更多從業者參與其中。
主持人：所以你認為五年后工程師數量會增加而非減少，對嗎？
Alexander：沒錯，其實我們也在不斷重新定義術語的內涵——比如“計算機”這個詞現在指代的東西早已不同，而如今我們又有了“軟件工程師”這個頭銜。所以我堅信未來會有更多創造者。
現在有個很有趣的觀察：人才棧正在發生壓縮現象。雖然當前我們仍然需要軟件工程師、軟件設計師，以及像我這樣的產品經理——關于 PM 這個角色你們可以盡情調侃，說實話我也覺得未必需要——但或許當人們談論“工程師”時，腦海中浮現的已經是比過去更全能的形態。倒退幾年，絕大多數團隊還嚴格區分后端工程師和前端工程師；而現在至少在 Codex 團隊，這種界限已經非常模糊，每個人都更趨向全棧。因此我認為人才棧確實會持續壓縮，但人類作為創造者的本質不會改變。
主持人：為什么你認為在這個世界里我們不需要產品經理？你這是在吊人胃口啊。
Alexander：首先我覺得產品經理這個角色本身就極難定義——它本質上就是個沒有固定范式的崗位，目標就是靈活適配團隊或業務的需求。比如當一群人正全力沖刺開發時，產品經理的價值在于后退幾步，用前瞻性視野預判方向，協調各方資源推進市場落地，同時擔任團隊的頭號啦啦隊長和質量把關人。
但仔細想想，這些我描述的（可能也是我當前做的）所有工作，完全可以由一位兼具產品思維的資深技術負責人或設計師來完成。所以產品經理這個角色確實常常能發揮作用，但在團隊規模真正變得龐大之前，可能并不需要配置太多這樣的崗位。
AGI 的瓶頸是什么？
主持人：過去幾天我可沒少狂扒你的“底褲”——把你的文章、推文、過往采訪翻了個底朝天，這趟探索簡直樂趣無窮。你曾在某處提到，人類驗證工作的速度和輸入效率才是制約 AGI 發展的關鍵瓶頸，而非模型算力或架構本身。然后這話就撂在那兒沒下文了，快給我解解惑：為什么說人類打字速度和驗證工作會成為核心瓶頸？你這句話到底藏著什么深意？
Alexander：確實如此。這個話題很有意思。我認為現在存在多個瓶頸，但這或許是最能吸引眼球的一個。如果不介意的話，我們不妨用蘇格拉底式問答來探討：你目前每天使用 AI 的頻率大概是多少？
主持人：每天 30 多次吧。
Alexander：那假設你完全不需要耗費任何精力，你覺得 AI 每天能幫到你多少次？
主持人：我認為在所有事務中，AI 將會全天候覆蓋每一件事。
Alexander：確實如此。現在無論是 OpenAI 內部還是外部的工程師都在告訴我：他們全天候開著 Codex，從不合上筆記本電腦。開會期間若沒讓它運行著，簡直就是在浪費時間——必須確保 Codex 隨時在為我處理工作。
這確實很酷也很令人興奮，但反過來說，要管理這些智能體、確保它們持續運轉本身也是個龐大的工作量。回到剛才說的每天 30 次使用頻率，我們觀察 Codex 用戶的使用數據也大致在這個區間。但在我看來，AI 本應每天為我們提供上萬次幫助——只要算力允許，這個目標終將實現。問題在于，即便像我這樣專門研究這個領域的人，明知該用 AI 處理所有事務，但我實在太懶，懶得敲那么多提示詞；也缺乏足夠的創意去發掘 AI 能幫忙的所有場景。結果我的使用頻率和你相差無幾。
直到現在，當我用 AI 完成像準備這次對話這樣有趣的任務時，還會暗自得意：“不錯，又解鎖了 AI 的新用法?！边@對你我這樣熱衷此道的人倒無妨，但我們不能指望普通人為享受通用人工智能的紅利而付出太多學習成本。
理想狀態應該是：使用 AI 無需琢磨提示詞技巧，它就該簡單到不費吹灰之力；你甚至無需意識到需要 AI 幫助，它自會理解你的處境，適時給予貼心的協助。
主持人：這正是我認為 Claude 做得好的地方——他們針對法律、Excel 等場景推出了定制化版本，讓用戶能直接上手建立 DCF 模型（雖然我對模型不感冒，但不得不承認比過去的操作強多了）。那么你認為你的職責是否就是將提示詞和人工操作產品化，從而消除這一瓶頸？
Alexander：沒錯，這正是我們要做的——既要確保模型具備卓越能力，最終更要讓 AI 高度產品化，可能是神奇的對話框、語音輸入，甚至直接加入群聊就能自動提供幫助。
不過中間階段其實藏著更深的門道，我認為當前最大的價值恰恰就藏在這個過渡期。具體來說，你可以嘗試針對特定市場將 AI 的某個功能產品化，雖然很多公司都在這么做，但真正找準有效形態并不容易。之前你播客有位嘉賓說得特別在理：企業沒有付費門檻根本沒法落地 AI。
主持人：對，就是 Invisible AI 的 Matt Fitzpatrick 提到的這個觀點。
Alexander：確實，從財務角度看是這樣，但我其實完全不同意企業級優先的自動化路徑。
我認為當前最重要的是為真實用戶打造工具。正如 Matt 在播客中提到的，通過全職員工構建自動化流程當然可行，但這會受制于自上而下的視角局限和人力配置的邊界。
而我憧憬的 AI 未來，是讓每個人都成為被 AI 賦能的超級個體。要實現這個愿景，我們需要打造面向個人用戶、能讓所有人輕松上手的工具。當前最有趣的階段，恰恰是為那些熱衷于探索 AI 應用場景的先行者構建工具。回想 Cognition 的 Code 工具初次發布時的精妙之處，正是提供了一個能在終端中無縫使用的開放工具，激發用戶自發探索應用場景。這啟示我們，在將 AI 拓展到編程之外的工作領域時，最重要的不是過度定制垂直場景工具，而是打造足夠開放的創作平臺，讓用戶能針對任何任務進行創造性應用。
智能體開發的三個階段
主持人：但這不就把責任和精力又推回給用戶了嗎？這恰恰回到了你之前說的“人類行動瓶頸”問題——如果連任務都不定義，等于把定義權完全交給了人類，而人類既缺乏這種定義能力，也缺少這樣做的意愿。
Alexander：是的，我是這么認為的，這也是我覺得它是瓶頸所在的原因。
在我看來，整個過程基本分為三個階段：首先，先讓智能體在軟件工程和編碼領域做到足夠出色，因為大語言模型本身就擅長這方面；其次，我們會意識到，要讓智能體在更廣泛的場景中發揮作用，讓它能夠操作計算機是非常有價值的，同時我們也會發現，所有智能體本質上其實都是編碼智能體，因為編碼是智能體使用計算機的最佳方式。
所以我們可以沿用這個極具靈活性的思路，把它開放給所有樂于探索和嘗試的人，我們已經看到有人開始通過類似 Codex 這類應用這么做了，這類應用原本是為開發者設計的，但開發者們卻用它來完成各種非編碼類的任務；最后，等我們驗證出有效的方案后，就進行你所說的產品化，打造出功能高度專一、用戶能夠開箱即用的產品。我認為我們會在未來幾個月里快速走完這一整個過程。
主持人：你剛才提到的關于企業內全職員工部署和實施的問題，關鍵還在于數據安全敏感性、權限配置和訪問條款——這些實際操作難如登天，而大多數人其實并沒有我們想象的那么聰明和自信。尤其是在大型企業環境中更是如此。我認為確實需要全職員工深入介入，為各種橫向解決方案進行定制化適配才能落地運行。我錯了嗎？
Alexander：我覺得你的判斷是對的。如果你一開始就試圖從零直接跳到一，腦子里又有一個宏大的愿景——比如構建一個覆蓋所有流程的終極自動化系統——那確實會立刻撞上大量現實障礙。
我這里并不是貶義地說“宏大”，而是說這類項目不可避免地要處理安全、合規等問題，而這些問題都是真實存在的。你還需要打通各種數據系統、系統記錄、執行系統等等。要完成這些，你基本上需要一個完整的、企業級的 IT 或數據基礎設施團隊來支撐。
但我們觀察到，如果完全采用這種自上而下（top-down）的方式，結果往往是：嚴重低估、甚至浪費了 AI 在幫助企業中的潛力。
相比之下，更好的方式可能是并行推進。一方面繼續解決系統層面的難題，另一方面，把 AI 先交到真正干活的人手里——那些每天在一線工作的員工。
當員工開始實際使用 AI，他們會逐漸建立起一種“心理模型”，理解 AI 能幫自己做什么、不能做什么。然后，他們會自然地把 AI 拉進自己的工作流中。
我舉個例子：假設你在做客服工作，公司開始用 AI 自動化你工作中一些重要環節，但你自己從來沒用過 ChatGPT，甚至被禁止使用。那么在這種情況下，你對“AI 到底是什么”是沒有直覺的。
但如果是在另一種世界里，你一邊日常使用 ChatGPT 工作，一邊看到 LLM 正在自動化你的一部分任務，那你對 AI 的理解會深刻得多。你會覺得自己是被“加速”的，是有控制權的，甚至能影響自動化往哪個方向發展，而不是被一個“從天而降的黑箱系統”所取代。后者其實是非常令人無力的。
所以回到你提的問題：你提到的數據控制問題確實存在，也非常現實。但歸根結底，每一個工具、每一個功能、每一個工作流，最終都是服務于某個具體的人——某個員工。而這些員工，最終都是通過瀏覽器、文件系統等接口在使用工具。換句話說，一切最終都會收斂到一個“界面”，而這個界面是可以被運行在本地計算機上的智能體（agent）所操作的。這也是為什么 OpenAI 會去做一件在外界看來有點“反?！钡氖隆?strong>我們在構建自己的瀏覽器（Atlas）。
你可能會問為什么要這么做，原因有很多，但其中一個關鍵原因是：當我們從端到端嚴格控制瀏覽器時，就能為企業構建安全的、可控的智能體式瀏覽體驗。
這樣，智能體就可以“代理式”地訪問那些企業還沒有通過 API 或 FD（功能部門）完全開放的系統和流程。
GPT-5.3 Codex效率大幅提升，
我們如何做到的？
主持人：你之前提到，有些工程師甚至不愿意合上電腦，因為他們不想中斷用 Codex 構建的效率。你們和 Cerebras 建立了合作，而 Cerebras 目前被認為是推理速度最快的算力提供方之一。這是一次非常漂亮的合作。那么，推理速度對使用 Codex 的開發者到底有多重要？
Alexander：簡單來說：非常重要。
主持人：那這會不會形成一種“推理能力的壟斷”？比如你們現在有了，競爭對手沒有。
Alexander：這只是我的個人看法，但我不認為最終會走向一種壟斷式的格局。市場上的競爭壓力非常大，未來一定會出現多種不同的解決方案。
不過我可以透露的是：關于這次合作，我們很快會有新消息公布，而且我對此非常興奮。這些東西一旦上線，會非常棒。
即便不談硬件合作，僅從模型本身來看，比如 GPT-5.3 Codex，相比之前的模型，在效率上已經有了顯著提升。我們收到的反饋是：開發者明顯感覺到它比以前快得多，而且是“有競爭力的快”。此外，你還可以在多個層面做優化：模型本身的效率以及推理方式的改進。
舉個具體的例子：我們最近在 API 層面做了一次更新，相關模型的響應速度提升了大約40%；而在 Codex 產品里，速度也提升了大約25%。所以，速度真的很重要，我們基本是在硬件、推理方式、模型層三個方向同時推進。
主持人：你剛才提到把 AI 交到用戶手里，這讓我想到推理成本的問題。我有位朋友 Jason Lemkin（來自 SaaStr）提出一個觀點：“推理就是新的銷售和市場”。意思是說，與其養龐大的銷售和市場團隊，不如把錢花在推理上，讓用戶更快上手、看到價值，最終甚至不再需要傳統的銷售和市場團隊。這有點像下一代的 PLG（產品驅動增長）。你怎么看？
Alexander：說實話，我對這個觀點是有些保留的。在這樣一個“人人都能構建產品、構建門檻越來越低”的世界里，真正困難的事情并沒有消失。什么是難的？是與客戶建立真正良好的關系 并理解他們真正需要什么。
而且我認為，這些事情甚至比以前更難了，因為市場上的選擇變得更多、軟件數量爆炸式增長。
另外，構建“正確的東西”和“高質量的東西”依然非常難。
所以回到銷售和市場這個問題，我并不認為它們會消失。相反，隨著市場競爭加劇，它們的難度其實是在上升的，而不是下降。
在 OpenAI，
很多人不再打開 IDE 了
主持人：能不能聊點更具體的？比如在 OpenAI 內部，現在有多少代碼是由 Codex 生成的？我記得之前 Claude for Work 的負責人 Boris 說他們內部幾乎 100% 都是 AI 寫代碼。
Alexander：我先說我個人的感受，再說團隊整體情況?；旧?，我認識的大多數人現在已經很少再打開傳統代碼編輯器了。
這種變化是逐步發生的，但一個非常明顯的“拐點”出現在GPT-5.2 Codex發布之后。那一代模型突然在以下幾個方面變得非常強：
能持續運行更長時間
能端到端完成任務
能管理上下文
能更好地遵循指令
這也是我們后來決定做 Codex App 的重要原因之一。在 GPT-5.2 Codex 之前，我們更多是在用 AI 做自動補全 或者“結對編程”（pair programming）。 那時候，你仍然需要坐在電腦前，手放在鍵盤上，AI 可能幫你做一點點事情，但整體節奏還是你在“開車”。
而從 2024 年 12 月 GPT-5.2 Codex 開始，我們切換到了一種完全不同的工作方式：我不再和 AI 一起寫代碼，而是把整個任務直接委托給它。流程變成了一起制定計劃、確認規格、然后我就“放手讓它跑”
這是一次非常本質的轉變。
這也是為什么我們在上周發布了 Codex App——我們想打造一種更適合“委托（delegation）”而不是“結對”的產品形態，讓你可以同時把任務分配給多個智能體。
即便在 OpenAI 內部，這種變化也非常劇烈。我沒有一個精確的百分比數據，但可以說：絕大多數代碼現在都是由 AI 寫的。很多人甚至不再打開 IDE。即便打開，更多也是為了設計模塊之間的接口 或協助規劃方案， 真正的代碼實現，已經不再由人類直接完成了。
Codex App 為什么
不是一個傳統 IDE？
主持人：那你覺得 24 個月后，IDE 還會是開發棧的一部分嗎？
Alexander：這要看你怎么定義 IDE。“集成開發環境”這個詞本身就非常模糊，幾乎什么都能算 IDE。如果按這個定義，那你甚至可以說 Codex App 也是 IDE。但我個人并不這么看。在我心里，IDE 是一個極其強大的編輯器。而我們在設計 Codex App 時，刻意沒有加入文本編輯功能，就是為了讓使用方式足夠清晰。
Codex App 的核心能力在于：管理多個智能體、委托任務以及審查變更。它還有一個非常顯眼的“Skills”系統，這是一個開放標準，能支持大量非編碼任務，比如：任務分流和部署監控。但它沒有文本編輯器，這是我們有意為之的設計選擇。
主持人：如果大量代碼都是由 Codex 生成的，那你們內部現在是怎么做代碼審查的？AI 會參與內部的代碼審查嗎？
Alexander：這里其實有幾個層面。首先，你想做什么這件事的“規格說明（spec）”或“計劃（plan）”，變得前所未有地重要。你需要從架構層面去思考：這段代碼應該如何工作。最近我們上線了一個非常重要的“計劃模式（Plan Mode）”。它的工作方式和其他系統不太一樣：智能體會先獨立提出一個完整的執行方案，通常是一個相當長、相當詳細的計劃，然后再回來問你：
你是否同意這種實現方式？ 是否希望對某些部分提出修改意見？
這其實非常像現實中的場景：假設你招了一個剛加入團隊、對代碼庫還不熟的新工程師。在正式開始寫代碼之前，他需要先向團隊提交一份類似 RFC（Request for Comments）的方案，征求大家的意見。所以，即便這還不是傳統意義上的代碼審查，但“對計劃的審查”正在變得越來越重要。這是因為我們已經進入了一個更偏向“委托（delegation）”而不是“協作編寫”的工作階段。
這一點往往被低估了。接下來才是更傳統意義上的代碼審查。我聽到的一個非常常見的問題，尤其是在開源社區，是所謂的“AI 垃圾代碼（AI slop）”。很多人直接把 AI 生成的代碼提交成 PR，這些 PR 質量很差，提交者可能根本沒有測試過，甚至沒有真正審過代碼。這是一個真實存在的問題。
因此，在使用 Codex 時，一個非常常見的做法是：讓 Codex 審查它自己生成的 PR 或代碼改動。而 Codex 在這方面表現得非常好。我們是明確訓練過模型去做代碼審查的。訓練目標包括：給出高信噪比的反饋、盡量減少“誤報式批評”（false positives）。這意味著：當 Codex 提出修改意見時，你是可以高度信任它的。
所以在 OpenAI 內部，以及我們推薦給外部用戶的做法是：主動讓 Codex 做代碼審查，甚至可以設置為自動審查。
事實上，在 OpenAI，幾乎所有代碼在推送到主倉庫時，都會自動經過 Codex 的審查。一個挺有意思的現象是：有些人為了“測試模型有多強”，會讓 Codex 去審查其他模型寫的代碼。結果往往是：“好吧，那我可能干脆直接用 Codex 寫代碼算了。”
主持人：你剛才提到，對于那些還沒用過 Codex，或者很久沒回來用的用戶，你怎么看“留存”這件事？我記得 YC 合伙人 Tom Blomfield 之前發過一條推文，提到不同代碼智能體之間的切換成本——不管是 Cursor、Claude Code 還是 Codex。在這種情況下，用戶到底有多“黏”？你們是如何思考留存的？
Alexander：我們在 Codex 上采取了一種相當反直覺的策略：把它做得盡可能開放。比如 Codex 的核心執行框架（harness）是開源的，我們一直在努力降低用戶在不同工具之間切換的成本。舉個例子：去年我們剛發布 Codex 時，做了一件很簡單的事——我們只是“確立”了一個約定，而不是強推一個品牌化標準。這個約定叫agents.md。它是一個文件，你可以在里面寫給智能體的指令。
我們刻意沒有叫它codex.md，而是希望它成為一個所有智能體都能用的通用約定。現在，幾乎所有智能體都在使用agents.md，這其實是一件很棒的事情。就在上周，我們還推動了另一件事：把Skills（技能）——也就是給智能體用的腳本和指令——放進一個中性的目錄里，叫agents/，而不是放進codex/這樣的私有命名空間。
同樣，除了“那個熟悉的例外”，大家基本都跟進了。從開發者角度來說，這意味著：選擇更多 并且試錯成本更低。當然，目前來看，代碼生成這類任務本身是高度“封閉”的（hermetic）。你可以把它理解成美劇里的“單元劇”：智能體讀取一個通用的 agents 文件、使用通用的 skills、生成一個補丁、補丁提交進 Git。
從輸入到輸出，都是高度廠商中立的，所以切換成本很低。但未來會發生變化。當智能體不再只是寫代碼，而是開始接入 Sentry、操作 Google Docs 或連接企業內部系統，這時，“連接某個系統”本身就變成了一次高度粘性的決策。尤其在企業場景下，你必須信任：智能體能訪問這些系統，同時又有足夠嚴格的安全護欄、沙箱和權限控制。而這些事情，你是不愿意反復做很多次的。
所以我們在構建 Codex 時，其實已經提前預判了這一階段的到來。這也是為什么我們采用了極其保守的沙箱策略——本質上是操作系統級別的控制。我個人很喜歡一本書叫《Seven Powers》，講的是企業構建長期價值和可持續性的七種方式，其中之一就是“留存與黏性”。但對我們來說，這件事的優先級其實有點不一樣。
“贏”的決定性因素：
算力優勢 + 最好的模型
主持人：但如果從商業角度看，你們肯定還是會關心：如何讓用戶留在 Codex，而不是在 Cursor 或 Claude Code 出現更好模型時立刻切走？
Alexander：這是個很好的問題。當然，我們是在經營一家公司，但從根本上說，我們的使命是“安全地把 AGI 的收益帶給全人類”。所以對很多人來說很反直覺的一點是：我們花了巨大的精力訓練模型，然后把這些模型提供給競爭對手使用。我知道，從風險投資的視角來看，這幾乎是難以理解的。
主持人：這在 VC 視角里確實非常反常。
Alexander：是的，但這正是 OpenAI 非常獨特的地方。我們在玩一場極其長期的博弈。當競爭對手變強時，我們是能學到東西的，這反而對我們有幫助。如果他們是封閉的、黑箱式地進步，我們反而學不到。
舉個例子：今天早上我還轉推了 Warp 的一個新發布。我和他們沒有任何商業關系，但他們在“云端 + 本地智能體協作”這件事上的一些設計思路，真的很有啟發性。這個領域有意思的地方就在于：大家在不同公司、不同路徑上，正在同時得出相似的結論，然后把它們實現出來。
當然，從現實角度講，我們也并不是沒有優勢：ChatGPT 帶來的巨大分發優勢、自研模型與自有執行框架的深度耦合、對新模型的提前訪問權。所以我們確實是在“為了贏而競爭”，而且我們有很多優勢。但與此同時，我們也在堅持把模型服務提供給整個生態，同時推動開放標準。
主持人：如果一定要用投資語言來問一句：最終決定勝負的關鍵是什么？是 GTM？是品牌？是產品執行？還是算力和推理速度？
Alexander：如果從公司整體角度說——當然這已經遠遠超出我的職級了——我會說是：算力優勢 + 最好的模型。
為了實現這一點，我們需要成功的商業模式來支撐持續投入。而 Codex 這種“研究 + 產品”高度融合的團隊，其實會反過來倒逼模型進步得更快。但如果從產品層面來說，我認為最重要的一點只有一個：做出一個真正好用、讓人愿意用的產品。我們一直強調先服務好個人，讓人真正“熟練”地使用這些工具，再自然地把自動化引入工作流。這條路徑看起來有點反直覺，但我認為它的長期影響力會更大。至于企業市場，GTM 非常重要。我學到的一個慘痛教訓是：你不能只是對企業說一句“你們隨便用吧”。
你需要做大量教育、支持復雜配置、和負責人（比如開發者體驗負責人）一起設計工作方式，再把這種工作方式復制到整個組織中。
主持人：那你們內部衡量成功的核心指標是什么？是收入嗎？
Alexander：不是。最核心的指標是活躍用戶數。
主持人：具體是 DAU 還是 WAU？
Alexander：目前我們主要看 WAU（周活躍用戶）。標準是：這個人是否真的在產品里完成過一次交互，比如發送過一個 prompt。
主持人：如果 Codex 是要替代 IDE 的，DAU 會不會更合理？
Alexander：我同意。DAU 很快會更合理。我們現在用 WAU，更多是歷史原因。我理想中的狀態是：任何一個任務，你的第一反應都是“讓一個智能體來幫我”。
就像查信息打卡 Google，問問題打開 ChatGPT。
下一階段是人們做任何事先打開一個輸入框，然后智能體開始行動，哪怕它只幫你完成其中一小步。
主持人：你認為 Chat 會成為 AI 與人類交互的長期主界面嗎？
Alexander：簡短答案是：會。
但更準確地說，是“對話界面 + 專用界面”的組合。如果你看科幻電影，未來的 AI 往往是一個你可以用任何方式、聊任何事的存在。你不應該需要區分這是我的編程 AI 或者這是我的銷售 AI。
你只是“跟一個東西說話”，它就會幫你。但對高階用戶來說，只靠聊天會很煩。就像你有一個助理，但你所有事情都必須通過“對話”才能完成，那是低效的。
所以最終形態會是 Chat / 語音作為通用入口，針對不同角色的專用 GUI。比如我：用聊天做播客準備，用 Codex App 深入看代碼。而一個市場人員用聊天問產品問題，用專門的分析界面看廣告數據。
構建高質量代碼模型的
數據是充足的
主持人：我在 LinkedIn 上提到過這檔節目，有一位來自另一家公司的優秀投資人留言說——
他用了一個“哈利·波特”的比喻，說某家公司就像伏地魔，“那個不能被提及名字的人”。他說：“你應該問問他，代碼數據的護城河到底怎么看？現在是不是 Anthropic 已經拿走了所有數據？”
Alexander：從我們目前看到的情況來看——當然，這一點我也會更多地參考我們研究團隊的判斷——我們認為用于構建高質量代碼模型的數據是充足的。我反而覺得，現在更有意思、也更困難的數據來源，在于知識型工作（knowledge work）任務。這類數據在互聯網上幾乎不存在，比如戰略分析、復雜決策、跨角色協作，實際業務判斷過程。
所以你會開始產生一些很有意思的想法，比如：是否需要付費讓人去“模擬完成任務”，從而學習這些完整的任務軌跡，是否應該收購一些已經倒閉、但沉淀了大量協作數據的公司，比如使用 Slack 的組織。總體來說，知識型工作的任務分布，比編碼復雜得多，也稀缺得多。
主持人：既然這些數據如此稀缺，那你們如何看待和數據服務商的關系？比如 McCor、Turing、Invisible、Scale 這類公司。你們會在這方面投入 10 倍資源，還是反而覺得“數據太貴了，不如自己做”？
Alexander：我們的判斷標準其實只有一個：哪種方式能讓我們跑得最快。在內部搭建完整的數據采集體系，時間成本和人力成本都非常高，而我們是一個相對精干的小團隊。所以到目前為止，我的觀察是：一旦我們需要大規模跑數據項目，通常會選擇和這些公司合作，把精力集中在模型和產品本身。
Codex 會走向低端消費者市場嗎？
主持人：在消費端，Codex 會不會和 Lovable、Replit 這類工具正面競爭？比如一年或兩年后，是否會下沉到“任何人都能做一個 about me 頁面或小企業網站”的層級？
Alexander：目前來看，我們并不覺得自己在和它們直接競爭。如果你看過我們的超級碗廣告，口號是：“You can just build things.”（你可以直接開始構建）。通過這個應用，我們注意到：越來越多技術背景不強的人，也開始用 Codex 來做東西了。他們做的事情通常很“Hello World”級別，但確實在發生。而且我們最近有一個很大的變化：開始向免費 ChatGPT 用戶和 Go 計劃用戶提供部分 Codex 功能。這在“可用性”層面是一次巨大的擴展。所以我確實預期，會有一些用戶原本可能會去用專門的低代碼工具，但現在因為 Codex 就在他們手邊，于是直接用 Codex 做一些簡單的構建。
主持人：如果讓你說一件“最想做得不一樣、但目前還沒法做的事”，會是什么？
Alexander：這是個有意思的問題。老實說，最近這幾周對我們來說非常好，我對當前發生的一切都挺興奮的。
主持人：這種“風向變化”的感覺，團隊內部能明顯感受到嗎？
Alexander：絕對能。我們對這種變化非常敏感。如果回看 Codex 的歷史：去年我們第一個發布的產品，是一個聽起來非常驚艷的想法——給每個智能體一臺云端電腦，可以并行完成任務。
坦白說，它并沒有像我們后來發布的產品那樣成功。從去年 8 月 GPT-5 之后，我們開始全力推進交互式編程，而這正是當下市場競爭最激烈的方向。公開數據上看從 8 月開始，我們大約增長了 20 倍，到年底，又幾乎翻了一倍。但真正的變化發生在上周。我們一直認為自己擁有最智能的模型（Codex 5.3），但用戶反饋是模型偏慢、不夠“好玩” 、在工作過程中溝通感不強
我們正面解決了這些問題。
即便對比某個在我們之前 20 分鐘發布、短暫“state-of-the-art”的競品模型，我們也明顯感覺到了變化。
同時，我們一直被詬病的一點是：IDE 插件體驗很好，但 CLI（命令行）不夠精致。而現在這個 App 的反饋幾乎是一邊倒的正向評價——簡單、直覺，甚至“出乎意料地簡單”。很多曾經的批評者也被轉化成了用戶。再加上超級碗廣告、免費開放策略——所以回到你的問題，我現在最想做的兩件事是：
第一，我想重新回到云端智能體（cloud agent）。去年我們從云端轉向交互式編程，是一個非常理性的決策：如果用戶還不能流暢地使用工具、還不能簡單地讓它跑起來，就貿然推進自動化工作流，那只會變成“只有極少數高級用戶能用的空想”。
但現在不一樣了。當用戶每天都在用、每次使用都會配置得更好，那么讓它獨立在云端運行，就不再是一個巨大跨越。
第二，是關注真正的瓶頸。現在，寫代碼本身幾乎已經變得“廉價”。真正難的是：如何做代碼評審、如何判斷質量以及如何確認方向是對的。這些問題仍然被嚴重低估、投入不足。
我的目標是：最終讓一個你信任的智能體，可以端到端負責一個微服務或內部工具，完成完整的迭代閉環，甚至直接接收用戶反饋，而不需要人類審查。這在智能、在安全、在控制層面，都是極其困難的問題。
市場終局：少數超級智能體，
而不是十幾個工具
主持人：你認為 Benchmark 和評測到底該占多大權重？
Alexander：這是個可能讓你不太滿意的答案：兩者都重要。Benchmark 能很好地衡量“智能水平”，尤其是在評測還沒被刷爆之前，進步非常有參考價值。但你必須把它和使用體驗結合起來。而體驗，本質上是“感覺（vibes）”。不管是內部同事還是客戶，我總是驚訝于：人們對模型的評價有多么依賴感覺。人生本來就很“vibes based”。我對孩子說的教訓是：人們更愿意和他們喜歡的人一起工作。
主持人：投資角度看，你如何判斷這個市場的最終形態？
Alexander：我認為，最終會是更少的玩家，捕獲更多的價值。我們現在處在一個“過渡期”：目前真正實現產品市場匹配的，幾乎只有編碼智能體。但這是暫時的。長期來看，智能體會變成什么都能幫你做的超級助手。
在那樣的世界里你不會希望公司里有 12 個不同的智能體，讓員工自己去想“該和誰說話” 。那樣他們就無法形成熟練度，也就無法真正把自動化融入工作。相反，如果你只有一個可以聊任何事情的智能體，員工的 onboarding 就是一句話：“有事就找它?！?它會成為工作的重力中心。
我以前在 Dropbox 工作。在 Slack 崛起之前，我們曾討論過：人們是該在文檔里評論，還是去 Slack 里討論？文檔內評論更高效，但現實是：Slack 成了溝通的中心引力場。哪怕效率更低，人們也更愿意在那里交流。我認為，未來的智能體，也會發生同樣的事情。
SaaS 是否會被模型公司“吃掉”？
主持人：現在的人才爭奪有多激烈？我常對公司說：與其在舊金山，不如在歐洲建團隊，因為 SF 的人才又貴又難留。我錯了嗎？
Alexander：人才戰爭現在非常激烈。即便是在OpenAI，我們品牌很強，也依然要花大量精力去“贏下”心儀的候選人。沒人是“免費送上門”的。
主持人：在股權定價下，最頂尖的人才還覺得有吸引力嗎？
Alexander：目前沒有人向我表達過相反的看法
主持人：你剛才提到，目前智能體真正大規模使用的場景，主要還是編碼，少量擴展到比如客服。但從投資角度看，我今天在尋找那些能長期積累價值、為客戶持續提供卓越產品的公司。
現在市場上有一種很強的觀點：大型 SaaS 公司的收入耐久性接近于零，SaaS 已死，因為模型提供商（你們、Anthropic 等）會“來吃我們的午餐”。 你會如何建議？
Alexander：我的第一反應其實非常樸素：所有東西最終都是為人服務的，否則意義何在？
即便是 SaaS，本質上也是為人設計的。所以我會反問幾個問題：這家公司是否真正擁有與“人”的關系？ 或者，它是否掌握了一個極其關鍵的系統記錄（system of record）？
如果答案是“是”，那我并不認為這家公司會輕易消失。事實上，在 AI 時代，這兩點——
人與系統的交互入口 + 核心記錄系統，可能比以往任何時候都更重要。
反過來，如果一家 SaaS 公司只是一個“膠水層”：不直接面對人也不擁有系統級記錄，那我會更謹慎。我不是這方面的終極專家，但這種公司讓我更不安。
Alexander：如果基于這種邏輯再看市場，比如Salesforce、ServiceNow股價下跌 20%、30%、甚至 40%，我認為這種反應被嚴重夸大了。
確實有一些公司處境艱難。坦率說，我認為Dropbox正面臨非常困難的局面。
但像Monday.com這樣的公司——對其主要用戶群體（大量中小企業和消費者）來說：你能不能用 AI 臨時“vibe coding”一個待辦清單？可以。
但成本是否劃算？并不劃算。
一個待辦清單的需求本身非常穩定、簡單：添加任務、完成任務、查看歷史、分配成員。
并不值得反復用 AI 定制。所以現實是：大多數人會繼續用現成工具。市場的恐慌情緒，更多是條件反射式的過度反應。
不過我確實認為：客服會成為被強烈沖擊的領域。老實說，我不太愿意站在那個賽道上。
給下一代工程師的建議
主持人：最后，請您回答幾個網友的提問。有位學生提問是這樣的我是 CS 學生，在斯坦福 / 劍橋 / ETH。如果我想在未來 5 年成為 AI 生態中有價值的工程師，你會怎么建議？
Alexander：說實話，從未有過比現在更好的時代來當工程師。你擁有前所未有強大的工具能快速理解復雜代碼庫、能讓 AI 幫你規劃改動，甚至能把過去幾天的研究壓縮到幾個小時。所以首先，你應該非常樂觀。
但問題變成：既然構建變得容易，什么變得稀缺？我給出的答案是：主動性（agency）、審美（taste）和質量（quality）。
我的建議只有一句話：去構建東西，而且是高質量的東西。當有人帶著有思想的項目來找我，那比一份標準簡歷有吸引力得多。
https://www.youtube.com/watch?v=S1rQngjpUdI
聲明：本文為 AI 前線整理，不代表平臺觀點，未經許可禁止轉載。
會議推薦
InfoQ 2026 全年會議規劃已上線！從 AI Infra 到 Agentic AI，從 AI 工程化到產業落地，從技術前沿到行業應用，全面覆蓋 AI 與軟件開發核心賽道！集結全球技術先鋒，拆解真實生產案例、深挖技術與產業落地痛點，探索前沿領域、聚焦產業賦能，獲取實戰落地方案與前瞻產業洞察，高效實現技術價值轉化。把握行業變革關鍵節點，搶占 2026 智能升級發展先機！
特別聲明：以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布，本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
