當AI能寫代碼、做審查、跑重構，工程師的核心價值究竟剩下什麼？

近日，OpenAI Codex主管Tibo Sottiaux在The Pragmatic Engineer播客中表示，在AI快速接管代碼執行層的今天，工程師真正難以被替代的，是另一套能力。

「如果你無法解釋你在試圖實現什麼，如果你無法表達你的意圖，如果你與你所服務的社區沒有連接，如果你沒有品味——那做出好的工作會難得多。」

這三件事——清晰的意圖表達、架構品味、系統把控力——是他給所有工程師的核心建議，也是他在Codex團隊內部反覆強調的工作原則。

在他看來，AI時代真正稀缺的能力有兩類：

第一，深度好奇心與快速理解系統的能力。 「在OpenAI做得好的人，都是那種能快速讀懂一個系統、鑽進一個新代碼庫、迅速搞清楚它在做什麼的人。」他說，這種能力在有了AI輔助之後反而更重要，因為需要吸收和推理的信息量更大了。

第二，清晰的意圖表達與架構品味。 Tibo強調，隨着AI承擔越來越多的執行工作，工程師需要更清楚地定義「盒子」的邊界——它應該做什麼、滿足哪些不變量——而不是糾結於盒子裏面的實現細節。「一旦你們對盒子的功能和約束達成共識，盒子裏面發生什麼，其實不需要太在意。」

AI代碼審查已「超越人類」，OpenAI全面強制執行

Tibo在節目中透露，Codex團隊早期就開發了專門的代碼審查模型，能夠深入追蹤多層依賴關係，發現人類審查員需要數小時才能定位的邏輯錯誤。

「這些模型在代碼審查上已經達到超人水平——不只是正確性，安全性也是。」他說。目前，OpenAI所有Pull Request都強制經過AI安全掃描，一旦被標記安全問題，PR將被阻止合併，「全部自動化」。

但Tibo認為，代碼審查真正的價值從來不只是找bug。「它一直是一種信息交換的儀式，讓大家對齊，引發討論——理想情況下這些討論應該在寫代碼之前就發生。」

他的判斷是：正確性和安全性的審查將被自動化；而真正值得人類投入注意力的，是圍繞意圖的討論——「你到底想做什麼？這件事值得做嗎？」這個討論不必發生在Pull Request裏，但必須發生。

維護成本下降，架構能力反而更重要

Tibo認為，維護成本的大幅下降，正在重塑工程師的價值分佈。

維護本質上是你為了讓系統持續運轉而不得不支付的稅。但現在，大量維護工作將被自動化——比如第三方依賴升級，模型可以在幾小時內掃完整個代碼庫，直接搞定。以前大家會拖着不做，因為不好玩，但它對安全來說非常重要。

更大的變化在於系統重構。「過去，完整的架構重構可能需要數年。現在這個成本被極度壓縮了。」但他同時強調，這反而讓架構判斷力變得更重要，而不是更不重要：

好的抽象、清晰的邊界、明確的不變量——如果你把形狀畫對了，你就能在'盒子'內部快速改變任何東西，而不影響其他服務。要為快速迭代而設計。

他提到，OpenAI內部有時會在一個周末內，讓100個Agent同時向同一個項目貢獻代碼。「這種規模的協作以前需要幾年時間慢慢擴張，現在可能一個周末就發生了。」

為什麼用Rust，為什麼開源，為什麼支持競爭對手的模型

Codex CLI用Rust編寫，在當時是一個反直覺的決定——彼時模型在Rust上的能力遠不如Python或TypeScript。

Tibo的解釋是：「我們從第一原則出發，把產品界面和Agent本身視為兩件不同的事。Agent的核心需要健壯、安全、高效。」他承認用TypeScript也能成功，「但如果你把所有東西寫在同一個代碼庫裏，你不可避免地會把東西耦合在一起，然後阻礙後續創新。Rust的邊界在這裏非常有用。」

開源的決定同樣出於務實考量。「你在構建一個編碼Agent，當然要把它指向自己。」Tibo說，開源讓社區參與成為可能，也讓團隊招聘變得更簡單——「新人入職，他們已經看過代碼庫了，onboarding基本就完成了。」

至於支持其他模型提供商，Tibo的邏輯更直接：「如果我們不支持，任何人都可以fork一份然後加上10行代碼。那樣只會讓用戶去用那個fork，毫無意義。」他說，「我希望靠最好的模型、最高效的模型、最好的產品贏得用戶——而不是靠鎖定。」

Tibo將Codex併入ChatGPT的技術合併描述為一次重大工程挑戰。

「這兩套系統完全不同。ChatGPT是全託管雲端架構；Codex完全跑在本地。合併的核心問題是：如何把這個本地編程Agent的能力，以足夠高效的方式搬到雲端，以便納入每月20美元的Plus套餐，服務數億用戶。」

目前，ChatGPT Work本質上是在雲端完整運行Codex的harness，配合一台高性能雲端虛擬機。「有些用戶已經發現，如果你足夠有創意，可以讓ChatGPT在裏面訓練另一個模型，安裝Blender做3D建模——它的權限非常開放。」

他透露，整個合併過程中，Codex本身也充當了「記者」角色——它接入了所有Slack頻道和文檔，自動記錄了整個項目的討論與決策過程，形成了完整的敘事檔案，內部稱之為「toggle arc」。

在未來方向上，他表示目前的「Work模式切換」只是臨時狀態：「我們的目標是完全統一——任何在Codex能做的事，在ChatGPT裏也能做，反之亦然。」

Tibo自己怎麼用Codex

Tibo描述了他的日常工作方式：大量使用手機端ChatGPT Work，在會議間隙用語音輸入任務，讓Agent生成報告、整理信息、探索代碼。

「我現在幾乎任何問題都能在30分鐘內得到答案。」他說，「無論是某個功能的用戶反饋、生產日誌的使用量、哪些功能應該下線——Codex都能給我一個初步答案。」

他還提到一個習慣：把白天沒時間深入的問題，晚上交給Codex跑，第二天早上看結果。「這讓每個早晨都很令人期待。」

對於工程師擔心自己的技能被AI取代，Tibo的回應是：「代碼是解決問題的工具。如果你真正在乎的是結果和系統運轉，那AI讓你能解決更多問題，這應該讓你成為更好的工程師。」

訪談全文如下：

與 Tibo Sottiaux 共談 Codex 的構建歷程

The Pragmatic Engineer Podcast2026 年 9 月 9 日

Tibo Sottiaux 是 Codex 的創建工程師之一。如今，他負責 OpenAI 的核心產品與平台組織，該組織也涵蓋 Codex。由於經常慷慨且頻繁地發布 Codex 使用額度重置公告，他也是 Codex 最為公衆熟知的代表人物之一。

在本期《The Pragmatic Engineer Podcast》中，Tibo 與我討論了 Codex 是如何構建、又如何持續迭代的。我們探討了 Codex CLI 為什麼使用 Rust 編寫並開源，Harness（代理運行框架）與模型如何演進，以及 Codex 為什麼支持多家提供商的模型。

Tibo 還分享了 OpenAI 團隊如何在整個軟件開發生命周期中使用 Codex，包括代碼審查、維護和系統重構。我們也討論了 AI 如何降低修改代碼的成本，以及由此帶來的一些有趣影響；ChatGPT 與 Codex 的合併；以及 Tibo 如何在自己的工作中使用這些工具。

開場片段

主持人 00:00

你最近在 X 上分享過一個很有趣的故事：你曾參與構建 Google 內部的一款機器人，它有點像 ChatGPT，而且比 ChatGPT 爆火早了一年。當時，Codex 感覺已經不只是一個研究項目了。

你們用 Rust 構建了它，而當時模型對 Rust 的支持並不在主要分佈範圍內。結果很快就發現：如果願意投入一些精力，Rust 作為一種語言其實非常適合構建智能體。

Tibo 00:28

當有人加入 Codex 團隊時，你會對他們說什麼？這裏的事情是怎麼推進的？

