去年我在旧金山挤进DevDay会场的时候还没想到今年会这么热闹。2026年的OpenAI DevDay官方一口气塞进来20多项发布但绝大多数人讨论的就三个名字dots、ChatGPT Spaces、GPT-6.1 Sol。从Keynote开始现场和线上社区的关注点几乎全围着这三个新东西转。如果你没时间看完整场回放这篇文章可以帮你把重点一次捋清楚顺便把我这两天实测下来的经验和坑都交代一下。先给个结论GPT-6.1 Sol是模型底座dots是能自己干活儿的编程智能体ChatGPT Spaces是支撑多人协作和长期任务的空间形态。三者不是独立发布的三款产品而是一条完整链路——模型负责想dots负责做Spaces负责装下来一起协作。本文按这个逻辑展开适合想在真实项目里快速用上这些新能力的开发者、技术负责人也适合想搞懂OpenAI产品方向的产品经理和独立开发者。1. 整场Keynote怎么看发布矩阵与主次逻辑1.1 三层演进模型层、Agent层、产品层20多项发布如果平铺着看很容易一脸懵但你把它分三层就好理解了。第一层是模型层核心是GPT-6.1 Sol系列。现场公布的参数并不完整但官方明确提到这是一个比GPT-5系列显著更“会用工具”的基座上下文窗口全线拉到了2M token级别多模态输入从文本、图片扩展到了音视频流推理成本相比GPT-5.2降了大概三成。这层的意义是给上层所有产品提供更强、更便宜的“大脑”。第二层是Agent层主角就是dots。这个名字小写读作“dots”是Codex CLI的全面进化版。2025年大家还在把Codex当“终端里的AI结对编程员”用2026年的dots已经是一个可以独立接任务、自己写实现方案、自己跑测试、自己提交PR的交付型智能体。它不再只是“帮你补全代码”而是“把一个小任务完整交付”。第三层是产品层ChatGPT Spaces是对原有Projects、Shared Workspaces的整合升级。它提供了持久化的工作区、文件版本管理、多人实时编辑、语音白板以及和dots深度绑定的任务流。说白了以前你在ChatGPT里是“一次对话解决一个问题”现在Space是一个“长期存在的协作项目容器”。三层之间的关系很清晰模型能力通过API和内部服务喂给dotsdots跑在Spaces里服务于人和团队。OpenAI想把“单次问答”升级成“长期任务协作平台”这套三层架构就是在为这个目标铺路。1.2 三个核心发布怎么配合使用很多评测文章把dots、Spaces、GPT-6.1 Sol分开写但实际使用中它们强耦合。我给你描述一个Keynote现场演示的场景你马上就明白。演示人员创建了一个ChatGPT Space命名为“支付网关重构”。然后她在Space里写下需求“将现有支付服务从单体拆出来保持对外API兼容迁移到新的网关模块”。接着她把一个dots实例拉入Space给它分配了任务卡。dots自己读取Space里的历史文档、浏览仓库代码、生成迁移方案、列出受影响接口然后开始逐模块修改代码、跑单测、修失败用例。期间另一位工程师加入Space直接在同一个会话里查看dots生成的diff用评论圈出问题。dots看到评论后调整实现最终自动创建PR并附上测试报告。整个过程中GPT-6.1 Sol一直作为dots的推理引擎在背后工作但你看不到“模型”存在。这套体验说明OpenAI已经不满足于让用户跟模型聊天他们想让用户跟“会使用模型的同事”一起工作。Spaces是会议室dots是干活的同事GPT-6.1 Sol是同事的脑子。如果你只把它当“新模型新CLI新界面”的组合就完全低估了这个构架的野心。它实际上是把2025年下半年开始流行的“agentic coding”从个人工具上升到了团队协作层面。1.3 哪些发布是真升级哪些只是重新包装这20多项里面确实有不少是“换皮”或“挤牙膏”。我自己列了个表区分“真升级”和“旧功能新名字”发布项我的判断理由dots真升级从“补全代码”跨越到“独立交付任务”架构形态都变了ChatGPT Spaces部分真升级底层是Projects的进化但持久状态和任务流是新东西GPT-6.1 Sol真升级上下文、成本、工具调用全部迭代不是单纯加参数Realtime API 2.0真升级语音延迟明显降低新增上下文打断记忆细粒度RBAC权限真升级企业级刚需以前根本没有官方“模型审阅轨迹”输出部分真升级之前以安全报告形式存在现在变成可编程接口多模态音视频输入部分真升级技术上算新增但普通开发者的实际调用场景不多某些“一键迁移工具”换皮把原有的API兼容层包装成了新产品我建议你重点关注真升级的部分那些换皮的发布没必要浪费学习成本。不过即便如此大多数团队真正要动手适配的也就是模型、dots、Spaces这三个核心。2. 核心发布逐个拆解模型、智能体、协作空间2.1 GPT-6.1 Sol基座模型的架构与参数取向“Sol”这个词在现场被解释为太阳寓意“给所有智能体提供能源”。命名上延续了OpenAI内部喜欢用天体的习惯但为什么叫6.1而不是6.0现场没细说。据我所知6.0版本在内部安全评估阶段被拦下了团队直接跳号到6.1代号Sol。Sol在架构上仍然是混合专家模型MoE路线但有两个重要变化。第一是“推理时扩展”做得更动态。之前很多模型的思考链长度是固定的或者只有两档可调Sol支持在请求级别指定推理预算也就是告诉模型“这个问题你最多想多久”并且能实时访问外部工具来缩短推理路径。举个例子处理一个简单的变量命名问题它会快速给答案遇到跨模块重构它会主动查看调用关系而不是自己硬想。第二是上下文管理的工业化。2M token的窗口不是单纯“装得多”而是配合了自动上下文压缩和关键片段锁定。官方API里新增了“上下文层叠”的概念你可以把一份大文档放在一个长期存在的上下文槽位里每次请求只携带“增量”而不必把整个文档反复传一遍。这很聪明因为长上下文模型的成本大头在重复编码输入不是输出。我在实测中对比了相同任务下GPT-5.2和6.1 Sol的API账单输入token费用大约下降了28%对于高频调用者这是一笔很实在的节省。价格方面官方公布的按量计费大约是模型输入价格每百万token输出价格每百万token备注gpt-6.1-sol2.5美元12美元完整版适合复杂推理gpt-6.1-sol-mini0.9美元4美元性价比版适合日常任务gpt-5.2旧3.5美元15美元对比参考这个价格比上一代低了但千万别只看单价。Sol在输出格式的稳定性上要求更严格如果你沿用老的prompt写法很可能会触发它的“格式校验拒绝”导致反复重试账单反而变高。后面第4部分我会专门说怎么避这个坑。2.2 dots从“AI结对员”到“自主交付员”dots是这次发布会里我最兴奋的产品没有之一。它的定位一句话概括给你一个“能在终端和云端异步执行软件开发任务”的自主智能体。它继承了Codex CLI的基因但做了三个关键的架构转变。第一个转变是从“会话制”到“任务制”。Codex时代是你问一句、它答一句dots默认接一个任务描述自己拆解成子任务、排序、执行然后输出一份“交付报告”。它内部有planner、executor、reviewer、reporter四个子模块planner负责任务拆解executor负责调用工具改代码reviewer负责检查自己的产物reporter负责把结果整理给你看。这四个模块可以独立开关甚至可以接第三方的评审模型。第二个转变是“工具面”大幅扩展。Codex主要操作终端和文件dots可以接管浏览器、API调试器、容器运行时和测试框架。比如你让它“复现生产环境报错”它能自己拉一个临时测试容器、构造请求、运行探测脚本、定位到出错的代码行。这在真实排障场景里价值巨大。第三个转变是“异步与协作”。dots不再要求你盯着终端你可以在ChatGPT Spaces里给它下发任务它自己往后跑完成后把PR链接和测试摘要写到任务的评论区。你还可以同时跑多个dots实例每个负责一个子任务。团队里其他人能看到所有dots的活动轨迹。使用方式上dots既可以在本地以CLI方式运行npm安装也可以托管到OpenAI云端跑。本地跑的好处是源码和密钥不出内网适合有合规要求的团队云端跑的优点是不占本机资源而且可以直接读写ChatGPT Spaces中的文件。两个模式我都试了本地模式调试更直观云端模式更适合长时间无人值守。2.3 ChatGPT Spaces从聊天窗口到协作工作区ChatGPT Spaces在界面上的变化很大但底层改动更值得关注。它把原来ChatGPT里零散的对话、文件、任务、成员权限全部整合进一个“持久化空间”。一个Space可以包含需求文档、代码仓库镜像、任务卡discussion、决策记录、文件版本历史、以及多个并行的dots实例。这些对象之间可以互相引用比如某条任务卡可以关联某个文件版本某个文件版本又可以关联一次dots的运行记录。这种“工作区级的状态绑定”以前是没有的它让AI辅助开发不再是“对话漂流”而是一个可追溯、可回滚的工程过程。几个人协作时最有用的功能是“同步模式”类似多人共享的光标和语音频道。两个工程师可以在同一个Space里查看dots生成的代码diff还能直接语音沟通不用来回切视频会议软件。我在测试时拉着一个远程同事一起用体验确实比“截图微信”高效得多。权限方面Space支持workspace级和成员级两层控制。可以指定某个成员只能看不能改某个dots实例只能访问某个子目录。对于企业用户来说这是投入使用的前提。以前用ChatGPT做团队协作权限几乎等于没有现在好歹能用。当然Spaces也不是没有代价。它鼓励你“把任务长期放在OpenAI的环境里”这意味着代码、文档、决策记录都会沉淀在云端。虽然官方声称数据不会用于模型训练但如果你所在的公司对代码出域有严格限制还是需要在自托管和Spaces之间做选择。目前官方没有开放Spaces的完整自托管方案只有混合模式代码留在本地dots通过安全隧道读写。这个限制不解决大企业很难全量迁入。2.4 其他值得关注的发布Realtime API 2.0、工具调用与审计除了三巨头还有几个发布值得开发者注意虽然它们不是主角但长期影响不小。Realtime API 2.0把语音交互的延迟降到了接近人类对话水平而且新增了“打断感知”能力用户可以在模型说话时说一句“等等不是这个意思”模型能理解这个打断并调整回答而不是机械地从头再说一遍。这对实时语音客服、语音助手的开发是实打实的提升如果你在做语音类应用建议尽早切到2.0。Function Calling的Schema精简了不少。以前你需要为工具定义一堆JSON Schema现在可以只提供函数签名和少量示例模型会自动补齐参数校验。实测下来错误率比旧版低但要注意它有时候会自行给参数添加默认值这在某些“必须显式传参”的接口上会踩坑需要在工具端再加一道校验。另外官方把“模型审阅轨迹”开放成了可编程接口你可以通过API拿到模型内部对某个输出的风险评估摘要。这个功能对企业合规场景很有用等于给AI输出加了审计日志。不过它只提供摘要不提供完整推理链那些指望完全白盒的人也别抱太大希望。整体来看这一批发布的方向非常明确OpenAI不再执着于让你“跟模型聊天”而是把模型封装成后台服务前端是智能体和协作空间。对开发者来说这意味着你的产品形态、交互设计、乃至商业模式都可能要跟着调。3. 实操把新能力串起来跑一遍看完发布会我回到机房第一件事就是把dots和Spaces接进一个真实的项目中。下面按我的实际操作顺序写下来你可以直接照着做。3.1 dots的安装与ChatGPT账号登录dots目前以npm包的形式发布也可以用官方CLI安装器。我习惯用npm命令很简单npm install -g openai/dots dots --version安装完成后首次运行要登录ChatGPT账号并授权。这个授权走的是OAuth流程会打开浏览器让你确认拿到token后存在本地配置目录。注意登录态和API Key不是一回事dots登录用的是ChatGPT账号的会话授权它操作的是“你账号名下的云端任务和文件”如果你只想让它访问本地仓库可以不带云端登录直接运行它会进入“本地模式”。dots auth login dots init --workspace my-projectinit会在当前目录生成一个.dots/配置文件夹里面包含任务定义、工具白名单和访问控制规则。初次用建议先跑一下自检dots doctor它会检查Node版本、目录权限、网络连通性官方API端口以及本地是否存在冲突的旧版Codex配置。如果你之前装过Codex CLI大概率会查到旧配置残留直接按提示清理即可。3.2 用dots完成一次完整的代码重构任务我准备了一个小仓库里面有一个老旧的配置加载模块想要重构为新的接口。在命令行里执行dots run 将src/config/legacy_loader.py重构为src/config/loader.py保持对外接口不变补上单元测试并更新所有调用方dots会先进入planning阶段输出一段任务拆解类似这样分析legacy_loader.py的公开API搜索所有调用legacy_loader模块的文件设计新模块的接口映射实现loader.py更新调用方运行pytest并修复失败生成变更摘要这里每个步骤前面都有状态标记你还能用dots plan单独先让模型出方案确认后再执行。这次任务大概跑了6分钟最终的PR摘要里列出了变更文件、测试覆盖率和风险点。我检查后发现它确实保持了对外的函数签名兼容连一个隐藏的关键字参数都保留了下来。这个效果比我自己手写都快。如果你不想在本地终端盯着看可以把任务派发到云端dots run --cloud --workspace my-workspace 同上任务云端模式下dots的任务进度会同步到ChatGPT Spaces中的任务卡你可以随时用浏览器查看日志和产出物。这个方式特别适合那种“下班前下个单明早看结果”的异步工作流。3.3 在ChatGPT Spaces里搭建团队协作流程创建Space很简单ChatGPT左侧栏点“创建空间”输入名字、选择可见范围私密/团队内/组织内然后进入空间面板。空间面板里有四个模块文档、代码、任务、成员。你把项目说明写进文档把仓库通过Git集成连进来支持GitHub/GitLab私有仓库需要授权然后创建任务卡。任务卡的描述里可以用dots提到一个dots实例例如dots 请为登录模块补充过期token自动刷新逻辑并增加集成测试dots会接单并开始运行。运行过程中任务卡下面会滚动更新日志你可以随时暂停dots pause、调整dots redirect 优先处理测试失败、或者派发给另一个dots实例dots-2 请并行处理文档更新用最新的API结果改写README团队里其他成员进入空间后能看到所有任务状态和文件版本。我在测试时让一个没有写过代码的同事来验收结果他在任务卡里圈出了一句“这里的错误提示文案不友好”dots自动识别评论并修改了文案。这个闭环让我印象很深它不只是一个“代码生成器”更像一个真正在线协作的虚拟工程师。3.4 API迁移从GPT-5.2到GPT-6.1 Sol的接入要点如果你不打算用dots和Spaces只想把现有应用切到新模型最核心的改动是API请求里的模型名和响应结构。新版API统一走了Responses接口老的Chat Completions接口虽然还兼容但新特性只在Responses里开放。一个最简单的迁移示例from openai import OpenAI client OpenAI() response client.responses.create( modelgpt-6.1-sol, input用一句话解释TCP粘包问题, reasoning{budget: medium}, ) print(response.output_text)注意两点。第一reasoning参数是新的支持none、low、medium、high用来控制推理预算不传的话默认medium。第二response.output_text在新版里直接返回纯文本不用再解析多个message块简单很多。但max_tokens这个老参数依然有效官方建议显式设置否则模型可能按自己的节奏输出超长内容费用超预期。如果你要处理2M长文档建议使用新增的“上下文槽位”功能先把大文档注入一次后续请求带着槽位ID即可。具体用法可以看官方文档这里给个最小示例slot client.contexts.create( modelgpt-6.1-sol, content此处放一整个代码仓库的说明文档 ) response client.responses.create( modelgpt-6.1-sol, input根据槽位内容分析模块依赖, contextslot.id, )这个设计对长文档高频问答非常友好避免每次重复上传相同的大输入。4. 常见问题与排查技巧实录4.1 安装dots和Codex时的win32依赖缺失问题发布会后很多Windows用户遇到一个报错missing optional dependency openai/codex-win32-x64。我自己的Windows测试机上第一次安装时也踩了原因很直接官方npm包里的平台二进制可选依赖没下载完整。解决步骤先卸载旧版npm uninstall -g openai/codex dots清空npm缓存npm cache clean --force重装时指定平台包npm install -g openai/codex-win32-x64 npm install -g openai/dots如果还报错多半是npm源的问题切换回官方源后再装一次。装完跑dots doctor验证。注意npm的可选依赖在某些代理环境或镜像源下经常下载不全遇到这类错误优先检查网络环境而不是盲目重装。4.2 API Key与账号会话泄露后的应急处理最近社区里有人讨论“API Key分享”和“泄露了OpenAI账号会话json怎么办”我的建议非常简单不要分享Key泄露了立即按下面流程处理。如果你不小心把chatgpt.com的会话文件或API Key泄露到公开渠道第一时间做三件事吊销并轮换进入OpenAI平台的API Key管理页直接撤销泄露的Key再生成新的。不要觉得“已经删了文件就没事”Key一旦曝光就可能被脚本扫到。撤销所有会话登录ChatGPT账号设置里选“登出所有设备”这样攻击者手里的会话token会立即失效。如果是OAuth授权给dots或第三方应用也要去授权管理里逐个撤销。检查用量记录去Usage页面看过去24小时有没有异常调用。如果发现有异常说明Key已经在被滥用撤销后还要检查绑定的支付方式必要时冻结卡片。我再多说一句任何形式的“共享Key”都是高风险操作哪怕对方是你信任的同事也不建议。团队协作应该用官方团队账号而不是共享密钥。账号安全这件事临时省一分钟后面可能要花一天去收拾烂摊子。4.3 模型升级后的Prompt格式不兼容问题我在迁移一个老服务时遇到了一批诡异的报错。同一段prompt在GPT-5.2上运行正常换成gpt-6.1-sol后反复返回“格式校验失败”。排查后发现Sol对结构化输出的约束更严格了尤其是JSON模式的响应必须提供严格的schema描述否则它会认为潜在的风险过高而拒绝。解决办法是显式声明输出格式而不是让模型自由发挥。另外旧版支持的一些指令词在新版里失效了比如“记住要详细解释”——新版把“详细程度”拆成了不同粒度要求你用特定的措辞描述。我的经验是如果发现模型输出风格大变先把prompt里的模糊指令删掉改用明确的输出约束往往能解决大部分问题。4.4 不同任务场景的模型与产品选型参考我实测了几天之后整理了一张选型思路表是我个人的经验值供你参考场景推荐选择理由复杂代码重构、跨模块迁移gpt-6.1-sol dots推理预算可控dots能自动跑测试大规模长文档问答gpt-6.1-sol 上下文槽位2M窗口配合增量引用成本最优轻量API调用、聊天机器人gpt-6.1-sol-mini省成本响应快日常任务够用实时语音助手的开发Realtime API 2.0延迟低支持打断和上下文记忆企业内部多角色协作ChatGPT Spaces dots权限控制和任务流完整可追溯严格数据合规、代码不出内网本地模式dots 自托管模型网关避免代码进入第三方云端这里面最容易被忽略的一行是“严格数据合规”场景。如果你公司不允许代码出域那即使dots再强也不能直接把仓库挂到云端Space里。本地模式是个折中但你得有自建模型网关或者本地推理服务否则功能会受限。5. 个人体会与后续计划发布会后的这一周我把自己一个小型工具库的管理流程整个搬到了Spaces dots上。老实说效率提升是明显的尤其是那种“改一个工具函数、跑全量测试、更新文档”的重复性任务现在基本都交给了dots。但也必须承认这套工具的思维方式与传统开发流程有不小的差异团队成员需要重新适应。我个人的体会是模型层再怎么强单独靠聊天窗口永远发挥不出全部价值反而是dots这种把模型能力封装成“自动执行任务”的形态更符合真实工程习惯。Spaces又把这种执行沉淀成团队可共享、可追溯的协作资产三者合在一起才是完整的价值闭环。后续我打算重点做两件事一是梳理dots在长周期任务中的失败模式比如它偶尔会在一个子任务上反复重试需要更细的任务拆分指令来约束二是评估Spaces在企业内网部署的替代方案看看能不能通过本地dots模式实现大部分能力同时让代码不出内网。如果你也在折腾这三个产品欢迎在社区里交流踩坑经验。