1. 这次DevDay说了啥先给没蹲直播的人划个重点1.1 发布主线从单点工具到协作平台早上五点半爬起来蹲直播屏幕上20多张slide一张接一张弹出来的时候我承认自己有点看麻了。这次OpenAI DevDay 2026的发布密度比前两年都高不光是GPT-6.1 Sol这个当家模型还有dots、ChatGPT Spaces这种直接改变开发协作方式的底层工具。如果只让我用一句话总结那就是OpenAI终于开始认真解决一个人用AI写代码很好用但一群人用AI协作却很乱这个问题。dots负责把任务拆开并行执行ChatGPT Spaces负责把对话沉淀成团队资产GPT-6.1 Sol则在底层把这两件事的体验都拉高了一档三件事其实是互相咬合的整体。整个Keynote的节奏也比以前紧凑开场大概只用了十分钟回顾数字后面全是产品功能演示。比较意外的是这次没有花太多篇幅去强调跑分超过谁而是把重点放在真实开发工作流里怎么用。现场demo大部分都是拿真实仓库操作包括一次用dots重构开源项目的完整录屏这个路子我是认可的——毕竟刷榜数据看多了还是落地的活儿更实在。1.2 这篇回顾适合谁看这篇回顾写给两类人。第一类是想快速知道这20多项发布里到底哪些值得跟进的前排围观群众我可以直接告诉你重点盯哪几个哪些属于看看就行。第二类是打算下周一就在团队里把dots和ChatGPT Spaces用起来的开发者我会把文档里没写清楚、实际使用才会撞上的细节都摊开讲。我在会后大概花了一个多月时间把主要的新东西都实际跑了一遍包括拿真实的中型项目做重构实验、给团队搭Spaces的权限结构、把GPT-6.1 Sol接入现有API服务并做了对比测试。下面所有内容都是我真实操作之后的记录不是发布会的ppt复读能帮你少走不少弯路。2. dots上手实测把单线程Codex变成并行流水线2.1 dots到底解决了什么问题用过Codex CLI的人应该都有体会单条任务交给它写个函数、改个bug、补个单元测试都很顺手。但一旦遇到把一个老模块拆成三个新模块还要同步重构调用方和迁移存量测试这种跨文件的活儿单线程的agent经常干到一半就开始迷失方向你反复喂上下文它在同一个文件里反复打转最后产出的代码还要你大改一遍。dots的思路是把这个过程工业化。它不直接替代Codex而是做在Codex之上的一个编排层。你用一小段DSL描述目标dots自动把目标拆成若干个子任务分析它们之间的依赖关系再把不同子任务分给多个并行运行的Codex代理去执行。官方给的名字含义是把点连成线——每个子任务是一个点依赖关系是一条线跑完之后所有点连成完整的交付。我在现场看demo时没太当回事觉得这不就是个任务队列加个调度器嘛。结果会后真拿实际项目试了一回发现事情没那么简单。它真正难的地方不在并发而在怎么拆拆的方式决定了多个代理之间会不会改到同一个文件决定了共享的代码库上下文能不能保持一致。dots在这方面做得比我预期好但也不是完全没有冲突问题后面细说。2.2 实操拆任务、起代理、收结果我实际跑的例子是一个Express老后端大约40个路由文件、20个模型文件、300多个测试代码堆在一起模块边界模糊属于典型的历史包袱项目。我的目标是把用户模块和订单模块拆干净各自补上独立的数据库访问层并把存量测试迁移到新模块。操作很简单先初始化工作区然后一条命令跑起来dots init my-refactor dots run 拆分用户与订单模块新增独立数据访问层迁移存量测试 \ --agents 4 \ --model gpt-6.1-sol \ --workspace ./repo执行之后dots先自动做了依赖分析生成了一个任务依赖图然后启动4个代理。其中两个负责拆模块一个负责补数据访问层一个负责迁移测试。调度逻辑确实是有的负责数据访问层的代理会等模块拆分代理跑完第一阶段、产出接口定义之后才动工而测试迁移的代理几乎同时开工先处理那些不依赖新接口的部分。跑完用了大概11分钟比我自己一个agent一个agent地手动催快了很多。产出质量也尚可新模块的边界基本合理测试迁移也覆盖了大部分存量用例。但代价也有——中间有两处并发写同一个文件的冲突dots报了错并回滚了其中一个代理的改动我手动合并之后才算完。这在第6部分会展开讲怎么处理。2.3 上手第一个项目时我得出的配置建议给几个基于实测的配置建议。首先小任务别用dots直接用Codex单agent跑就行。我试过让dots处理一个给函数加注释级别的任务结果它照样起了三个代理上下文互相重复token烧得飞快产出和一个agent跑没区别纯属浪费。其次拆任务时要刻意让各子任务的文件交集尽量小。dots虽然会做依赖分析但文件级别的并发写冲突它只能事后检测回滚不能事前完全避免。你可以在任务描述里就写清楚不要改动xxx文件实测下来能明显减少冲突率。最后--agents参数不是越大越好。我试过8个代理并发跑同一个仓库冲突率直线上升而且最终的合并成本远超节省的时间。目前体感4个左右是甜点区如果你拆的任务边界特别干净再往上加到6个也问题不大。3. ChatGPT Spaces让聊天记录从用完即走变成团队资产3.1 普通会话与Space的核心差异ChatGPT Spaces本质上是一个持久的、带权限控制的、可以挂文件、挂工具、挂长期上下文的协作工作区。它和普通ChatGPT聊天最本质的区别在于普通会话是一次性的聊完就散了上下文随手丢下次开新对话又得重新喂一遍背景而Space是一个你长期维护的项目现场所有参与者共享同一个上下文池你可以随时回来接着聊机器人也记得住这个空间之前发生的所有事情。我打个比方。普通聊天像是微信里临时拉个群事情聊完群就沉底了新进来的人看不到之前的消息Spaces则像是给项目专门开了一个长期维护的wiki群所有历史决策、文件版本、工具配置都留在那里成员随时可以翻新成员进来也不会断片。这个定位其实很微妙。它不是简单地把聊天记录存档而是把上下文本身变成了一个可以被管理的对象。对于团队来说这意味着AI协作不再是个人行为而是能和项目生命周期绑定在一起的团队行为。3.2 Space里真正好用的四个功能我实际用下来觉得下面四个功能最值得关注。持久化上下文池Space内的所有对话自动共享上下文摘要新成员加入后可以直接追问我们之前讨论的限流方案结论是什么不需要从头补课。实测下来上下文摘要的压缩质量还不错大方向没跑偏。共享文件库可以把需求文档、接口文档、设计稿直接拖进SpaceAI会基于这些文件回答问题和写代码。这个功能在个人版里也有但在Space里它是多人都能用的相当于给团队一个活的、AI可读的共享知识库。外部工具接入支持挂GitHub、Notion、Slack、Jira这些常用工具。触发方式类似现有ChatGPT的Actions机制但Space的接入是实例级的可以做到这个Space只看这个仓库、只写这个看板。对话转存个人会话里聊出的有效内容可以一键转存到某个Space。这个功能极其顺手避免了我在个人聊天里已经讨论出方案了还要重新在团队空间里再讲一遍的尴尬。我特别推荐把接口评审和技术方案讨论放在Space里做。因为这种讨论时间跨度长、参与人多、决策链条长普通会话根本撑不住Space的持久上下文优势在这里体现得最明显。3.3 权限模型与配额团队落地前必须弄清的事权限模型是Space能不能在团队里落地的一个决定性因素。官方把角色分为四档Owner、Admin、Member、Viewer。Owner负责销毁空间和管理所有权Admin可以管理成员和工具接入Member可以正常对话和上传文件Viewer只能阅读不能发言。权限模型我建议用表格看更清楚能力ViewerMemberAdminOwner阅读对话是是是是发言否是是是上传/删除文件否是是是接入工具否否是是管理成员否否是是删除空间否否否是我踩过的一个坑是配额。Space的上下文池虽然持久但token占用是计入团队总配额的。我们一开始把所有历史对话都堆在一个大Space里结果很快就顶到配额上限后续新对话开始被自动压缩摘要。后来学乖了按项目阶段开新Space重要结论主动沉淀成摘要文件放进去这样既能保留上下文又不会臃肿。4. GPT-6.1 Sol模型升级不只是变聪明4.1 官方给的关键升级点GPT-6.1 Sol是这次发布会的压轴模型代号Sol是太阳的意思。从官方公布的资料看升级点集中在四个方面。推理能力多步推理的准确率明显提升官方给的数据是在数学竞赛题和复杂代码生成上有大约8到10个百分点的提升。这个幅度在这个体量的模型上不算小。上下文窗口正式支持1M token的上下文比上一代的400K又大了一圈。这个提升不是无意义的堆参数它直接对应了ChatGPT Spaces这类长期工作区的需求——长文档、多轮协作、大仓库分析都需要更大的上下文窗口来支撑。工具调用与Agent能力工具调用的准确率和稳定性都有优化尤其是在多工具串行调用、根据上一步结果动态选择下一步工具这类场景下。这个点和dots的协作逻辑是配套的。响应速度首token延迟大约降低了30%整体吐字速度也更快了。实测下来体感明显不是纸面数字。4.2 实测感受代码、推理、长上下文我自己把GPT-6.1 Sol接入了日常的几个工作流包括代码审查、重构建议、长文档总结和一个自定义的agent任务跑了大概三周说几个真实感受。代码方面最直观的提升是改代码时更少跑偏了。之前的模型在改一个函数时经常顺手把调用方也改了但改得不完整留下编译错误Sol在这类跨文件修改上收敛了很多改完的代码风格也更接近原有代码的习惯。我拿同一段老代码让它做重构Sol给出的方案明显更保守、更可落地而不是动不动就推倒重来。推理方面我拿一些逻辑链条比较长的bug场景试了试比如这个报错是由配置文件里的默认值、上游接口的返回格式、还有缓存策略三方面共同导致的请定位并给出修复方案。Sol能比较稳地沿着这个链条一步步查下去而不是跳到一个看似合理的结论就停。长上下文方面1M窗口在实际使用中确实能装下更大的仓库。我把一个中小型项目的全部核心代码加文档喂进去大约60万token它能基于完整的项目结构回答问题而不是像以前那样只能看到片段。不过提醒一句上下文越长模型越容易在细节上迷失关键信息还是要靠你自己在提问里点出来。4.3 API定价与接入建议定价方面GPT-6.1 Sol的API定价与上一代持平没有因为能力提升而涨价输入输出价格分别是每百万token 2.5美元和10美元。缓存命中的输入价格会再低一些。考虑到推理成本整体在下降这个定价算合理对生产环境替换是有吸引力的。接入建议有三点。第一不用急着把所有流量都切过去先在代码生成和复杂推理这类场景做灰度观察正确率和延迟是否符合预期再逐步加大流量。第二如果做长上下文应用务必设计好上下文裁剪策略不要把所有历史都丢进去一方面是因为1M窗口虽然大但终究有限另一方面是上下文越脏模型回答质量下降得越快。第三如果你在用dots或类似编排工具建议把默认模型直接设为gpt-6.1-sol它在多任务并行时的稳定表现值得多花这点token成本。5. 剩下20多项发布我按值不值得跟进分了个级5.1 开发者工具链Codex、CLI、调试器这次发布里开发者工具链的更新量很大主要是围绕Codex的生态扩展。Codex CLI升级到了2.0版本增加了断点恢复、会话回放和更细粒度的权限控制。断点恢复这个功能非常实用——之前长任务中途断网或者超时整个执行进度就丢了现在可以接着跑。会话回放则方便你复现agent执行过程中的关键决策。权限控制细化到是否允许修改配置文件这个级别安全感好了很多。另外官方推出了一个叫Codex Debugger的调试工具可以直观查看agent执行过程中的上下文变化和工具调用链。我在用dots跑任务遇到问题时靠这个工具定位到是哪个agent在哪个步骤产生了冲突排查效率高了很多。这个工具目前是免费开放的值得装一个。然后是Codex的插件系统。官方开放了Codex Plugin API允许你把自定义工具接入到agent的执行链路里。我们团队内部接了一个线上日志查询工具让agent在排查问题的时候可以直接查日志效果很不错。这条我觉得是值得长期跟进的本质上是把agent从能聊推向能干。5.2 API与平台能力Realtime、批量、微调API层面也有不少更新我挑几个实际的讲。Realtime API升级到了2.0语音延迟进一步降低支持了更自然的打断和更丰富的语音风格控制。如果你们在做语音类产品这次更新值得研究实测下来的语音交互流畅度已经比较接近真人对话的节奏了。批量推理引擎Batch Inference Engine是个容易被忽视但很实用的更新。它可以把异步任务排队执行价格比实时API低50%适合大量离线处理场景比如批量打标签、批量总结、数据清洗。我们有个文本分类的离线任务切到批量接口之后成本直接降了一半。微调平台也加了不少能力包括LoRA的图形化配置、微调后的自动评估还有一个跟我关系比较大的模型蒸馏工具增强版。你可以用大模型生成的高质量标注去微调小模型用蒸馏的方式把能力下沉。实测用Sol生成训练数据微调一个小模型做分类任务效果逼近大模型的90%成本只有十分之一。5.3 企业功能与多模态应用企业版层面推出了Secure Workspace主要卖点是企业级的数据隔离、审计日志和更细的合规控制。ChatGPT Spaces的企业版还有专属部署选项数据可以完全驻留在企业的合规区域内。有合规要求的团队可以直接对接这个方向。多模态方面也有一些看点视觉模型能更准确地理解图表和界面截图配合一个叫Canvas for Vision的新编辑器可以直接在截图或设计稿上让AI进行标注修改。这个对前端和设计团队比较友好不过在我这里优先级不高。我把20多项发布按值不值得跟进分了个级级别发布项说明强烈建议跟进dots、GPT-6.1 Sol、Codex CLI 2.0、模型蒸馏工具直接影响日常开发效率和成本值得了解ChatGPT Spaces、Codex Debugger、Realtime API 2.0、批量推理引擎特定场景下有明显价值看看就行部分视觉新功能、个别企业功能场景较窄或离普通开发者太远6. 开发者高频问题与排查记录6.1 Codex安装依赖报错这次发布会前后很多之前装过Codex的用户在升级时遇到了一个报错内容大致是missing optional dependency openai/codex-win32-x64然后提示reinstall codex: npm install。这个问题的本质是npm的optional dependencies在特定平台下没有正确安装常见于Windows系统或者node版本不一致的情况。我实测有效的处理方式如下# 先彻底卸载清掉缓存再重装 npm uninstall -g openai/codex npm cache clean --force npm install -g openai/codex如果重装之后问题还在直接补装缺失的平台依赖包npm install -g openai/codex-win32-x64最后一步是检查node版本。我遇到的情况是node 18和20的兼容性最好如果你用的node版本过新可能出现依赖编译的问题建议切到LTS版本再装。这个坑属于典型的文档里没写、下载量一大才暴露的问题遇到了别慌按这个顺序排查基本都能解决。6.2 API Key安全这里要重点提醒一个事API Key千万不要分享也绝对不要提交到git仓库里。现在网上有一些API Key分享的说法或者把key直接写在代码里方便测试的做法这些都是安全隐患。一旦key泄露别人可以拿你的额度去跑任务账单上全是别人的消耗轻则破财重则被封号。我在本地开发时的习惯是把key放进环境变量文件并且把.env文件加入.gitignore。如果有团队协作的需求应该通过密钥管理服务去分发key而不是在聊天工具里直接发明文。这次发布会提到了API Key的用量审计和异常检测功能建议都打开可以及时看到是否有异常的调用来源。6.3 dots任务挂起与并发冲突dots跑多代理任务时我遇到最多的两类问题是任务挂起和并发写冲突。任务挂起通常是网络波动或者某个代理长时间没有输出导致的。第一步是用dots log --tail查看当前执行状态定位是哪个子任务卡住了如果是网络问题等恢复后重试通常会好。如果卡住的是单个代理可以用dots resume命令从断点恢复这个功能在Codex CLI 2.0里是配套实现的。并发写冲突的处理比较麻烦。dots检测到两个代理同时改一个文件时默认会回滚其中一个代理的改动然后向你报告。我的处理方式是用Codex Debugger回放两个代理的执行过程判断谁的改动更合理然后手动重新应用。预防的办法就是前面说的在任务描述里明确限定每个子任务的文件边界这比事后解决冲突省事很多。6.4 Spaces的同步问题ChatGPT Spaces用了一段时间遇到过两个小问题。一个是文件更新后AI有时还是引用旧版本的内容。这是因为Space的文件索引不是实时更新的文件上传后需要一点时间重新索引。解决办法是在上传后发一条请基于最新版本的文件回答之类的话触发生成新的摘要。另一个是多人同时编辑时的版本覆盖问题。Space本身不提供文档协同编辑它的定位是上下文池。如果团队需要多人同时改同一份文档建议文档本身的编辑还是走Notion或Google DocsSpace只负责AI协作和讨论。一开始我们试图把Space当文件服务器用后来发现定位错了工具还是用在它擅长的地方最好。7. 会后一个月我自己的几点使用心得7.1 我最终把哪些场景真正切到了新工具会后一个月我每天实际在用的新东西比预期少但留下来的都是真正有效果的。dots目前是我做模块级重构的标配但凡涉及跨文件、多步骤的改动我都会先让它跑一遍GPT-6.1 Sol已经接入了主力API服务稳定性和生成质量都比上一代好ChatGPT Spaces则成了团队技术讨论的默认场地特别是在接口评审和方案决策这种需要长期跟进的话题上。7.2 给后来者的一条最实在建议如果说只给大家留一条建议那就是不要一次性把所有的AI新功能都堆到生产流程里。先用一个小项目、一个小团队把dots跑通把Spaces用起来把Sol接进一条测试链路跑出结果再逐步扩大。AI工具的落地从来不是工具本身的问题而是流程适配的问题。你团队的工作流越成熟AI工具能发挥的增量空间就越大。这次DevDay的发布固然热闹但把热闹变成生产力始终还是要靠动手去试。