Codex和Claude Code都跑偏了，前OpenAI研究員稱Jev出現前AI世界是個悲劇

極客邦科技InfoQ·2026年09月25日 11:30“下一個時代並不是 Claude Code時代。” 編譯 | 林綺蓓、蔡芳芳 策劃 | Tina “它會逐漸退到軟件背景中，像數據庫、正則表達式或其他基礎設施一樣，成為開發者隨手調用的普通能力。” 這是 TypeSafe CEO、Jev 創始人 Diogo Almeida 對 AI 的設想：當智能真正融入軟件，用戶甚至不必意識到它的存在。但怎樣才能讓開發者放心地把判斷交給 AI，而不用守在旁邊反覆檢查？

幾個月前，在 AI Engineer 大會的演講中，這位曾參與 OpenAI InstructGPT 工作的研究者就提出，“下一個時代並不是 Claude Code時代”。在他看來，Claude Code 與 Codex 本質上仍屬於同一個階段——AI 的主要角色仍然是圍繞人提供輔助。他關心的是，為什麼 AI 如此聰明，能解決數學界的千禧年難題，卻連最基礎的活都無法實現自動化工作？9 月 22 日，做客 Latent Space 播客接受採訪時，Diogo 再次談起這份不滿，措辭更加直接：“在我看來，Jev 出現之前的 AI 世界，簡直是個悲劇。

”在他看來，問題在於：強大的“智能引擎”已經有了，把它接進實際業務流程的接口卻仍然欠缺。這一次，他帶來了自己的答案——Jev。通過面向校準決策的強化學習（RLCD），團隊希望讓模型輸出可供代碼直接使用的選擇、評分和概率，讓開發者能夠依據不確定性設置閾值，決定何時執行、何時交給人處理。從參與訓練聽懂人類指令的模型，到嘗試讓代碼直接調用智能，Diogo 為什麼要重新選擇訓練目標？他又準備如何讓 AI 成為像數據庫一樣普通的軟件能力？這場兩小時的訪談講述了他的判斷與嘗試。太長不看版： Swyx：對於那些可能不太瞭解情況或者只想得到確切答案的人來說，Jev 到底是什麼？

Diogo Almeida：目前最準確的稱呼是 System1 模型，它的能力範圍遠遠超出決策本身。這類模型的目標，在於讓代碼成為模型輸出的直接使用者。Swyx：你對 RLHF 的一個核心看法是：模型的回答會向用戶想聽的內容，而不是反映它對一件事真正的內部置信度。能具體談談嗎？Diogo Almeida：幾乎沒人注意到 RLHF 的缺點，特別是“模式坍縮”（mode dropping）。RLHF 的模式坍縮會讓模型偏向生成更安全、更常見的答案，而犧牲概率分佈的真實校準，這既掩蓋了長文本中的錯誤累積，也解釋了為什麼文本模型不擅長決策。Swyx：RLCD 與 RLHF 的核心區別是什麼？

Diogo Almeida：區別首先在於優化目標：RLHF 側重讓模型遵循人的指令、給出獲得認可的回答，RLCD 則希望模型成為軟件能夠可靠調用的能力。Swyx：為什麼 Jev 不把拒答機制直接放進模型底層？Diogo Almeida：我不反對安全本身，但我認為不應把特定價值判斷直接寫進通用模型底層能力，而應像數據庫一樣劃清技術能力與具體使用責任的邊界。Swyx： 你所說的可靠性是什麼？開發者能否相信同一個版本的行為保持穩定？Diogo Almeida：我更重視穩健性：問題含義沒變，就不該因為加入無關字符而大幅改變判斷，而不只是追求相同輸入得到相同輸出。

已經部署的模型，我們不會悄悄修改，因為 API 是別人程序裡的依賴。但我們會快速發佈新版本，目前還不能承諾永久維護每個舊版本。Swyx： 不依賴公開榜單，你們怎樣判斷模型是否真正做到了更高的性價比？Diogo Almeida：我們會通過內部評測比較成本和能力，追求同等成本下更強、同等能力下更便宜。我不反對評測，反對的是圍繞榜單優化，讓分數脫離真實價值。開發者最終還是要把模型放進自己的工作流，測量實際表現，不能只看價格、速度或一個總分。Swyx：開發者應該怎樣組織任務，才能更可靠地使用 Jev？

