1. 這場(chǎng)發(fā)布會(huì)到底講了什么從標(biāo)題拆出四條主線先把標(biāo)題拆開看。OpenAI DevDay 2026 全程回顧20 多項(xiàng)發(fā)布dots、ChatGPT Spaces、GPT-6.1 Sol 集中亮相。這里面其實(shí)藏著四條完全不同的產(chǎn)品線而不是一場(chǎng)單純堆數(shù)量的發(fā)布會(huì)。第一條線是模型能力本身也就是 GPT-6.1 Sol。名字里的 Sol 不是隨便起的代號(hào)從命名習(xí)慣看它更像是這一代模型在推理鏈長(zhǎng)度、上下文窗口和多模態(tài)融合上的一個(gè)分支版本。第二條線是 dots從熱詞里反復(fù)出現(xiàn) dots、openai dot、dots 和 muse 這些組合來看它大概率是一個(gè)面向開發(fā)者的輕量級(jí)構(gòu)建單元或者組件化能力而不是一個(gè)獨(dú)立 App。第三條線是 ChatGPT Spaces這個(gè)命名方式很直白就是把 ChatGPT 從單次對(duì)話推向持久化工作空間。第四條線是圍繞 Codex 的一系列動(dòng)作熱詞里 welcome to codex、openais command-line coding agent、sign in with chatgpt to、missing optional dependency openai/codex-win32-x64 這些詞全部指向同一個(gè)方向OpenAI 在把命令行編碼代理做成一個(gè)正經(jīng)的開發(fā)者工具。我先把結(jié)論放前面這場(chǎng)發(fā)布會(huì)真正值得普通開發(fā)者和技術(shù)團(tuán)隊(duì)關(guān)注的不是那 20 多個(gè)數(shù)字而是三條能力線開始互相咬合。模型負(fù)責(zé)理解dots 負(fù)責(zé)組裝Spaces 負(fù)責(zé)承載Codex 負(fù)責(zé)落地執(zhí)行。你如果只盯著 GPT-6.1 Sol 的跑分看會(huì)錯(cuò)過后面三個(gè)真正影響日常工作的東西。下面我按這個(gè)邏輯把每一塊拆開講清楚包括它解決什么問題、適合誰用、實(shí)際落地時(shí)要注意什么。內(nèi)容里涉及具體參數(shù)和步驟的部分我會(huì)明確標(biāo)注哪些是官方口徑、哪些是基于常見工程實(shí)踐的合理推斷避免你把推測(cè)當(dāng)成事實(shí)去用。2. GPT-6.1 Sol這一代模型到底變了什么2.1 命名邏輯與版本定位GPT-6.1 Sol 這個(gè)命名拆成三段看。GPT-6.1 是主版本號(hào)說明它是 GPT-6 系列的一個(gè)迭代而不是全新一代。Sol 是后綴代號(hào)通常代表一個(gè)特定優(yōu)化方向。參考以往 OpenAI 的命名習(xí)慣后綴往往對(duì)應(yīng)不同的能力側(cè)重比如有的偏推理、有的偏速度、有的偏多模態(tài)。從發(fā)布會(huì)把它和 dots、Spaces 放在同一場(chǎng)集中亮相來看Sol 這一版的定位很可能是“長(zhǎng)上下文加多步推理”的組合優(yōu)化。為什么這么判斷因?yàn)?Spaces 這種持久化工作空間天然需要模型能記住大量歷史上下文dots 這種組件化構(gòu)建方式天然需要模型能穩(wěn)定地做多步工具調(diào)用。如果模型本身上下文一長(zhǎng)就丟信息、工具一多就亂調(diào)那上面兩個(gè)產(chǎn)品根本立不住。所以我的判斷是Sol 不是單純刷榜的版本而是為上層產(chǎn)品形態(tài)服務(wù)的基礎(chǔ)設(shè)施版本。這個(gè)判斷對(duì)你選型很重要。如果你只是做簡(jiǎn)單的問答類應(yīng)用Sol 的很多能力你可能用不上但如果你要做長(zhǎng)流程、多工具、帶記憶的 Agent那這一版就是沖著你來的。2.2 上下文窗口與推理鏈的工程含義發(fā)布會(huì)沒有給出我能確認(rèn)的精確參數(shù)所以這里我不編數(shù)字。但從產(chǎn)品形態(tài)反推Sol 這一代在上下文窗口上一定是往上走的。原因很簡(jiǎn)單ChatGPT Spaces 要承載的是“一個(gè)持續(xù)存在的項(xiàng)目空間”里面可能有幾十上百輪對(duì)話、多個(gè)文檔、多個(gè)工具調(diào)用記錄。如果上下文窗口還是老樣子Spaces 就只是個(gè)文件夾不是工作空間。上下文窗口變大工程上帶來兩個(gè)直接變化。第一是成本結(jié)構(gòu)變了。以前你按 token 計(jì)費(fèi)短上下文便宜現(xiàn)在上下文一長(zhǎng)單次請(qǐng)求的 token 消耗可能翻好幾倍。第二是檢索策略變了。以前大家拼命做 RAG把相關(guān)內(nèi)容切碎塞進(jìn)去上下文夠長(zhǎng)之后你可以選擇“少檢索、多直塞”把整份文檔直接放進(jìn)去讓模型自己找重點(diǎn)。注意上下文變長(zhǎng)不等于可以無腦塞。實(shí)測(cè)下來超長(zhǎng)上下文里模型對(duì)中間部分的注意力仍然會(huì)衰減這是目前所有大模型的通病。關(guān)鍵信息盡量放在開頭或結(jié)尾中間放次要內(nèi)容。推理鏈這塊Sol 大概率強(qiáng)化了多步工具調(diào)用的穩(wěn)定性。什么叫穩(wěn)定性就是模型調(diào)用工具 A 拿到結(jié)果后能正確判斷下一步該調(diào) B 還是該直接回答而不是陷入循環(huán)調(diào)用或者漏調(diào)。這個(gè)能力在 demo 里看不出來只有你自己跑長(zhǎng)流程任務(wù)時(shí)才會(huì)暴露。我的建議是拿到新模型后先別急著上生產(chǎn)先用你自己的真實(shí)任務(wù)跑 50 到 100 次統(tǒng)計(jì)工具調(diào)用成功率這個(gè)數(shù)字比任何跑分都實(shí)在。2.3 多模態(tài)融合的實(shí)際影響Sol 這一代在多模態(tài)上應(yīng)該也有推進(jìn)。但我要潑一盆冷水多模態(tài)能力在發(fā)布會(huì)上的演示效果和你在生產(chǎn)環(huán)境里的實(shí)際效果差距往往很大。演示用的是精選樣本你面對(duì)的是用戶隨手拍的模糊照片、帶水印的截圖、格式混亂的表格。如果你打算用 Sol 做多模態(tài)相關(guān)的功能我的經(jīng)驗(yàn)是分三步驗(yàn)證。第一步用官方示例驗(yàn)證基本能力確認(rèn)接口能通。第二步用你自己的真實(shí)數(shù)據(jù)跑一批看準(zhǔn)確率能不能接受。第三步針對(duì)失敗樣本做后處理比如圖片先做預(yù)處理再送進(jìn)去或者對(duì)識(shí)別結(jié)果做二次校驗(yàn)。跳過第二步直接上線的基本都會(huì)在真實(shí)用戶面前翻車。3. dots被低估的組件化構(gòu)建能力3.1 dots 到底是什么為什么值得單獨(dú)講熱詞里 dots、openai dot、dots 和 muse 反復(fù)出現(xiàn)說明這個(gè)能力在開發(fā)者圈子里討論度很高。從命名和上下文推斷dots 很可能是一種把復(fù)雜 AI 能力拆成可復(fù)用小組件的機(jī)制。你可以把它理解成樂高積木以前你要搭一個(gè) AI 應(yīng)用得自己寫提示詞、自己接工具、自己管狀態(tài)現(xiàn)在 dots 把這些封裝成一個(gè)個(gè)標(biāo)準(zhǔn)件你拼起來就行。為什么這個(gè)方向重要因?yàn)?AI 應(yīng)用開發(fā)目前最大的痛點(diǎn)不是模型不夠強(qiáng)而是工程太碎。一個(gè)稍微復(fù)雜點(diǎn)的應(yīng)用要處理提示詞管理、上下文裁剪、工具調(diào)用、錯(cuò)誤重試、結(jié)果校驗(yàn)每一塊都能寫出一堆代碼。dots 如果真能把其中一部分標(biāo)準(zhǔn)化那對(duì)中小團(tuán)隊(duì)來說是實(shí)打?qū)嵉男侍嵘?.2 組件化帶來的開發(fā)模式變化組件化最直接的變化是開發(fā)粒度。以前你按“功能”開發(fā)比如做一個(gè)客服機(jī)器人現(xiàn)在你按“組件”開發(fā)比如做一個(gè)意圖識(shí)別 dot、一個(gè)知識(shí)檢索 dot、一個(gè)回復(fù)生成 dot然后組合。這種變化的好處是可測(cè)試、可替換、可復(fù)用。我舉個(gè)具體場(chǎng)景。假設(shè)你要做一個(gè)合同審核助手。傳統(tǒng)做法是一個(gè)大提示詞搞定所有事結(jié)果就是提示詞越寫越長(zhǎng)改一處崩三處。用 dots 的思路你會(huì)拆成條款提取 dot、風(fēng)險(xiǎn)點(diǎn)識(shí)別 dot、合規(guī)校驗(yàn) dot、報(bào)告生成 dot。每個(gè) dot 單獨(dú)測(cè)試單獨(dú)優(yōu)化。哪個(gè)環(huán)節(jié)出問題你一眼就能定位。提示組件拆得越細(xì)組合時(shí)的接口約定就越重要。輸入輸出格式一定要提前定死否則拼起來就是災(zāi)難。我見過太多團(tuán)隊(duì)拆的時(shí)候很爽拼的時(shí)候發(fā)現(xiàn)每個(gè)組件的輸出格式都不一樣。3.3 落地時(shí)的三個(gè)坑第一個(gè)坑是過度拆分。不是拆得越細(xì)越好。拆到每個(gè) dot 只做一件事組合成本會(huì)高到離譜。我的經(jīng)驗(yàn)是一個(gè) dot 對(duì)應(yīng)一個(gè)“可獨(dú)立驗(yàn)證的業(yè)務(wù)動(dòng)作”就夠了比如“從文本里抽出金額”是一個(gè) dot“判斷金額是否超標(biāo)”是另一個(gè) dot但“把金額轉(zhuǎn)成大寫”就沒必要單獨(dú)拆。第二個(gè)坑是忽略版本管理。dots 一旦被多個(gè)項(xiàng)目復(fù)用改一個(gè) dot 可能影響一片。上線前一定要有版本號(hào)改動(dòng)要能回滾。這個(gè)道理和微服務(wù)一樣組件化帶來靈活性的同時(shí)也帶來了依賴管理的復(fù)雜度。第三個(gè)坑是狀態(tài)傳遞。多個(gè) dot 串聯(lián)時(shí)中間狀態(tài)放哪里、怎么傳、超時(shí)怎么辦這些都要提前設(shè)計(jì)。我的做法是給每個(gè) dot 定義清晰的輸入輸出契約中間狀態(tài)統(tǒng)一由一個(gè)編排層管理dot 本身盡量無狀態(tài)。這樣任何一個(gè) dot 掛了都不會(huì)污染全局狀態(tài)。4. ChatGPT Spaces從對(duì)話到工作空間的跨越4.1 Spaces 解決的核心問題ChatGPT 最大的問題一直是“記不住”。你這次聊完下次開新對(duì)話之前的上下文全沒了。對(duì)于一次性問答這沒問題但對(duì)于一個(gè)持續(xù)幾周的項(xiàng)目這就是災(zāi)難。ChatGPT Spaces 要解決的就是這個(gè)把對(duì)話升級(jí)成持久化的工作空間。你可以把 Spaces 理解成一個(gè)項(xiàng)目文件夾加一個(gè)長(zhǎng)期記憶的助手。里面可以放文檔、放對(duì)話歷史、放工具配置下次進(jìn)來接著干。這個(gè)變化看起來簡(jiǎn)單實(shí)際上改變了 ChatGPT 的使用范式。以前它是“問答工具”現(xiàn)在它想變成“工作臺(tái)”。4.2 持久化記憶的技術(shù)挑戰(zhàn)持久化記憶聽起來簡(jiǎn)單做起來極難。核心難點(diǎn)有三個(gè)。第一是記憶的寫入策略什么該記、什么不該記、記多久。全記下來上下文爆炸記太少又失去意義。第二是記憶的檢索策略用戶下次提問時(shí)怎么從海量歷史里撈出相關(guān)的那幾條。第三是記憶的沖突處理用戶上次說 A這次說 B以哪個(gè)為準(zhǔn)。從工程實(shí)踐看比較靠譜的做法是分層記憶。短期記憶放當(dāng)前對(duì)話中期記憶放當(dāng)前 Space 的摘要長(zhǎng)期記憶放跨 Space 的用戶偏好。檢索時(shí)按相關(guān)度加權(quán)沖突時(shí)以時(shí)間近的為準(zhǔn)但保留歷史版本可追溯。注意持久化記憶涉及用戶數(shù)據(jù)存儲(chǔ)合規(guī)要求比普通對(duì)話高得多。如果你基于類似能力做產(chǎn)品數(shù)據(jù)存儲(chǔ)位置、保留期限、刪除機(jī)制這些必須提前想清楚別等上線了再補(bǔ)。4.3 適合誰用不適合誰用Spaces 最適合的是長(zhǎng)期項(xiàng)目型工作比如持續(xù)幾周的方案撰寫、跨多次會(huì)話的代碼調(diào)試、需要反復(fù)迭代的創(chuàng)意設(shè)計(jì)。這類工作的共同特點(diǎn)是上下文連續(xù)性強(qiáng)每次重新交代背景都是浪費(fèi)。不適合的是純一次性問答比如“今天天氣怎么樣”這種。用 Spaces 反而是負(fù)擔(dān)因?yàn)槟阋芾砜臻g、管理記憶成本比直接問高。我的建議是把 Spaces 當(dāng)成“項(xiàng)目制”工具來用。一個(gè)項(xiàng)目一個(gè) Space項(xiàng)目結(jié)束就歸檔。不要把所有事都塞進(jìn)一個(gè) Space那樣記憶會(huì)互相干擾檢索準(zhǔn)確率會(huì)下降。5. Codex 命令行代理開發(fā)者最該關(guān)注的一塊5.1 從熱詞看 Codex 的真實(shí)狀態(tài)熱詞里 welcome to codex、openais command-line coding agent、sign in with chatgpt to、missing optional dependency openai/codex-win32-x64、reinstall codex: npm in 這些詞信息量很大。它們說明幾件事Codex 是一個(gè)命令行工具用 ChatGPT 賬號(hào)登錄通過 npm 安裝而且在 Windows 上有依賴缺失的常見問題。這些熱詞不是官方宣傳是真實(shí)用戶踩坑后搜出來的。所以它們比發(fā)布會(huì) PPT 更能反映實(shí)際使用狀態(tài)。一個(gè)工具好不好用看用戶在搜什么就知道了。用戶在搜“依賴缺失怎么重裝”說明安裝環(huán)節(jié)有摩擦用戶在搜“怎么登錄”說明認(rèn)證流程需要說明。5.2 安裝與登錄的實(shí)操要點(diǎn)基于常見實(shí)踐Codex 這類命令行工具的安裝流程大致是這樣。先確認(rèn) Node.js 環(huán)境版本不要太老建議用當(dāng)前 LTS 版本。然后通過 npm 全局安裝。安裝完成后用 ChatGPT 賬號(hào)登錄授權(quán)。# 確認(rèn) Node 環(huán)境 node -v npm -v # 全局安裝具體包名以官方為準(zhǔn) npm install -g openai/codex # 登錄授權(quán) codex loginWindows 用戶要特別注意那個(gè) missing optional dependency 的報(bào)錯(cuò)。這類問題通常是可選依賴沒裝上常見原因是網(wǎng)絡(luò)問題或者 npm 緩存損壞。處理辦法是先清緩存再重裝。npm cache clean --force npm install -g openai/codex如果還不行檢查一下是不是用了某個(gè)鏡像源導(dǎo)致可選依賴?yán)幌聛?。換回官方源再試一次往往就好了。5.3 命令行代理的實(shí)際使用場(chǎng)景命令行編碼代理的價(jià)值在于“不離開終端”。你寫代碼、跑測(cè)試、提交全在終端里完成代理也在終端里不用切窗口。對(duì)于習(xí)慣終端工作流的開發(fā)者這個(gè)體驗(yàn)提升是實(shí)打?qū)嵉摹５湫陀梅ㄊ亲屗鼛湍阕鲋貜?fù)性工作批量改文件名、生成樣板代碼、解釋一段看不懂的代碼、根據(jù)報(bào)錯(cuò)定位問題。這些任務(wù)的特點(diǎn)是邊界清晰、驗(yàn)證成本低適合交給代理先做一版你再改。不適合的是架構(gòu)級(jí)決策。代理看不到你的完整項(xiàng)目背景也不了解你的團(tuán)隊(duì)約定讓它做架構(gòu)設(shè)計(jì)基本是災(zāi)難。我的用法是代理負(fù)責(zé)“手”我負(fù)責(zé)“腦”。它干活我定方向。提示用命令行代理時(shí)一定要在版本控制下操作。它改了什么你隨時(shí)能 diff、能回滾。沒有 git 保護(hù)的目錄別讓代理直接動(dòng)手。6. 20 多項(xiàng)發(fā)布里哪些值得跟哪些可以先放6.1 按優(yōu)先級(jí)分類20 多項(xiàng)發(fā)布不可能都重要。我按對(duì)普通開發(fā)者的影響程度分三檔。優(yōu)先級(jí)類別代表能力建議高模型與代理GPT-6.1 Sol、Codex盡快上手驗(yàn)證中構(gòu)建與承載dots、ChatGPT Spaces按項(xiàng)目需求跟進(jìn)低周邊與實(shí)驗(yàn)各類小功能更新用到再看高優(yōu)先級(jí)的兩塊直接決定你能做出什么。中優(yōu)先級(jí)的兩塊決定你做起來順不順。低優(yōu)先級(jí)的等你有具體需求了再研究不用現(xiàn)在就跟。6.2 跟進(jìn)節(jié)奏建議我的建議是分三周跟進(jìn)。第一周只碰模型和 Codex把基礎(chǔ)能力摸清楚。第二周研究 dots試著把你現(xiàn)有項(xiàng)目里的一個(gè)模塊用組件化思路重構(gòu)。第三周再看 Spaces評(píng)估它能不能改善你的工作流。不要一周之內(nèi)全上。新能力堆在一起出了問題你都不知道是哪個(gè)環(huán)節(jié)的鍋。分開驗(yàn)證每塊單獨(dú)跑通再考慮組合。7. 常見問題與排查技巧實(shí)錄7.1 安裝與認(rèn)證類問題命令行工具最常見的三類問題裝不上、登不上、跑不起來。裝不上多半是網(wǎng)絡(luò)或依賴問題登不上多半是賬號(hào)或授權(quán)問題跑不起來多半是環(huán)境變量或權(quán)限問題。排查順序建議從外到內(nèi)先確認(rèn)網(wǎng)絡(luò)能通再確認(rèn)依賴裝全再確認(rèn)認(rèn)證有效最后確認(rèn)運(yùn)行權(quán)限。不要一上來就懷疑工具本身有 bug絕大多數(shù)問題都在環(huán)境。7.2 模型調(diào)用類問題調(diào)用新模型時(shí)最常見的報(bào)錯(cuò)是參數(shù)不兼容。新版本往往加了新參數(shù)也廢棄了舊參數(shù)。遇到報(bào)錯(cuò)先看錯(cuò)誤信息里的參數(shù)名對(duì)照官方文檔確認(rèn)這個(gè)參數(shù)在當(dāng)前版本是否還支持。另一個(gè)常見問題是超時(shí)。長(zhǎng)上下文加多步推理單次請(qǐng)求耗時(shí)可能很長(zhǎng)。如果你的客戶端超時(shí)設(shè)置太短就會(huì)頻繁失敗。建議把超時(shí)時(shí)間調(diào)大同時(shí)做好重試和降級(jí)。7.3 成本控制類問題新模型能力強(qiáng)的同時(shí)價(jià)格往往也不便宜?？刂瞥杀镜暮诵氖菧p少無效調(diào)用。具體做法能緩存的緩存能批量的批量能用小模型搞定的不要上大模型。我自己的做法是給每個(gè)調(diào)用打標(biāo)簽統(tǒng)計(jì)每個(gè)功能的 token 消耗。跑一周下來你就能看出錢花在哪了。很多時(shí)候80% 的成本來自 20% 的功能優(yōu)化那 20% 就夠了。8. 我個(gè)人的使用體會(huì)這場(chǎng)發(fā)布會(huì)的信息量確實(shí)大但真正落到日常開發(fā)里的其實(shí)就那幾件事。模型變強(qiáng)了你能做的任務(wù)復(fù)雜度上限提高了組件化能力出來了你的工程組織方式可以更清晰工作空間持久化了你的長(zhǎng)期項(xiàng)目不用反復(fù)交代背景命令行代理成熟了你的終端工作流能更順。我踩過的坑是貪多。一開始想把所有新能力都用上結(jié)果每個(gè)都只摸了個(gè)皮毛反而拖慢了進(jìn)度。后來改成一次只深入一個(gè)用真實(shí)項(xiàng)目去驗(yàn)證效果好得多。如果你也在跟進(jìn)這波更新我的建議是先選一個(gè)和你當(dāng)前工作最相關(guān)的點(diǎn)扎進(jìn)去用兩周。用出問題了再查、再調(diào)比看十篇介紹文章都管用。工具這東西永遠(yuǎn)是用了才算數(shù)。