Codex負責人打臉Cursor CEO“規范驅動開發論”！18天造Sora爆款，靠智能體24小時不停跑，曝OpenAI狂飆內幕

作者 | 高允毅

自 8 月 GPT-5 發布以來，Codex展現出驚人的爆發力，用戶增長 20 倍，每周處理數萬億 tokens，成為了 Open AI 最受歡迎的編程智能體。

“Codex 能快速實現 20倍的增長，不只是因為模型變強了，還因為我們理解了，真正的智能體不是一個模型，而是模型、API 和框架共同努力的結果。”在最新播客中，OpenAI 的編程智能體 Codex 產品負責人 Alexander Embiricos 揭露背后的秘密。

比如，Codex 在長時任務能力上的突破。為了讓它能夠連續工作十幾個小時甚至數天，團隊設計了名為“壓縮”的機制——模型負責提煉關鍵信息，API 承接任務鏈路，框架負責穩定運行。三層像齒輪般咬合，使 Codex 能夠完成傳統大模型難以支撐的長時編程任務。

正是這樣的底層邏輯，讓 Codex 在業務實戰中有驚人表現。

Andrej Karpathy 曾公開分享，他被一個 bug 困住數小時，最終交給 Codex 處理，一小時內就完成了修復。

Sora 團隊更是依靠 Codex，在短短 28 天時間，從 0 到 1 完成 Android 應用的上線，直接沖到 App Store 第一。

回顧過往，Alexander Embiricos 也坦言，Codex 的路徑并非一開始就清晰。

早期的 Codex“太過未來”，采用遠程異步交互方式，這符合資深工程師的習慣但對大部分工程師并不友好。而真正的拐點來自一個關鍵調整：團隊將 Codex 從云端遷回本地，讓它直接在工程師的 IDE 中工作，才更接地氣起來。

目前的 Codex，在 Alexander Embiricos 看來，像一個“聰明但不會主動的實習生，寫代碼寫的很快。”而 Codex 一直在自我監督，自我訓練，不斷進化。Alexander Embiricos 期待未來 Codex 可以真正參與軟件開發的全流程，成為工程師的好隊友。

Alexander Embiricos 還談到 OpenAI 的組織文化，他驚嘆于 OpenAI 的速度與野心，迭代速度之快聞所未聞。比起其他組織的“先瞄準在射擊”，他認為 OpenAI 的獨特之處，正在于“先射擊，再瞄準”，即先發布，再根據真實使用反饋優化路徑。而搜集世界最優秀的人才與自下而上的文化，使這種高速迭代成為日常。

對于未來 AGI 會何時到來，Alexander Embiricos 也給出了一個有趣的視角，他認為當前真正的限制 AGI 的因素不是模型能力，而是人類——我們輸入速度有限、審查速度有限，正在拖累其發展。

他做了一個預判，第一批生產力曲線出現陡增的用戶將在明年出現，其后的變化會加速擴散。“當增長曲線突然變得異常陡峭時，”他說，“我們可能就已經站在 AGI 的門口。”

播客里還分享了更多關于 Codex 背后的細節和 Alex 的精彩觀點，我們翻譯了該內容，并在不改變原意基礎上進行了刪減和整理，以饗讀者。

播客精彩觀點匯集：

1. 在 Codex 的幫助下，OpenAI 僅用了幾周時間，就憑借兩三位工程師的協作，打造出了 Sora 安卓應用，并使其在 App Store 排名第一。Sora 應用從零到員工測試僅用了 18 天，并在 10 天后正式發布。Codex 通過分析現有的 iOS 應用、制定工作計劃以及同時比較兩個平臺來實現功能，從而提供了極大的幫助。

2. 即使人工智能模型明天停止改進，我們仍然需要花費數年時間進行產品開發，才能充分發揮它們的潛力。這項技術的發展速度超過了我們目前能夠最佳利用它的能力。

3. 充分利用 Codex 的關鍵在于：選擇最棘手的問題，而不是最簡單的問題。這些工具旨在解決棘手的 bug 和復雜的任務，而不是簡單的任務。從那些你平時需要花費數小時才能解決的問題入手。

4. OpenAI 最初的 Codex 產品“過于超前”。它以異步方式在云端運行，這對高級用戶來說很棒，但對新手來說卻很困難。當它將 Codex 帶回工程師們日常工作的地方——他們自己的電腦上的代碼編輯器——時，其增長速度呈爆炸式增長。過去 6 個月里，Codex 的使用量增長了 20 倍。

5. 編寫代碼可能成為人工智能完成任何任務的通用方式。人工智能與其點擊界面或構建單獨的集成，不如即時編寫小型程序，這樣才能發揮最佳性能。這意味著每個人工智能助手都應該內置編碼能力，而不僅僅是專門的編程工具。

6. OpenAI 的設計師現在編寫并發布自己的代碼。設計團隊維護著一個由人工智能輔助構建的、功能齊全的原型。當他們有了想法，他們會直接編寫代碼、進行測試，并經常自行提交到生產環境。只有當代碼庫特別復雜時，工程師才會介入。

7. 人工智能生產力的最大瓶頸不是人工智能本身，而是人類的打字速度。限制因素在于你輸入提示的速度以及你審查人工智能生成工作的速度。在人工智能能夠更可靠地驗證自身輸出并主動提供幫助之前，我們將無法看到這些工具所能帶來的全部生產力提升。

8. 編寫代碼的樂趣正在逐漸被審查人工智能生成的代碼所取代。工程師們曾經熱愛構建代碼的創造性過程，而現在他們卻花費更多時間閱讀人工智能生成的代碼。下一個挑戰是如何讓代碼審查過程更快、更令人滿意。

9. 新型人工智能模型現在可以連續工作 24 到 60 多個小時來完成單個任務。一種名為“壓縮”的技術可以讓人工智能在內存耗盡之前總結其學習到的內容，然后在新的會話中繼續工作。這使得人工智能能夠實現以前無法實現的通宵或多天自主工作。

10. 如果你現在要創辦一家公司，深入了解特定客戶比擅長產品開發更重要。產品開發變得越來越容易。如今，真正的優勢在于知道該開發什么產品，以及為誰開發產品。

OpenAI 的速度、

文化與用人方式

Lenny：我想先從你在 OpenAI 的經歷談起。你大約一年前加入 OpenAI。在那之前，你創辦自己的公司大約五年，再之前你在 Dropbox 擔任產品經理。OpenAI 顯然是一家與你過去工作過的所有公司都截然不同的地方。我想問，在 OpenAI，最特別的運作方式是什么？你在那里學到了什么，是你認為無論未來走到哪里（假設你有一天會離開）都會帶走的？

Alex：到目前為止，我覺得在 OpenAI 工作的節奏和雄心遠遠超出我的想象。說這句話時我會想到，以前在創業圈，每個人都認為自己的公司速度快、人才要求高、目標宏大，但來到 OpenAI 后，我意識到這些詞在這里意味著完全不同的尺度。在 OpenAI，我重新理解了“速度”和“雄心”真正的含義。

我們常聽到外界感嘆人工智能公司的發展速度快，而我首先想到的例子就是模型本身的爆炸式增長。盡管我們擴大了外部數據規模，但像 Codex 這樣十倍級別的模型增長只在幾個月內完成，其后的進展又繼續加速。至少對我而言，在經歷那些階段之后，我發現自己在打造科技產品時，會自然把目標設定為達到那種速度和規模，否則就會覺得不足。相比之下，我在創業公司所經歷的節奏顯得慢得多。