Diogo Almeida：我建議把複雜任務拆成最小、可以獨立判斷的語義單元，用結構化輸入提供必要信息，再由代碼控制最終行為。Choice 對應選擇分支，Noul 對應條件判斷，Score 對應評分、排序和篩選。每一步都可以單獨評估、調整閾值；能力不足時，就轉交人工或暫不部署。Swyx： 對企業開發者來說，Jev 有哪些值得嘗試的應用方向？Diogo Almeida：我們梳理了四類：分析因處理成本太高而閒置的“暗數據”；為實時流程提供快速判斷；檢查其他模型的調用和輸出；把智能判斷嵌入軟件核心邏輯。

我尤其看好暗數據分析和編程 Agent，但具體如何組合模型，仍要看它能否降低成本、解決原本解決不了的問題。Swyx： 面對前沿 AI 的風險，放慢發展速度是唯一選擇嗎？Diogo Almeida：我認為，這種討論往往默認大家必須沿著現有 RLVR 路線繼續加大投入，但研究目標和技術路線都可以重新選擇。為了提升表現而給模型多大行動空間，本身就是設計決定，不該被當作不可避免的前提。我更希望探索其他方向，讓已有智能可靠地進入軟件，自動化實際工作。Swyx：如果研究者在前沿實驗室得不到資源，你會建議他們出來創業嗎？Diogo Almeida：要看為什麼離開。

如果只是想自由嘗試課題，現有實驗室可能仍然最合適；如果找到了值得長期投入的新任務，我會支持創業。我不認為漂亮的研究履歷會自動創造價值，也不看好拿到資金後重復已有工作的做法。先明確自己的核心目標，再圍繞真正值得解決的問題展開研究。1Jev 發佈的第一週，創始人的情緒糟糕透了 Swyx：歡迎來到錄音室。就在本週，我的好朋友 Diogo 發佈了 Jev，它幾乎佔領了社交平臺的熱點話題。此時此刻，你感覺怎麼樣？Diogo Almeida：情緒上來說，從來沒有這麼糟過。我現在簡直像一具疲憊不堪的行屍走肉，因為同時發生的事情太多了，到處都有問題等著我處理。但是，從心理層面來說，那反而完全不一樣。

我經常講這件事，並且這幾年我在那些大小項目活動裡也反覆說過，整個 AI 領域就像遊樂園裡的哈哈鏡屋，所有人都像瘋了一樣。每個人都在說各種奇怪又說不通的話。可是就這一週，我好像和現實更合拍了，像是突然之間感受到：“哦，大家終於看見了。”——AI 能做到的事情，遠比過去人們想象的多。我們真的可能推動了一場由 AI 驅動的經濟革命，這件事重新回到桌面上了，簡直實在是太棒了。我特別興奮的一點，是開發者真的能夠理解我們在做什麼，這種感覺非常強烈。我也想對這些開發者表達我長久的感激。我對整個開發者社區以及現在發生的一切都特別興奮，真的太棒了。

Swyx：你昨天還跟我說，你決定優先去做 town hall，也就是社區公開交流，而不是把時間都花在 VIP 和投資人之類的人身上。因為你希望確保真正得到你最多注意力的，是工程師、開發者這些真正使用產品的人。Diogo Almeida：是的。當時確實會有一種感覺，像是“天啊，我現在正在跟一些非常重要的人說話。”我可能不該透露是誰。但對我來說，如果在我那個列滿了待聊對象的龐大日程表裡，開發者社區竟然不在其中，這對我來說會很不舒服。實際上，如果按照我的理想狀態，我會一直和開發者社區在一起交流。我剛才甚至在想，“我要不要一邊走來你的演播室，一邊開一場社區大會？”後來我又覺得，“不行，這也太瘋狂了。

” Swyx：對於那些可能不太瞭解情況或者只想得到確切答案的人來說，Jev 到底是什麼？Diogo Almeida：這個問題其實挺難回答的，但我是這麼看這件事的：我們需要一種全新的模型類別。至於這一類別到底叫什麼，我們沒有執著於某個名字。目前我們想到最準確的稱呼是 System 1 模型。之所以沒有把它稱為“決策模型”，是因為 System 1 的能力範圍遠遠超出決策本身。我現在只能說這麼多。我們原本沒想到這次會成為一次這麼受關注的發佈，所以手裡還有東西沒有拿出來。Swyx：你們當時就該說這是一次“低調的研究預覽”。Diogo Almeida：某種程度上確實就是，它其實真的有點像一個研究預覽。