新人最常聽到的一句話是：「你問過 Codex 嗎？」他們仍會驚訝地發現，基本上任何問題都可以問 Codex。

構建功能很有趣，但維護很痛苦。維護本質上是為了讓系統持續運行而必須長期支付的一種「稅」。不過，我認為很多維護工作都會被自動化。

代碼審查這個概念還會存在嗎？代碼審查的角色正在改變。

主持人 01:01

Codex 是當今最受歡迎的 AI 編碼框架之一，但它是如何起步的？

很多人可能是通過 Tibo 慷慨且頻繁的 Codex 使用額度重置公告認識他的。他從 Codex 產品誕生之初就參與其中，並一直領導着更廣泛的 Codex 團隊。

今天，我們將討論 Codex 的起源、它為什麼使用 Rust 構建並開源；Codex 團隊和 OpenAI 內部的編碼方式如何變化；維護和重構成本變得極低意味着什麼；Codex 併入 ChatGPT 的過程；以及該項目中許多不被充分重視的工程挑戰。

如果你想了解 OpenAI 內部的團隊如何規劃、審查和交付軟件，本期節目不容錯過。

從童年、數學到創業

主持人 03:10

Tibo，歡迎來到播客。很高興邀請到你。

Tibo

感謝邀請。再次見到你真好。

主持人

確實很高興。上次我們是線下見面，這次則通過視頻連線。

首先我想問：你是如何進入科技行業的？你是什麼時候意識到自己想和計算機打交道的？

Tibo 03:30

這是個好問題。那是很久以前的事了。

我出生在布魯塞爾。後來，我的父母決定搬離布魯塞爾，買一棟小房子並進行翻修。不過，那棟房子位於一個偏僻的村莊，周圍沒有多少事情可做。

我想，當時村裏大概只有 200 人。而且其中沒有多少人是我想聊天、或者能夠成為朋友的對象。

那時我大約 8 歲，於是就開始接觸計算機。對我來說，那也是互聯網的早期階段。計算機和互聯網成了我學習了解世界的途徑。

之後的經歷基本都由此而來。我想，我得感謝父母把我帶到那個偏僻的地方，讓我別無選擇，只能對計算機產生興趣。

主持人 04:20

高中畢業後，你進入大學，開始系統學習這方面的知識，對嗎？

Tibo

是的。我在大學學習數學，具體來說是應用數學。我很早就入學了，所以也很早畢業。

有很長一段時間，我覺得自己可能撐不下去，甚至會退學。

在讀書期間，我開過一些小公司，也做過小型諮詢業務。我為銀行工作過，對供應鏈和應用數學問題非常感興趣。我嘗試將這些能力商業化，並從中學習了很多。

後來，我進入了比利時的創業圈，在那裏待了一段時間。之後我搬到倫敦，先後在 Google、DeepMind 工作，如今則來到了 OpenAI，也就是加州。

我很喜歡加州的天氣。這個話題我們之後可以再聊。

主持人

你大學畢業後就創辦了創業公司，對嗎？你很早就有創業衝動。

Tibo 05:13

是的。那家創業公司主要做醫藥供應鏈。

我們分析臨床試驗的供應鏈，嘗試優化和判斷：是否應該多生產一些藥物？應該把藥物運往哪裏、從哪裏發貨？如何避免浪費？通過這些方式提高臨床試驗的效率。

Tibo 05:35

我們使用的是傳統的非機器學習技術，主要是優化求解、蒙特卡洛模擬等方法。

本質上，這是一個隨機多階段優化問題。我們也將這套方法應用在鋼鐵行業和歐洲電網中。

只要一個問題具備優化問題的結構，我們就會對此感興趣。直到今天，那家公司仍然存在，我認為他們依舊在做一些非常有意思的工作。不過，隨着現代 AI 的發展，這個領域當然也發生了很大變化。

主持人 06:21

很有意思的是，你說「那不是機器學習，只是傳統方法」，接着又提到蒙特卡洛模擬、優化和各種算法。

我的感覺是，你會不斷深入一個問題領域：面對一個問題，運用自己學過或沒學過的數學知識，不斷挖得更深。我理解得對嗎？

Tibo 06:41

對。這正是我癡迷於應用數學的原因。

理論數學、理論科學和物理學中，有些工作是為了發現未知的事物，或者探索其中的美。它們關乎模式和推動知識邊界，但你未必總能知道如何將其應用到現實中。

而現實世界中存在大量有趣的問題。我非常感興趣的一點是：怎樣讓世界變得更好？怎樣運用複雜的數學方法，優化我們身邊的世界？

這就是那家創業公司背後的許多核心理念。

Google、DeepMind 與大語言模型的早期探索

主持人 07:19

創業之後，你去了 Google，2015 年加入 Google 倫敦辦公室。

我記得 2015 年進入 Google 是一件競爭極其激烈的事。從行業地位和聲望來看，可能就像今天進入 OpenAI 一樣困難。

你最初參與的是地圖相關工作，後來轉到了 DeepMind。能談談你當時做了什麼，以及為什麼會離開一個你顯然很喜歡的領域——優化、物流以及這些問題嗎？

Tibo 07:46

實際上，我一開始並不在 Google Maps。我最初加入的是一個旨在加快網絡和網站速度的項目，尤其是提升移動端網站速度。

當時，Google 正在觀察桌面端向移動端的轉變，越來越多流量轉向手機，因此希望提前佈局，資助了多個計劃和項目。我參與的就是其中之一。

那段經歷非常有趣，因為我們是廣告組織內部的一個小團隊。這個項目的目標，是在流量向移動端轉移的背景下，彌補廣告收入可能出現的損失。

我大概做了兩年，後來項目被取消了。儘管那是我在解決高難度技術挑戰方面最開心的一段經歷，但我也從中學到很多：例如，沒有產品市場匹配度、沒有正確的用戶、沒有有效的反饋閉環時會發生什麼；以及，當產品經理說項目進展順利、但實際上進展很糟糕時，不應盲目信任。

有一天，一位副總裁從加州飛來，告訴我們：「我們要取消這個項目。很遺憾，你們只有幾百名用戶，這顯然不符合 Google 的規模標準。」

令人難以置信的是，當時很多人感到驚訝。

這件事給我留下了一個一直帶在身上的教訓：始終保持質疑，始終深入思考你正在產生什麼影響，以及你所參與項目在整體中的重要性。

Tibo 09:20

之後我去了 Google Maps，那裏非常有意思。我參與了評價功能相關的工作。

大約一年之後，我實在無法忽視 DeepMind。它是一個位於倫敦的特別地方，當時有很多令人驚歎的事情正在發生。

那是很早的階段，AlphaGo 等項目已經開始引起討論。他們似乎在做非凡的事，真正挑戰那些最困難的問題。以我的背景而言，我自然會被吸引。

進入 DeepMind 後，我參與了大量研究基礎設施和研究工具的工作。這也是一個我持續了近十年的主題。

我做事的方式一直是：如何構建工具和產品，幫助其他人提高效率，並為他們帶來很大的價值。

起初，我是為研究人員構建這類工具。隨着時間推移，我開始以越來越通用的方式思考這些問題，最終走到了今天。

主持人 10:19

你最近還在 X 上分享過一個有趣的故事：你參與過 Google 內部一個類似 ChatGPT 的機器人項目，而且這比 ChatGPT 正式發布早了一年。能談談這件事嗎？這是我以前從未聽過的故事。

Tibo 10:44

這是 DeepMind 內部的項目。當時其實有多個相關嘗試，Google Brain 也是獨立團隊，他們也在探索大語言模型。

但大語言模型並不是 DeepMind 的主線。當時 DeepMind 更專注於宏大挑戰、博弈問題以及強化學習，而不是語言方向。

不過，有一個團隊在推進大語言模型。他們思考的問題是：如果海量文本語料就是一切，會怎樣？如果將語言能力推到極限，並持續擴大語言模型規模，是否足以通向通用智能？

這在當時是一個熱門爭論。