創業過程中往往需要權衡投入與失敗的可能性：先嘗試、再轉型。不過在 OpenAI，我深刻意識到影響力之巨大，而要把工作做好，需要投入極高的精力。這種需求迫使我更加果斷地安排時間。

Lenny：在繼續往下之前，我想追問一件事：像 Codex 這樣能迅速推進的團隊，是否有某種特別的組織架構或結構性原因？還是因為我對開源軟件的運作方式不夠了解，所以才讓團隊能這樣快速前進？一定存在一些結構讓這一切發生。

Alex：一方面，我們所使用的技術本身就徹底改變了很多事情，包括我們構建產品的方式，以及能夠為用戶實現的功能。雖然我們經常討論基礎模型的改進，但即使我們停止模型層面的進展（雖然事實上并沒有），我們在產品開發方面仍然落后很多，還有大量產品尚未實現。可以說，這個領域的成熟度遠高于外界想象。

不過，也有很多讓我意外的地方。剛到 OpenAI 時，我對組織架構了解不多。例如，以往在創業公司或在 Dropbox 擔任產品經理時，鼓舞團隊士氣、確保團隊朝正確方向前進，是極其重要的標配工作。但在 OpenAI，由于我們并不確切知道近期會出現哪些功能，也不知道哪些功能最終奏效，即便從技術層面可行，也無法確定最終結果，因此需要保持謙遜，通過不斷嘗試來學習。

這里的組織架構設計為高度自下而上運作，每個人都渴望快速推進。許多公司聲稱是自下而上，但 OpenAI 真正如此。這對我來說是寶貴的學習經驗，也讓我意識到未來可能很難再回到非人工智能公司工作。我甚至不確定那意味著什么。如果讓我重新回到過去，我的做事方式一定會完全不同。

Lenny：我聽到你的描述，感覺更像“預備、射擊、瞄準”，而不是“預備、瞄準、射擊”。許多人工智能公司的思路似乎是：因為不知道用戶最終會怎樣使用產品，所以花大量時間把產品做到完美毫無意義。最好的方式是盡快發布，觀察人們如何使用，再快速迭代。

Alex：這個比喻有一定道理，但目標成分本身是模糊的。我們大致預測未來可能發生什么，但其中仍有大量不確定性。一位研究主管常說，在 OpenAI，我們可以就一年后的未來展開高質量對話，但越接近那個時間點，反而越難做出理性規劃。我們會構想遠期未來要實現什么，尤其在人工智能對齊等議題上，我們必須考慮非常長期的未來。但當真正進入產品階段后，我們會開始關注戰術層面的細節，例如具體要構建哪些產品、人們會如何實際使用。產品方面，我們更依賴實證研究來驗證。

Lenny：當人們聽到你們的做法，會覺得像你這樣的公司可以大膽嘗試許多事情，并且在未來幾個月內不必制定嚴格計劃。但關鍵是，你們聘用了世界上最優秀的人才，這似乎是讓這樣的公司取得成功的關鍵因素。

Alex：這點讓我非常有共鳴。我剛加入時，對每個人展現出的個人動力與自主性感到震驚。我認為 OpenAI 的運作方式無法靠閱讀一篇文章或聽一檔播客就復制到其他公司。這樣說可能直白，但很少有公司擁有能夠以這種方式運作的人才。如果要讓這樣的模式在別處出現，大概率必須做出許多調整。

Codex 的定位、

核心哲學與產品愿景

Lenny：那我們來聊聊 Codex。你是 Codex 的負責人。Codex 現在進展如何？你能分享一些數據嗎？另外，也不是所有人都清楚 Codex 是什么，你能解釋一下嗎？

Alex：Codex 是開源編碼智能體，更具體來說，它是一款 VS Code 的 IDE 擴展，你可以安裝擴展或終端工具。安裝后，你可以與 Codex 互動，回答與代碼相關的問題，編寫代碼，運行測試，執行代碼等，也就是軟件開發生命周期中最繁重的部分——實際編寫將被部署到生產環境的代碼。

更廣泛來說，我們認為 Codex 是軟件工程團隊成員的起點。當我們談到“隊友”這樣的詞時，我們設想的并不僅是讓它編寫代碼，而是讓它參與軟件編寫的整個流程，從構思、規劃，到下游的驗證、部署與維護。

我喜歡把今天的 Codex 想象成：一個非常聰明的實習生，但不會查看 Slack，也不會主動檢查像 Sentry 那樣的監控系統，除非你要求它這么做。因此，即使它非常聰明，你也不會完全放手讓它在無人監督的情況下編寫代碼。現在大多數人使用它的方式仍然是與它結對編程。

但我們希望未來能達到這樣一種程度：就像你雇傭新實習生一樣，不只是讓他們寫代碼，還讓他們參與整個流程。即使他們第一次嘗試不完全正確，他們會持續參與并通過迭代最終實現目標。

Lenny：我理解你提到的 “不會看 Slack” 的意思，是說它不會分心，總是全神貫注在工作上。但你的意思是它無法掌握正在發生事情的完整背景，對吧？對于團隊中最優秀的成員來說，你不會告訴他們每一步該怎么做，你只是在最初幾次會議中讓他們了解你的溝通方式，然后他們就能在團隊中獨立工作，甚至主動與代碼庫的其他部分協作。

Alex：是的，我們認為一個真正優秀的隊友應該是積極主動的，而 Codex 的一個主要目標就是讓智能體具備這種積極主動性。我認為這是實現 OpenAI 使命的重要部分——讓人工智能真正造福全人類。

當下的人工智能產品實際上很難使用，因為用戶必須非常明確地思考何時向模型尋求幫助。如果你不主動發出請求，模型就無法提供幫助。如今，一個普通用戶可能每天只向人工智能發出幾十次指令。但如果一個系統真正智能，人類每天能從它獲得數千次幫助。

因此，我們與 Codex 合作的大部分目標，是弄清楚如何打造這樣一種默認情況下就能提供幫助的“隊友智能體”。

Lenny：當人們想到 Cursor 或云端代碼工具時，它們像集成開發環境，能輔助寫代碼、自動補全等。我聽出你描述的愿景不同，你指的是一個真正像遠程隊友一樣為你構建代碼的系統。你可以與它對話，讓它執行操作，同時也擁有 IDE 自動補全等功能。你們對 Codex 的思考方式究竟有什么不同？

Alex：我們的目標是讓開發者在完成任務時感覺擁有超能力，以更快的速度完成工作，同時不必處處停下來思考“我現在應該如何調用人工智能來完成這件事？”。它應當像系統的一部分一樣與你協作，當你做出動作時，它就能自動開始工作，而不需要你為它操心。

Codex 的技術突破、

增長動力與三層系統結構

Lenny：我還有很多類似的問題。不過我想先問一下：Codex 的進展如何？有沒有一些可以分享的統計數據或數字？

Alex：Codex 自發布以來一直呈現爆炸式增長。GPT-5 在八月份發布，當時我們已經觀察到一些非常有趣的產品洞察。如果你感興趣，我可以詳細說明這種增長是如何發生的。我們上次公開的數據是，自八月以來 Codex 的使用增長超過十倍，而現在已經達到二十倍。Codex 模型目前每周服務數萬億級的代幣，是我們最受歡迎的編碼模型。