總之，我們內部有幾個詞來描述出現的這一類新的模型。比如機器原生模型（machine-native）、System 1 模型、大型可編程模型（large programmable）。我的理解是，這類模型的目標，在於讓代碼成為模型輸出的直接使用者。預訓練大語言模型最初面向的是互聯網文本補全；經過 RLHF 訓練的聊天和指令遵循模型，面向的是文本回復；RLVR 則和 RLHF 之間有一塊界限不太清晰的區域。而我們希望這類模型的輸出能夠直接被代碼消費，所以公司才會叫 TypeSafe。我們真正想要的，是讓 AI 儘可能強大。而我們認為，實現這一點的方式是讓它與軟件結合。

因此，我們設計時考慮的不只是模型外部的使用方式，連模型深層的內部機制也要針對軟件進行優化。Jev 是我們的第一個大型可編程模型，也可以叫 System 1 模型，隨你稱它為什麼。它的優化目標是“每美元智能”，Jev 這個名字也由此而來。Swyx：Jevons Paradox，傑文斯悖論。Diogo Almeida：對，就是傑文斯悖論。它的目標是實現性價比最高的智能模型。我特別喜歡跟人討論，在可靠性、成本、校準和速度之間，到底什麼最重要。Jev 這個名字以後會代表一系列站在“每美元智能”方面處於領先地位的前沿模型。當然還有別的優化方向。在機器學習裡，至少對於擅長機器學習的人來說，一切都關乎取捨。

而我們決定在這個方向上全力以赴。2從模式坍塌到校準失真：RLHF 的另一面 Swyx：我覺得“校準”是近來才開始受到關注的一個問題。我們之前請 Hugging Face 的 Clementine Foreia 做過一期節目，當時有聊到了這個話題。這也是你對 RLHF 的一個核心看法：模型的回答會向用戶想聽的內容，或者最可能出現的內容收攏，而不是反映它對一件事真正的內部置信度。Diogo Almeida：我聽說你們的聽眾技術背景很強，所以正想深入講講這個問題。發佈視頻裡的每一項表述，我都花了很大力氣核對，確保準確、真實。顯然，這種做法還挺少見。

視頻裡有一點幾乎沒人注意到，就是 RLHF 的缺點，尤其是“模式坍縮”（mode dropping）。Swyx：mode dropping 還是 mode collapse？Diogo Almeida：在這裡我說的是一回事。以後我想專門寫一篇博客，但現在我想盡可能把這件事講給更多人聽。我其實很認同 Yann LeCun 的不少判斷。但他有一頁很有名、也很有爭議的幻燈片，大意是“大語言模型註定行不通”。Swyx：你說的是那個“蛋糕”比喻？Diogo Almeida：不是，是講序列長度的那一頁。他的推理是：如果生成每一步都有出錯概率，文本越長，至少犯一次錯的概率就越高。

這個推理看起來在數學上很直觀，但模型的實際表現並沒有簡單地照這個趨勢發展。我很喜歡拿它來問：數學推導和觀察結果之間，差異出在哪裡？Swyx：問題出在哪裡？Diogo Almeida：問題在於，如果模型試圖覆蓋整個分佈，或者它的概率分佈經過了良好校準，那麼它不會因為產生少數離群結果而受到過度懲罰。你會預期它有時生成落在常見分佈內的內容，有時生成分佈之外的內容；覆蓋整個分佈，就會出現這種情況。你可以想想生成對抗網絡出現之前的圖像生成模型：它們生成的圖像往往是模糊的。而生成對抗網絡會模式坍塌：它會直接丟掉佔比很小的類別，只生成那些最常見的類別。

也正因為如此，前面那個“序列越長錯誤必然累積到不可用”的效應並沒有按最簡單的方式出現。為了生成很長、又不容易出現明顯錯誤的文本，模型就得極其保守，因為一旦犯錯，人很容易看出來；相反，一個看上去沒問題、其實遺漏了微妙之處的回答，就很難被察覺。為了讓模型的概率分佈保持校準而帶來的要求，對文本序列的生成方式會產生很大的影響。這層關係很微妙。我認為，它既解釋了為什麼那種直觀的錯誤累積推論沒有應驗，也解釋了為什麼文本模型不擅長決策：讓本來用於生成文本的模型承擔過多決策任務，效果往往不好。Swyx：既然說到 Yann，你認同他的解決方案嗎？也就是用世界模型，比如 JEPA 這一類嵌入模型的方法。