後來有一個團隊決定真正全力推進這個方向。對於我們這些為研究構建工具的人來說，很自然會開始思考：我們能用這個模型做什麼？怎樣把它呈現給研究人員？怎樣讓他們調試輸入與輸出？

最終，你會得到一個聊天系統。

我們在內部構建了它，也玩得很開心。最初的模型有點荒誕，表達不太連貫，也談不上特別有用，但和它們交互、不斷嘗試依然很有趣。

這個應用像野火一樣傳播開來，大家都在 DeepMind 內部分享各種對話記錄。

Tibo 12:05

它感覺已經不只是一個研究項目，或者說不只是給研究人員使用的項目。

因此，隨着時間推移，大家開始希望將它作為外部產品發布。但 DeepMind 並沒有為此做好準備。

在 Google 內部，產品發布有一套既定流程，有完整的生產體系和經過多年優化的標準技術棧。它們確實很擅長把產品做好，但在這樣的環境中進行真正的創新也很困難。

為什麼加入 OpenAI

主持人 12:41

我想回到當時你的處境。假設是在 2023 年或 2024 年：你身處 Google，那裏持續發表出色論文、開展優秀研究；你做的事情也非常有趣，正在不斷突破此前的邊界。

而且你已經在公司內部完成過一次轉換。對於一個在當前崗位上感到舒適、滿意的人來說——我想你當時應該也是如此——是什麼讓你仍然會去探索其他可能性，甚至考慮 OpenAI？

Tibo 13:02

我當時確實很舒適。Google 是個好地方。

但我希望能遇到優秀的人，也希望加入一個我真正相信的使命。我希望與那些真正忠於這一使命、深切關心如何以直接而深刻的方式為世界帶來積極影響的人一起工作。

我不希望加入一個這樣的組織：大家只是做自己的工作，然後把「如何讓它變得有用」的問題交給其他人。

我想加入一個能綜合考慮所有變量的團隊，一個研究與產品真正共同設計的團隊。

當時 OpenAI 發展得非常好。ChatGPT 正在起飛。我認識了一些 OpenAI 的人，然後發現：ChatGPT 團隊居然只有大約 20 人。

我當時想：「等等，什麼？你們只有大約 20 人在做 ChatGPT？這個人數少得驚人。這一定意味着極強的自主性。你們是怎麼做到的？如何讓只有 20 名工程師的團隊維護如此規模的產品？」

隨着不斷深入了解，我發現那是一個非常出色的團隊，有偉大的使命，也有極具天賦和驅動力的人。

這些因素吸引了我。

Tibo 14:23

加入 OpenAI 後，我進入了推理模型發布前的相關工作。

這很符合 OpenAI 的風格：我剛加入不久，就有人說：「我們正在做一件事，準備發布推理模型。這可能是一種新範式，開始衝刺吧。」

大約一個月後，公司就發布了 o1-preview。

這讓我感到非常振奮。我想加入的正是這樣一個地方：行動迅速、在意影響、與世界保持同步、真正傾聽外界。

而這也是我後來在構建 Codex、構建產品時一直堅持的理念：擁有社區，傾聽社區，專注於建立極強的反饋閉環。

然後，構建真正值得關心的東西，關注它能為世界提供的實際價值。

Codex 的起點

主持人 15:10

之後，你很快開始參與 Codex。你是在 2024 年加入 OpenAI 的。

能帶我們回到當時嗎？你加入時，大家對於 AI、大語言模型和編程的看法是什麼？

我知道當時有一個 ASE 項目。我們曾在《The Pragmatic Engineer》的深度訪談中談過它——Autonomous Software Engineer，也就是自主軟件工程師，內部稱為 A3。

Tibo 15:34

對，內部叫 A3。不過，我們現在已經沒有單獨的 A3 項目了，它已經成為 Codex。

對我而言，我最初加入時是為研究構建基礎設施。我過去做過很多大規模數據存儲、數據分析和理解訓練過程的工具。

這些年裏，我做過很多不同的事，但核心始終是為他人構建工具，讓他們更高效，認真對待如何把這件事做好，並通過工具和基礎設施創造新的可能。

所以，我加入 OpenAI 後依然延續同樣的思路。

隨着 o1-preview 以及後續一些模型的出現，我們很清楚：必須利用模型本身幫助我們提升速度。

於是，我開始癡迷於一個問題：模型的限制是什麼？我們怎樣用這些模型輔助研究本身？

我與研究部門的其他同事一起開始訓練模型、構建小型智能體。這些纔是真正的 Codex 前身。

我們訓練內部模型，讓它們非常熟悉 OpenAI 的 Python 代碼庫，也讓它們對架構、代碼風格等具備良好的判斷力。

當時僅支持 Python。想法是藉助它快速構建基礎設施，同時幫助研究人員更快地編寫代碼，從而讓我們整體推進得更快。

當不斷推進並將事情簡化到核心時，我們發現可以非常快速地取得進展、快速學習。

Greg 和 Sam 都非常支持。尤其是 Greg，他非常堅持一點：我們不應只關注自身，也必須關注如何造福世界。

他鼓勵我們把這件事不僅視為 OpenAI 內部工具，也要將其變成真正的產品。

這就是我們將這項研究工作與 A3 項目合併、開始構建同一個產品的時候。

之後，我們進行了衝刺，推出了最初的雲端 Codex。它當時並沒有真正實現產品市場匹配，因為使用摩擦仍然有點高。

我們隨後還發布了 Codex CLI，並持續推進。

不過，核心問題始終是：怎樣讓模型真正幫上忙？

為什麼 Codex 選擇 Rust

主持人 18:25

你剛纔提到，最初你們訓練模型理解 Python 代碼，幫助構建更好的基礎設施。

但後來你們做了一個很有意思的決定：Codex 使用 Rust 構建。當時模型對 Rust 的支持並不像對 Python 或 TypeScript 那樣好。為什麼做出這個決定？

是因為預期模型會趕上來？還是因為性能更重要？這個選擇似乎與大多數其他框架不同。

Tibo 18:48

是的，大多數其他智能體框架並不是用 Rust 構建的，而是使用模型更擅長的 TypeScript、Python 或其他語言。

我們從第一性原理出發，很早就將產品界面與智能體本身視為不同的東西。

因此，我們認為必須以一種穩健、安全、面向效率和規模而設計的方式來構建智能體核心。

過去這些年，我參與過不少項目：一開始只是「一個有趣的東西」，後來卻需要擴展到最大型數據中心的規模。在這種情況下，早期技術決策最終會變得非常重要，前提是你不能因此犧牲過多的開發速度。

這是一種取捨。

我們有很多非常高產、出色的 Rust 開發者。我們的內部模型雖然不算特別擅長 Rust，但也並不差。

此外，Rust 在編譯期能提供大量驗證：靜態檢查等。這些特性對智能體也很有幫助。

所以很快就變得清晰：如果投入一些精力，Rust 作為語言其實非常適合智能體。

我們的主要關注點是正確性和效率。

主持人 20:07

你的意思是，對於你們而言，值得提前思考產品最終要達到什麼狀態。

例如，在語言選擇上，儘管有了智能體之後重寫很多東西比過去容易，但如果一開始就建立正確的基礎，仍然能減少返工。

Tibo 20:28

對。我認為即使我們用 TypeScript，甚至 Python 來寫，最後也能成功。之後某個階段，我們可能再重寫它。

但對於我們而言，保持智能體本身與產品之間非常清晰的分離，是一個極其重要的原則。

如果把所有內容放在同一個代碼庫、同一種語言中，最終不可避免會有些鬆散，彼此的耦合會比應有的程度更深。之後，這會阻礙進一步創新。

因此，從某種意義上說，Rust 的邊界非常有用。

為什麼 Codex 開源

主持人 21:08

你們做出的另一個有趣決定，在主要 AI 實驗室中很獨特：將這些組件開源。

CLI、SDK 和 App Server 都是開源的。你們是什麼時候、又為什麼做出這個決定？

