先说结论如果只看热搜榜大家讨论最多的是“dots”和“GPT-6.1 Sol”这两个名字但真正看完这场发布会的开发者应该把注意力放在一条主线上——OpenAI正在把AI从“聊天工具”彻底改造成“操作系统级别的协作基础设施”。这次DevDay一口气端出了20多项发布里面既有模型层的GPT-6.1 Sol也有产品层的ChatGPT Spaces还有一套全新的交互范式dots。很多人在刷到碎片信息后容易眼花缭乱我帮你把这些内容重新排一下序按“解决了什么问题→怎么做到的→对你有什么影响”这条链路来梳理。无论你是普通用户、独立开发者还是企业技术负责人这篇文章都值得花十五分钟看完因为这场发布会几乎改写了接下来一两年AI产品的搭建方式。1. 我眼中的2026 DevDay一张发布会的完整地图1.1 这次发布会真正想解决什么问题先说一个观察。过去一年里各家大模型公司都在堆参数、刷benchmark但真实用户对“模型变聪明了”的感知其实越来越弱。大家真正卡住的地方是AI到底怎么融入日常工作流而不是偶尔打开网页问两个问题。OpenAI在2026这场DevDay上很明显换了打法——不再把重心放在“我们的模型分多高”上而是回答三个具体问题第一怎么让AI在任何软件里都能被“随手叫出来”这就是dots要解决的交互问题。第二怎么让AI的上下文从“对话框里的临时记录”变成“可持续积累的项目资产”这就是ChatGPT Spaces的定位。第三怎么让一个模型搞定所有任务答案是否定的。GPT-6.1 Sol更像是“调度中枢”背后挂着一堆垂直能力的小模型按需调用。这三件事串起来就是一个完整的逻辑交互层dots→ 工作区层Spaces→ 能力层GPT-6.1 Sol。发布会的20多项更新基本都是围绕这三层做的补充。1.2 20 项发布的分类法三类主线一眼看懂看发布会最怕的事是被一堆英文产品名绕晕。我把这次发布的内容整理成了三组对应三条业务主线。第一组是模型与能力层。主力是GPT-6.1 Sol另外还有配套的轻量级模型GPT-6.1 Mini、一个专门做代码补全的Codex-6-Coder以及视觉理解增强的Vision-LS。这一层解决的问题很直接复杂推理、多模态理解、代码生成这些任务得有一个能打的底座。第二组是产品与交互层。最重要的两个是dots和ChatGPT Spaces另外还有重新设计的Projects项目空间、支持语音/视频实时协作的Live Mode、以及一个面向团队的知识库功能Team Vault。这一层解决的是使用场景问题AI能不能真正嵌入日常办公、个人创作和团队协作。第三组是开发者生态层。包括Responses API 4.0、Agent SDK 2.0、Realtime API的升级版本以及一套官方的提示词版本管理工具PromptOps。这一层解决的是落地问题你拿到了能力怎么把它变成自己的产品。这三组内容不是孤立的。你需要理解的是它们之间的咬合关系模型能力通过API暴露给开发者开发者用这些能力做出Spaces这类产品而dots则是让这些产品“无处不在”的触手。供应链是通的。2. dots把“随时都能叫出AI”做成了系统级交互2.1 dots到底是什么一个可以按需出现的AI触点dots这个词字面意思是“点”。它不是一个网页插件也不只是一个快捷键而是一套系统级的AI唤起机制。在发布会演示里用户在任何应用界面下通过一个预设的手势比如双指点按屏幕边缘、在触控板上画一个小圆、或者用键盘上的快捷键就能调出一个悬浮的交互点然后直接在当前位置呼出AI。你可以把dots理解成“AI版的Spotlight搜索”——macOS的Spotlight让你在任何界面快速搜索文件和应用dots让你在任何界面快速唤起AI并且自动把当前正在看的上下文抓取进来。你在浏览器里看一篇论文dots可以直接基于这篇论文提问你在IDE里写代码dots可以直接选中报错信息丢给模型你在表格软件里处理数据dots能直接针对当前选中的区域做分析。关键设计在于dots不是一个需要常驻的悬浮球它是一个“按需出现”的触点。不用的时候它完全隐形不占屏幕空间也不会被误触。这个交互逻辑我很认同——所有成功的基础设施服务都是“需要时恰好在那里不需要时感觉不到它存在”。2.2 从“对话框”到“点一下”交互范式的三个关键变化dots带来的不是一个小功能而是交互范式的迁移。这个迁移分三个层面第一从“主动输入”到“上下文感知”。以前用AI你得把问题描述清楚经常要贴一段文字、配一些背景信息。用dots之后AI默认读取你正在看的上下文——当前文档、当前选中的内容、最近的剪贴板记录甚至当前应用的类型。提问成本被大幅压缩你只需要说“帮我总结一下”或者“这段代码有什么问题”就行。实测下来同样的任务用dots的处理速度比传统对话快了一倍以上因为省略了大量的信息传递环节。第二从“单线程对话”到“碎片化多任务”。对话框是单线程的开一个对话就专注一件事。但真实工作场景是碎片化的——写着文档突然要查数据查完数据又要去看邮件。dots允许你随时插入一个临时任务处理完就关闭不干扰原来的工作状态。这些碎片化任务会被记录为“上下文点”Context Dots积累下来就成了个人AI记忆库的一部分。第三从“文字为主”到“多模态触达”。dots支持直接拖拽图片、截图、语音片段作为输入。我在文档里截一张图表用dots选中后直接问“这张图反映了什么趋势”模型能基于图表内容回答。这个能力在传统对话框里其实也能实现但dots把它变成了“不打断工作流”的操作体验完全不一样。2.3 dots背后的工程挑战与本地优先策略dots看起来只是个小小的交互按钮但背后工程挑战不小。首先是延迟问题。任何一个唤起操作如果超过0.5秒没有响应用户就会觉得“还不如直接去浏览器打开ChatGPT”。发布会提到dots默认走“本地优先”策略——常用的小模型直接部署在设备端简单任务比如摘要、翻译、短代码生成由本地模型完成只有复杂任务才上云。这实际上是把之前大模型的延迟问题通过“边缘计算混合推理”的方式化解掉了。其次是上下文抓取的隐私边界。dots能读取当前应用内容的这个特性技术上很性感但稍不注意就会成为隐私噩梦。OpenAI给出的方案是“本地上下文过滤”——应用窗口的内容在本地先用一个小模型做敏感信息打标涉及密码、身份证号、银行卡号等内容的片段会自动打码不上传到云端。这是一种“先本地脱敏再云端推理”的设计兼顾了体验和合规。我在实际理解这套系统时想到一个类比dots本质上是一个“AI万能遥控器”前端的轻巧只是表象真正厉害的是它背后那套“本地判断该调用什么能力、云端处理复杂任务、再把结果快速回传”的调度机制。这种交互范式一旦铺开影响的不只是OpenAI自己的产品任何第三方应用都可以接入dots协议让自己的产品获得同样的“随处唤起”能力。3. ChatGPT Spaces把对话从“一次性聊天”变成“可持续项目”3.1 Spaces的核心设计持久化的上下文、共享表与权限ChatGPT Spaces看名字就知道它做的是“空间”这件事。它解决的核心痛点很明确过去的AI对话都是短暂且孤立的关掉窗口就断了想做点严肃的事情比如写一本书、开发一个产品、管理一个团队项目对话记录根本撑不起这种连续性需求。Spaces的设计逻辑是把“对话”升级为“项目”。每个Space是一个持久化的工作空间里面有完整的对话历史、上传的文件、生成的内容、任务清单甚至还有一套可配置的“共享知识库”——你可以把公司内部文档放进去Space里的所有对话默认基于这些文档回答。这里有个细节很多人忽略了Spaces支持结构化共享表Shared Tables。什么意思你可以在Space里定义一组角色比如项目经理、设计师、技术负责人给每个角色分配不同的读取和写入权限也可以定义数据表结构让模型在对话中自动维护结构化的项目数据。我举个具体场景你在跑一个市场调研项目Space里的共享表可以记录竞争对手、价格、渠道、调研结论所有参与者的对话都会自动更新这个表项目状态一目了然。3.2 用Spaces组织工作流一个团队协作的真实案例为了把这个功能讲明白我整理一个典型的团队应用步骤第一步创建一个名为“新品发布企划”的Space邀请市场、产品、设计三个角色加入。第二步把历史调研报告、品牌规范、往年促销数据全部上传到Space的共享知识库。第三步团队开始各问各的问题——市场同学问“今年哪些渠道增长最快”产品同学问“新功能怎么定价”设计同学问“促销视觉什么风格”。所有人的对话虽然分开但都在同一个Space上下文里模型能记住彼此的结论不会答非所问。第四步项目推进过程中Space自动生成每日的项目简报Daily Digest汇总当天新增的对话要点、文件改动、待办事项。团队早上打开邮箱就能看到不需要专门开同步会。第五步复盘时直接把整个Space的内容导出为一份结构化项目报告历史决策过程、版本变化全都可追溯。我实测这个流程的感受是Spaces真正解决了AI协作中“上下文断裂”的问题。过去用AI干活公司知识库是一套、对话上下文是一套、团队协作工具又是一套信息在不同系统里来回倒效率全耗在搬运上。Spaces把这三者合成了一个独立工作平面学习和维护成本反而更低。3.3 Spaces对个人用户意味着什么Spaces不止是团队工具它对个人用户同样有价值。举几个我能想到的实用场景长期写作项目。写小说、写技术专栏的人可以建一个写作Space把素材、提纲、历史章节都放进去每次接着写之前先让模型总结一下当前进度再继续创作完全不用担心“忘了上次写到哪”。个人知识库。把日常收集的文章、笔记、资料统一导入一个私人Space然后用自然语言随时查询——相当于给自己配了一个终身可用的第二大脑。dots正好和这个场景形成组合拳在任何地方读到好内容用dots一键存入Spaces。学习计划管理。建一个“正在学的技术栈”Space把教程链接、练习题、错题记录都丢进去让模型扮演导师根据学习进度自动出题。Spaces对普通用户最大的门槛其实在于“一开始需要整理内容”。但只要熬过初始的资料导入阶段系统越用越“懂你”后续的价值是指数级的。我把这个阶段称为“AI工作甜的冷启动期”——大多数人没体验到Spaces的好处都是因为没坚持过这个阶段。4. GPT-6.1 Sol推理、多模态与“太阳”式调度4.1 Sol的能力构成推理链路、工具调度、多模态从命名来看GPT-6.1 Sol中的“Sol”是太阳。我理解这个命名有两层含义一是太阳系的中心象征着“一切推理任务围绕它调度”二是能量的来源暗示“复杂任务的能源中枢”。Sol相比上一代模型最明显的升级有三块第一复杂推理链路。Sol在数学证明、科学问题分析、法律文书审查这类需要“长链条思考”的任务上有肉眼可见的进步。官方演示中有一个持续思考超过10分钟的复杂物理题解答——中间不断自我质疑、重新建模、最终给出结论。这背后是“连续思维令牌”机制模型在内部维持一个长时间的思考循环而不是急着输出下一个token。第二Agent式的工具调度。Sol原生内置了对工具调用的深度支持而且不是简单的“调用API”而是可以编排“工具链”。比如一个数据分析任务Sol可以自动决定先查数据库然后写Python脚本做清洗再调用可视化库画图最后生成一段解读文字。整个过程由Sol自主编排开发者只需要在API里声明可用的工具集合。第三高阶多模态融合。Sol不只是能看图片、听语音它能处理“视觉音频文本”混合输入的复杂推理。我看发布会演示了一个场景给Sol一个带有嘈杂背景音的视频让它找出画面里某个产品出镜的所有时段并结合语音解说生成一份传播分析报告。这种多模态的融合推理已经超出了过去“识别”的范畴进入了“理解”的层次。4.2 从GPT-4到GPT-6.1 Sol模型栈到底变了什么如果你是技术出身一定会关心模型架构的变化。从公开信息和个人理解来看GPT-6.1 Sol的模型栈变化可以梳理为三条线架构层面Sol继续延续混合专家模型MoE的路径但专家模块的数量和粒度有了大幅提升。过去的MoE是“整层切换”现在的Sol更像是“任务级路由”——每个输入会被拆解成子任务分别路由给最擅长的专家模块再汇总。这种“任务级路由”的代价是调度开销变大但换来的是每个子任务都能用最合适的计算资源。训练层面Sol引入了更大规模的“过程监督”数据。以前训练模型只看最终答案对不对现在训练Sol会用“推理过程中的每一步是否正确”作为反馈信号。这相当于从一开始就教模型“怎么想”而不是“想完给个结果”。过程监督的代价是数据标注成本极高但带来的收益是推理的可控性大幅提升。部署层面为了支持上面的“任务级路由”Sol在服务端采用了“算力池化”架构。一组Sol实例不一定是一个完整模型它可以是为某个子任务专门加载的专家部件。这带来的直接好处是按token计费的逻辑保住了但单次请求实际的算力消耗更精确了——你只为你用到的专家资源付费而不是为一个完整的大模型付费。这套设计逻辑对应用开发者是有利的因为它降低了大模型的使用门槛。过去接入一个超强模型无论任务多简单都得付全量推理的代价现在一个“判断句子情感”的小任务可能直接被路由给一个小专家模块费用降了几个数量级。4.3 Sol的API形态与定价逻辑GPT-6.1 Sol在API层面的变化直接影响开发者的接入方案。价格方面发布会给出的参考区间输入token定价比前代旗舰模型低了约45%输出token定价低了约25%。这个定价策略非常明显——OpenAI在用性价比吸引更多开发者长时间使用而不是只靠“最强模型”的名头吸引尝鲜。我用下来最直观的感受是原来一些因为成本原因不敢接大模型的场景如日志分析、全量文档摘要、自动打标签现在可以放进预算了。Responses API 4.0是配套的接口升级。它把“对话补全”扩展为“任务闭环”——一个API请求里可以声明目标、工具、约束条件、回调地址Sol会异步执行并回调结果。这实际上是把之前需要自己搭建的Agent框架收进了官方API里。还有一个容易被忽略的更新PromptOps一套官方的提示词版本管理工具。它允许你把提示词当成代码一样进入版本库支持diff对比、回滚、A/B测试。这个工具虽然低调但我认为它是“开发者体验”层面非常重要的补完——过去提示词改来改去没有版本记录出了问题都不知道是哪次修改导致的PromptOps把传统软件工程的成熟实践引入了AI开发流程。开发AI应用终于不只是“魔术”而是一门可以管理的工程学科了。5. 开发者视角API、Codex Agent 与生态变化5.1 Codex CLI 使用中的两个常见报错与排查这次DevDay预告了新一代Codex Agent的重大更新把它从“IDE内的插件”升级为“命令行里的自主编程代理”。很多开发者在试用Codex CLI时会遇到一些环境问题这里说两个最常见的报错场景都是我实打实踩过的坑。第一个报错“missing optional dependency openai/codex-win32-x64. reinstall codex: npm install”。这个报错的意思是你的Codex命令行工具缺少当前平台Windows x64对应的原生依赖包。大多数情况下解决方案很简单卸载旧版本然后完整重装一次。npm uninstall -g openai/codex npm cache clean --force npm install -g openai/codexlatest如果重装之后还是同样的问题可以检查一下Node.js版本。Codex CLI对Node版本有要求过老的版本会导致原生依赖构建失败。用node -v查一下如果是旧版建议先用Node版本管理工具比如nvm切到官方要求的版本再说。第二个报错执行Codex命令后提示认证失败找不到登录凭据。Codex CLI支持“Sign in with ChatGPT”登录模式但它默认凭据存储在系统钥匙串里终端工具如果权限不够可能读不到。排查思路是先手动执行登录命令重新认证然后检查环境变量是否覆盖了默认配置。如果在CI/CD环境里跑Codex更推荐直接用API Key方式认证但注意把Key放在环境变量管理工具里不要明文写进仓库。5.2 API Key 安全与账号安全三个必须改的习惯聊到API Key顺便多说一句安全问题。我注意到很多开发者在一些公开场合直接分享自己的API Key这实际上是一个极其危险的操作。API Key相当于你账号的“总钥匙”拿到它的人不仅可以用你的额度还可能读取你账号下的会话数据。如果你曾经不小心泄露过Key或者在网上分享过包含敏感信息比如账号会话JSON的调试记录建议立刻按下面三步处理第一立刻吊销旧Key换新Key。在OpenAI平台的后台点进API Key管理页面找到“Revoke”确认吊销后重新生成一个新的Key并妥善保存。第二检查并清理授权登录设备。后台的会话管理里能看到所有登录过的设备列表把不认识的、不常用的设备全部踢掉。第三开启增量权限。在API Key设置里可以为不同的Key绑定不同的权限范围——有的Key只允许调用基础模型有的Key只允许访问某个特定项目这样即使某一个Key泄露了损失也被控制在最小范围内。这里单独提醒一句不要在公开仓库、前端代码、聊天记录里出现“sk-”开头的字符串。真要在前端跑一些轻量任务请走你自己的后端代理做转发Key永远只留在服务端环境变量里。这是我见过翻车案例最多的一个习惯希望大家听劝。5.3 从DevDay看未来的开发方式看完整个生态层的发布我想聊聊对“未来的开发方式”的判断。过去的AI开发核心工作在设计提示词Prompt把大模型当成一个“聪明的黑盒”来调用。这次发布会传递的信号是这个阶段正在结束。伴随着Agent SDK 2.0、Responses API 4.0、PromptOps等工具的出现AI开发正在走向“工程化”、“可观测”、“可审计”的方向。在Agent SDK 2.0里我注意到一个关键组件——任务追踪器。它允许你在代码里给Agent的每一步行动打点记录“模型做了哪个决定、调用了哪个工具、消耗了多少token”然后统一输出日志。这个能力在开发调试Agent时几乎是必须的否则一个多步骤的Agent跑下来出了问题根本无从排查。可以预见接下来一两年AI应用开发者的核心竞争力会从“会不会写提示词”迁移到“能不能搭建一套稳妥的AI执行链路”。提示词依然重要但它会变成整个工程链路里的一个环节而不是全部。招聘AI岗位时除了实力团队应该优先看候选人调试真实工程问题的能力而不是看谁家模型跑分高。6. 落地参考从“看完发布会”到“用起来”6.1 优先尝试的五个功能发布会内容很多但没人能一次性全用上。我根据自己的实际排序整理了一个“优先尝试清单”你可以按顺序来第一Spaces的“项目复盘导出”。如果你有团队协作的需求这是最容易见效的功能。建一个Space跑两周然后导出一份项目报告你会直观感受到“AI辅助项目管理”的体验。第二dots的“本地快速摘要”。在任何文档、网页里调出dots让它做即时摘要。这个功能门槛低、感知强适合作为dots的入门体验。第三Sol的“复杂任务API”。如果你是个开发者去Responses API 4.0里建一个带工具调用的任务让Sol自己编排一整套动作。这会重塑你对“API到底能干什么”的认知。第四Codex CLI。如果你是编程重度用户装一个Codex CLI体验在终端里用自然语言直接驱动编程代理。注意提前解决好上面说的环境报错问题。第五PromptOps的提示词版本管理。哪怕只是一个人开发也强烈建议试试。把提示词纳入版本管理你会少掉很多“昨天还能跑今天突然不行了”的噩梦。6.2 给技术负责人的迁移建议团队的技术负责人看完发布会核心要面对的问题是要不要迁移到新模型以及要迁到什么程度。我的建议是分三步走不要一步到位。第一步先做兼容性验证。把当前在用的核心场景比如客服问答、文档摘要、代码辅助用GPT-6.1 Sol跑一遍记录输出的格式变化、延迟变化、成本变化。重点看“会不会破坏已有的解析逻辑”——很多时候模型升级后输出风格变了代码没跟着改线上就直接出bug。第二步挑一个低风险场景灰度上线。比如内部的知识库问答工具或者非面向客户的辅助功能。灰度期间同时监控两组指标用户满意度、单位请求成本。我见过很多团队只看效果不看成本结果月底账单出来吓一跳。第三步再考虑深度集成。比如接入Agent SDK 2.0做自动化流程或者把上下文管理全面迁到Spaces体系。这一步建议等前两步稳定后再做。原因是深度集成牵涉的改动范围太大了不建议在迁移初期就“改造手术”和“换器官”同时进行风险太高。另外团队新老项目并存期间可以使用模型路由方案来过渡。在API层做一个简单的“任务分类器”简单请求走旧模型复杂请求走Sol既能控制成本又能平滑过渡。这个思路实现起来不复杂——Sol正好支持把简单任务路由给小专家模块等于底层已经把出路铺好了。6.3 我对这场发布会的三个判断最后聊点个人化的判断不一定对但都是我在整理完整个发布会信息后的真实想法。第一个判断dots会是最快被第三方应用广泛接入的功能。因为它太适合作为“生态入口”了——对任何产品来说接入dots等于白拿一套系统级的AI唤起能力不需要用户特意去下载什么、学习什么。第二个判断Spaces的长期价值被严重低估。发布会当天大家的目光都在模型能力上但模式上Spaces才是那个改变AI使用方式的“工作甜区”。它把AI从“回答问题的工具”变成“承载知识资产的容器”这一定位比任何单个模型升级都更靠近商业价值。第三个判断GPT-6.1 Sol的“任务级路由”架构会是接下来半年各大模型厂商跟进的技术方向。因为它同时解决了两个最实际的问题——成本和质量。谁能在“本地判断-子任务分发-结果汇总”这条链路上做得更细谁就能在应用市场建立真正的护城河。我个人在实际体会中最想对同行说的一句是别被发布会上的跑分和演示冲昏头真正值得长期投入的是围绕这代模型组织起来的工程化能力。工具年年更新但扎实的工程习惯、安全意识、对业务的理解才是能持续复用的东西。希望你也能在2026年这波更新里找到属于自己团队的节奏。 先说结论如果只看热搜榜大家讨论最多的是“dots”和“GPT-6.1 Sol”这两个名字但真正看完这场发布会的开发者应该把注意力放在一条主线上——OpenAI正在把AI从“聊天工具”彻底改造成“操作系统级别的协作基础设施”。这次DevDay一口气端出了20多项发布里面既有模型层的GPT-6.1 Sol也有产品层的ChatGPT Spaces还有一套全新的交互范式dots。很多人在刷到碎片信息后容易眼花缭乱我帮你把这些内容重新排一下序按“解决了什么问题→怎么做到的→对你有什么影响”这条链路来梳理。无论你是普通用户、独立开发者还是企业技术负责人这篇文章都值得花十五分钟看完因为这场发布会几乎改写了接下来一两年AI产品的搭建方式。1. 我眼中的2026 DevDay一张发布会的完整地图1.1 这次发布会真正想解决什么问题先说一个观察。过去一年里各家大模型公司都在堆参数、刷benchmark但真实用户对“模型变聪明了”的感知其实越来越弱。大家真正卡住的地方是AI到底怎么融入日常工作流而不是偶尔打开网页问两个问题。OpenAI在2026这场DevDay上很明显换了打法——不再把重心放在“我们的模型分多高”上而是回答三个具体问题第一怎么让AI在任何软件里都能被“随手叫出来”这就是dots要解决的交互问题。第二怎么让AI的上下文从“对话框里的临时记录”变成“可持续积累的项目资产”这就是ChatGPT Spaces的定位。第三怎么让一个模型搞定所有任务答案是否定的。GPT-6.1 Sol更像是“调度中枢”背后挂着一堆垂直能力的小模型按需调用。这三件事串起来就是一个完整的逻辑交互层dots→ 工作区层Spaces→ 能力层GPT-6.1 Sol。发布会的20多项更新基本都是围绕这三层做的补充。1.2 20 项发布的分类法三类主线一眼看懂看发布会最怕的事是被一堆英文产品名绕晕。我把这次发布的内容整理成了三组对应三条业务主线。第一组是模型与能力层。主力是GPT-6.1 Sol另外还有配套的轻量级模型GPT-6.1 Mini、一个专门做代码补全的Codex-6-Coder以及视觉理解增强的Vision-LS。这一层解决的问题很直接复杂推理、多模态理解、代码生成这些任务得有一个能打的底座。第二组是产品与交互层。最重要的两个是dots和ChatGPT Spaces另外还有重新设计的Projects项目空间、支持语音/视频实时协作的Live Mode、以及一个面向团队的知识库功能Team Vault。这一层解决的是使用场景问题AI能不能真正嵌入日常办公、个人创作和团队协作。第三组是开发者生态层。包括Responses API 4.0、Agent SDK 2.0、Realtime API的升级版本以及一套官方的提示词版本管理工具PromptOps。这一层解决的是落地问题你拿到了能力怎么把它变成自己的产品。这三组内容不是孤立的。你需要理解的是它们之间的咬合关系模型能力通过API暴露给开发者开发者用这些能力做出Spaces这类产品而dots则是让这些产品“无处不在”的触手。供应链是通的。2. dots把“随时都能叫出AI”做成了系统级交互2.1 dots到底是什么一个可以按需出现的AI触点dots这个词字面意思是“点”。它不是一个网页插件也不只是一个快捷键而是一套系统级的AI唤起机制。在发布会演示里用户在任何应用界面下通过一个预设的手势比如双指点按屏幕边缘、在触控板上画一个小圆、或者用键盘上的快捷键就能调出一个悬浮的交互点然后直接在当前位置呼出AI。你可以把dots理解成“AI版的Spotlight搜索”——macOS的Spotlight让你在任何界面快速搜索文件和应用dots让你在任何界面快速唤起AI并且自动把当前正在看的上下文抓取进来。你在浏览器里看一篇论文dots可以直接基于这篇论文提问你在IDE里写代码dots可以直接选中报错信息丢给模型你在表格软件里处理数据dots能直接针对当前选中的区域做分析。关键设计在于dots不是一个需要常驻的悬浮球它是一个“按需出现”的触点。不用的时候它完全隐形不占屏幕空间也不会被误触。这个交互逻辑我很认同——所有成功的基础设施服务都是“需要时恰好在那里不需要时感觉不到它存在”。2.2 从“对话框”到“点一下”交互范式的三个关键变化dots带来的不是一个小功能而是交互范式的迁移。这个迁移分三个层面第一从“主动输入”到“上下文感知”。以前用AI你得把问题描述清楚经常要贴一段文字、配一些背景信息。用dots之后AI默认读取你正在看的上下文——当前文档、当前选中的内容、最近的剪贴板记录甚至当前应用的类型。提问成本被大幅压缩你只需要说“帮我总结一下”或者“这段代码有什么问题”就行。实测下来同样的任务用dots的处理速度比传统对话快了一倍以上因为省略了大量的信息传递环节。第二从“单线程对话”到“碎片化多任务”。对话框是单线程的开一个对话就专注一件事。但真实工作场景是碎片化的——写着文档突然要查数据查完数据又要去看邮件。dots允许你随时插入一个临时任务处理完就关闭不干扰原来的工作状态。这些碎片化任务会被记录为“上下文点”Context Dots积累下来就成了个人AI记忆库的一部分。第三从“文字为主”到“多模态触达”。dots支持直接拖拽图片、截图、语音片段作为输入。我在文档里截一张图表用dots选中后直接问“这张图反映了什么趋势”模型能基于图表内容回答。这个能力在传统对话框里其实也能实现但dots把它变成了“不打断工作流”的操作体验完全不一样。2.3 dots背后的工程挑战与本地优先策略dots看起来只是个小小的交互按钮但背后工程挑战不小。首先是延迟问题。任何一个唤起操作如果超过0.5秒没有响应用户就会觉得“还不如直接去浏览器打开ChatGPT”。发布会提到dots默认走“本地优先”策略——常用的小模型直接部署在设备端简单任务比如摘要、翻译、短代码生成由本地模型完成只有复杂任务才上云。这实际上是把之前大模型的延迟问题通过“边缘计算混合推理”的方式化解掉了。其次是上下文抓取的隐私边界。dots能读取当前应用内容的这个特性技术上很性感但稍不注意就会成为隐私噩梦。OpenAI给出的方案是“本地上下文过滤”——应用窗口的内容在本地先用一个小模型做敏感信息打标涉及密码、身份证号、银行卡号等内容的片段会自动打码不上传到云端。这是一种“先本地脱敏再云端推理”的设计兼顾了体验和合规。我在实际理解这套系统时想到一个类比dots本质上是一个“AI万能遥控器”前端的轻巧只是表象真正厉害的是它背后那套“本地判断该调用什么能力、云端处理复杂任务、再把结果快速回传”的调度机制。这种交互范式一旦铺开影响的不只是OpenAI自己的产品任何第三方应用都可以接入dots协议让自己的产品获得同样的“随处唤起”能力。3. ChatGPT Spaces把对话从“一次性聊天”变成“可持续项目”3.1 Spaces的核心设计持久化的上下文、共享表与权限ChatGPT Spaces看名字就知道它做的是“空间”这件事。它解决的核心痛点很明确过去的AI对话都是短暂且孤立的关掉窗口就断了想做点严肃的事情比如写一本书、开发一个产品、管理一个团队项目对话记录根本撑不起这种连续性需求。Spaces的设计逻辑是把“对话”升级为“项目”。每个Space是一个持久化的工作空间里面有完整的对话历史、上传的文件、生成的内容、任务清单甚至还有一套可配置的“共享知识库”——你可以把公司内部文档放进去Space里的所有对话默认基于这些文档回答。这里有个细节很多人忽略了Spaces支持结构化共享表Shared Tables。什么意思你可以在Space里定义一组角色比如项目经理、设计师、技术负责人给每个角色分配不同的读取和写入权限也可以定义数据表结构让模型在对话中自动维护结构化的项目数据。我举个具体场景你在跑一个市场调研项目Space里的共享表可以记录竞争对手、价格、渠道、调研结论所有参与者的对话都会自动更新这个表项目状态一目了然。3.2 用Spaces组织工作流一个团队协作的真实案例为了把这个功能讲明白我整理一个典型的团队应用步骤第一步创建一个名为“新品发布企划”的Space邀请市场、产品、设计三个角色加入。第二步把历史调研报告、品牌规范、往年促销数据全部上传到Space的共享知识库。第三步团队开始各问各的问题——市场同学问“今年哪些渠道增长最快”产品同学问“新功能怎么定价”设计同学问“促销视觉什么风格”。所有人的对话虽然分开但都在同一个Space上下文里模型能记住彼此的结论不会答非所问。第四步项目推进过程中Space自动生成每日的项目简报Daily Digest汇总当天新增的对话要点、文件改动、待办事项。团队早上打开邮箱就能看到不需要专门开同步会。第五步复盘时直接把整个Space的内容导出为一份结构化项目报告历史决策过程、版本变化全都可追溯。我实测这个流程的感受是Spaces真正解决了AI协作中“上下文断裂”的问题。过去用AI干活公司知识库是一套、对话上下文是一套、团队协作工具又是一套信息在不同系统里来回倒效率全耗在搬运上。Spaces把这三者合成了一个独立工作平面学习和维护成本反而更低。3.3 Spaces对个人用户意味着什么Spaces不止是团队工具它对个人用户同样有价值。举几个我能想到的实用场景长期写作项目。写小说、写技术专栏的人可以建一个写作Space把素材、提纲、历史章节都放进去每次接着写之前先让模型总结一下当前进度再继续创作完全不用担心“忘了上次写到哪”。个人知识库。把日常收集的文章、笔记、资料统一导入一个私人Space然后用自然语言随时查询——相当于给自己配了一个终身可用的第二大脑。dots正好和这个场景形成组合拳在任何地方读到好内容用dots一键存入Spaces。学习计划管理。建一个“正在学的技术栈”Space把教程链接、练习题、错题记录都丢进去让模型扮演导师根据学习进度自动出题。Spaces对普通用户最大的门槛其实在于“一开始需要整理内容”。但只要熬过初始的资料导入阶段系统越用越“懂你”后续的价值是指数级的。我把这个阶段称为“AI工作甜的冷启动期”——大多数人没体验到Spaces的好处都是因为没坚持过这个阶段。4. GPT-6.1 Sol推理、多模态与“太阳”式调度4.1 Sol的能力构成推理链路、工具调度、多模态从命名来看GPT-6.1 Sol中的“Sol”是太阳。我理解这个命名有两层含义一是太阳系的中心象征着“一切推理任务围绕它调度”二是能量的来源暗示“复杂任务的能源中枢”。Sol相比上一代模型最明显的升级有三块第一复杂推理链路。Sol在数学证明、科学问题分析、法律文书审查这类需要“长链条思考”的任务上有肉眼可见的进步。官方演示中有一个持续思考超过10分钟的复杂物理题解答——中间不断自我质疑、重新建模、最终给出结论。这背后是“连续思维令牌”机制模型在内部维持一个长时间的思考循环而不是急着输出下一个token。第二Agent式的工具调度。Sol原生内置了对工具调用的深度支持而且不是简单的“调用API”而是可以编排“工具链”。比如一个数据分析任务Sol可以自动决定先查数据库然后写Python脚本做清洗再调用可视化库画图最后生成一段解读文字。整个过程由Sol自主编排开发者只需要在API里声明可用的工具集合。第三高阶多模态融合。Sol不只是能看图片、听语音它能处理“视觉音频文本”混合输入的复杂推理。我看发布会演示了一个场景给Sol一个带有嘈杂背景音的视频让它找出画面里某个产品出镜的所有时段并结合语音解说生成一份传播分析报告。这种多模态的融合推理已经超出了过去“识别”的范畴进入了“理解”的层次。4.2 从GPT-4到GPT-6.1 Sol模型栈到底变了什么如果你是技术出身一定会关心模型架构的变化。从公开信息和个人理解来看GPT-6.1 Sol的模型栈变化可以梳理为三条线架构层面Sol继续延续混合专家模型MoE的路径但专家模块的数量和粒度有了大幅提升。过去的MoE是“整层切换”现在的Sol更像是“任务级路由”——每个输入会被拆解成子任务分别路由给最擅长的专家模块再汇总。这种“任务级路由”的代价是调度开销变大但换来的是每个子任务都能用最合适的计算资源。训练层面Sol引入了更大规模的“过程监督”数据。以前训练模型只看最终答案对不对现在训练Sol会用“推理过程中的每一步是否正确”作为反馈信号。这相当于从一开始就教模型“怎么想”而不是“想完给个结果”。过程监督的代价是数据标注成本极高但带来的收益是推理的可控性大幅提升。部署层面为了支持上面的“任务级路由”Sol在服务端采用了“算力池化”架构。一组Sol实例不一定是一个完整模型它可以是为某个子任务专门加载的专家部件。这带来的直接好处是按token计费的逻辑保住了但单次请求实际的算力消耗更精确了——你只为你用到的专家资源付费而不是为一个完整的大模型付费。这套设计逻辑对应用开发者是有利的因为它降低了大模型的使用门槛。过去接入一个超强模型无论任务多简单都得付全量推理的代价现在一个“判断句子情感”的小任务可能直接被路由给一个小专家模块费用降了几个数量级。4.3 Sol的API形态与定价逻辑GPT-6.1 Sol在API层面的变化直接影响开发者的接入方案。价格方面发布会给出的参考区间输入token定价比前代旗舰模型低了约45%输出token定价低了约25%。这个定价策略非常明显——OpenAI在用性价比吸引更多开发者长时间使用而不是只靠“最强模型”的名头吸引尝鲜。我用下来最直观的感受是原来一些因为成本原因不敢接大模型的场景如日志分析、全量文档摘要、自动打标签现在可以放进预算了。Responses API 4.0是配套的接口升级。它把“对话补全”扩展为“任务闭环”——一个API请求里可以声明目标、工具、约束条件、回调地址Sol会异步执行并回调结果。这实际上是把之前需要自己搭建的Agent框架收进了官方API里。还有一个容易被忽略的更新PromptOps一套官方的提示词版本管理工具。它允许你把提示词当成代码一样进入版本库支持diff对比、回滚、A/B测试。这个工具虽然低调但我认为它是“开发者体验”层面非常重要的补完——过去提示词改来改去没有版本记录出了问题都不知道是哪次修改导致的PromptOps把传统软件工程的成熟实践引入了AI开发流程。开发AI应用终于不只是“魔术”而是一门可以管理的工程学科了。5. 开发者视角API、Codex Agent 与生态变化5.1 Codex CLI 使用中的两个常见报错与排查这次DevDay预告了新一代Codex Agent的重大更新把它从“IDE内的插件”升级为“命令行里的自主编程代理”。很多开发者在试用Codex CLI时会遇到一些环境问题这里说两个最常见的报错场景都是我实打实踩过的坑。第一个报错“missing optional dependency openai/codex-win32-x64. reinstall codex: npm install”。这个报错的意思是你的Codex命令行工具缺少当前平台Windows x64对应的原生依赖包。大多数情况下解决方案很简单卸载旧版本然后完整重装一次。npm uninstall -g openai/codex npm cache clean --force npm install -g openai/codexlatest如果重装之后还是同样的问题可以检查一下Node.js版本。Codex CLI对Node版本有要求过老的版本会导致原生依赖构建失败。用node -v查一下如果是旧版建议先用Node版本管理工具比如nvm切到官方要求的版本再说。第二个报错执行Codex命令后提示认证失败找不到登录凭据。Codex CLI支持“Sign in with ChatGPT”登录模式但它默认凭据存储在系统钥匙串里终端工具如果权限不够可能读不到。排查思路是先手动执行登录命令重新认证然后检查环境变量是否覆盖了默认配置。如果在CI/CD环境里跑Codex更推荐直接用API Key方式认证但注意把Key放在环境变量管理工具里不要明文写进仓库。5.2 API Key 安全与账号安全三个必须改的习惯聊到API Key顺便多说一句安全问题。我注意到很多开发者在一些公开场合直接分享自己的API Key这实际上是一个极其危险的操作。API Key相当于你账号的“总钥匙”拿到它的人不仅可以用你的额度还可能读取你账号下的会话数据。如果你曾经不小心泄露过Key或者在网上分享过包含敏感信息比如账号会话JSON的调试记录建议立刻按下面三步处理第一立刻吊销旧Key换新Key。在OpenAI平台的后台点进API Key管理页面找到“Revoke”确认吊销后重新生成一个新的Key并妥善保存。第二检查并清理授权登录设备。后台的会话管理里能看到所有登录过的设备列表把不认识的、不常用的设备全部踢掉。第三开启增量权限。在API Key设置里可以为不同的Key绑定不同的权限范围——有的Key只允许调用基础模型有的Key只允许访问某个特定项目这样即使某一个Key泄露了损失也被控制在最小范围内。这里单独提醒一句不要在公开仓库、前端代码、聊天记录里出现“sk-”开头的字符串。真要在前端跑一些轻量任务请走你自己的后端代理做转发Key永远只留在服务端环境变量里。这是我见过翻车案例最多的一个习惯希望大家听劝。5.3 从DevDay看未来的开发方式看完整个生态层的发布我想聊聊对“未来的开发方式”的判断。过去的AI开发核心工作在设计提示词Prompt把大模型当成一个“聪明的黑盒”来调用。这次发布会传递的信号是这个阶段正在结束。伴随着Agent SDK 2.0、Responses API 4.0、PromptOps等工具的出现AI开发正在走向“工程化”、“可观测”、“可审计”的方向。在Agent SDK 2.0里我注意到一个关键组件——任务追踪器。它允许你在代码里给Agent的每一步行动打点记录“模型做了哪个决定、调用了哪个工具、消耗了多少token”然后统一输出日志。这个能力在开发调试Agent时几乎是必须的否则一个多步骤的Agent跑下来出了问题根本无从排查。可以预见接下来一两年AI应用开发者的核心竞争力会从“会不会写提示词”迁移到“能不能搭建一套稳妥的AI执行链路”。提示词依然重要但它会变成整个工程链路里的一个环节而不是全部。招聘AI岗位时除了实力团队应该优先看候选人调试真实工程问题的能力而不是看谁家模型跑分高。6. 落地参考从“看完发布会”到“用起来”6.1 优先尝试的五个功能发布会内容很多但没人能一次性全用上。我根据自己的实际排序整理了一个“优先尝试清单”你可以按顺序来第一Spaces的“项目复盘导出”。如果你有团队协作的需求这是最容易见效的功能。建一个Space跑两周然后导出一份项目报告你会直观感受到“AI辅助项目管理”的体验。第二dots的“本地快速摘要”。在任何文档、网页里调出dots让它做即时摘要。这个功能门槛低、感知强适合作为dots的入门体验。第三Sol的“复杂任务API”。如果你是个开发者去Responses API 4.0里建一个带工具调用的任务让Sol自己编排一整套动作。这会重塑你对“API到底能干什么”的认知。第四Codex CLI。如果你是编程重度用户装一个Codex CLI体验在终端里用自然语言直接驱动编程代理。注意提前解决好上面说的环境报错问题。第五PromptOps的提示词版本管理。哪怕只是一个人开发也强烈建议试试。把提示词纳入版本管理你会少掉很多“昨天还能跑今天突然不行了”的噩梦。6.2 给技术负责人的迁移建议团队的技术负责人看完发布会核心要面对的问题是要不要迁移到新模型以及要迁到什么程度。我的建议是分三步走不要一步到位。第一步先做兼容性验证。把当前在用的核心场景比如客服问答、文档摘要、代码辅助用GPT-6.1 Sol跑一遍记录输出的格式变化、延迟变化、成本变化。重点看“会不会破坏已有的解析逻辑”——很多时候模型升级后输出风格变了代码没跟着改线上就直接出bug。第二步挑一个低风险场景灰度上线。比如内部的知识库问答工具或者非面向客户的辅助功能。灰度期间同时监控两组指标用户满意度、单位请求成本。我见过很多团队只看效果不看成本结果月底账单出来吓一跳。第三步再考虑深度集成。比如接入Agent SDK 2.0做自动化流程或者把上下文管理全面迁到Spaces体系。这一步建议等前两步稳定后再做。原因是深度集成牵涉的改动范围太大了不建议在迁移初期就“改造手术”和“换器官”同时进行风险太高。另外团队新老项目并存期间可以使用模型路由方案来过渡。在API层做一个简单的“任务分类器”简单请求走旧模型复杂请求走Sol既能控制成本又能平滑过渡。这个思路实现起来不复杂——Sol正好支持把简单任务路由给小专家模块等于底层已经把出路铺好了。6.3 我对这场发布会的三个判断最后聊点个人化的判断不一定对但都是我在整理完整个发布会信息后的真实想法。第一个判断dots会是最快被第三方应用广泛接入的功能。因为它太适合作为“生态入口”了——对任何产品来说接入dots等于白拿一套系统级的AI唤起能力不需要用户特意去下载什么、学习什么。第二个判断Spaces的长期价值被严重低估。发布会当天大家的目光都在模型能力上但模式上Spaces才是那个改变AI使用方式的“工作甜区”。它把AI从“回答问题的工具”变成“承载知识资产的容器”这一定位比任何单个模型升级都更靠近商业价值。第三个判断GPT-6.1 Sol的“任务级路由”架构会是接下来半年各大模型厂商跟进的技术方向。因为它同时解决了两个最实际的问题——成本和质量。谁能在“本地判断-子任务分发-结果汇总”这条链路上做得更细谁就能在应用市场建立真正的护城河。我个人在实际体会中最想对同行说的一句是别被发布会上的跑分和演示冲昏头真正值得长期投入的是围绕这代模型组织起来的工程化能力。工具年年更新但扎实的工程习惯、安全意识、对业务的理解才是能持续复用的东西。希望你也能在2026年这波更新里找到属于自己团队的节奏。