我們做的一件重要事情是組建了一個緊密整合的團隊，讓產品與研究團隊共同迭代模型與框架。這種方式讓我們可以更快速地開展更多實驗，理解模型與工具如何協作。我們訓練模型時使用自己的框架，并對框架持有非常明確的觀點。最近，我們開始看到其他大型 API 編碼客戶也采用類似方法，這些模型因此變得更加通用。

如今，Codex 已成為使用最廣泛的編碼模型，API 中也有相應的版本。

Lenny：你提到過“增長被解鎖”，我對此很好奇。在你加入之前，我感覺云端代碼幾乎統治一切，每個人都在使用它，它是當時最好的代碼生成方式。但后來 Codex 出現，我記得 Karpathy 發過一條推文，說他從未見過這樣的模型。他遇到一個非常棘手的 bug，花了幾個小時都無法解決，結果讓 Codex 跑了一個小時，它就解決了。你們是怎么做到的？

Alex：OpenAI 一直有一個非常明確的使命，就是構建 AGI。因此我們持續思考如何讓產品能夠在更大規模中發揮作用。正如我之前提到的，一個工程師如果能夠每天從人工智能那里獲得數千次幫助，那才是真正的價值。所以我們不斷反思模型與產品應該如何演進。

當我們推出第一版 Codex（Codex Cloud）時，它幾乎相當于擁有一臺屬于你自己的云端計算機，你可以把任務委托給它，這本身就非常驚人。其中一個主要優勢是你可以并行運行大量任務。但是，它也有一些挑戰，例如環境配置復雜、設置麻煩，以及模型必須通過工具去驗證更改、學習如何使用這種提示方式。

以我常用的類比來說，這就像你雇了一位隊友，但你永遠無法與他實時對話，只能遠程、異步來回溝通。對某些人來說，這確實是一種有效的工作方式，也可能成為未來的重要方向。但在早期階段，它對新用戶的門檻非常高。

因此，我們仍然保持“可委派且主動”的愿景，但必須先以更直觀的方式讓用戶從中獲得價值。如今，大多數用戶是通過 IDE 擴展或 CLI 使用 Codex，讓智能體在本地與你協作。你的電腦提供環境，它在沙箱中操作，確保安全可靠，同時可以訪問必要的依賴。如果某個命令無法在沙箱中運行，它會詢問你，讓你介入。這讓模型能進入一個強大的“反饋循環”，而我們團隊的任務就是讓這種反饋循環逐漸成為產品使用的自然副產品。

如果把模型比喻為團隊成員，給他一臺剛從商店買來的全新電腦——沒有密碼、沒有權限、沒有工具——他很難發揮作用。但如果你和他并肩工作幾小時，你會不斷為他補齊各種權限、工具與操作方式，而在獲得這些前提后，他就能獨立工作數小時。

因此，我的理解是：最初版本的 Codex 太“未來”，像一個遠程云端智能體，以異步方式工作；而你們所做的，是把它重新拉回開發者熟悉的環境，讓它在 IDE 本地工作，使用戶更容易習慣新的開發方式。

Alex：這很有意思。在 OpenAI 內部，我們長期依賴 dogfooding（自己用自己做的產品）來推進產品的發展。通過在真實環境中持續使用自己的產品，Codex 在過去一年里顯著加速了公司的工程進程，不論是云端還是本地版本都讓整體效率獲得巨大提升。

不過，內部獲得的反饋與市場反饋并不完全一致。因為 OpenAI 的工程文化本身就以提示驅動為中心：先通過提示規劃任務，再依賴大規模并行執行，最后異步收集結果。這種工作流程對我們來說非常自然，但對大多數外部用戶而言卻并非直覺，他們并不會天然以模型為中心組織開發。

因此在構建產品時，我們依賴內部信號，但也必須清楚地意識到不同使用者之間存在巨大差異，需要同時為專家和新手提供可理解的工作路徑。

Lenny：我很好奇，訓練數據在其中是否也發揮了作用。Codex 的進步究竟來自更干凈或更好的數據，還是更多來自模型本身的提升？有哪些因素真正推動了它的加速？

Alex：這確實是大家常見的疑問：Codex 的能力提升究竟是因為數據變得更好，還是來自模型本身？實際情況是多方面共同作用。

首先，模型本身確實有巨大提升。就在上周三，我們發布了 GPT-5.1.1 Codex Max，這個名稱非常貼切。它之所以出色，是因為在你之前使用 GPT-5.1 Codex 處理的任何任務上，大約能快 30% 完成，同時它的推理能力也顯著增強。在更高層次的任務中，它表現得更智能。

你提到 Karpathy 的推文，那類“給我你遇到的最棘手的 bug，我讓模型試試”的例子現在明顯增多，而 Codex Max 特別擅長處理這些困難問題。這本身就讓我們覺得非常激動。

不過我們現在的思考方式有所變化。過去，我們更多認為“只要訓練最好的模型就好了”，但現在我們意識到真正的智能體并不只是一種模型，而是由三層結構組成：一個非常智能的推理模型、一套 API，以及一個能讓模型發揮能力的框架。

例如，我們非常自豪 Codex 能夠連續長時間運行。有時我們甚至收到用戶反饋，說模型連續運行了 24 小時或更久。這已經超過傳統模型的上下文長度，因此我們必須為此設計出解決方案，也就是“壓縮”。模型需要理解壓縮的概念，API 必須能接收壓縮指令，框架最終負責傳遞這些信息。三者缺一不可。

市場上各種編碼工具各自擁有完全不同的工作方式，有的強調語義搜索，有的依賴自定義工具，有的像我們這樣強調 shell 操作。如果想訓練一個模型，讓它在所有框架下都表現最佳，可能并非不可能，但速度一定會被拖慢。因此，我們在 Codex 中保持明確主張，讓它只使用 shell，并在沙盒環境內運行。這讓模型能夠快速學習適合這一環境的操作行為，也讓整個系統更加可靠。

因此，回到你提出的問題，真正的加速來源于我們同時構建這三層結構，并持續針對每一層進行調整，再觀察它們如何協同作用。這種緊密整合的產品與研究合作方式，是 Codex 能快速成長的核心原因。

寫代碼是模型最好的

方式與編碼智能體的未來

Lenny：從你的描述來看，真正推動 Codex 的，不只是模型能力的提升，而是模型、API 和框架三者共同構成的整體系統。我很好奇，從更高層次來看，你認為人工智能和編碼智能體的未來會走向什么方向？

Alex：我認為未來的人工智能智能體會逐漸擺脫“被動工具”的角色，轉向“主動隊友”的角色。今天，大多數人工智能工具仍然依賴用戶提出明確指令，它們并不會主動參與你的工作流程。但一個真正智能的系統應該能夠做到默認幫助你，而不是等待你下達命令。

回到軟件工程的例子，如果你把人工智能視為隊友，那么你不會希望每一個任務都必須以詳細指令開始。你希望它能自動理解上下文、自動介入流程，并在你需要之前采取行動。我認為未來的智能體應該能夠在軟件開發的不同階段參與，包括規劃、構思、驗證、部署和維護，不再局限于編寫代碼。