問題的一部分似乎在於，我們讓模型基於已經輸出的詞元（token）繼續推理，再把輸出送回去，反覆循環，直到生成完整的一句話。Yann 提出的解法是聯合嵌入預測架構（JEPA），你覺得這就是解決辦法嗎？你對此有什麼看法？Diogo Almeida：我可能不該把機器學習內部的事講得太細。不過，除了說話有時比較放得開，我做事其實很務實。剛才對模型的判斷也是從實際效果出發。我是不是 Scaling Law 的支持者？要看它能帶來什麼。Scaling Law 告訴你：投入一定量的資源，某項能力能提高多少。通常，資源投入要大幅增加，收益卻不會同比增長。

除非那一點能力提升非常有價值，否則看起來就不是一筆好投資。對我來說，更重要的問題是：用手頭已有的資源，我們怎樣才能帶來最大的實際改變？我的出發點始終是實用性。比如 Yann LeCun 的 JEPA 方向，我覺得早期研究很精彩，也很喜歡看到優秀的研究工作。至於它現在是否已經足夠實用，我暫時不想下判斷。目前研究界還有很多沒有被充分挖掘的好成果，像未經打磨的鑽石。它們沒有進一步變成有用的技術，部分原因是大家還沒找到適合發揮其價值的任務。Jev 的發佈當然對 TypeSafe 有利，但我希望它帶來的影響不止於此。

一方面，開發者可能會基於 Jev 做出大量新軟件；另一方面，也會有人沿著不同方向探索：還能用什麼方式把模型能力提供給程序，讓軟件做出更多以前做不到的事。如果這些嘗試同時出現，那種感覺就有點像早期互聯網那種充滿活力的氛圍——大家紛紛探索，新的用法不斷冒出來。我想這也是為什麼推特上大家一提到“Jev”，就像在開派對一樣。Swyx：這很讓人振奮，因為它和我們習慣聽到的說法太不一樣了。過去常有人說：“抱歉，這件事你做不了。模型研發要遵循縮放規律，只有大實驗室才有資源參與。

” 3Jev 的開發理念：AI 做決定時，不能突然拒答 Diogo Almeida：Discord 上經常有人問我：為什麼反對安全對齊，為什麼 Jev 不會拒答？我還沒來得及完整解釋。先說清楚，我並不反對安全本身。我認為，常見的安全對齊方式往往與使用者的目標不一致；而對供程序調用的模型來說，突然返回一句拒絕，簡直像是發生了類型錯誤。如果你是人在和聊天機器人互動，或者用編程工具時碰到“抱歉，我不能讀取 DNA.py”，當然會覺得煩，但至少你能看見它、換個辦法繼續。大家用久了，甚至習慣了處理這種情況。可如果模型是後臺運行的軟件依賴，某次調用突然拒絕了，會發生什麼？

調用它的用戶可能根本不知道底下還有這個模型。難道只因為輸入裡出現一條特殊消息，就讓整個軟件流程隨機中斷嗎？我認為，這種設計沿用了“AI 是一個聊天同事”的想象，沒有充分考慮模型作為軟件組件時需要滿足什麼要求。Swyx：你想要的是一種能在各種地方使用的基礎能力。Diogo Almeida：對，一個足夠通用的“認知核心”。它要能適應未來各種我們現在想不到的用例。用戶已經拿 Jev 做了不少出乎意料的東西，我們當然沒針對那些具體應用訓練過它。不過，這並不讓我意外；我們訓練時就讓它處理過更多樣的情況。再回到安全對齊。

我認為，對 ChatGPT、Claude 這種直接面向人的產品，設置安全規則是可以理解的。但需要區分能力對齊和安全對齊：能力對齊是讓系統儘可能按使用者的要求完成任務。軟件工程師很需要這一點——行為越可預測，越容易把模型集成進程序，也越少需要反覆試探。Jev 現在離理想狀態還很遠。我們希望把可靠性再提高几個數量級，最終讓調用智能像執行數據庫查詢一樣自然：需要時調用，不必每次都擔心它會怎樣回應。而我所說的安全對齊，往往意味著模型除了遵循當前使用者的指令，還要優先服從模型提供方——比如 OpenAI 或 Anthropic——設定的另一套規則。這兩套要求有時會發生衝突。