尤其過去常有人開玩笑說 OpenAI 並不「開放」，但這正好相反。其他一些競爭者選擇發布閉源框架，而 Codex 是開放的。

為什麼要開源？

Tibo 21:36

我們覺得，將代碼開源是一件非常酷的事。

因為從根本上說，我們構建的是一個編程智能體。於是我們開始思考：既然有了它，當然會讓它指向自身；也許還可以建立一個貢獻者社區，讓大家用它來改進它，然後我們從中學習。

此外，當時我們很清楚：如果我們成功，開源本身以及代碼本身的角色都會改變。

因此，成為這個社區的一部分，而不是與它脫節，是很重要的。

我認為，如果你不親身經歷問題，就很難真正解決問題。

還有一點是，當時雖然我們仍處於很早的階段，但我們覺得自己對如何做好這件事有一些想法。我們正與訓練和研究共同設計這些能力，關鍵在於以最靈活、最好的方式表達模型能力。

但我們並沒有所有答案。

因此，我們願意公開地展示：一個好的框架是什麼樣的，我們如何思考它。我們發布了一些非常技術化的深度解析和博客文章，也進行了很多討論。

我們認為，外面的世界發展很快，有許多非常聰明的人。我們也會從其他開源項目中獲得啓發。

所以，不如建立一個公平的環境，在這個階段鼓勵大量嘗試與探索。

主持人 23:17

如今已經過去一年到一年半了——在 AI 的時間尺度裏，這已經非常久。

回顧這段經歷，開源給工程和工程團隊帶來了哪些好處？同時，開源又有哪些困難？我希望聽到兩方面坦誠的看法。

Tibo 23:59

確實有缺點，開源是有成本的。

好處是：能夠公開構建真的很棒。我們的倉庫也很小，這很有價值。

每當我們招聘新人，加入 Codex 團隊時，他們之前通常已經看過倉庫、研究過 Pull Request。入職引導基本已經完成了。

真正的入職方式只是：用 Codex 瀏覽倉庫、詢問一些問題。但這不再是什麼祕密，因此新人可以立刻開始高效工作。

我們也收到了很多優質貢獻。當然，也會收到海嘯般的隨機內容。

主持人

這顯然也是你和所有其他開源項目都會遇到的問題。開源正在發生變化。

Tibo

沒錯。

對我和團隊很多人而言，直接參與社區、直接作出貢獻，會帶來很大能量。這不只是口頭上說「我們重視社區」，而是真正付出努力去做一些事情。我們並非必須這麼做。

缺點則在於，開源部分與我們其他代碼是分離的。因此，有時我們必須人為劃分邊界，並在多個倉庫之間協作，尤其是在開發一些特別令人興奮的功能時。

另外，公開構建有時意味着：我們還沒來得及發布，別人就已經複製了相關實現。

這會讓人有點難受，但也是遊戲規則的一部分。既然你選擇公開構建，就相當於接受了這樣的約定：別人可以複製它。

我們的許可證也非常寬鬆。不過，當你正在做某個功能，卻發現其他人已經將其複製並先行發布，確實還是會有點刺痛。

第三點，和其他開源項目一樣，我們會被大量隨機貢獻淹沒，必須承擔處理這些內容的額外成本。

不過，這也會促使我們去解決這個問題，我認為這是一件好事。

為什麼 Codex 支持其他模型

主持人 25:42

除了開源之外，還有一點讓我感到意外：直到最近我才知道，Codex 並不只綁定 OpenAI 的模型，也可以使用其他模型。

從廠商的角度看，這似乎不那麼直觀。因為我看到的其他廠商在推出 CLI 時，通常都會說「只能搭配我們的模型使用」。

你們為什麼決定這麼寬鬆地允許其他模型使用 Codex 的框架？

Tibo 26:16

這對我們來說很自然。

如果你是這個社區的一部分，並且在構建優秀的編程智能體框架，為什麼要把它綁定到自己的模型上？做出這種決定會讓人覺得有些失望。

這感覺並不對。

我通常會努力做出一些自己能夠坦然解釋的決定：這就是正確的做法。

開源的邏輯也是一樣。

任何人都可以輕鬆地 Fork 它，然後只改十行代碼就加入對其他模型提供商的支持。但如果這樣做，你只是在鼓勵用戶去使用 Fork，接着你會面臨額外的維護負擔。

而這個 Fork 存在的唯一理由，僅僅是因為你不願意改十行代碼來支持另一個模型提供商。這很沒有必要。

為什麼不從一開始就支持呢？

另外，我們從給用戶提供選擇中獲益很多。

今天，你可能很喜歡 OpenAI 模型，並且使用它們非常高效；但明天可能發布一個新模型，你想試試看。為什麼要強迫你為了嘗試一個新模型，就徹底更換整套工作環境？

我們還可以從這些反饋中獲益。也許你喜歡另一個模型的某些特性；也許那個模型效果並不好，但這依然能讓我們獲得信息。

善待用戶和社區，是正確的做法。

我們自己也會嘗試其他模型，也會在同一個框架中測試它們。這對所有人都有好處。

這種可選性對於與我們合作的企業也很重要。任何嚴肅的公司都希望保留選擇權，因此我們會堅定支持這一點。

主持人 28:16

我很欣賞這一點，因為它感覺非常坦誠。

它迫使整個公司在每一層都要做到最好：模型層、框架層、開源層，以及可選模型支持。這樣你就不能放鬆下來，說「好了，我們暫時可以歇一歇」。

Tibo 28:30

是的。我希望我們通過最好的模型、最高效的模型和最好的產品來贏得用戶。

如果我們把用戶鎖定在產品裏，只因為某一個限制性條件，我認為這也不會吸引最優秀的人來參與構建這個產品。

我們在這裏做的是自己最好的工作，非常在意用戶體驗。無論底層由哪個模型驅動，體驗都應該令人愉悅。

我喜歡憑實力取勝，而不是憑登入入口取勝。

Codex 如何在本地與雲端運行

主持人 31:50

作為工程師，我一直覺得，只要工具之間有競爭，作為用戶就會受益。

我記得微軟和 JetBrains 曾有 IDE 之戰；雲服務商也不斷通過功能競爭；如今則有智能體框架和模型之間的競爭。

作為用戶，我們擁有更多選擇，產品發展更快，我們的聲音也能被更好地聽到。

說到框架，能介紹一下 Codex 今天是如何運行的嗎？

當我啓動一個 Codex 任務時，它總是在我的機器上運行嗎？它會選擇雲端嗎？會使用沙箱嗎？我該如何控制或了解這些？作為工程師，我需要了解多少？

Tibo 32:28

默認情況下，Codex 在沙箱中運行。

如果某條命令需要在沙箱外獲取額外權限，Codex 會向用戶請求許可。但默認情況下，所有工具執行都發生在沙箱內，並且完全在你的本地機器上運行。

這種模式已經持續一年多了。

不過，這也在不斷演進。現在你可以選擇在雲端運行，它會在受管理的虛擬機中執行。這與 ChatGPT Work 所提供的是同一類虛擬機。

你可以查看這個環境，但它實際上運行在 Kata 容器中，是一個安全環境。所有操作都在該虛擬機內部完成，不會在你的機器上執行。

你的本地設備只負責接收輸入和流式返回輸出。

這樣當然會顯著減輕你的 CPU 和機器負擔，也能夠擴展得更多。

這只是一個開始。未來，使用雲端機器會更加無縫。你可能會同時使用筆記本上的部分執行和雲端機器上的部分執行。

隨着模型越來越強大、越來越有能力，它們可以利用的計算資源和其他資源，遠遠超過本地機器所能提供的範圍。

因此，在某個階段，僅將執行限制在本地機器上會成為一種約束。

主持人 34:15

本地運行有一個很大的優點，我想這也是我喜歡它的原因。

當然，它也會帶來麻煩。如果我同時運行幾個智能體，它們會佔用 CPU；如果我想合上筆記本，就不能讓它半開着繼續運行。