我們希望模型具備足夠的判斷能力，能夠識別當前任務，理解它在整個開發生命周期中的位置，并根據情況主動采取行動。這不僅是提升效率，而是改變整個開發流程的思維方式。

從更廣義的人工智能未來來看，我們的目標始終是構建真正能夠造福所有人的人工智能。讓智能系統成為世界上每一位使用者的隊友，讓每個人都能因為人工智能而擁有更高的生產力、更強的創造力，以及更公平的資源獲取能力。這是 OpenAI 的使命，也是我們構建這些智能體系統的最終方向。

Lenny：聽起來，智能體未來不只是工具，而是真正的團隊成員。你剛剛提到 Codex 的構建方式與其他編碼產品不同，因為它有非常明確的框架與主張。我想更深入理解這意味著什么。為什么保持這種“強主張”如此重要？

Alex：如果你觀察市場上各種編碼產品，會發現它們有完全不同的工具框架與非常不同的理念。例如，有些系統主張一切靠語義搜索，有些依賴定制工具，有些讓用戶自己設計輸入方式，而 Codex 的核心主張是讓智能體像一個在 shell 中工作的工程隊友，并讓整個系統圍繞這個工作方式展開。

如果我們試圖讓模型同時適應所有不同的框架，速度會變得極慢。因為模型必須學會彼此沖突的行為方式，而訓練過程會被分散、干擾，最終無法做到任何一個方向的最佳表現。保持明確主張，使我們能在一個清晰的環境下快速迭代，并利用沙盒確保安全可靠。

讓智能體在 shell 環境中工作不僅是為了熟悉度，也因為它能最自然地與開發者的實際工作流程結合。模型會在一個穩定的環境中執行操作、驗證結果、處理依賴，從而形成一個強大的反饋循環。我們再根據這個反饋循環調整模型、API 和框架，讓三者形成緊密協作的結構。

因此，真正的加速來自于我們明確地構建模型、API 和框架三層結構，讓它們成為一個完整的智能體系統，而不是分散的組件。

Lenny：你覺得在這個領域最終該如何取勝？人工智能是否會一直處在公司之間互相競爭、模型不斷互相超越的狀態？會不會出現某家公司能夠獨占鰲頭，讓其他人永遠追不上？是否真的存在一條明確的通往勝利的道路？

Alex：這讓我想到一個重要概念：人工智能的未來不僅是擁有幾個你認識的隊友來幫你寫代碼，而是擁有一種真正意義上的團隊合作精神。工程團隊的成員做的事情遠遠不止寫代碼，他們會安排日程、移動會議、主動修復問題、提出建議，甚至在你還沒開口前就做出正確的行動。現在想象一個世界，幾乎每天都有研究實驗室發布匪夷所思的新技術，對人類來說要跟上這種節奏，必須依賴這樣的團隊力量。而人工智能將成為這種團隊的一部分。

未來的超級助手應該是這樣的存在：你只需要開口，它就知道該怎么幫助你。你不需要學習它的功能，也不需要閱讀使用技巧，只要啟用它，它就能立即發揮作用。如果我們能構建出這樣一個系統，它就會成為一個極具競爭力、也極可能勝出的產品。

Alex：在我看來，聊天是一種非常好的人工智能使用界面，特別是在你不知道該怎么做的時候。就像我在 Teams 或 Slack 里和隊友交流一樣，聊天是一種自然且通用的方式。我可以提出任何問題，不論是否與編程有關，而一個超級助手應該在這種對話里表現得和隊友一樣。當你需要深入代碼時，你會使用更專門的工具，例如一個深度集成代碼環境的智能體。當你只需要表達任務時，聊天就夠了。所以我們希望構建的人工智能既像 ChatGPT 這樣的通用助手，也能在專業領域，例如編程里，發揮深度能力。就像 ChatGPT 已經成為很多人生活的一部分一樣，你甚至在工作之外也會使用它。等你開始工作時，你自然會說：我直接問它就好了。我不需要了解所有功能連接器，它會告訴我它能做到什么，甚至會在我沒提問時主動提供幫助。如果我們能達到這樣的狀態，我認為這就是一條構建成功產品的道路。

Lenny：我和 ChatGPT 負責人 Nick Charlie 聊過，他說 ChatGPT 的最初名字其實非常接近“超級助手”。看起來這一條超級助手的路線，與編碼智能體的路線幾乎像是 B2C 和 B2B 兩種版本。一個更偏面向大眾，一個更偏團隊應用、編寫代碼、自動執行各種任務。這也是你們的設計理念嗎？就像企業版的 ChatGPT？

Alex：我們現在討論的內容橫跨大約一年的產品演進時間，許多事情可能會發生得很快，也可能還需要時間。不過我可以解釋其中的邏輯。要構建一個超級助手，它必須能夠真正“做事”，并不是停留在生成文本的層面。

過去一年我們學到的一個核心經驗是：模型要真正發揮作用，必須能夠使用電腦，而且需要能夠熟練使用。于是我們開始思考，模型應該以什么方式使用電腦。理論上可以嘗試模擬操作系統或使用鼠標式的點擊，但這些方式既慢又不穩定。事實證明，最強大、最可靠的方式，就是讓模型通過編寫代碼來操作電腦。編碼是人工智能最自然、最高效的行動方式。因此我們越來越明確地意識到，如果你想構建一個通用智能體，它其實一定會具備編寫代碼的能力。即使用戶不是工程師，他們也可能不會意識到智能體正在通過寫代碼完成任務。就像人們不關心自己是否在使用互聯網，只會問 Wi-Fi 有沒有連上一樣。

這也是我們在 Codex 上構建的核心：它是一個軟件工程團隊的助手，而它能做事情的方式，就是寫代碼。隨著我們看到越來越多人用 Codex 做產品相關的任務，我們也更確信，幾乎所有強大的智能體最終都會通過編寫代碼來完成工作。

Alex：這也是智能體真正強大的地方。通過寫代碼，智能體能夠構建可組合、可重復使用的能力。代碼可以被導入、被共享，就像團隊成員之間共享腳本一樣。否則，一個只能通過點擊操作界面的智能體，其能力是無法積累、復用或共享的。因此，當我們問“通往勝利的道路是什么”，答案不是模型彼此比速度，而是構建一個能夠寫代碼、能隨著團隊使用而成長的智能體體系。未來用戶加入團隊時，可以直接繼承智能體此前寫過的腳本和能力，就像新人入職時繼承團隊的內部工具一樣。這會形成一個不斷累積的系統，而不僅是模型單點的智能。

Lenny：Karpathy 曾說過，現在的智能體大多還很弱，但未來會非常強大。你對此怎么看？

Alex：我認為編碼智能體現在已經非常有價值，而代碼之外的智能體還在早期階段。我的個人判斷是，當所有智能體都能通過編程以可組合的方式行動時，他們才會真正變得強大。這也是為什么為軟件工程師構建產品如此重要。軟件工程師本身喜歡構建、喜歡創造，他們會用各種方式推動工具進化，而這些涌現行為非常值得觀察。你能從工程師如何使用你的工具里學到巨量東西，也能更清楚應該把什么融入產品。

AI 對軟件工程與

產品開發的影響