Swyx：你說的是不同層級的規則和價值取捨。Diogo Almeida：對。對於直接面向用戶的產品，這樣做有道理。比如 ChatGPT 的提供方不希望產品支持某些成人角色扮演內容，那是他們的選擇，也可能符合他們面向家庭用戶的產品定位。但 API 不一樣。開發者需要根據接口的行為來寫程序。如果模型在程序運行過程中突然按提供方的另一套規則拒絕執行，開發者很難處理。我對此確實有點激動，得讓自己冷靜一下。Swyx：大家能感受到你很在意這件事。不過我想提出一個更嚴肅的反例：如果有人用這個 API 來殺人呢？成人內容或許屬於私人選擇，但 AI 也可能被用於戰爭。

公司完全可以合理地決定，不希望自己的 API 被用於這類用途。Diogo Almeida：我理解。企業可以出於實際考慮持有這種立場。我自己也不希望我們的技術被用來傷害人，當然希望它更多地用於有益的事情，也願意為此作出努力。但我不認為應該把這些偏好直接寫進通用技術的底層能力。我的顧慮是，每當你為了某一種特定規則，強行讓模型在某些問題上改變判斷，就可能進一步割裂它的能力。現在的模型已經有不少這樣的不一致了。我更傾向於把智能看作數據庫，而不是一位“AI 同事”。我們通常不會要求數據庫在執行查詢時，自行判斷用戶最終會不會把結果用於壞事。我認為，對通用智能接口也應該考慮類似的責任邊界。

還有一件事讓我覺得奇怪：有開發者在 Slack 上告訴我們準備部署某個應用，問“我們可以這樣用 Jev 嗎？”我的第一反應是：我們提供的是 API，你是開發者，具體應用怎麼設計，不該事事由我們批准。理想情況下，複雜任務會被拆成許多較小的調用；作為底層服務提供方，我們甚至不應該知道下游用戶的完整任務是什麼。這種邊界能給軟件工程師更大的自主空間。我希望他們把能力用於好的事情。我們也討論過開源、公益支持等辦法，只是眼下還沒精力落實。但只要由我負責，我就不希望把這些價值偏好直接固化進模型的底層判斷裡。Swyx：既然說到平臺與開發者的關係，也想澄清一下你們的隱私條款和使用條款。

之前有些人產生了誤解，覺得你們對 API 用途限制得很嚴。Diogo Almeida：我不確定你具體指哪一條，不過我看到過一些關於基準測試的討論。Swyx：對。你之前公開說過，相關限制是預覽期條款裡留下的，正式發佈時沒有及時移除，團隊準備修改。Diogo Almeida：團隊有些進展我甚至還沒跟上。我請他們和律師確認這件事。我們顯然不打算阻止用戶測試和比較模型；恰恰相反，我支持他們這麼做。但這和我怎麼看公開基準榜單是兩回事。我非常不喜歡公開榜單。至於用某些內部基準作為實際能力的替代指標，我的態度也比較審慎。Swyx：你擔心的是榜單很快飽和，還是模型可能見過公開測試題，因此容易刷分？

Diogo Almeida：刷分容易，是原因之一。假設兩年後，市場上有很多公司在做與 Jev 類似的產品，我們提供的價值可以說是“每美元獲得多少智能”，或者“每秒獲得多少智能”。大家很容易盯著價格和速度，因為它們好測量。但價格和等待時間是用戶付出的成本，用戶真正想得到的是有用的智能。難就難在，模型到底有多好，有些部分很難用一個分數概括。Jev 發佈後，開發者親自試用產生的反應，甚至比發佈視頻更讓我在意。他們感受到模型在實際使用中的表現，也感受到我們為此下了多少功夫。公開基準想用數字幫助大家建立信任，但它太容易被針對性優化。

即使團隊主觀上不想刷榜，也可能不斷收集與測試集相似的數據，讓模型在榜單上表現更好。過去有些實驗室收集類似 MMLU 的題目來訓練，在我看來，這不過是繞了幾步優化基準成績。所以我認為，開發者可以先憑實際體驗建立初步判斷，隨後必須把模型放進自己的工作流，測量它在那個具體任務上的表現。我們的工作則是持續提高可靠性，讓它越來越值得信任。可靠性始終是 TypeSafe 要解決的問題；如果只想儘早發佈一個能力不夠好的版本，我們一年半前就可以推出 Jev 了。