我曾去過一家 AI 公司的辦公室，看到有人把筆記本半開着。他們問我：「你在運行智能體嗎？」我說：「對，我有一個任務正在跑。」

但我之所以喜歡本地運行，是因為我有本地工具、本地 Postgres 數據庫，以及各種本地配置。

雲端確實很棒，但它沒有這些現成環境，或者說設定起來很麻煩。

你們是否在考慮或試驗如何處理這些環境配置？

這讓我想起我們在 AI 出現之前討論過的雲開發環境。2022 年、2023 年它們很熱門，但後來大家開始更多討論 AI。

我覺得，除大型科技公司外，雲端開發機並沒有真正普及，因為前期設定成本很高，還要承擔維護成本。

Tibo 35:21

是的。對於獨立開發者或小團隊來說，過去使用雲開發環境的收益並不明顯。

但有了現在的智能體能力之後，設定的成本幾乎可以忽略不計。

如果智能體有能力完成環境設定，它就應該替你完成。

例如，你說自己有本地 SQLite、一個本地服務器、MCP 等環境。要在雲開發機中配置完全相同的環境，並讓它們保持同步，到底有多難？

如果模型能替你完成這件事，那也許就不難。

我認為，我們將看到完全由雲端編排的機器重新興起，這將讓你不再受筆記本電腦限制。

我們已經看到 ChatGPT Work 在這方面取得了巨大成功：它可以在手機上使用。

我每天早晨喝咖啡時，都會通過語音把一堆任務交給它。它會完成這些任務；它可以訪問我的日曆、電子郵件和 Slack。

能夠邊走邊處理事務，不需要隨身帶着筆記本，感覺非常棒。

目前，我們交付的能力仍比較極端：執行依然發生在筆記本上。但如果你無需一直讓筆記本保持開啓狀態，那將非常美好。

Harness 與模型如何共同進化

主持人 36:41

你們過去是如何改進 Codex 的？

我記得自己第一次使用早期版本的 Codex 時，可以和它交談，它也能完成一些任務。

但比如我說：「做這個改動。」它完成了改動，可我有單元測試，它卻沒有運行。

之後幾個月，不知道具體是哪天，它開始自動運行測試。

這些變化是怎樣實現的？你們是在改進運行腳本、指令，還是某種啓動腳本？還是在改進模型？

作為開發者，我該如何理解每個版本的進步——框架與模型之間分別發生了什麼？兩者又是什麼關係？

Tibo 37:26

這是個好問題。

從某種意義上說，框架總是比模型領先一點。

主持人

這是什麼意思？

Tibo

意思是：模型具備某些能力，但你會給它加上一些「柺杖」，讓它能夠以可靠、高效且符合用戶預期的方式完成任務。

這就是框架的作用。

它提供護欄、安全性，提升效率，並讓智能體更容易被引導、控制和調整。

框架通常還負責所謂的「開發者消息」，也就是在每輪開始時注入上下文中的指令。這顯然會影響智能體在整個回合中的行為。

你看到的很多效果，都是框架與模型共同作用的結果。

最初，你可能會發現它不運行測試，因此必須提醒它運行測試。之後，我們訓練出更好的模型，它們更能理解：當用戶提出請求時，用戶真正希望它完成什麼。

於是，隨着模型進步，你不再需要告訴它運行測試。

長期來看，我們會看到系統提示詞越來越短，框架本身也越來越簡化。

主持人 39:08

在 Codex 團隊內部，你們是否會設定具體目標？

比如說，現在 Codex 作為「框架加模型」的組合，在某件事上做得不夠好，或者會犯一些愚蠢錯誤。

作為工程團隊，你們如何推進下一版本的 Codex？

作為開發者，我會覺得模型有點像魔法，它自然會變得更好。我知道你們肯定有反饋渠道。

但你們同時也在構建框架和工具，這大概是團隊負責的部分。

你們甚至如何設定目標？傳統軟件開發中，你會說「我們要做這個功能」，然後去實現，因為你知道怎麼做。但這裏的開發過程對我來說有些模糊。

Tibo 39:44

確實如此，這也是我們為什麼共同設計大部分事情。

這是研究團隊與工程團隊之間協作的過程，尤其是與構建核心智能體框架的工程團隊協作。

我們總是在討論：今天我們在什麼方面做得很好？什麼方面做得還不夠好？還有哪些事情值得做，因為它會成為一個很酷的產品功能？

之後，我們會判斷：這個問題應該通過框架改動解決，還是通過模型改動解決？

如果要通過模型改動解決，那麼多久能做到？一個月？三個月？六個月？

我們會據此推進。

根據模型能夠多快解決問題，以及需要在哪個訓練層面調整，我們有時會決定完全不在框架裏做改動，而是等待模型解決它。

我們會全面使用智能體。我們用智能體分析大量反饋，歸納主題，幫助我們進行討論和確定優先級。

我們會分析編碼領域的使用情況，也會分析金融、通信、營銷等其他領域——如今用戶已經在這些領域使用我們的智能體。

我們大致知道自己在不同子類別中的表現，也始終在推動能力邊界。

有一點很有意思：隨着預訓練模型變得更好，隨着整體模型變得更好，整個系統的能力都會提升。

當然，也有些事情是我們會特別投入更多注意力的。

OpenAI 內部如何使用 Codex 開發軟件

主持人 41:12

你提到「全程使用智能體」。我們能否談談 Codex 團隊的軟件開發生命周期？

在過去、AI 出現之前，新工程師加入團隊時，通常會被告知流程是這樣的：

產品經理或團隊有一個想法；我們制定計劃；一起估算；拆分工作；編寫代碼；測試；代碼審查；發布；使用功能開關；然後進入值班支持。

這就是過去的方式。

現在，當有人加入 Codex 團隊時——他們顯然已經在開源部分有所貢獻——你會如何告訴他們，這裏的事情是怎麼完成的？

Tibo 42:11

如果他們是完全的新手，我會先把他們介紹給優秀的人。

然後，他們最常聽到的一句話是：「你問過 Codex 嗎？」

在 OpenAI，Codex 默認接入了幾乎所有東西。它可以訪問 Slack、文檔和所有代碼。

新人仍會感到驚訝，因為你基本上可以問它任何問題，它經常都會給出非常好的回答。

理解一個項目的狀態、誰在負責某件事、某項決策為什麼做出，最簡單的方式往往是直接問 Codex。因為 Codex 在內部幾乎知道所有這些事。

這也是我們為什麼會在公開頻道中完成大量工作，會以相對廣泛的權限共享文檔：這樣每個人都能訪問信息，智能體也能夠檢索、推理和整合這些內容。

我們還有一些對團隊生產力和協作非常有幫助的工具，目前尚未發布，但很快會推出，其中一部分會在 DevDay 上亮相。

這些能力能讓你與團隊其他成員保持高度同步，幫助你快速理解現狀，也幫助你迅速產出成果。

一般建議是：關心用戶，關心產品的一致性，關心模型及其發展方向。

如果你正在構建一個一萬行代碼的「柺杖」，只是為了繞過你知道模型未來會修復的缺陷，那麼你很可能做錯了。

我們有一套原則，但此時它更像是一種團隊文化和精神。新人加入後，會通過整個團隊繼承這些根基。

主持人 44:02

假設我有一個想法，我認為它很好。我先和 Codex 討論，可能也會和一些同事討論。

我決定把一個很酷的新功能作為自己對 Codex 的第一個、或者第一個重大貢獻。

接下來怎麼做？

顯然，我會用 Codex 編寫代碼，也會測試並確保它正常運行。從那裏開始，流程是什麼？

你們是否仍有代碼審查的概念？是否有 AI 代碼審查、驗證、分階段發布、上線後驗證？

畢竟 Codex 面向數百萬用戶。它啱啱跨過 2,000 萬活躍用戶的里程碑；而如果進入 ChatGPT，面向的用戶規模還會大得多。

Tibo 44:44

無論是發布到 Codex 還是 ChatGPT，流程都出人意料地相似。