Lenny：關于工程行業，你知道很多人一直在討論未來是否還需要學習編程，工程師是否會被人工智能取代等問題。但你把人工智能描述成隊友，一個與你并肩作戰的存在，讓你變得更強，而不是替代者。你認為，當人工智能像隊友一樣與工程師協作，會對整個工程行業產生怎樣的影響？

Alex：這是一個非常復雜的問題，但可以從幾個方向理解。我們剛才討論過，每個智能體最終都可能需要通過編碼的方式來完成任務，而這其實只是更大理念的一部分。隨著代碼變得越來越普及，它會被用于更多場景，而不是更少。即便在人工智能出現之前，代碼已經無處不在，而人工智能只會讓編程變得更加核心和普遍。因此，具備這種能力的人類工程師反而會更加重要，他們能夠理解問題、設計系統、與人工智能協作、提出判斷，而這些能力會變得越來越有價值。我認為人工智能并不會讓工程崗位消失，而是會改變工程師的工作內容。現在我們要思考的是，作為產品團隊，我們應該如何構建工具，讓人類的成長速度最大化，而不是讓他們因為工具太復雜而失去方向。

比如現在與編碼智能體合作時，大量代碼是由智能體寫出的，但我們發現許多工程師真正感到樂趣的部分，是寫代碼本身，而不是審查他人寫的代碼。審查代碼通常是軟件工程中最枯燥也最耗費精神的部分之一。現在人工智能能寫出大量代碼，意味著工程師需要更多時間去審查，而不是創造。這讓工作體驗變得更乏味。所以我們開始思考怎樣讓產品變得更有趣，讓用戶感到擁有掌控感，而不是覺得自己被迫花時間檢查人工智能寫的東西。我們加入了代碼審查功能，讓用戶能更快建立對人工智能輸出的信心；我們讓智能體在執行任務時更努力地驗證自己的工作結果，讓它先檢查，再讓用戶檢查；我們甚至會思考在界面上用戶應該先看到什么，例如對于一個界面組件，如果智能體同時生成了代碼和圖像預覽，我們會讓用戶先看到圖像，因為那才是工程師真正關心的最終結果。只有當圖像已經展示而且經過智能體審查后，才需要用戶查看代碼本身。

Lenny：我之前采訪過 Cursor 的 CEO Michael，他提到一種趨勢叫“規范驅動開發”，也就是你只需要寫規范，由人工智能負責寫全部代碼。他認為未來工程師會在比現在更高的抽象層面上工作，而不再需要真正編寫或查看大量代碼。你認為工程未來會朝這個方向發展嗎？

Alex：我認為抽象的層級一定會繼續提升，而且其實已經在提升了。今天許多開發方式本質上就是一種提示驅動的改寫，人們已經開始通過更高層的描述來讓人工智能完成工作。像規范驅動開發、計劃驅動開發等方式已經有人在使用，比如當人們問“如何讓 Codex 在某個任務上持續工作更長時間”時，他們通常會先寫一個類似 Markdown 的計劃文檔，確認步驟和目標，再讓智能體執行。如果計劃本身具有結構性和可驗證性，智能體就能執行很久。但規范驅動開發是否適用于所有人，我不是很確定，因為不是每個人都喜歡寫規范。確實有一些人天生使用規范來組織思想，但很多團隊并不是這樣工作。

我有一個更接近現實工作的比喻：許多團隊最終完成任務的方式，其實更像“聊天驅動開發”。團隊成員在聊天工具里不斷討論、同步、修改、決策，流程在對話中自然推進，任務在溝通中就完成了。并不是每件事都需要正式規范，而是有人提一個想法，有人再補充說明，有人提出下一步行動，然后工程師直接去做。這種方式其實比寫規范更普遍，也更貼近日常行為模式。如果人工智能智能體要融入團隊，它很可能也會遵循這種方式。對于小問題，人們不想寫規范，只想說一句話，比如“這個小 bug 修一下”。對于客戶反饋，人們只想把信息丟給它，讓它自己去理解并處理。在我設想的未來，人工智能將能夠完全融入這種日常溝通流中，以聊天作為主要工作方式，而不是依賴正式文檔。

我甚至曾想象過一個極端版本的未來：智能體人像使用手機一樣工作，它看到的一切都是豎屏視頻流，用戶可以像刷短視頻那樣快速瀏覽智能體提出的建議。如果不喜歡就左滑，如果覺得不錯就右滑，也可以按住錄音直接補充指令。這種形式聽起來有點荒謬，但它抓住了一個關鍵點：智能體會持續觀察外部信號、用戶行為、市場動向和團隊狀態，并主動提出它認為重要的事項。就像一個特別積極主動的工程隊友，會告訴你應該構建什么、應該修復什么，它會自己跟蹤情況，隨時把重要事推到你的面前。雖然我們沒有在做這個“滑動式智能體應用”，但這種思路很好地展示了智能體可能的未來形態。

Alex：在這個未來智能體的設想里，它會持續吸收外部信號，而這點讓我覺得特別重要。回顧一些成功的人工智能產品，像我們在 OpenAI 早期用過的 Branded Codebase，它最初就是 GitHub Copilot 背后的模型，后來我們又重新使用了這個品牌，因為它確實非常出色。雖然代碼執行很強大，但我其實更喜歡自動補全功能。自動補全可能是迄今為止最成功的人工智能產品之一，它的神奇之處在于，它總是在你需要靈感的時候出現，而且能迅速提供幫助。如果它偶爾犯錯，通常也不是太煩人，這種錯誤的代價很低。它讓我意識到自動補全是一種混合主動性的交互方式，它會根據你正在做的事情提供情境化的響應，在你行動的瞬間與之配合。這種特性非常值得我們繼續探索。

當我想到瀏覽器產品，比如我們之前發布的 Atlas，我覺得瀏覽器可能是人工智能下一步可以深度介入的位置。在瀏覽器里，人們每天處理的大量信息并不是代碼，而是各種網頁內容。如果人工智能能在這個空間里主動幫助你，它就能像隊友一樣處理許多與工作相關的事務。一個真正的隊友不會只處理你給到的任務，而是會在你瀏覽網頁、查資料、閱讀文檔的時候主動理解你在做什么，并快速提供協助。瀏覽器是一個天然的環境，因為它承載了大量情境信息，也包含多種形式的信號，而這些信號對智能體判斷你真正需要什么至關重要。

Lenny：我真的很喜歡你剛才說的那段，因為它信息量非常大，非常豐富。瀏覽器里的自動補全也是很有意思的概念。想象人工智能可以在網頁、草稿、研究資料等一切你正在瀏覽的內容中主動幫助你，這太迷人了。我之后還想問你更多關于 Atlas 的內容。另外，你剛剛提到代碼執行能力也很巧妙，我覺得我現在開始看到整個體系是怎么串聯起來的了。

Lenny：我之前采訪過 Block 的 CTO John。他們有一個內部智能體系統叫 Goose。他講過一個例子，說有個工程師走進辦公室，一只“鵝”就像隊友一樣盯著他，監聽他的所有會議內容、關注項目進展，并主動幫他做正確的事情。它會提交 PR、寫郵件、草擬 Slack 消息，就像一個主動的工程師隊友一樣，這和你描述的路線非常接近。

