刚从OpenAI DevDay 2026会场出来的时候我确实有点恍惚。散场通道里到处都是举着手机拍大屏的人旁边两个老哥在争论dots到底该算工具还是Agent前面还有人在翻ChatGPT Spaces的权限设置页面。二十多项发布一口气砸下来再加上压轴的GPT-6.1 Sol如果不是亲历现场很容易只记住一个模型名字就跑了。所以我干脆把现场笔记整理成这篇回顾。这篇东西写给谁看第一类是像我一样盯着模型迭代的开发者第二类是负责部署AI工具、关心协作链路的产品经理第三类是单纯想搞明白OpenAI下一步要干什么的深度用户。这篇文章不吹发布会上的漂亮话只讲我看到的实际形态、它们之间的关联以及哪些发布值得你明天就试用。1. 开场Keynote的三个信号工具链、工作空间、模型代际一起卷1.1 现场节奏二十多项发布是怎么被塞进一个小时的今年的Keynote节奏非常快台上的信息密度比去年高了一个量级。每个产品负责人上台基本只有三四分钟全程没有太多铺垫直接打开界面、跑演示、给参数、切下一个。我坐在媒体区左手边的人一直在飞速记功能名右手边的人已经在吐槽“这根本来不及消化”。这种节奏本身就是一种信号OpenAI已经不满足于一年只发一个重磅模型而是希望把模型、产品、开发者工具、企业治理、生态合作打包成一个整体向前推。我在现场能明显感到台上的演示顺序是有设计的——先讲人怎么用再讲开发者怎么接入最后才讲模型本身。这和过去“模型开场、应用收尾”的逻辑正好相反。二十多项发布看似杂乱其实没有一项是孤立的。dots、ChatGPT Spaces、GPT-6.1 Sol三者之间存在明确的依赖关系Spaces是承载空间dots是空间里的执行单元Sol是空间背后负责复杂推理的引擎。理解了这条线再看其他发布就顺了。1.2 把发布归成五类主线立刻变清楚要在一小时内吸收全部发布内容最朴素也最有效的办法就是归大类。我按自己的现场笔记把二十多项发布粗略归成五类归类典型发布我的现场判断模型层GPT-6.1 Sol、配套多模态接口从单一模型转向“任务模型组合”Sol承担长程推理产品层ChatGPT Spaces、dots、Muse工作台主战场从对话框转向持久化工作区开发者工具Codex命令行Agent、API统一网关强调“签入即用”降低接入门槛平台运维按任务包计费试点、结果缓存策略开始帮用户管理长任务的巨额成本治理与生态团队权限中心、内容水印、企业审计日志回应企业客户对合规和安全的需求这样一看就明白了今年的发布不是“东一榔头西一棒槌”而是围绕一个核心目标展开——把AI从一次性的对话变成可以持续运行、多人协作、长期积累的工作系统。1.3 为什么说这次的重点不是“参数”而是“入口”过去两年DevDay的焦点基本都在模型参数、上下文窗口、跑分成绩上。今年有意思的是全场几乎没有人反复强调benchmark数字台上的注意力明显转移到了“用户默认打开的那个界面”上。这是什么意思呢对大多数人来说他们日常接触AI的入口就是ChatGPT或其嵌入的工作软件。谁掌握了入口谁就掌握了用户习惯。今年的发布里ChatGPT Spaces其实就是要把这个入口进一步“工作化”让用户不再只是打开一个聊天框而是打开一个包含了资料、任务、成员、自动化的完整空间。我个人的判断是模型能力依然是底盘但现在差异化竞争已经抬升到了“入口与工作流”这一层。GPT-6.1 Sol再强如果用户没有合适的载体去使用它感知就有限。dots和Spaces本质上是为Sol这类重模型准备的“落地容器”。2. dots 不是又一个小按钮而是 OpenAI 对“产品形态”的一次重构2.1 dots 到底是什么一个能塞进对话流里的轻量执行单元在Keynote上听到dots这个名字的时候大多数人第一反应是“这又是个小功能”。但实际动手试过之后会发现它的产品逻辑比想象中要重得多。dots可以理解为一个微型执行单元它不是完整对话也不是独立应用而是一个嵌在聊天流、文档或工作区里的小卡片。你给它一段输入它执行一个具体动作然后返回结构化结果。举个例子现场演示了把一份合同里所有截止日期自动提取成日历任务、把一封长邮件转成三个待办事项、把一段客服对话里的用户情绪标记出来。每个动作都很小但做得很专注用完即走不需要专门开一个对话去“调教”。这让我想到很早以前的软件插件概念但dots更轻更像函数有输入、有输出、有副作用阈值。用户不用理解模型怎么工作只需要知道“这一段文本丢进去它给我一个结果”。2.2 Muse 与 dots零件和装配台的关系现场陆续出现了一个和dots关联很深的名字Muse。如果说dots是零件Muse就是把零件组装起来的工作台。官方演示里Muse是以一块类似电子白板的界面出现的。你可以把多个dots拖到同一块画布上用连线定义它们的执行顺序和输入输出关系。比如一个处理客户反馈的流程先把原始反馈文本送入“情绪判定”dot再根据情绪结果分流到“加急处理”dot或“自动回复”dot最后汇总成一张报表。整个流程可以保存成模板团队其他人直接复用。这个设计解决了dots最大的潜在问题——单点好用但难成体系。单个dots做一件事很顺手但真实工作流程往往是多步骤的Muse正好承担了流程编排的角色。我在现场试玩了一下拖拽连线的手感很顺而且每个节点都能单独替换成另一个同类型dot相当于把业务逻辑可视化、模块化了。2.3 和 GPTs、Assistant API 相比dots 的取舍在哪里很多人会问dots和GPTs有什么区别这个问题我在现场问了几个工程师又结合自己的使用经验做了个对比维度dotsGPTsAssistant API粒度单步微技能完整助理配置编程接口级能力运行载体聊天流、文档、Spaces内嵌独立对话窗口任意自建应用能力范围一个点状动作人设知识库多动作完全由开发者编排适合人群普通用户也能建需要一定配置能力面向开发者可组合性可在Muse工作台拼装通常独立使用通过代码任意组合我的理解是三者不是替代关系而是不同抽象层级。GPTs解决“我想要一个管家”dots解决“我只需要一个动作按钮”Assistant API解决“我要把手伸进自己的业务系统”。对大多数普通用户来说dots上手门槛最低也最容易产生“原来AI还能这么干”的直观感受。2.4 实测下来的手感与维护心得我在体验区花了大概四十分钟创建了几个dots整个过程比预想中简单填写一句指令、定义输入格式、设一个输出样式就能生成。改动起来也快改完立刻看到效果不像以前调Prompt那样反复试。但我踩了两个坑值得提一下。第一个坑是“一个dot什么都想做”我一开始试图让一个dot同时完成提取、分类、翻译和生成回复结果输出结构变得非常不稳定。后来拆成四个独立dot用Muse串起来反而稳定得多。第二个坑是权限边界dots默认不会自动读取工作区外部的数据所有外部访问都需要显式授权我一开始没配置导致dot运行时报错。维护经验总结下来就三句话dot只做一件事输入输出字段要固定命名和标签规范好。团队里多人协作时dot的归属和可见范围也要提前约定否则会出现“我建的dot你改不了你要的dot我找不到”的混乱局面。3. ChatGPT Spaces从一对一对话到多人可协作的工作区3.1 Spaces 解决的核心痛点上下文总是被打断如果用一句话概括ChatGPT Spaces解决的核心问题那就是“对话的记忆不再是一次性的而是变成了一块可以反复使用的白板”。过去用ChatGPT做正经事最大的痛苦就是上下文断裂。你今天上午让AI帮你整理竞品资料下午想继续又要重贴一遍链接、重新说明背景。团队协作时更麻烦一个人建好的Prompt和资料另一个人接手后基本要从头开始。Spaces把这个问题解决了它创建一个持久化的空间空间里有栏目、文件、链接、成员以及一堆dots和对话记录。所有进入空间的AI操作都共享同一份上下文。你在这个空间里问过的每句话、上传过的每个文件、跑过的每个dot都会沉淀成空间记忆下次打开就是接着上次继续。现场演示了一个竞品调研场景团队把一个研究报告放在空间里把产品页面截图拖进去然后在讨论区直接问“上季度提到的关键词在新版网页里出现了几次”AI直接引用空间里的历史文件给答案。这个能力放在以前需要人工把资料重新喂一遍。3.2 上手一个团队 Space 的完整步骤我在体验区完整创建了一个团队Space按照现场的公开流程走了一遍步骤大概是这样在ChatGPT主界面点击“新建Spaces”选择“团队协作”类型输入空间名称和用途描述。设置栏目结构官方默认给了“资料库”“对话记录”“任务看板”“沉淀归档”四个栏目也可以自己加。邀请成员分配三种角色所有者、编辑者、访客。所有者管理权限和计费编辑者可以增删内容访客只能查看指定栏目。上传共享素材包括文档、表格、网页链接、图片这些会成为空间里AI引用的基础资料。启用需要的dots比如会议纪要、周报生成、待办提取把它们放进对应的栏目。最后在某个栏目下发起对话这时的对话就开始共享整个空间的上下文了。看起来不复杂但有一个细节很容易忽略栏目的权限是独立配置的。也就是说访客不一定能看到所有对话编辑者也可以只负责某一个栏目。这一点在团队场景中非常重要否则很容易出现“新成员意外看到了历史敏感讨论”的情况。3.3 权限、安全与保姆级提醒Spaces把权限中心单独拎出来做成了发布项可见OpenAI自己也意识到协作类产品的安全是拦路虎。我的建议很直接刚上手时不要贪图方便把所有成员都设为编辑者宁可多花两分钟把每个人能看的栏目划清楚。另外一定要警惕“把太多内容一次性倒进共享空间”。我正在处理的一个客户项目本想图省事把全部会议记录、合同扫描件、内部讨论都放进团队Space结果发现访客角色能看到部分栏目内容赶紧做了二次清理。后来我的习惯是先按阶段上传资料敏感文件单独放到仅所有者可见的栏目。还有一个安全细节和热搜里的“会话数据泄露”相关。如果你曾经把包含完整对话上下文的JSON分享到公开渠道或者同步到了某个不受控的团队空间首先要做的不是删除消息而是立刻吊销相关会话令牌、轮换绑定的密钥再检查该会话是否经过API被第三方读取。这个优先级比单纯清聊天记录高得多。4. GPT-6.1 Sol现场demo之外的冷静审视4.1 Sol 的定位与三个现场演示GPT-6.1 Sol是这次大会的压轴戏。从名字来看Sol有“太阳”和“独奏”的双关意味官方在介绍时的表述是“面向长时间、多步骤、复杂任务的执行模型”。通俗点说它不是用来聊天的而是用来“干活”的。现场演示了三个典型场景。第一个是长文档处理一份几十页的合同Sol把里面所有时间节点提取出来直接生成一个日历任务列表全程没有人工干预。第二个是代码工程在一个真实仓库里Sol通过Codex接手一个跨文件修改任务改了三个文件、跑了测试、提交了一个PR草稿。第三个是多模态混合输入用户一边说问题一边对着屏幕截图Sol同时理解语音和图像定位到前端问题并给出修复建议。这三个场景的共同点是都有一个明确的开始和结束且过程需要多个工具配合。这正是Sol相对上一代模型最明显的进步点它更像一个项目执行者而不是一个查询引擎。4.2 能力边界哪些事别指望它看完demo很容易兴奋但我在实际使用对比中也有几个清醒的判断值得写下来。首先Sol不会凭空获得未授权的数据访问能力。现场演示看似流畅背后是预配置好的工具链和权限。如果你期待它自己去爬取某个需要登录的系统、读取未授权的数据库那是不可能的也是不该做成的功能。其次长任务运行过程中依然存在上下文漂移。我自己测试一个多步骤数据分析任务中期模型开始遗忘最初的约束条件生成了偏离要求的结果。这就需要在任务设计阶段加入检查点每隔几步让Sol输出阶段性结论而不是一口气丢给它一个超大的目标。第三幻觉问题没有被彻底消除。信息不足时它依然会用听起来合理的答案填补空白。尤其在一些冷门领域错误会非常隐蔽。工程上建议的做法是让Sol先列出它不确定的条目而不是要求它给出一个“看起来完整”的答案。4.3 接入节奏与成本策略接入方式分三层。普通用户可以直接在ChatGPT Plus的Spaces里体验团队用户可以在团队Space中开通Sol作为后台推理引擎开发者则通过API或Codex接入。官方没有现场给出完整的计费数字但从公布的策略方向看长任务成本会比普通对话高出不少。我在现场最关心的问题就是成本。一台长任务如果运行半小时涉及多次模型调用和工具调用费用累计会非常可观。结合目前的公开信息和第三方共识我的建议是不要让Sol处理那些用小型模型就能解决的简单任务先做任务分级。比如摘要、情感分类这类工作让上一代小模型先跑只有涉及多模态推理、长时间规划、复杂代码修改的任务才把Sol请出来。另外官方提到了结果缓存策略同样的子任务在短时间内重复执行命中缓存就可以大幅降低费用。实际使用中把高频查询的结果主动缓存到自己的存储里比每次都让模型重新算成本能省下不止一半。5. 开发者生态与 API 的隐性变化Codex、定价与多模态入口5.1 Codex 从“终端里的助手”变成“常驻的工程同事”这次大会上Codex的分量明显加重了。开场环节有一句欢迎语几乎占了半屏Welcome to Codex。它已经不再是我印象中那个在终端里陪你聊代码的辅助工具而是变成了一个可以常驻后台、自动执行多步骤任务的工程智能体。现场演示的流程大概是开发者用ChatGPT账号登录Codex在终端里给出一个任务描述比如“把支付模块的订单状态处理逻辑重构并保持接口兼容”。然后Codex会自己创建分支、读取代码、修改多个文件、运行测试最后把改动做成PR提交。整个过程开发者不用盯着每一步执行任务完成后收到通知来review即可。我个人的实操体会是Codex能提高效率但前提是把它放在一个受控环境里。我试过让它直接操作一个我日常开发的分支结果它改了某个依赖版本导致另一个模块测试失败。虽然它后来自己修复了但这个过程浪费了宝贵的CI时间。正确的做法是给它一个独立分支或沙箱仓库让它自由发挥完成后再人工合入。另一个经验是任务描述里必须写清楚“完成定义”否则模型会认为写完代码就算完成而不是“测试通过且接口向后兼容才算完成”。5.2 多模态 API 入口统一带来的接入变化API层面的变化虽然没有产品层那么抢眼但对开发者来说可能是影响最深远的。今年发布了一个统一的会话式多模态接入入口把文本、图像、音频放在同一个接口体系里处理避免了过去“不同模态走不同接口、依赖不同SDK”的割裂状态。具体来说以前想让应用同时理解图片和语音通常要自己做拼接先用语音识别模型转成文本再把图片传给视觉模型然后把结果重新组装。这次的统一入口让我可以直接给模型传一个包含音频片段和截图的会话上下文它在内部完成理解。语音方面官方发布了兼容现有标准协议的新接口对实时语音应用来说集成成本明显下降。我在现场试了官方示例代码整个调用链比之前短了一截而且响应延迟控制得比想象中好。对于正在做语音助手或客服系统的团队这个更新值得尽快评估。5.3 成本、配额与 Key 管理的实战建议API发布多了成本管理反而成了开发者最需要花心思的部分。根据现场公布的定价结构方向和行业普遍做法我整理了一个成本控制的基本框架场景建议方案简单摘要/分类用上一代小模型不要上Sol长任务高频子步骤命中缓存写自定义缓存层大量短请求走批量接口按任务包计费实时语音用低延迟专用接口避免用重型模型长期Agent任务设任务级预算上限超限自动暂停配额与限流也需要注意。新的统一网关把不同服务的认证和限流统一起来了但这也意味着一个Key的异常流量会影响所有接口。我在现场和几个开发者聊下来大家都认同一个原则不同业务模块使用独立Key不要全局共用一个。key管理上有一条必须强调无论如何都不要分享API Key。网上那些“api key分享”的帖子你永远不知道背后有没有人已经用你的额度跑了一晚上。建议做法是给每个开发者分配独立子Key绑定最小权限定期轮换同时在网关侧开启异常调用监控比如某个Key在凌晨突然产生大量长任务请求就应该告警。另外如果会话级别的JSON或带完整上下文的日志被泄露优先吊销相关密钥并清空会话缓存比安抚用户重要得多。6. 回到工位之后哪些功能值得立刻上手哪些可以再等等6.1 我会立刻用的三件事第一件搭一个个人研究型Spaces。把平时零散的阅读材料、网页截图、笔记草稿都放进去让AI基于这些资料帮我做阶段总结。以前我收藏了几百篇文章基本等于没收藏现在有了一个持久的整理空间效率提升是立竿见影的。第二件用dots把周报和会议纪要自动化。我的日常里有大量重复劳动会议录音转文字、关键结论提取、待办分发。过去这些要手动整理现在拆成几个dots在Spaces里串起来每周节省的时间至少两到三小时。第三件把Codex用在独立分支的代码重构任务上。先从风险低、边界清晰的任务开始比如重命名、提取公共函数、补充单元测试。这类任务规则明确让Agent去做很划算而完成定义很容易写清楚。6.2 建议冷静观察的几件事虽然发布很热闹但有几件事我建议大家不要急着上production。一是长时间运行的Agent任务Sol虽然展示了很强的执行能力但在我的测试中仍然会偶尔跑偏生产环境需要有完善的checkpoint和回滚机制。二是团队权限模型Spaces的权限中心目前对小型团队很友好但大型组织里复杂的跨部门权限、审计合规需求还需要更多企业级文档和模板沉淀。三是新计费结构按任务包计费听起来能省成本但具体到自己的业务场景是否划算必须拿真实流量跑一遍才知道不要看到demo就无脑迁移。普通用户可以先玩的、开发者要深度评估的、团队负责人要重点看权限与合规的这三条线最好分开决策。6.3 给不同类型读者的上手清单普通用户先去开通ChatGPT Plus创建一个个人Spaces把最常用的文件传进去试着用一次周报生成。别急着研究所有新功能先把“持久工作区”这个概念用起来。开发者从Codex的独立分支开始写一个带明确完成定义的任务观察它如何拆解步骤、如何申请权限、如何汇报结果。同时申请API网关的开发者预览把现有应用按新入口重新接一遍。团队负责人别急着全员铺开。先让三五个核心成员在一个项目Space里跑两周看权限配置是否满足需求、资料沉淀是否顺畅、费用是否在预期内再决定是否推广。我在散场之后重新翻了一遍笔记今年真正让我留意的不是某一个单独发布的亮点而是所有功能都指向同一个方向把AI的使用从“对话框”搬进“工作现场”。dots在用户身边就地执行一步Spaces把一整块工作持久化Sol则负责长时间不松手的那类任务。对我个人来说接下来半年真正拉开差距的不是谁手里有最强的模型而是谁先把工作流程改造成AI能直接参与的结构。这个改造本身比挑模型更值得花时间。