4“最苦澀的教訓”：先選對任務，再談模型和數據 Swyx：你前面提到自己的“最苦澀的教訓”（The Bitterest Lesson），我們來展開講講。Diogo Almeida：Sutton 的“苦澀的教訓”強調算法和計算的重要性。但在我看來，數據比算力重要得多；而最難、也最重要的，是先選對任務，找到研究的 North Star（核心目標）。大語言模型的發展中，研究目標發生過幾次這樣的轉變。RLHF 把重點轉向指令遵循，當時沒人意識到模型能在這件事上做到那種程度。RLVR 又把方向往前推了一步。現在，我們用 RLCD 定義了另一個任務：讓程序能夠把模型放進運行流程，可靠地調用它的判斷。

數據對此至關重要。我怎麼強調都不為過。Swyx：所以你們更願意把 TypeSafe 稱為一家“數據實驗室”，而不是“模型實驗室”？Diogo Almeida：完全正確。我們會一直非常重視數據。對我來說，模型能力的提升，很大程度上就是數據問題。數據工作極其複雜，卻也能把可靠性一位一位地往上推。數據選取和處理方式稍有變化，結果就可能大不一樣。Swyx：你們也在大量招聘數據人才。怎樣才算優秀的數據工作者？你說過你們使用合成數據，但“數據是合成的”顯然只說到了表面。是不是還要有人認真檢查這些數據，指出問題，再回去重新生成？Diogo Almeida：是，但完整回答會複雜得多。

我給新入職的數據同事做的培訓，可能比這期播客還長。這裡先講最重要的幾層意思。首先，任務決定數據的形態。RLVR 需要的數據在某種程度上是供模型探索的環境；RLHF 需要人類反饋。每種任務都有自己的數據形式，我們也一樣。所以我們做的合成數據，並不是一個通用模板生成出來的東西。其次，我們不想用用戶數據訓練模型，即使取得許可、技術上也做得到，我們仍不想依賴它。真實世界的數據有很強的偏向：很多人反覆提出相似問題，需求呈現冪律分佈。直接按這些數據訓練，模型容易對高頻場景過擬合，其他能力反而變得不均勻。我們瞄準的是多年後的應用。

到那時，模型也許會成為深入軟件技術棧各層的通用基礎設施，支撐今天還沒人想到的產品。如果打個比方，可以把一般的大語言模型想成 UDP，把我們的模型想成 TCP：開發者能在上面構建各式各樣的應用。即使我們拿到了今天所有用戶數據，它也只能讓模型更適應今天，未必能幫助開發者做出未來的軟件。因此，數據團隊的工作有點像藝術創作。他們研究模型的“認知核心”，找出能力不平整、不穩定的地方，再有針對性地處理。我們認為自己的模型在這方面已經相對平滑，但不可能做到完美。一次修正最好能改善一類問題，在過去、現在和未來不同情境下都有效，而不只是修好某一道題。Swyx：解決普遍問題，而不是隻解決一個具體案例。

Diogo Almeida：正是這樣。每次做到這一點，都需要很強的判斷力。5“Jev 出現之前的 AI 世界，是個悲劇” Swyx：你剛才說，我理解數據的方式受 RLVR 影響很深，這個批評挺公允的。那我們具體聊聊 RLCD。你們目前還沒有發表介紹它的論文，對嗎？在不瞭解技術細節的情況下，大家怎樣判斷 RLCD 確實代表一種不同的方向，而不只是一個新造的術語？“校準”這個概念我能理解，但 RLCD 與大家熟悉的 RLHF 究竟有什麼區別？Diogo Almeida：還沒有發表論文。你的問題很好，不過要回答它，我想先反問一句：RLHF 指的是什麼？這個詞在不同時期指過好幾種工作。

最早有通過人類偏好反饋，讓系統學會完成難以精確規定的任務的研究。我記得有一項工作涉及教機器人做後空翻，可能與 Paul Christiano 等人的研究有關，但具體是哪篇，我也不能完全確定。PPO 是一種算法，並不天然意味著獎勵一定來自人類反饋。後來 OpenAI 做了“學習摘要”的工作，把 PPO 用在語言模型上，讓模型學習完成摘要這類很難用簡單規則規定好壞的任務。人們也會把這稱為 RLHF，不過我沒有參與那篇論文。但當我說 RLHF 時，我更想強調的是指令遵循這個任務，而不是某篇論文采用了 PPO。