Alex：是的，這很有趣。如果我們問他們在生產力上遇到的瓶頸是什么，我敢猜可能就是那些需要不斷查看的事物，而他們構建的 Goose 正是針對這種問題。在 Codex 里我們也看到類似情況，人們非常喜歡用 Codex 集成 Slack，特別是在需要快速處理問題的時候。比如在 Slack 里問它某個 bug 為什么出現，數據科學家會問某個指標為什么變化，它可以直接在 Slack 窗口中給出分析。這種體驗非常自然，也很容易被團隊接受。但一旦涉及真正寫代碼，人們還是需要回到代碼環境里去看實現。

我認為現在真正的瓶頸已經不在于寫代碼本身，而在于驗證代碼是否正確。工程師能愿意寫代碼，但大型團隊投入最多時間的活動往往是代碼審查和驗證，尤其是最后階段的質量把控。如果我們想要讓智能體真正融入工程團隊，就必須讓團隊能夠為智能體配置更多自主性，讓智能體在后期流程中承擔更多責任，而不是把大量驗證任務重新推回給工程師。

Alex：寫代碼是愉快的，但檢查別人寫的代碼往往不是。尤其當你需要負責最終上線質量時，任何微小的錯誤都可能導致生產環境崩潰，而你必須對這些問題負責。現在人工智能能寫大量代碼，但團隊最終要花更多時間去驗證它寫的東西，這讓工程的后期階段成為新的瓶頸。這也是我們不斷思考的一件事：如果我們希望智能體真正幫助人類，而不是把工程師推出流程之外，我們必須讓智能體獲得更多在后期階段的自主性，并且讓團隊能夠配置智能體，使它在驗證、檢查、審閱方面承擔更多實際責任。否則工程師永遠會卡在最后的審查階段，被迫花大量時間做他們并不喜歡的部分，而不是構建與創造。

Lenny：你說的完全符合我從其他公司聽到的情況。許多真正處在技術前沿的團隊現在遇到最大的瓶頸并不是寫代碼，而是弄清楚要構建什么，然后在最后階段花大量時間審查、確認、驗證。如果一個項目需要一百個小時，有八十個小時可能都花在審查與驗證上，而不是構建本身。你剛才提到的這種方向，確實非常接近許多公司正在思考的未來。

Codex 如何影響產品經理的運作方式

Lenny：Codex 對你作為產品經理的工作方式帶來了哪些影響？我們已經知道它明顯改變了工程部門，比如代碼是 AI 幫寫的。那么它對你以及 OpenAI 的項目經理帶來了什么實際變化？

Alex：對我來說，我感受到的最大變化是“能力被大幅增強”的感覺。我一直都是偏技術型的產品經理，特別是在為工程師構建產品時，我總覺得必須深入理解產品本身，像吃自己的狗糧一樣使用它。但現在的感覺是，你不僅能理解產品，還能做遠比以前更多的事情。Scott Belsky 曾談過“壓縮人才階層”的想法，也許我沒有說得很準確，但意思是角色之間的界限變得模糊了，對某些角色的需求比以前少了，因為每個人能做的事情變多了。每當你做一件事，你就突破一次溝通障礙，于是整個團隊的效率也被抬高了。

如果你問更具體的產品工作方式，現在我可以直接問 Codex 各種問題，獲得意見，也能快速了解新的變化。原型設計也變得更快了。很多人談到規范文檔，不過在我看來，真正讓我意外的是，我們原本構建 Codex 的核心目標，是讓它編寫能夠被投入生產的代碼。然而我們現在看到的大量實際用例，卻是工程師用 Codex 來寫“一次性代碼”。這種現象讓我感覺像是回歸了“無處不在的代碼”這個古老的想法。

許多人開始用 Codex 做信息分析，他們把一堆數據丟進去，讓 Codex 幫他們構建一個交互式的數據查看器。這種事情以前做起來很麻煩，現在卻完全值得讓智能體去處理。同樣的事情也發生在設計團隊，如果設計師想制作一個動畫，他們過去必須自己寫程序，現在他們用 Codex 寫了一個臨時的動畫編輯器，再用那個編輯器制作動畫，然后提交到代碼庫里。我們的設計團隊因為 Codex 獲得了巨大的加速。他們甚至建立了類似 “Vibe-coded” 的分類體系，把自己的原型直接做成 Codex 使用的版本。

現在團隊的討論方式也發生了變化，因為成千上萬的事情同時發生，設計師往往直接在自己的原型里表達想法，而不是在文檔里討論。我們會試用他們的原型，如果大家喜歡，他們就把這個原型實現為產品界面的 Vibe Code，工程師再負責把它轉化為正式的 PR。如果代碼庫是 Rust 或 CLI 這樣比較復雜的環境，他們會做到接近目標，然后工程師幫他們完成最后提交。

最近發布的 Sora 安卓應用就是一個最震撼的例子，內部因為使用 Codex 而產生了巨大的速度提升。OpenAI 的技術復雜度非常高，而過去一年我們看到全公司各類角色的使用技巧都大幅提升，而 Codex 的影響也隨之增強。Sora 安卓版是一個全新應用，我們從零開發，只用了 18 天就做出員工可試用版本，又過了 10 天發布給公眾。換句話說，從開始到正式上線只用了 28 天。而這個過程中，Codex 幫了非常大的忙，有一種“游戲開了簡單模式”的感覺。

當你是一家必須在多個平臺構建軟件的公司時，Codex 會讓這些事情變得容易許多。工程師讓 Codex 去分析 iOS 應用，然后自動生成遷移到 Android 的工作計劃，再根據計劃執行。由于我們同時關注 iOS 與 Android，Codex 能提供很多可參考的部分，顯著加速了開發。結果就是，團隊只用了兩周時間就完成上線準備，而整個四周流程包括投產上線。更夸張的是，應用上線后馬上登頂應用商店排行榜。

Atlas 瀏覽器的開發也是類似的故事。Atlas 是一個很有分量的項目，因為構建瀏覽器本身就是非常困難的事情。我們必須構建許多底層系統，而現在的團隊基本都是高級用戶級別地使用 Codex。他們告訴我，過去需要 2～3 名工程師花 2～3 周才能完成的功能，現在只需要一個工程師一周時間。這是巨大的加速。目前團隊正在全力構建 Windows 版本，同時改進 Windows 上的 Codex 支持。最近我們發布的模型已經開始原生支持 PowerShell，這是一種非常重要的 Windows 系統語言，這也讓 Codex 在 Windows 平臺上的表現提升許多。

整個公司因為 Codex 而加速，從研究到模型訓練速度，再到設計與營銷，我們經常看到產品營銷人員直接在 Slack 里更新字符串或文案，這些都是變化的一部分。公司內部對 AI 的使用已經滲透到每個角色，速度之快讓人驚嘆。Sora 應用的成功也證明了這種變化的力量，你能想象只有兩三個工程師，卻發布了一款登頂全球應用商店的產品，這在以前幾乎不可想象。

Atlas 的開發同樣令人震撼。工程師們告訴我，他們幾乎用 Codex 處理所有事情。當我問他們“你們怎么衡量加速”，他們說，過去需要兩三周和兩三名工程師的工作，現在一個人一周搞定。你問未來是否可能讓非工程師完成這些工作？我認為這是可能的。角色邊界正在模糊化。你仍然需要對自己構建的東西的本質有理解，但具體細節將越來越抽象，就像你不用懂匯編語言也能寫 Swift，一樣的道理。