儘管 ChatGPT 面向的是約十億活躍用戶，而且還在增長，但你依然可以提交一個 Pull Request、做一項改動，並在第二天甚至當天發布，直接覆蓋十億用戶，而且一切都沒問題。

我們真正做的是培養強烈的主人翁意識與責任感。

人們被充分授權去做改動，甚至是大的改動。

通常會被要求提供的是：證明它會受到良好歡迎的證據；證明它是值得加入的內容；證明它值得長期維護的證據。

而維護的成本也已經大幅下降。因此，我們對這些事情的思考方式與兩三年前有所不同。

另外，我們會儘可能自動化。

代碼審查、部署和迴歸檢測等大量流程，基本都已自動化。

這樣，大家就可以把注意力集中在想法本身、它將如何幫助用戶、整體體驗的一致性、智能體的能力和持續改進上。

我們有一長串希望實現、但尚未完成的事情。

我們的北極星方向是：一個令人愉悅、易於使用的個人 AGI。

它應當了解關於你的、它需要了解的一切；能夠訪問正確的資源；有時能代表你採取存在風險的行動；之後向你發送推送通知，讓你進行確認。

用戶應該能夠深刻理解它。它要了解你的日程、目標，可以主動為你提供幫助，並且使用起來應該極其自然。

你應當能通過自然語言、語音來控制它。也許它還應理解你的情緒；如果擁有攝像頭畫面，它應該能以最自然的方式理解你。

它不應該是一個有十個不同按鈕和複雜配置的東西。AGI 應該簡單易用。

代碼審查的角色正在改變

主持人 46:34

你剛纔簡略提到了審查，但我想回到代碼審查的話題。

你曾在 Google 工作，參與過 Google Maps 這類面向數億用戶的產品。Google 以嚴格的代碼審查文化聞名。

我想他們有兩層代碼審查：一層是語言正確性審查。他們長期以來一直在行業內不斷完善這套流程，也相信它的有效性。

你怎麼看這部分正在發生的變化，尤其是人工審查？

長期以來，直到一兩年前，我都會說代碼審查有很多好處：知識共享、第二雙眼睛、降低「巴士因子」，因為其他人也會理解代碼；以及圍繞架構而不僅僅是代碼展開討論。

但現在代碼量多得多了。

代碼審查的價值是什麼？在哪些情況下依然重要？在你們這樣領先的團隊中，人工或開發者參與審查的價值在哪裏？又在哪些地方可以放心交給智能體？

Tibo 47:50

代碼審查的角色正在改變。

我早期參與 Codex 的一個項目，就是和研究團隊一起開發一個代碼審查模型。

我們的目標是讓它達到這樣的水平：它能夠發現邏輯和推理中的錯誤，而人類可能需要數小時、甚至多人投入才能發現同等程度的問題。

因為這可能需要向下深入三四層依賴關係，理解文檔是否有誤，理解某個第三方依賴的實現是否與預期不同，進而發現你的不變量沒有被維持，最終導致 Bug。

除非你本身是那個庫的專家，否則很難注意到這些問題。

我們開發了這些代碼審查模型，也發布了它們。如今，它們發現錯誤、進行深度驗證的能力已經成為主線模型的一部分。

在基準測試中，它們在代碼審查方面已經超越人類。

這不僅適用於正確性，也適用於安全性。

例如，模型能跨越非常複雜的上下文進行推理，最終指出：「這裏存在一個嚴重的安全漏洞。」

如今，在 OpenAI 的所有 Pull Request 中，這已成為強制要求。如果系統標記出安全問題，我們會阻止 Pull Request 合併。這一切都是自動完成的。

我認為，代碼審查過去始終關乎正確性，確保功能正常運行；但它也是一種信息交流的儀式，使人們保持同步，並鼓勵討論。

理想情況下，這些討論應該在寫代碼之前進行，但有時它們只會圍繞代碼發生，因為一旦代碼合併，它就進入生產環境並開始實際運行，而之後你還必須維護它。

因此，其中還包含社會協作的因素。

我認為，正確性、網絡安全和安全審查都會被自動化。

真正會保留下來的，是圍繞意圖展開的討論：你到底想做什麼？你嘗試做的事情是否正確？

我認為，這種討論可以發生在 Pull Request 之外，不必圍繞代碼本身。

也許這會幫助我們更清晰地區分：哪些地方真正需要討論，而哪些地方過去只是因為沒有現在這樣的工具，纔不得不通過代碼審查來進行討論。

這會發生變化。

過去，代碼審查是一個強制機制：因為在代碼合併、進入生產環境前，你必須進行這些討論。

但我認為，現在有其他方式來完成這些討論、共同設計，並確保意圖正確。代碼本身的重要性將不再那麼高。

主持人 50:26

回想我經歷過的所有代碼審查，當然有許多美好的記憶：我們有過很好的討論，或者我學到了很有價值的東西。

但坦率地說，也有很多時候它非常令人痛苦。

我想推進自己的工作，就不斷催別人：「能審一下我的代碼嗎？」對方說：「不行，我現在很忙。」我再說：「但我真的需要這個來解除阻塞。」然後對方就被迫切換上下文。

代碼審查一直都有好與壞。

我想，無論未來如何，始終都會有好處和壞處，只是它們在轉移。

其中一個好處是，工程師不必再把注意力花在那些並不真正需要人工判斷的基礎問題上。

Tibo 51:24

是的，這會節省時間。

我們將逐漸看到這樣的情況：團隊先就一個「盒子」及其整體契約達成一致。

只要對資源使用、數據訪問、安全等有嚴格保證，那麼盒子內部發生什麼，可以是任何事情。

你不必關心盒子內部的每一項實現。

真正需要達成共識的是：這個盒子到底做什麼？必須滿足哪些不變量？

我認為，這些才值得進行高質量討論，也許可以由你最喜歡的智能體輔助完成。

一旦這些內容明確，在盒子內部修改任何事情，都不再需要重新進行同樣的討論。

這能真正保護和節省人的注意力。

維護與重構成本下降

主持人 52:07

維護成本已經降低。

在 Google、Uber、創業公司等各種組織中，維護一直都是熱門話題。構建功能很有趣，但維護卻令人痛苦。

很多時候，我們後來才意識到：「也許這個東西根本不值得做。」

在 Codex 和 OpenAI 內部，你看到維護成本如何變得更低？這會如何改變大家構建系統的方式、目標、抱負，以及自定義工具等方面的決策？

Tibo 52:30

維護本質上是一種長期支付的稅，用來保證系統持續運行。

過去需要維護，未來仍然需要維護。

但我認為，很多維護工作會被自動化。

比如，你有一個第三方依賴，需要升級版本。過去你可能會想：「我得記得處理這件事。」但現在，如果有好的變更日誌，代碼文檔也足夠完善，模型可以推理整個改動。

它可以在數小時內掃描整個代碼庫並完成升級。

過去，人們可能會把這件事擱置，因為它不夠有趣；但它對業務和項目其實很重要，尤其涉及安全漏洞時。

你希望保持最新狀態，希望及時應用所有補丁。

我認為，這些都會被完全自動化。

因此，維護工作中很大一部分會近乎免費地完成。

另外，過去如果你想徹底重構，或者需要新的架構，以便為新的權衡、新的工作負載認知或新功能騰出空間，突然發現現有系統限制極大，必須全面重構——這是一項代價極高的工程。

有時甚至需要多年。

我認為，這件事現在也大幅加速了。

因此，犯錯的成本正在下降。

但與此同時，軟件工程中那些經典原則仍然很重要。例如，良好的抽象仍然非常有幫助。

這又回到前面提到的「盒子和不變量」：如果你劃出了正確的邊界，就能夠更快修改盒子內部，而不會影響其他服務或基礎設施。

我認為，設計時必須考慮如何支持極快的迭代與變化。

主持人 54:34

我記得曾和 Peter Steinberger 交流，那是在他加入 OpenAI 前。我們談到了 OpenClaw 以及他如何思考這類系統。