真正重要的，是研究者確定了一個新的 North Star：讓模型理解並遵循人的指令，是一個值得持續優化的方向。今天的 DPO 及其後續方法即使沒有使用那篇論文裡的算法，也仍是在做這個意義上的 RLHF。同樣，RLCD 對我們來說是在提出一個新的任務目標。我使用這個名字，是想準確說明我們在優化什麼：讓 AI 能被程序調用，成為軟件可以使用的能力。Swyx：也就是說，關鍵詞是“可編程的 AI”：讓程序能夠在不需要人每一步介入的情況下使用模型，進而自動化更多工作。我理解你的 North Star 對嗎？Diogo Almeida：對，但還要加一個前提：必須務實。我們得看清當前語言模型實際擅長什麼。

有些面向程序的新輸出類型在概念上可能很棒；如果技術還不足以讓它可靠工作，暫時不推出，也沒什麼可遺憾的。在我看來，Jev 出現之前的 AI 世界，簡直是個悲劇。這話聽起來很狂妄，但這個想法在我創辦公司很久以前就有了。Swyx：這點我可以作證。你已經談了好幾年。Diogo Almeida：是。我起初以為做出一個能供程序調用的模型不會太難，整個項目一週就能完成。事實證明我錯得離譜。以前我甚至覺得：“這個問題我馬上就能解決。”現在想來，我得向當時被我低估的 OpenAI 同事道歉。AI 領域還有另一件令人遺憾的事：承諾很大，實際交付卻跟不上。我認為 RLHF 和 RLVR 路線都存在這個問題。

但讓我一直放不下的，是 AI 明明已經表現出很強的能力，卻仍有大量簡單工作無法自動化。我在演講時常問：為什麼 AI 能處理極其困難的數學問題，卻連許多基礎、重複的工作都接不過去？這些工作不要求人有多高的智力，也談不上令人滿足，但現實中仍得有人做，因為軟件還沒法可靠地把它們自動化。我們已經有了一臺很強的“智能引擎”，卻缺少合適的接口，把它接進那些有經濟價值的流程。即使有一天 TypeSafe 不復存在，這個方向也已經被打開。別人也許需要一兩年追上來，也可能更快；如果模型質量的差異持續重要，我們會有更長時間的優勢。但比公司競爭更重要的是，整個領域開始探索：智能還可以怎樣接入軟件。

我相信這會改變技術接下來的發展路徑。Swyx：我完全同意。你們真正創造的是一種新的可能性。我試著替你概括一下，方便大家理解：不要把 TypeSafe 和 Jev 的成功看成僅僅是“出現了一種新的模型類型，我可能可以繼續沿用之前的路徑去做事”。不是這樣，實際上，可能還有好幾種別的模型類型值得探索，這個行業應當是百花齊放的態勢，應該讓各種嘗試奮都發展家裡。其中有些方向，你們大概也會親自去做。Diogo Almeida：完全正確。那種早期互聯網的活力又回來了。我覺得我們重新回到了某種技術烏托邦時刻，再也不用像以前那樣感慨：“唉，有時候我的編程智能體能工作，但真正最好的東西都被公司內部藏起來了”。

創造新東西又成了一種真實的可能。當然，接下來會是一個相當瘋狂的世界，大家最好坐穩了。我對此興奮極了。Swyx：現在你們有了資金，也有了發佈後的勢頭，終於能把想法做出來給大家看。Diogo Almeida：對。以前一直講，卻不能把最關鍵的東西拿出來，感覺像總在吊大家胃口。我的演講尤其如此：我說 AI 應該推動自動化，卻沒法展示它具體怎樣做到。你之前看過我們的宣言，還說有些地方寫得太模糊：“第一步是什麼？你們說的智能模型究竟是什麼？” Swyx：我當時問你模型在哪裡，你只說“快有了”。我主要對“可組合”這個詞有意見，不過“Build Prod, Not God”這句口號很好。

Diogo Almeida：謝謝。團隊很認同這句口號。我們對正在做的事很興奮，但大家也很務實。Swyx：宣言裡還有一份“秘密總體計劃”，講怎樣一步步構建面向機器、可組合的 AI。Diogo Almeida：寫成“秘密總體計劃”是你的建議，我得正式把功勞記給你。Swyx：謝謝。不過你當時只給我看了一半故事