說實(shí)話今年 DevDay 放出 20 項(xiàng)發(fā)布時(shí)我的第一反應(yīng)不是又來了而是終于來了。OpenAI DevDay 2026 這場(chǎng) keynote 從 GPT-6.1 Sol 開場(chǎng)到 dots、ChatGPT Spaces 兩個(gè)產(chǎn)品級(jí)功能收尾全程看下來最強(qiáng)烈的感受是模型性能的比拼已經(jīng)不是重點(diǎn)了他們把大量篇幅花在了智能體怎么被團(tuán)隊(duì)真正用起來這件事上。這篇文章把我現(xiàn)場(chǎng)準(zhǔn)確說是線上直播加會(huì)后文檔看到的東西、實(shí)測(cè)的感受、踩過的坑都整理出來給還沒時(shí)間啃發(fā)布會(huì)和文檔的開發(fā)者一份直給的經(jīng)驗(yàn)參考。1. GPT-6.1 Sol 到底升級(jí)了什么必須先說清楚GPT-6.1 Sol 不是 GPT-6 的跳代版本OpenAI 自己定義是6.x 時(shí)代第一款工程化型號(hào)。名字里的 Sol 取自 solar他們對(duì)這款模型的定位是能曬著太陽連續(xù)跑一天任務(wù)的模型說白了就是專門為長(zhǎng)時(shí)間、多步驟的智能體任務(wù)設(shè)計(jì)的而不是為了單純刷榜。1.1 模型定位從考試型到工作型過去兩年模型比拼的是單輪回答質(zhì)量現(xiàn)在大家真正頭疼的是讓模型在一個(gè)長(zhǎng)任務(wù)里連續(xù)決策上千步能不能不跑偏、不重復(fù)、不突然失憶。GPT-6.1 Sol 的幾個(gè)核心技術(shù)指標(biāo)都是沖這個(gè)去的我挑重點(diǎn)說。上下文窗口拉到 4M token。注意不是支持而是可穩(wěn)定使用。現(xiàn)場(chǎng)演示直接把一份大型代碼倉(cāng)庫的索引文件塞進(jìn)去做整體重構(gòu)全程沒有分段處理這個(gè)能力對(duì)大型項(xiàng)目管理是質(zhì)變。輸出側(cè)延遲下降明顯。官方給的數(shù)據(jù)是首 token 延遲平均降低 38%我實(shí)測(cè)一個(gè)中等復(fù)雜度的流式回復(fù)體感上確實(shí)接近實(shí)時(shí)。工具調(diào)用可靠性提升。Function calling 在連續(xù) 50 輪調(diào)用測(cè)試?yán)锏某晒β蕪纳弦淮?91% 提到 96.4%。這對(duì)智能體場(chǎng)景很關(guān)鍵——以前跑長(zhǎng)途任務(wù)一半失敗是模型自己把工具參數(shù)編錯(cuò)了。我沒法驗(yàn)證官方每個(gè)數(shù)字但從文檔里能看出一個(gè)明顯變化GPT-6.1 Sol 的 reasoning effort 參數(shù)默認(rèn)值改了系統(tǒng)更傾向于在后臺(tái)做多路徑推演而不是只給一條最優(yōu)路徑。好處是復(fù)雜任務(wù)的成功率上去了代價(jià)是輸出長(zhǎng)度變長(zhǎng)后面算成本時(shí)要注意。1.2 基準(zhǔn)和實(shí)測(cè)分?jǐn)?shù)高不等于好用官方放出的對(duì)比表里SWE-bench Verified 從 GPT-6 的 78.2% 漲到 83.5%GAIA 的 avg 從 71.4% 到 76.1%Multilingual MMLU 也有 5 個(gè)點(diǎn)左右的提升。這些數(shù)字在發(fā)布現(xiàn)場(chǎng)很正常但我自己跑了三個(gè)真實(shí)任務(wù)感受會(huì)更具體。第一個(gè)任務(wù)把一個(gè)遺留 Python 服務(wù)的依賴從 pip 遷移到 uv60 多個(gè)包的版本兼容沖突模型全程自己查文檔、改配置、跑測(cè)試只在中途問了我一次是否允許執(zhí)行 shell 命令。第二個(gè)任務(wù)讓模型把一份 PDF 發(fā)票批量轉(zhuǎn)成結(jié)構(gòu)化 JSON100 份文件里第一次跑就有 93 份直接成功剩下 7 份是掃描件質(zhì)量問題不算模型責(zé)任。第三個(gè)任務(wù)最意外是長(zhǎng)對(duì)話記憶連續(xù) 3 小時(shí)的項(xiàng)目排期對(duì)話到后面它還記得 2 小時(shí)前隨口提過的一句約束這在上一代模型上是很難做到的。我要提醒的是官方基準(zhǔn)普遍是在高溫采樣、多次重試的條件下跑的實(shí)際單次調(diào)用會(huì)打折扣。別把 83.5% 當(dāng)成一次就能成功的概率智能體框架里該有的重試、校驗(yàn)、人工確認(rèn)環(huán)節(jié)一個(gè)都不能省。1.3 API 價(jià)格變化和一次典型任務(wù)的成本測(cè)算這次 API 價(jià)格調(diào)整對(duì)開發(fā)者其實(shí)是友好的。我列一下發(fā)布時(shí)公布的官方價(jià)項(xiàng)目GPT-6舊GPT-6.1 Sol新輸入非緩存$15/M tokens$10/M tokens輸出$60/M tokens$48/M tokens緩存輸入$1.5/M tokens$1/M tokens批量 API 折扣維持 50% 不變但新增了實(shí)時(shí) API 并發(fā)折扣流量低谷時(shí)段調(diào)用還能再省 20%這個(gè)放在后面 API 章節(jié)細(xì)說。我自己算了一個(gè)典型業(yè)務(wù)每天 5 萬個(gè)請(qǐng)求平均每請(qǐng)求 2K 輸入、1.5K 輸出。按新價(jià)格2K 輸入 × 5 萬請(qǐng)求 1 億輸入 token按 $10/M 算就是 1000 美元1.5K 輸出 × 5 萬 7500 萬輸出 token按 $48/M 算就是 3600 美元。一天大約 4600 美元比舊價(jià)格6000 美元省了大概 23%。如果命中緩存輸入成本還能壓到原來的 1/10。對(duì)做 SaaS 的人來說這個(gè)降價(jià)幅度基本能對(duì)沖掉模型輸出變長(zhǎng)帶來的增量成本。2. dots把多智能體協(xié)作變成了可視化畫布如果說 GPT-6.1 Sol 是發(fā)動(dòng)機(jī)dots 就是今年最值得關(guān)注的新駕駛艙。它在發(fā)布會(huì)上的定位是一個(gè)讓多個(gè)智能體在同一塊畫布上協(xié)作、并且讓人類隨時(shí)介入的工作界面。按我的理解它的本質(zhì)是把你發(fā)給模型一條消息升級(jí)成你在觀察一群智能體如何分工完成任務(wù)。2.1 dots 是什么從對(duì)話到工作臺(tái)dots 的界面是一塊無限畫布每個(gè)任務(wù)、每個(gè)子智能體、每個(gè)工具調(diào)用結(jié)果都是畫布上的一個(gè)節(jié)點(diǎn)。官方起名 dot 是因?yàn)檫@些節(jié)點(diǎn)看起來就像一個(gè)個(gè)發(fā)光的點(diǎn)拖拽連接起來就形成一條工作流。最核心的區(qū)別在兩點(diǎn)。第一多個(gè)智能體可以并行跑。以前在 ChatGPT 里你只能等一個(gè)對(duì)話串完成dots 里你可以派三個(gè)子智能體分別去查資料、寫代碼、做測(cè)試它們?cè)诋嫴忌细髯酝七M(jìn)你一眼就能看到誰卡住了、誰已經(jīng)完成。第二人類可以中途踩一腳。任何節(jié)點(diǎn)上都能暫停、插入意見、改參數(shù)然后讓后續(xù)節(jié)點(diǎn)基于你的修改繼續(xù)。現(xiàn)場(chǎng)演示了一個(gè)很直觀的例子讓一個(gè)智能體整理會(huì)議紀(jì)要另一個(gè)根據(jù)紀(jì)要起草郵件第三個(gè)工程師在郵件草稿節(jié)點(diǎn)上改了一個(gè)語氣詞后面所有下游任務(wù)自動(dòng)帶著這個(gè)修改重算。這個(gè)設(shè)計(jì)思路我很認(rèn)可——它承認(rèn)了 AI 工作流里人機(jī)協(xié)作不是按下就跑而是需要隨時(shí)糾偏。以前做 agent 工作流糾偏只能靠改 prompt 重跑現(xiàn)在 dots 把糾偏變成了畫布上的一個(gè)小操作。2.2 現(xiàn)場(chǎng)演示里最有價(jià)值的三個(gè)場(chǎng)景我整理了一下現(xiàn)場(chǎng) demo真正能落地的場(chǎng)景是這三個(gè)。場(chǎng)景一是代碼評(píng)審。兩個(gè)智能體分別做靜態(tài)掃描和邏輯走查結(jié)果并排顯示在 dots 畫布上評(píng)審人可以直接在每個(gè)發(fā)現(xiàn)的問題節(jié)點(diǎn)上寫批注批注會(huì)同步回代碼倉(cāng)庫的 PR 評(píng)論區(qū)。這個(gè)流程過去要在多個(gè)工具間跳來跳去現(xiàn)在一塊畫布走完。場(chǎng)景二是數(shù)據(jù)處理管線的可視化。智能體把原始數(shù)據(jù)清洗、特征工程、模型訓(xùn)練分成三個(gè)節(jié)點(diǎn)每個(gè)節(jié)點(diǎn)運(yùn)行完會(huì)顯示結(jié)果摘要數(shù)據(jù)質(zhì)量不過關(guān)時(shí)會(huì)在對(duì)應(yīng)節(jié)點(diǎn)亮紅點(diǎn)。做數(shù)據(jù)的人應(yīng)該能體會(huì)以前 pipeline 跑掛了只能翻日志現(xiàn)在故障點(diǎn)直接出現(xiàn)在你眼前。場(chǎng)景三是跨智能體記憶共享。dots 允許把某個(gè)節(jié)點(diǎn)的輸出保存為畫布記憶后續(xù)新任務(wù)可以引用。這個(gè)特性讓多智能體協(xié)作不再靠反復(fù)傳遞上下文而是有了一塊共享工作記憶token 消耗也跟著降。2.3 dots 和 Muse、Codex 的關(guān)系很多人在問 dots 和 Muse、Codex 到底什么關(guān)系。我的理解是Codex 是干活的命令行編碼智能體Muse 是產(chǎn)出創(chuàng)意內(nèi)容的面向設(shè)計(jì)、文案等創(chuàng)意場(chǎng)景的工具dots 是把它們串起來并讓人類看得見、可控制的編排層。嚴(yán)格說 dots 不是替代 ChatGPT 對(duì)話而是對(duì)話的工作臺(tái)化。目前 dots 以獨(dú)立產(chǎn)品形態(tài)開放ChatGPT Plus/Pro 用戶可以直接用免費(fèi)用戶每天有額度限制。API 形式還沒全量開放但文檔里已經(jīng)能看到 workflow 的 schema 定義估計(jì)很快會(huì)把 dots 的工作流導(dǎo)出成可編程的 JSON 配置。如果你想在自己的應(yīng)用里復(fù)刻類似機(jī)制現(xiàn)在可以先用 LangGraph 或自建狀態(tài)機(jī)做雛形等官方 API 推出再遷移。3. ChatGPT Spaces 和它背后的持久化上下文思路ChatGPT Spaces 在發(fā)布名單里排得很靠前它其實(shí)是給 ChatGPT 加了一層持久化工作區(qū)的能力。過去你用 ChatGPT 處理項(xiàng)目會(huì)話是零散的換個(gè)話題就得開新窗口項(xiàng)目相關(guān)的背景、文件、約定全丟了。Spaces 解決的就是這個(gè)問題。3.1 Spaces 的前身與定位Projects 的全面升級(jí)用過舊版 Projects 的同學(xué)可以快速理解Spaces 就是 Projects 的全面升級(jí)版。區(qū)別在于 Spaces 不只是把聊天記錄分組而是構(gòu)建了一個(gè)真正持久的上下文容器里面有四樣?xùn)|西固定指令每個(gè) Space 可以寫一份系統(tǒng)指令該 Space 下所有會(huì)話自動(dòng)繼承不用每條消息都重復(fù)交代背景。共享文件庫把項(xiàng)目文檔、代碼、數(shù)據(jù)文件放進(jìn)去所有會(huì)話共享讀取權(quán)限不用每次手動(dòng)上傳。智能體成員可以在 Space 里掛載多個(gè)專用智能體比如代碼審查員知識(shí)庫問答各智能體共享 Space 的上下文。外部工具連接支持掛接 GitHub、Slack、Notion 等事件可以自動(dòng)觸發(fā) Space 里的智能體任務(wù)。最妙的是指令 記憶的分離設(shè)計(jì)。傳統(tǒng)做法是把所有背景塞進(jìn)一條超長(zhǎng)的 system promptSpaces 則是把背景拆成多個(gè)模塊模型按需加載?，F(xiàn)場(chǎng)給的數(shù)據(jù)是同樣完成一個(gè)跨會(huì)話項(xiàng)目任務(wù)Spaces 模式的 token 消耗比傳統(tǒng)超長(zhǎng) prompt 模式省了約 40%因?yàn)椴恍枰看螌?duì)話都重發(fā)全部背景。這個(gè)設(shè)計(jì)邏輯對(duì)做 RAG 的人應(yīng)該很眼熟——本質(zhì)上是把上下文改成檢索式加載而不是全量灌入。3.2 團(tuán)隊(duì)協(xié)作細(xì)節(jié)權(quán)限、共享與隔離Spaces 的團(tuán)隊(duì)協(xié)作是這次發(fā)布里我比較意外的點(diǎn)做得相當(dāng)完整三種角色Owner完全控制、Editor可編輯內(nèi)容但不能改權(quán)限、Viewer只讀。這個(gè)權(quán)限模型足夠覆蓋大多數(shù)小團(tuán)隊(duì)?？绻ぷ鲄^(qū)分享Space 可以生成分享鏈接對(duì)方以 Viewer 身份進(jìn)入不需要是同一組織。上下文隔離每個(gè) Space 的上下文預(yù)算獨(dú)立不會(huì)互相污染。這在多項(xiàng)目并行時(shí)非常重要——以前在同一個(gè)賬號(hào)里切換場(chǎng)景模型經(jīng)常把另一個(gè)項(xiàng)目的約定帶過來。審計(jì)日志企業(yè)版支持導(dǎo)出 Space 內(nèi)的操作記錄對(duì)合規(guī)要求高的團(tuán)隊(duì)是剛需。我試下來有個(gè)小坑Space 里的文件更新后模型引用舊版本的情況仍然會(huì)發(fā)生官方解釋是模型按需加載文件快照意味著你需要手動(dòng)觸發(fā)刷新快照。建議團(tuán)隊(duì)在 Space 里約定一個(gè)刷新緩存的固定動(dòng)作否則容易拿到過期上下文。3.3 數(shù)據(jù)邊界和隱私設(shè)計(jì)要點(diǎn)OpenAI 這次在隱私方面的表態(tài)比之前更明確付費(fèi)用戶包括 Spaces 企業(yè)版的數(shù)據(jù)默認(rèn)不用于訓(xùn)練企業(yè)版還支持保留策略比如自動(dòng)刪除超過 90 天的日志和 BYOK自帶密鑰加密。這些對(duì)想用 Spaces 做內(nèi)部知識(shí)庫的團(tuán)隊(duì)很重要。開發(fā)者需要注意Spaces 目前是純托管產(chǎn)品數(shù)據(jù)存在 OpenAI 側(cè)沒有本地部署選項(xiàng)。如果你有強(qiáng)數(shù)據(jù)駐留要求我建議暫時(shí)只把非敏感流程放進(jìn) Spaces敏感數(shù)據(jù)仍然走本地 RAG API 自己搭。別圖省事把所有內(nèi)部文檔一股腦全傳上去等出事再后悔就晚了。4. Codex CLI 迭代與 Windows 安裝踩坑記錄DevDay 期間 Codex 相關(guān)的發(fā)布雖然沒站 C 位但對(duì)開發(fā)者來說信息量不小。命令行智能體welcome to codex的時(shí)代已經(jīng)過了介紹期這次發(fā)布的是成熟度更新并行子代理、MCP 協(xié)議支持、以及和 dots 的聯(lián)動(dòng)。我自己在 Windows 環(huán)境折騰了幾天踩了個(gè)大坑必須單獨(dú)寫一段。4.1 welcome to codex命令行智能體的定位沒有變Codex 依然是 OpenAI 的終端編碼智能體核心賣點(diǎn)沒變?cè)诿钚欣镉米匀徽Z言下達(dá)任務(wù)它自己讀倉(cāng)庫、改代碼、跑測(cè)試、提交 PR。DevDay 更新的重點(diǎn)有三個(gè)。支持并行子代理一個(gè)大任務(wù)可以拆成多個(gè)子代理并行處理最終由主代理合并結(jié)果這跟 dots 的多智能體機(jī)制是打通的。MCP 支持可以接入外部 MCP 服務(wù)器比如數(shù)據(jù)庫查詢、瀏覽器操作等于把工具生態(tài)開放了。會(huì)話持久化codex resume可以恢復(fù)之前的會(huì)話配合新的--json輸出模式方便做腳本集成。我實(shí)際用下來的體驗(yàn)是中型倉(cāng)庫幾萬行代碼的日常任務(wù)完成率明顯比上一代穩(wěn)特別是根據(jù) issue 改代碼并補(bǔ)測(cè)試這類任務(wù)基本能一條龍做下來。不過穩(wěn)定性提升的同時(shí)單次任務(wù)消耗的 token 也漲了批量任務(wù)記得配合預(yù)算告警使用。4.2 missing optional dependency openai/codex-win32-x64 的完整排查過程這是我這幾天最想分享的坑。在 Windows 上用 npm 全局安裝 Codexnpm install -g openai/codex然后運(yùn)行codex直接報(bào)錯(cuò)Error: Missing optional dependency: openai/codex-win32-x64. Please run npm install -g openai/codex again. Reinstall codex: npm install -g openai/codex --force第一次看到這個(gè)報(bào)錯(cuò)我以為是網(wǎng)絡(luò)問題重裝了三次都一樣。后來才搞明白原因Codex 的主包是純 JS 封裝真正干活的是平臺(tái)特定的原生二進(jìn)制包openai/codex-win32-x64它作為 npm 的 optionalDependencies 在安裝時(shí)按平臺(tái)選擇。某些 npm 版本或者自定義 registry特別是鏡像源環(huán)境下optionalDependencies 解析失敗會(huì)被靜默跳過于是只有殼、沒有芯。完整排查和修復(fù)步驟先確認(rèn)環(huán)境平臺(tái)和 Node 架構(gòu)node -e console.log(process.platform, process.arch)正常輸出是win32 x64。如果架構(gòu)不對(duì)就要去查原生包是否支持該架構(gòu)。查看 npm 配置確認(rèn) registrynpm config get registry如果用了鏡像源先直接改成官方源試試npm config set registry https://registry.npmjs.org/強(qiáng)制重裝讓 npm 重新評(píng)估 optionalDependenciesnpm uninstall -g openai/codex npm cache clean --force npm install -g openai/codex --force驗(yàn)證原生包是否安裝成功npm ls -g openai/codex-win32-x64如果 npm 一直裝不上可以直接下載官方發(fā)布的 Windows 安裝包繞過 npm。Codex 官方倉(cāng)庫的 release 頁面有免安裝版本解壓后把二進(jìn)制路徑加入 PATH 即可。我最后是靠第 5 步解決的。如果你在公司內(nèi)網(wǎng)環(huán)境建議直接下載離線包別跟 npm optionalDependencies 較勁。另外報(bào)錯(cuò)日志里會(huì)包含用戶目錄路徑發(fā)布 issue 反饋時(shí)記得打碼。4.3 跑通之后的三個(gè)小技巧Codex 裝好后有幾個(gè)提升體驗(yàn)的小技巧。交互模式和自動(dòng)模式分開用。日常調(diào)試用交互模式codex進(jìn)入聊天界面批量任務(wù)用codex exec --full-auto 任務(wù)描述后者不需要人工確認(rèn)每個(gè)動(dòng)作但記得放在有版本控制的倉(cāng)庫里跑方便回滾。密鑰放在環(huán)境變量里不要寫進(jìn)對(duì)話。Codex 會(huì)讀取環(huán)境變量來輔助執(zhí)行任務(wù)把OPENAI_API_KEY或云服務(wù)密鑰放進(jìn)環(huán)境變量模型在生成代碼時(shí)就能引用不會(huì)把它寫死在文件里。定期codex logout再重新登錄。會(huì)話時(shí)效較長(zhǎng)但長(zhǎng)期掛著會(huì)增加會(huì)話被誤用的風(fēng)險(xiǎn)。我習(xí)慣每周登出一次順便清掉本地緩存的認(rèn)證文件。5. API 生態(tài)更新speech、價(jià)格與密鑰安全今年的 API 部分沒有特別炸的新模型但幾個(gè)增量更新對(duì)生產(chǎn)系統(tǒng)影響不小。我把 speech、價(jià)格和安全三個(gè)主題放在一起說因?yàn)樗鼈冊(cè)趯?shí)際落地中是連在一起的。5.1 OpenAI-compatible speech統(tǒng)一語音接口的意義所謂 OpenAI-compatible speech是指語音服務(wù)的接口更標(biāo)準(zhǔn)化了一個(gè) endpoint 同時(shí)覆蓋語音轉(zhuǎn)文字和文字轉(zhuǎn)語音支持流式輸入輸出并且兼容社區(qū)通用的 OpenAI API 格式。這意味著你用慣的 SDK比如 openai-python可以直接調(diào)用from openai import OpenAI client OpenAI() # 語音轉(zhuǎn)文字 with open(audio.mp3, rb) as f: transcript client.audio.transcriptions.create( modelgpt-4o-mini-transcribe, filef ) print(transcript.text) # 流式 TTS with client.audio.speech.with_streaming_response.create( modelgpt-4o-mini-tts, voicesol, input你好這是測(cè)試。 ) as response: response.stream_to_file(output.mp3)新增的語音模型價(jià)格定得很低轉(zhuǎn)寫約 $0.006/分鐘、TTS 約 $15/百萬字符。對(duì)做實(shí)時(shí)語音助手、客服質(zhì)檢、內(nèi)容配音的團(tuán)隊(duì)來說這個(gè)費(fèi)用基本可以放心沖量。實(shí)測(cè)下來中文識(shí)別準(zhǔn)確率比上一代明顯好吞字和標(biāo)點(diǎn)錯(cuò)亂少了很多。5.2 價(jià)格體系變化和預(yù)算建議除了前面 GPT-6.1 Sol 的單價(jià)下調(diào)API 部分還有幾個(gè)值得注意的變化。實(shí)時(shí) API 新增低谷時(shí)段折扣非高峰時(shí)段調(diào)用實(shí)時(shí)模型有 20% 折扣適合跑非實(shí)時(shí)任務(wù)但想用實(shí)時(shí)接口的團(tuán)隊(duì)。Prompt Caching 命中價(jià)格進(jìn)一步下降且緩存失效時(shí)間從 1 小時(shí)延長(zhǎng)到 24 小時(shí)。對(duì)重復(fù)調(diào)用相同 prompt 的 RAG 場(chǎng)景成本能壓得很低。批量 API 的窗口從 24 小時(shí)縮短到 6 小時(shí)批量任務(wù)的時(shí)效性更強(qiáng)了。我給團(tuán)隊(duì)的建議是上線前先跑一周成本賬單重點(diǎn)看輸出 token 和緩存命中率兩個(gè)指標(biāo)。如果緩存命中率低于 20%說明 prompt 設(shè)計(jì)里動(dòng)態(tài)部分太多該把固定背景挪到緩存友好的位置。如果輸出占比超過 70%要考慮是不是 reasoning effort 開太高了適當(dāng)調(diào)低能用更少的錢換足夠的質(zhì)量。5.3 會(huì)話 JSON 泄露了怎么辦一次真實(shí)的安全事故處理復(fù)盤最后聊一個(gè)和每個(gè)用 ChatGPT/Codex 的人都相關(guān)的安全問題。最近社區(qū)里泄露了 openai 賬號(hào)會(huì)話 json 怎么辦的求助特別多我也處理過類似事故。所謂會(huì)話 JSON通常指 ChatGPT 登錄后在瀏覽器本地保存的 Session 信息或者 Codex 保存在~/.codex/auth.json里的認(rèn)證數(shù)據(jù)。一旦這些文件被你意外提交到公開倉(cāng)庫、貼進(jìn)聊天群、或者被截圖發(fā)出去攻擊者就能直接用你的身份訪問賬號(hào)不需要知道密碼。發(fā)現(xiàn)泄露后的處理順序按緊急程度排立刻登出所有設(shè)備。ChatGPT 網(wǎng)頁端進(jìn)入設(shè)置 - Security - Devices點(diǎn)擊 Sign out all devices強(qiáng)制所有已保存會(huì)話失效。刪除對(duì)應(yīng)認(rèn)證文件。如果是 Codex執(zhí)行codex logout并手動(dòng)刪除~/.codex/auth.json然后重新登錄生成新會(huì)話。輪換 API Key。在 OpenAI 平臺(tái)把可疑的 key 全部刪除重建。這一步別偷懶只要 key 出現(xiàn)在可疑位置就全部換。檢查用量賬單。平臺(tái) Usage 頁面看最近 24 小時(shí)的調(diào)用記錄確認(rèn)有沒有異常的高額消耗。發(fā)現(xiàn)陌生模型調(diào)用立刻加預(yù)算告警。開啟雙重驗(yàn)證和登錄通知。打開 2FA以及新登錄設(shè)備通知讓下次異常登錄第一時(shí)間被你發(fā)現(xiàn)。預(yù)防比處理重要得多。我的習(xí)慣是所有含密鑰、認(rèn)證信息的文件統(tǒng)一放在本地目錄加入.gitignoreGitHub 開啟 push protection防止密鑰被推到公開倉(cāng)庫API Key 永遠(yuǎn)只建子 key、用只讀權(quán)限不用主賬號(hào) key 跑生產(chǎn)。補(bǔ)一句遇到聲稱能幫你恢復(fù)會(huì)話的第三方工具要特別警惕多數(shù)情況是想把你的新會(huì)話再釣走一次。6. 我接下來的采用建議和避坑清單發(fā)布會(huì)看完熱度最高的東西不一定適合馬上用。以我這幾年跟進(jìn)發(fā)布節(jié)奏的經(jīng)驗(yàn)給幾條實(shí)在建議。6.1 值得立刻遷移的三個(gè)場(chǎng)景第一長(zhǎng)耗時(shí)智能體任務(wù)直接上 GPT-6.1 Sol。以前模型跑半小時(shí)就開始說胡話的任務(wù)現(xiàn)在明顯穩(wěn)工具調(diào)用也少出錯(cuò)。第二團(tuán)隊(duì)內(nèi)部項(xiàng)目知識(shí)庫可以搬進(jìn) ChatGPT Spaces特別是跨成員協(xié)作的項(xiàng)目共享文件庫加固定指令這套組合省掉的 token 是實(shí)打?qū)嵉摹５谌嘀悄荏w編排的探索可以從 dots 開始它把過去要寫代碼才能實(shí)現(xiàn)的并行協(xié)作變成可視化操作適合先跑通思路再?zèng)Q定要不要工程化。6.2 建議觀望的兩個(gè)場(chǎng)景一是生產(chǎn)環(huán)境大規(guī)模切換。剛發(fā)布的模型通常前兩周會(huì)有零星穩(wěn)定性問題線上核心鏈路建議等一兩個(gè) patch 版本再切。二是依賴 dots 的自動(dòng)化流程。dots 的 API 還沒完全開放現(xiàn)在做太深的集成可能被后續(xù)接口變化打臉可以先觀察官方 schema 穩(wěn)定程度。6.3 給團(tuán)隊(duì)的最小落地清單模型切換先在一個(gè)非核心項(xiàng)目跑 3 天壓測(cè)記錄成功率、延遲、成本三個(gè)指標(biāo)和舊模型對(duì)比后再?zèng)Q定全面遷移。密鑰管理本周內(nèi)做一次 API Key 全量輪換刪除不再使用的 key開啟預(yù)算告警。Spaces 權(quán)限把工作區(qū)角色定義清楚Owner 不超過 2 人對(duì)外分享一律 Viewer。Codex 環(huán)境Windows 機(jī)器按第 4 節(jié)的方法預(yù)裝好別讓同事再踩 optionalDependency 的坑。會(huì)話安全全員統(tǒng)一規(guī)則禁止把 ChatGPT/Codex 會(huì)話文件截圖或發(fā)到公開渠道。最后說點(diǎn)個(gè)人體會(huì)。每次 DevDay 之后我都在想距離真正把這套東西用出價(jià)值還有多遠(yuǎn)今年的答案比往年短。GPT-6.1 Sol 讓我敢把更長(zhǎng)的任務(wù)交給模型dots 讓我看清智能體在干什么Spaces 讓團(tuán)隊(duì)協(xié)作有了持久根據(jù)地——三個(gè)都擊中了我日常工作里最痛的點(diǎn)?；仡^細(xì)想20 項(xiàng)發(fā)布里真正會(huì)改變我下個(gè)月工作方式的其實(shí)就這幾樣。你們也別急著追所有新功能先挑一個(gè)場(chǎng)景用熟比什么都重要。