他說自己不怎麼閱讀代碼，但我能看出來，他一直把架構放在腦中。

他告訴我，他會頻繁重構，思考如何實現模塊化，如何讓 100 名貢獻者各自構建內容而不互相干擾。

我從你的話裏聽到的是：這種關注、規劃和結構化工作也許變得更加重要了。

過去，這可能主要是架構師、資深工程師或經驗豐富的人在做，其他工程師則在周圍構建較小的部分。

但現在，聽起來所有工程師都需要在構建軟件時關注這些問題、提前做好規劃。

Tibo 55:16

是的，GPT 模型在這方面也越來越好。

它們越來越擅長思考長期維護、良好架構等問題。

這是一種自然的下一步：不只是關注代碼質量，例如某個文件中的代碼是否乾淨；而是思考架構本身是否正確，是否能降低長期維護負擔，是否能為未來產品或功能的擴展與變化留出空間。

這種長期工程實踐，模型正開始變得非常擅長。

我覺得很有意思的是：我們構建的軟件，其生命周期正在以更快的速度推進。

以前，一個項目起步時，也許只是你自己和幾位工程師。之後才慢慢增加工程師。若項目非常成功，一年後可能會有 50 名甚至 100 名工程師加入。

你有時間預見這一切，有時間讓人加入，有時間準備文檔和其他流程。

但現在，突然有 100 個智能體同時參與一個項目，這種事情可能一個周末就會發生。

因此，我們進入這一切的速度，比過去快得多。

工程師如何適應高速變化

主持人 56:42

但你和 OpenAI 的同事是如何面對這一切的？這種變化不會擾亂你們的認知嗎？

你的意思是，你已經在這個行業工作很久了，有幾十年經驗。過去我們習慣了一種節奏，而現在節奏快得多。

一年前你還在做的事情，現在可能已經不做了，因為模型已經擅長完成它。

你如何與這種變化和解？

我相信，有些與你的軟件工程能力相關的事情，你過去非常擅長，但現在可以交給智能體。

這不會帶來一點失落嗎？

我們啱啱說過，自己的開源功能被別人複製會讓人有點難受。同樣地，如果你以前很擅長重構，而現在智能體可以做；今天也許是架構設計，未來模型可能也非常擅長，你會不會覺得有點可惜？

Tibo 57:43

我認為，這其中確實存在一種手藝層面的感受。

有時我仍會打開編輯器，親自寫一些代碼。那種感覺很好。

我對一些夜晚有很美好的回憶：坐在 Vim 前不斷編碼，喝着可口可樂 Zero，不必思考其他任何事情，只專注於眼前的問題。

但我認為，真正重要的是進入心流、解決問題。

我發現，這裏的同事，以及我交流過的所有人，都在非常迅速地適應。

如果你的心態是：代碼只是解決問題的工具，而現在你能解決的問題多得多，那麼變化就是積極的。

過去，如果你想做個基準測試，卻不確定結果如何，你可以直接讓它在後台執行。可能只需要 30 秒，就能獲得可靠數字，從而做出更好的權衡。

只要你真正關心結果、關心繫統是否正常工作，這應該會讓你成為更好的工程師。

在 OpenAI，這使我們能更高效地運行推理，更有效地利用計算資源，並將這些能力交付給世界。

因此，大家都專注於這一點：以過去不可能達到的速度解決重要問題。

到目前為止，我還沒有遇到有人說：「這不好，這不有趣。」

主持人 59:10

我理解的是，如果你有足夠宏大的問題，有遠超過今天、明天或下周所能解決的問題，這就不是問題。

因為當你在某個方面變得更高效後，你只會繼續向前。

這就像很多創業公司：它們的抱負總是遠大於自己當下能完成的事情。

Tibo 59:32

沒錯。我們絕對不缺問題要解決，而且我認為短期內也不會缺。

我們在數學突破、科學突破、讓世界變得更好、真正為人類構建產品，以及以深刻人性的方式解決人們最重要的問題方面，還有很長的路要走。

這正是我們在這裏的原因。

Tibo 01:00:00

再回到編程和那些深夜。

我剛纔講的，可能有些浪漫化。事實上，我也經歷過很多深夜，試圖重構某件事，三個小時後才發現這條路根本走不通，必須從頭開始。

那非常令人沮喪。

當然有快樂的時刻，但也有那種代碼無法編譯的時刻，你不斷想：「為什麼它還是編譯不過？」

主持人 01:00:30

我相信你也經歷過這種情況：時間已經很晚了，你該睡覺了，但因為有一項任務只做了一半，根本睡不着。

我記得自己甚至會夢到代碼。

而如今，我在為自己的業務開發軟件時，通常不會再有那種「只完成一半」的狀態。因為我可以讓智能體完成任務，然後離開；要麼任務已經完成，要麼它在運行，要麼我已經得到失敗的證據。

一切都加速了。

Tibo 01:01:13

我現在仍然會有類似的情況。

很多人都會這麼做，我自己也是如此：有時我會思考一些更大的問題，可能來自白天的對話，或者我還沒來得及深入研究。

於是，我會讓 Codex 在夜間研究這些問題。

第二天醒來查看結果時，我會非常興奮。因此，每個早晨都令人期待。

主持人 01:01:34

我覺得這就形成了一種長時間運行任務的模式。

當然，你可以使用 /goal 命令來持續運行任務。這也是幾個月前才加入 Codex 的能力。

回到「框架是柺杖」這個概念，/goal 是否就是一種柺杖？它是否是為了讓模型在很長一段時間裏專注於單一目標而設計的？

Tibo 01:01:56

是的。/goal 是必要的，它讓模型能夠長期圍繞一個目標保持正軌。

它甚至可以讓模型在面對真正困難的問題時，持續運行數天或數周。

但隨着新一代模型出現，我們看到的是：你不再需要 /goal，也不再需要圍繞它的額外框架。

你可以直接告訴模型：「去工作一周。」它確實能做到。

ChatGPT 與 Codex 的合併

主持人 01:02:21

說到難題，以及你們並不缺少難題，有一個從外部看來很有意思的發布：你們所說的「合併」。

Codex 出現在 ChatGPT 中。

從工程師的視角看，我會說這件事中等程度地有趣。我們已經在用 Codex；現在可以在 ChatGPT 應用裏打開它，很好。

但我通常不會在應用裏使用 ChatGPT，而是直接進入 Codex。

不過，我和 OpenAI 的很多人、包括你團隊的人交流過，他們說這項合併前進行了很多準備，面臨很多持久且艱鉅的挑戰。

能否介紹一下：這究竟是一個多大的項目？你們需要做什麼？為什麼難？Codex 及其他工具又如何幫助你們以過去難以實現的方式完成它？

自從合併推出後，你不斷分享 Codex 用戶數量增長的數據，增長速度比過去快得多。我猜這裏解決了巨大的擴展問題。

Tibo 01:03:25

這次合併有很多挑戰。

首先，兩者的技術棧完全不同。

ChatGPT 是完全託管的、基於雲端的產品。所有東西都運行在我們的系統上，我們以傳統的大規模、高效率方式存儲和構建它。

而 Codex 是完全本地化的。

因此，合併的核心在於：如何讓這個本地編程智能體獲得同樣的價值與能力，並圍繞它構建一個產品，使其能夠惠及更廣泛的人群。

這也是我們加入 OpenAI 的原因：希望讓非常廣泛的全球人群從中受益。

因此，這是一個令人興奮的探索過程：怎樣構建一個雲端版本，使它在本質上具備非常相似的能力；同時，又能夠以高效的方式服務數千萬、數億用戶，從而可以將它包含在 Plus 訂閱方案中。

ChatGPT Work 本質上是在雲端運行完整的 Codex 框架，並配備一台雲端計算機。

它實際上是一台非常強大的機器。人們已經發現並展示了它能做什麼。

如果你的提示詞足夠有創造力，可以讓 ChatGPT 在其中訓練另一個模型；也可以讓它安裝 Blender，進行 3D 建模。