隨著時間推移，我們會看到越來越高的抽象層，接近自然語言本身的抽象。自然語言極其靈活，工程師可以用它討論計劃、規格、產品與想法，而智能體可以將這些自然語言直接轉為可執行代碼。未來不會突然變成沒人再寫代碼，所有事情都用規范文檔描述，而會是循序漸進的過渡。我們先為編碼智能體設置完善的預覽系統與測試系統，讓它能看到自己修改后的結果。下一步可能讓智能體加載示例頁面、自動檢查視覺效果。再進一步，人類負責篩選，智能體負責構建。未來 Codex 甚至能自動告訴你如何設置環境，甚至在代碼庫里自動設置。

Codex對生產力的影響、創意與

執行力的價值、垂直領域AI的未來

Lenny：生活在這樣一個劇烈變化的時代真是令人驚嘆。我很好奇這些變化會產生哪些次生影響，尤其是當構建速度變得如此之快時，會帶來什么后果？這是否意味著分發會變得更重要？創意會變得更有價值？當變化如此迅速時，你覺得我們會走向什么方向？

Alex：我仍然認為，想法本身的價值沒有很多人想象的那么高。真正困難的永遠是執行，你可以在短時間內搭建一個東西，但要讓它真正有意義、連貫、有生命力，需要極高的執行力。產品的分發依然極其重要，一切所有的前后環節都顯得更關鍵了。除了構思、上市和盈利這些核心環節以外的許多部分，都因為開發變容易而變得不再那么稀缺。

過去我們處在一個奇怪的臨時狀態，構建產品太難，因此只有極擅長產品開發的人能夠突破重圍，你甚至不需要對某個客戶群體有深度理解，也可能做出成功產品。而現在情況完全不同了，我認為如果只能選擇一件必須掌握的能力，那就是對某個具體客戶的問題擁有極其深入的理解。如果你創辦一家初創公司，并且對行業有深度洞察，同時在領域里有人脈，尤其是面對被現有 AI 工具嚴重服務不足的客戶，那么你已經掌握了成功的核心。如果你的能力很強，但沒有明確的客戶對象，情況反而會更困難。現在的時代對“深刻理解問題的人”更友好，對“只擅長構建東西的人”更不友好。

這也是為什么許多人看好垂直領域的 AI 初創公司。你可以用通用模型解決許多泛化問題，但如果你致力于把演示文稿制作做到極致，你會比任何人都更了解那類用戶的問題。你會深刻融入他們的日常工作流，你會知道哪些細節真正重要。這些東西才是最終決定性的。

衡量Codex的進步：用戶留存、

真實反饋與社區信號

Lenny：當你們評估 Codex 的發展時，會關注什么指標？你們有很多基準測試，也做了許多內部評估，那么真正讓你們判斷“我們做得很好”的指標是什么？

Alex：一個我不斷提醒自己的事情是，像 Codex 這樣的產品，本質上是一種你必須真正使用的工具。這意味著我們作為團隊，很容易變成“高級用戶”，并在無意間過度關注一些對普通用戶來說并不關鍵的功能。為了避免這種偏差，我們必須非常認真地看待用戶留存數據，尤其是 D7，也就是用戶使用后的第七天是否還會回來。

我甚至會注冊許多新賬號，只為了更真實地體驗首次使用流程。我愿意花錢去購買其他產品，只為確保我們對比的是實情。因為這個領域仍處于早期，人們對這些工具的使用習慣還沒有完全形成。

另一個特別重要的角度是社區反饋。我們有一個內部的反饋與社交媒體團隊，他們非常深入地泡在 Reddit、Twitter 等社區里。Reddit 的內容更真實，Twitter 上的討論往往更即時也更尖銳。我們非常關注這些渠道的氛圍，因為一個編碼智能體可以做很多事情，但往往會在某些細節上失敗，而這些失敗只有真實用戶才會指出。Reddit 是我越來越關注的地方，因為那里的高贊評論通常反映真實用戶的痛點與需求。

如果你問我常看哪些子版塊，我不會特別說一個名字，因為 Reddit 的推薦機制已經能把最重要的內容推給我。我只需要觀察人們真實表達的情緒，那比任何內部指標都更有價值。

為什么要做瀏覽器、Atlas的由來、

情境化助手的愿景

Lenny：你們發布了 Atlas。我在推特上說我試用了 Atlas，但我并不是很喜歡“純 AI 搜索”的體驗，有時候我就是想用 Google，不想等 AI 給我一個完整的回答，而且當時我感覺沒有辦法切換，所以我發推說我要切回去。我并不是覺得這有什么問題，但我看到好像有人因此有點受傷。我猜這其實是典型的“先發布產品、觀察用戶行為、再迭代”的例子吧。我想問的問題是：你們為什么要做一個網頁瀏覽器？

Alex：我之前在 Atlas 上工作過一段時間，說一下我自己的故事。我在加入 OpenAI 之前做過一個關于屏幕共享與結對編程方向的創業項目，而我們當時的核心理念就是構建一個具備上下文理解能力的桌面助手，因為我覺得把所有背景告訴助手實在太麻煩了，你得花很多精力解釋你在做什么，而如果助手能自己理解你的工作情境，它就能讓你的操作速度快很多。所以從某種意義上說，Codex 就像一個從編碼任務出發的“情境助手”。

對我個人來說，很多工作都發生在瀏覽器里，所以如果我們能自己做一個瀏覽器，讓智能體在更完整的上下文中幫助你，而不是像傳統桌面軟件那樣通過一種“黑客式”的方式抓取信息，那會極大改善助手的體驗。瀏覽器能夠直接訪問渲染引擎，而不是依靠截圖，也不需要依賴那些緩慢且不穩定的接口。它可以直接讀取 DOM、輔助功能樹等所有結構化信息，以更可靠的方式提供幫助。

我喜歡用電子游戲來類比，比如你走到某個對象旁邊，按下 X 鍵，游戲就會自動執行正確的互動。在軟件世界里，要做到這一點，系統必須知道你當前在做什么，需要什么幫助，并且必須有恰當的情境線索。想象我們要覆蓋的所有世界范圍的任務，智能體每天有可能幫助你成千上萬次。如果它只能通過推送通知來告訴你“我幫你做了這個”，那么你每天會收到成千上萬條 AI 通知，那一定令人崩潰。真正理想的方式是，當你專注于某個工作，比如查看儀表盤時指標突然下降，智能體可以在右側出現，為你解釋原因，并告訴你可能的解決方案，而且它只在你關心的那一刻出現。

瀏覽器讓我們能夠做到兩件最重要的事情：第一，為智能體提供完整的情境，讓它知道什么時候該幫忙；第二，讓用戶完全掌控哪些內容能被智能體看到。如果你愿意，你可以在 AI 瀏覽器中打開頁面，讓它對頁面采取行動；如果不愿意，你可以在其他瀏覽器中打開，這種清晰的邊界既保證安全又讓體驗順暢。我們希望實現一種“混合主動性”，在你最需要的恰當時刻表現出智能，而不是以通知轟炸你。

Codex的非工程應用：設計、

分析與意想不到的用途

Lenny：說到 Codex 作為超級助手，你提到它不僅能寫代碼，還能像隊友一樣幫助你工作。那么有沒有哪些非工程師對 Codex 的使用方式讓你覺得有趣或意想不到？