它的權限非常寬鬆，能訪問互聯網，是一台功能強大的機器。Codex 在這台機器上運行。

這就是我們通過 ChatGPT Work 交付的能力。

這其中涉及很多系統層面的挑戰。

團隊完成得很快。顯然，Codex 幫助我們更高效地分析並構建大量基礎設施，也幫助我們處理 Codex 與 ChatGPT 之間出現的很多細微差異。

例如，合併插件架構、合併庫，並真正朝着統一系統邁進。

我們的目標是：用戶不應該覺得有些事只能在 Codex 中做、不能在 ChatGPT 中做，或者反過來。

我們希望構建一個統一產品，讓你以自己希望的方式，訪問同樣的智能。

Tibo 01:06:05

整個過程中還有一件很有趣的事：Codex 也充當了記者。

它記錄了整個過程中的步驟、爭論和討論。團隊之間針對如何實施、如何命名、何時引入、以什麼形式引入、什麼與什麼合併，進行了非常熱烈的討論。

我們考慮過許多不同方案。

因此，這個項目有很有趣的新聞記錄元素：Codex 隨着時間推移記錄了整個過程。

這也逐漸被稱為 OpenAI 的「切換開關故事線」。

我們引入了 Work 開關。圍繞它是否是正確做法，也有過大量討論。但後來，我們逐漸真正喜歡上了它。

隨着時間推移，我們會進一步合併這些能力。

我們正朝着完全統一的方向前進。目前的狀態只是暫時的：當你處於 Work 模式時，能力會更強；但長期來看，我們會將這些能力帶給所有 ChatGPT 用戶。

Tibo 如何使用 Codex

主持人 01:07:13

你個人如何使用 Codex？

你的工作配置是什麼樣的？你如何使用智能體、處理哪些任務、管理哪些事情？

相關地，我問過 Peter Steinberger 我應該問你什麼。他說：「你一定要問他，他參與那麼多項目，日曆像俄羅斯方塊一樣排滿，但通常還顯得很愉快。他是怎麼做到的？」

Tibo 01:07:33

我的日曆還好。

如今我能夠完成更多事情，是因為有了 Codex 這樣的技術。

我已經把很多工作轉移到手機上，通過 ChatGPT Work 完成。

每當我想記錄一件事，我就直接把它發出去。我經常使用語音輸入。

每當我有問題，以前我可能會寫下來，之後再研究，或者委託給別人；現在，我會直接在 ChatGPT Work 中把任務發出去，然後得到一份報告。

它擁有許多自定義技能和自定義指令，現在已經非常適合為我生成我能高效吸收的報告、幻燈片和代碼探索結果。

因此，每當我在會議之間有空檔，你可能會看到我對着手機說話。

正如我前面提到的，我們在公開頻道中完成許多工作。Slack 中有很多信息，Notion 和 Google Docs 中也有很多信息。

所以，幾乎不存在我覺得無法提出的問題。Codex 至少可以對任何問題進行第一輪思考。

無論是分析某個功能的公衆情緒，查看生產日誌以了解某項功能的使用量，列出應該淘汰的、沒有獲得用戶認可的內容，還是了解某個團隊正在做什麼——任何問題，我都可以在大約 30 分鐘內獲得答案。

所以，我用它來做所有事情。它在各種意義上都是我的個人智能體。

周末時，我也常做一些代碼探索或構建原型，嘗試想象產品的未來。我會和團隊中的其他人一起做這些事，不一定總是同一個團隊。

有時，一天之內，我就可以構建出一些原本只存在於腦海中的東西。

比如有一天早上醒來，我會想：「我們應該探索一下構建這個東西意味着什麼。」

然後，我就能把這些想法表達出來，在一天內做出一個能展示給其他人的東西。大家可以據此思考、批評，並希望從中獲得啓發。

這並不意味着我們一定要發布它。

更像是：我把這個想法從腦海中釋放出來，然後繼續做其他事情。

這是一個非常神奇的時代，也非常賦能。

給軟件工程師的建議

主持人 01:10:19

最後，如果一位軟件工程師、AI 工程師，或者任何構建軟件的人，希望培養所需的技能和經驗，以便有機會加入 Codex 團隊、OpenAI 或一家 AI 創業公司，成為一名善於使用這些工具的優秀構建者，你有什麼建議？

人們經常問：我應該從理論開始嗎？基礎知識有多重要？還是只要非常擅長使用工具就可以？

Tibo 01:10:41

我認為有兩件事很重要。

第一，是對事物如何運作抱有深度好奇心；第二，是訓練自己快速理解事物的能力。

事情會持續變化，但在 OpenAI 表現極其出色的人，通常是那些能夠迅速理解一個系統、進入新的代碼庫並理清其脈絡的人。

當然，如今智能體能夠幫助完成這些工作。

你需要吸收的信息非常多，因此，能夠理解並推理這些信息非常重要。

其中很大一部分，其實是提出好問題：事物到底是如何運作的？

不斷追問「五個為什麼」，持續向下挖掘。這樣你會學得非常快。

第二點，是與社區保持同步，或者說，與那些你試圖為其解決問題的人保持同步。

並不是每件事都在解決一個直接的問題。有時，你解決的是一個對另一群人有用的問題，而他們最終也在為人類問題的解決作出貢獻。

但你必須清楚地理解用戶的品味、需求和要求；必須能夠清晰思考，並持續訓練這種思維清晰度。

這對我來說非常重要。

如果你無法解釋自己想實現什麼，無法解釋自己的意圖，無法與某個社區建立聯繫，也沒有相應的品味，那麼你就很難做出偉大的工作。

主持人 01:12:05

太棒了，Tibo。非常感謝這次對話，真的很精彩。

Tibo

感謝邀請。

節目總結

主持人 01:12:16

我一直想和 Tibo 深入聊一次，很高興終於實現了。

我很欣賞 Tibo 不僅談論開源的好處，也坦率談到了它的缺點。

尤其是，當你正在公開開發某項功能時，競爭對手可能複製這個功能，並在你正式發布前搶先上線。這確實會令人不舒服。

另外，開源還會帶來大量低質量貢獻，而你仍然必須以某種方式處理它們。

另一個有趣的觀點是，Tibo 說框架總是比模型領先一步。

從內部來看，Codex 團隊認為自己的工作，是通過框架、工具和設定指令為模型構建「柺杖」。隨後，下一版本的模型會被訓練得不再需要那麼多柺杖。

坦率說，作為開發者，這聽起來有一點讓人泄氣：我構建的東西，下一版模型可能天然就會知道，於是就能被移除。

不過，我懷疑事情並不只是構建這些柺杖，也包括構建模型會使用的工具。下一代模型應該不會重新發明 MCP 協議、技能或插件。至少我希望不會。

我也很喜歡了解從內部看，合併 ChatGPT 和 Codex 是怎樣的過程。

這意味着要將原本完全本地化的編程智能體 Codex，整合進一個託管式雲端技術棧；同時還要做到足夠高效，使其能夠納入 OpenAI 每月 20 美元的訂閱方案。考慮到 20 美元能購買的計算資源並不算多，這並不容易。

還有一件很有趣的事：Codex 本身充當了整個項目的記者。由於它出現在所有 Slack 對話和文檔中，因此能夠記錄所有重要爭論和決策。

我不得不承認，這一部分有一點「老大哥」的感覺：AI 一直在看。

但這很可能會成為未來創業公司的新常態。我還沒有決定自己對此究竟是什麼感受。

最後，我很認可 Tibo 給工程師的建議：保持好奇心，快速理解系統，並與自己正在服務的人群保持同步。

從 Tibo 的分享中聽到基礎能力依然如此重要，也令人感到安心。

請查看下方節目說明，其中包含關於 Codex、Claude Code、Cursor 構建方式及其他相關主題的深度解析。

如果你喜歡本期內容，請在你使用的播客播放器中留下評分。這對我和節目都意義重大。

謝謝，我們下期再見。