Alex：確實有很多意想不到的用法，但目前為止，最明顯的仍然是那些偏向技術或與編程相關的領域，比如數據團隊或做分析的人。然而我相信隨著時間推移，非工程角色會出現更多創造性的用法。現在團隊主要專注于讓 Codex 在編碼上做到極致，因為這里還有大量基礎工作要完善。

Codex 適用哪些代碼庫、

如何最好使用它、入門策略

Lenny：對于想使用 Codex 的人來說，Codex 是否能適用于所有類型的代碼？它能支持哪些語言？比如有人說“我不懂 SAP，你能用 Codex 直接幫我寫嗎”？最佳實踐是什么？

Alex：實際上，使用 Codex 的最佳方式不是給它簡單任務，而是給它最困難、最真實的問題。有些工具適合從簡單任務試用，而 Codex 的定位更像是一款專業工具，如果你想評估它的真實能力，應該讓它處理大型代碼庫里的復雜任務，例如調試一個你自己也不確定原因的 bug，讓它為你查找問題根源，再實現修復方案。

關于語言支持，我們的訓練覆蓋范圍跟真實世界的使用分布接近，只要不是特別冷門或完全私有的小眾語言，Codex 基本都能處理。對剛開始使用 Codex 的人來說，我會建議把它當成新隊友一樣，先讓它理解代碼庫，再一起制定計劃，然后讓它逐步執行任務。以這種方式，你能更快建立信任，也更容易掌握如何與 Codex 有效協作。

AI時代的技能、職業影響、

未來AGI時間表與團隊擴張

Lenny：當 AI 逐漸能寫代碼后，很多人開始問：我還應該學習編程嗎？如果我是學生，我應該學習什么？哪些計算機科學知識在未來更重要？

Alex：我認為學習編程依然非常重要，但理由正在發生變化。首先，隨著編碼智能體不斷變強，學生和職涯早期的人反而能更快做出完整作品，這意味著他們與資深工程師之間的差距縮小了。使用最新工具的熟練度將成為重要優勢。

另一面是，真正關鍵的不是“打字寫程序”，而是理解軟件系統結構、理解什么使系統高效、能夠推理復雜架構，并具備團隊溝通協作能力。AI 不會突然讓所有人不用寫代碼，而是會逐步擴展抽象層，但系統設計與判斷力仍然屬于人類。工程師仍需能配置智能體，使其驗證自己的工作。比如我們在 Atlas 工程中，有工程師專門要求 Codex 解釋自己無法自我驗證的原因，然后讓 Codex 反復循環改進。

此外，如果一個人對某個領域擁有深厚知識，例如模型訓練基礎設施、數據系統或其他復雜領域，他們依然會極具價值，因為 AI 反而會迫使這些專家使用智能體來加速自己的工作。

Codex自我訓練、自動監控系統、

未來智能體的形態

Alex：當你處于某個技術前沿領域時，會出現一種非常有趣的現象：你不僅需要深刻理解那個領域本身，還必須充分利用編碼智能體，而智能體的存在反過來又加速你推進前沿本身的能力。Codex 在 OpenAI 內部已經編寫了大量用于管理訓練運行和關鍵基礎設施的代碼，我們的研究迭代速度極快，而 Codex 在審查過程中發現了許多真正有意義的錯誤，包括一些非常隱蔽的配置問題。這讓我們看到了一種未來趨勢的影子：我們甚至開始出現類似“Codex 委員會”這樣的結構，使 Codex 幫助 Codex 自身服務訓練系統。

Lenny ：Codex 的自我訓練到底意味著什么？

Alex：在訓練過程中有大量圖表，人們必須隨時查看它們，因為訓練成本極高且變化迅速。訓練運行背后存在許多系統，其中一個系統出錯就可能導致整個訓練失效，所以 Codex 會在循環中持續檢查這些圖表的表現，并且逐漸學習如何從中推斷問題。當某個系統需要修復或暫停時，Codex 會識別出異常，提出需要采取行動的建議，甚至可能有權直接修復并重啟流程。我們仍在探索最有效的方式，但核心思路是讓智能體持續監控和優化訓練，使研究團隊能以更高效的方式推進工作。

這種能力讓我覺得未來的智能體絕不會只是一個“寫代碼工具”，它將成為一種具備持續監督能力、判斷能力和行動能力的系統成員。它理解代碼庫，卻不僅僅服務于代碼本身，而是可以在整個復雜系統運行過程中發揮“智能監護人”的作用。

關于 AGI 的時間表：

我們距離人類級智能有多近？

Lenny：AGI 的時間表眾說紛紜，很難確定真正的進展。你怎么看？我們是否正在向更像人類的人工智能逐步進化？

Alex：對我來說，這個問題更像是在思考我們什么時候能看到真正意義上的加速曲線，也就是那種典型的曲棍球棒式增長。

現在有許多限制因素，但我認為最被低估的限制因素之一其實是人類本身，比如人的打字速度、提示寫作速度、人類的多任務能力。就像你剛才提到的，你可以讓智能體監督你做的所有工作，但如果你沒有為智能體構建良好的自主機制，你仍然得不斷驗證它的工作是否正確。于是我們就遇到了新的瓶頸：你能不能審查它寫出的所有代碼？能不能驗證所有它提出的修改？如果人類在這個環節仍然處于瓶頸位置，那么整個系統就無法真正加速。

所以我們需要把這些生產力循環中的人為阻塞解除掉，把那些不斷提示與不斷驗證的步驟轉移出去。如果我們能重建系統，讓智能體能夠默認發揮作用，而不是由人不斷喚醒，那么我們就能真正解鎖那條曲棍球棒曲線。

這并不是一個非此即彼的過程，很大程度取決于你在構建什么。如果你明年是一家創業公司，正在構建一個新應用，那么你完全可能把它搭建在一個比以往更自主的智能體堆棧上。相反，如果你在 SAP 這樣的公司工作，它們有大量的舊系統，不可能一夜之間讓智能體完全接管端到端流程，它們必須逐步替換、逐步更新，讓智能體能處理越來越多的部分。

所以我對這個問題的回答可能有點無聊，但我確實認為，從明年開始我們會看到第一批早期 adopters 的生產力出現曲棍球式的躍升，而在接下來的幾年里，這種加速會不斷擴散。當曲線進一步變陡，真正進入模糊但高速的階段，我們可能就已經靠近 AGI 了。

Lenny：我喜歡這個答案，它很現實，也很符合我們常談的那一點：審查人工智能的輸出真的很煩人，也是巨大的瓶頸。提升編碼效率是一回事，但解決后期的驗證問題是另外一件更關鍵的事情。你提出“人類打字速度是瓶頸”這個觀點非常獨特，我從未聽過，但它非常有啟發性。

https://www.youtube.com/watch?v=z1ISq9Ty4Cg&t=224s

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

AI 工具網站上線海外，原來只需要幾分鐘？迭代慢、延遲高、變現難這三大“天坑”，被騰訊云 EdgeOne Pages 正式版一次填平！

立即注冊，領取開發者專屬權益包：免費加速無限量 + 免運維全棧開發 + 安全出海一站式，讓你的業務即刻出海，無憂上線！

今日薦文

你也「在看」嗎？