OpenAI DevDay 2026：GPT-6.1 Sol、dots与Spaces重塑AI协作开发

1. 2026 DevDay 主舞台的节奏与整体印象

今年的 DevDay 开场没有那么多预热视频，直接就是 Sam Altman 上台放了半分钟 demo：让 GPT-6.1 Sol 在几分钟内完成一个多智能体协作的完整任务，从拆解需求、分配子任务、调用外部 API、生成可视化报告，到最终把结果整理进 ChatGPT Spaces 的一个共享空间里。整个过程几乎没有人工干预，旁边只配了简短的语音指令。说实话，这个开场看得人挺热血，因为这就是过去一年整个行业反复念叨的“Agent 真正落到工作流里”的样子。之后的 45 分钟，官方陆续放出了 20 多项更新，信息密度极高，但真正值得开发者停下来细品的，一个是全新的交互产品 dots，一个是面向团队协作的 ChatGPT Spaces，再就是新模型底座 GPT-6.1 Sol。

这次发布会的定位非常明确：不再是单纯堆参数、堆 benchmark，而是把“模型、工具、协作界面、开发者基础设施”串成一条完整的链。如果你只看模型参数，会以为只是常规迭代；但如果你把 dots、Spaces、API 更新放在同一个上下文里看，会发现 OpenAI 在试图重新定义“人和 AI 一起工作”的形态。这篇文章我想以参会者和开发者的双重视角，把整场发布会里真正有干活的东西拆开讲，包括哪些更新值得立刻上手、哪些东西目前还有坑、以及我对整套体系的判断。

2. 全场 20+ 项发布的总览与分层

2.1 发布内容的四大层次

我把这次 DevDay 的发布内容按层拆解，理解起来会清晰很多：

• 模型层：GPT-6.1 Sol 正式发布，同时开放了 Sol 的轻量版 Sol Mini 给高并发场景，还有配套的 Embedding 新模型。
• 界面与交互层：全新的 dots 产品，以及 ChatGPT Spaces 从预览转为全面开放，这两个属于普通用户和团队都能直接感知的更新。
• 开发者平台层：Realtime API、微调 API、结构化输出、函数调用这些基础能力都做了重要升级，其中不少还直接降了价。
• 生态与协作层：应用商店机制完善、第三方工具集成规范、团队工作区的权限模型强化。

这个分层不是官方给的，但是按我的理解，它更能说明这次发布会的真实意图。模型能力是基础，但哪怕模型再强，如果没有好用的交互界面和稳定可控的 API 底座，开发者也没办法把它变成真正的产品。这次 DevDay 让人兴奋的地方在于，三层都有实质性的进展，而不是只有模型层单点突破。

2.2 值得优先关注的重点项目

在所有发布里，有三个东西热度最高：dots、ChatGPT Spaces、GPT-6.1 Sol。后面我会分别展开。这里先说说其他容易被忽略但不该错过的更新。

• 提示词缓存价格再次下降：新的长上下文缓存，首次命中成本直接降了 75%，对做 RAG 或者长文档处理的人影响极大。
• 结构化输出支持嵌套 AnyOf：以前要做复杂的 JSON Schema 校验，经常得自己拼 Prompt 再加外置校验器；现在模型原生支持更复杂的数据结构，响应格式的正确率提升明显。
• Realtime API 增加了语音活动检测的置信度字段：这在做语音对话产品时非常关键，能大幅减少误断句。
• 批量 API 支持了检查点断点续跑：大批量任务中间挂了不用全量重来，对生产环境友好很多。

这些小更新单独看都不算革命，但组合起来使用成本更低、容错更强，这恰恰是生产环境最需要的。推荐有条件的团队直接把相关的 Beta 功能开起来测试，大部分都是向下兼容的开关。

3. 详解 dots：被很多人低估的交互范式变化

3.1 dots 到底是个什么东西

dots 是这次 DevDay 上最让我意外的一个产品。它不是一个传统的聊天界面，也不是普通的画布工具。你可以在一个无限画布上创建一个个“点”，每个点可以承载一段文本、一张图片、一段音频、一段代码、一个 API 调用结果，甚至一个正在运行的小型 Agent。点和点之间可以连线，连线代表信息流向或者依赖关系。整个画布可以被 ChatGPT 实时读取和理解，也就是说，你可以用很随意的方式把素材丢上去，然后让模型基于这些“点”之间的关系去推理和生成。

听起来是不是有点像“可视化思维链”？对，实际上 dots 带来的体验确实如此。普通聊天窗口的问题在于上下文是线性的，信息只能一条条往下堆；而 dots 把上下文变成了网状结构。举个例子，我在现场试了试让 dots 帮我梳理一份产品竞品分析：左侧放了三家竞品的官网截图和定价页面，中间放了我自己产品的用户反馈截图，右侧让模型生成了三个对比维度。模型不仅正确理解了这些点的位置关系，还自动在“用户反馈”和“竞品定价”之间建立了一条连线，标注出“价格敏感度可能是流失主因”。这种对空间布局和关系的理解，是普通对话模式很难做到的。

3.2 dots 的技术底座与适合的使用场景

dots 背后实际上依赖的是 GPT-6.1 Sol 的多模态空间理解能力。模型不是把画布简单地转成文字描述，而是能够理解各个点的坐标、大小、层级、连线关系，以及点里面承载的不同模态内容。这意味着 dots 特别适合这几类工作：

• 研究整理类：把论文、网页、数据报告全部丢进画布，让模型按逻辑重新组织，并用连线标出相互引用和矛盾点。
• 头脑风暴与方案设计：一个想法一个点，点和点随意连接，快速展开成完整方案。比传统的思维导图更灵活，因为每个点都像是活的。
• 代码与架构设计：在画布上画出模块、接口、数据流，再让模型根据这个架构图直接生成代码骨架。实测对于中大型项目的起步阶段效率提升很明显。

不过说实话，dots 当前版本还远远不够完美。它的文件加载速度在画布元素超过 200 个时会有明显下降，而且默认的自动连线偶尔也会“自作聪明”连错逻辑。我在现场也听到不少开发者反馈，希望官方能开放更多画布操作的 API，让自己开发的 Agent 可以主动向画布写入内容。OpenAI 在会上表示这已经在规划列表里，但没给明确时间。我的建议是：如果你现在主要用 ChatGPT 做长文档分析、复杂调研、团队方案设计，dots 值得立刻上手；如果你只是日常问答，那没必要强行切换。

4. ChatGPT Spaces：从单人对话升级到团队协同空间

4.1 Spaces 的核心功能拆解

ChatGPT Spaces 是这次发布会里另一个重量级更新。简单说，它就是把原来“一个对话从头聊到尾”的模式，升级成一个持久化、结构化、可共享的工作空间。你可以在一个 Space 里同时创建多个子对话、多个文件存储夹、多个自定义 Agent，甚至多个互相关联的 dots 画布。所有成员看到的是同一个动态更新的空间状态，而不是各自对着一个孤立的聊天记录。

最值得关注的是 Space 引入了全新的角色权限体系。以前团队用法基本都是共用账号或者把对话记录导出再到处转发，既混乱又不安全。现在一个 Space 下可以设置 Owner、Editor、Viewer，还支持按 Agent 的粒度去限制权限。举个例子，你可以只让某个成员使用团队微调过的“代码审查 Agent”，但不允许他直接调用“生产环境变更 Agent”。这种精细化的管控，对稍微有点规模的技术团队是刚需。

另外，Spaces 和 GPT-6.1 Sol 的“持续性记忆”做了深度集成。每个 Space 都有自己独立的知识库和记忆空间，模型会基于该 Space 的历史讨论、上传的文档、成员反馈来组织回答。这让模型不再像一个每次都“失忆”的聊天机器人，而更像一个熟悉你们团队上下文的老同事。我个人尝试下来，在多轮复杂项目协作中，回答质量的稳定性确实比普通模式高出一截。

4.2 Spaces 在团队工作流中的实际接入方法

我的建议是不要一上来就把所有对话都迁到 Spaces 里，而是选一个正在推进的项目做试点。具体步骤可以参考：

1. 创建一个新 Space，命名为项目名。
2. 把项目相关的文档、历史讨论记录、数据文件统一上传到 Space 的知识库。
3. 在 Space 里创建三个子助理：资料分析、方案生成、代码实现。
4. 拉入团队核心成员，按职责分配角色权限。
5. 把每天的工作对接讨论全部放进 Space 对应频道，保持上下文连续。
6. 每完成一个里程碑，用 Space 的总结功能自动生成项目周报。

这套流程我们在一个内部工具的重构项目里跑了大概两周，最直观的变化是“重复沟通”显著减少。以前每次新需求都要把背景资料从头讲一遍，现在模型直接能从 Space 的记忆里调出相关上下文，新成员也能通过历史记录快速接手。当然，Spaces 也有一些待改进的点，比如搜索功能目前只支持标题和正文关键词，不支持语义检索；移动端的编辑体验明显弱于网页端。这些问题官方应该会在后续迭代里解决，但不影响它成为当前团队协作最值得尝试的 AI 工作空间。

5. GPT-6.1 Sol：模型能力的全面梳理与实测感受

5.1 模型规格与关键能力提升

这次发布会的主角毫无疑问是 GPT-6.1 Sol。命名上“Sol”来自拉丁语里的“太阳”，意思也很直白：这是一个试图成为“核心引擎”的模型。从官方公布的数据来看，GPT-6.1 Sol 的核心提升集中在这几个方向：

• 上下文窗口扩展到 4M token，实测可以在一整轮对话里读完几十本技术文档，并在后续问题中准确引用其中的细节。
• 多模态理解能力大幅增强，不仅支持图片、音频、视频输入，还首次把“空间布局”纳入了统一理解框架。dots 产品就是直接受益者。
• 工具调用与多步规划能力明显提升，尤其适合 Agent 场景。官方展示了一个案例：模型自主完成了从电商后台拉取销售数据、清洗数据、生成可视化图表、撰写分析报告、发出邮件通知的完整链路，整个过程只被用户打断了一次。
• 推理效率优化明显。Sol 对比上一代旗舰在相同任务上的首字响应延迟降低了约 40%，这对交互型产品极其重要。

还有一个容易被忽略的更新：Sol 引入了动态推理预算控制。以前我们调用大模型，要么固定 max_tokens，要么开启 reasoning mode 让模型无限推理，很难控制成本和延迟。现在 API 参数里可以直接设置推理预算，比如“简单问答用低预算，复杂代码生成用高预算”，模型会自动调整思考深度。实测下来，在保证结果质量基本不变的情况下，普通问题处理成本下降了约三分之一，这对生产环境的意义非常实际。

5.2 从开发者视角看 Sol 的 API 形态

从 API 接入角度看，全新的模型名是gpt-6.1-sol和gpt-6.1-sol-mini。其中 Mini 版在代码生成和结构化输出上的表现依然很强，但价格只有旗舰版的大约四分之一，长上下文处理能力为 1M token。如果你做的是高并发的客服系统或者内容分类任务，Mini 版应该会成为新的性价比之选。

官方还上线了模型路由功能：你可以在同一个 API 请求里指定一组模型，并设定一个质量目标。系统会根据输入提示词的复杂度，自动决定这次用 Mini 版还是旗舰版。对于不想手工拆分流量逻辑的团队来说，这个功能真的能省很多事。另一个让我比较惊喜的是，Sol 的微调 API 现在支持了多模态数据，你可以用自己的图片和文本混合语料来微调模型，这在之前是没开放的。不过我得提醒一句，微调不是万能药。如果你想改变模型的行为风格、输出格式，微调很有用；但如果你想给模型注入新知识，直接用 RAG 往往成本更低、效果更可控。

5.3 实测中发现的注意点与优化建议

我用提前开放的 API 跑了几组任务，其中包括代码生成、长文档摘要、以及一个相对复杂的多表 SQL 生成。总体上 Sol 的代码质量确实比上一代好，尤其是在理解项目上下文和遵守代码风格方面。但也有几个坑需要提醒大家：

• 在超长上下文的极端场景下，如果文档中间混杂了大量无关内容，Sol 偶尔会在回复中“过度参考”较早的片段，导致最新信息被稀释。建议关键信息尽量放在上下文的开头或结尾，并且用明确的 XML 分段标记。
• 动态推理预算这个参数需要调优。我一开始把预算拉得太低，导致复杂问题出现逻辑不完整；后来改成“阶梯式预算”，让模型先尝试低预算，失败再升级，才找到平衡。
• 4M 上下文窗口确实很香，但它对工程架构的挑战也很大。你依然需要做上下文裁剪和压缩，不可能真把所有内容无脑塞进去。官方提供了上下文摘要和分块引用接口，建议直接使用而不是自己造轮子。

整体来说，GPT-6.1 Sol 代表了当前技术上能做出来的最好水平之一，但把它放回真实业务里，模型的绝对能力只是基础，工程化的数据管理、调用策略、成本控制才是决定项目能不能长期跑下去的关键。

6. 开发者平台更新：API、工具链与成本策略

6.1 API 关键更新一览与定价变化

这次 DevDay 在开发者平台方面也放了不少大招。很多更新不是那种一眼惊艳的类型，但放到生产环节里，每一条都能实打实省成本、稳服务。我把最关键的几条整理成了表格：

定价方面，除了缓存降价，官方还调整了 Sol 系列的输入输出 token 价格，同时把微调 API 的按 token 训练费下调约 20%。另外，新推出的“按任务计费”模式允许开发者为常见任务购买固定套餐，而不是按 token 计费。对于调用量稳定的业务，这个模式能带来更高的成本可预测性。我建议做 To B 产品的团队认真算一笔账，如果任务类型集中，按任务计费通常会比按 token 计费省不少。

6.2 新工具链：Codex CLI 正式版与 Code Interpreter 内置

发布会上，OpenAI 花了很大篇幅介绍 Codex CLI。简单来说，它是一个跑在终端里的编程智能体，可以在你的本地代码仓库里直接读代码、改代码、跑测试、提交 commit。和之前只能在云端沙箱里运行不同，Codex CLI 直接附着在你自己的开发环境里，支持各类主流版本管理工具。我实际用下来，它对大型代码仓库的导航能力比我想象中要强，能准确找到跨模块的函数调用链。尤其是 Debug 场景，它会主动在工程里搜索相关日志和异常堆栈，然后提出修改方案。对于脚本维护和重构任务，配合这次发布的动态推理预算，体验已经接近一个中级开发者的水平。

同时，Code Interpreter 也被升级成一个更完整的工具集。它现在可以自主运行 Python、R、JavaScript，并且支持访问网页内容抓取和数据库连接。用大白话说，你给对话一个任务，它可以自己决定用什么代码、查什么库、画什么图，而不是像以前一样只能在一个受限环境里跑简单脚本。这个变化对数据分析场景很有价值，我在现场试着让它读取一个 CSV 后生成可视化分析，再结合 dots 画布整理成汇报页面，整个流程大约三分钟，中间不需要切换任何工具。

6.3 开发者需要避开的成本与配置陷阱

说完了亮点，也说说我在实际测试中踩过或者观察到别人踩过的坑。

第一个坑是“缓存命中率幻觉”。OpenAI 的提示词缓存并不是你输入了相同文本就必然命中，它对前缀相同的部分才生效。如果你在每次请求前面都拼一个动态时间戳或者随机 ID，缓存就完全失效。正确做法是尽量保持前缀静态，把动态内容放到请求的后面。

第二个坑是动态推理预算设得太低。我在几个代码生成任务里试过把推理预算设为低档，结果模型确实返回得很快，但生成的代码在一些边界条件上处理得不够严谨。这类问题在单元测试覆盖不完善的项目上尤其危险。建议大家对生成结果保持机器和人双重校验，至少跑一遍静态检查。

第三个坑是工具调用的循环防护。新版函数调用支持依赖声明之后，Agent 可以串联多个步骤，但也更容易因为外部 API 异常而进入死循环。务必设置最大调用轮数，以及在每个步骤后做结果状态检查。官方给你提供了轮次计数上下文变量，但不会主动帮你切断异常循环。

7. 常见问题排查与现场反馈速查

7.1 开发者高频问题与解决建议

针对这次发布的新功能，我整理了大家在现场和开发者社区里讨论最集中的几个问题，这里直接给结论。

• 为什么我的 dots 画布在某些浏览器上总是卡顿？大概率是 GPU 加速没有开启。Chrome 和 Edge 需要硬解支持，Safari 在画布元素超过 300 个时建议开启“降低动态效果”。另外很多卡顿其实来自插件冲突，换无痕模式试试往往就解决了。
• Spaces 同步的延迟大概是多少？正常网络环境下，网页端基本是秒级同步。但如果开了很多大文件预览，可能延迟到十几秒。建议大文件只保留在知识库里，不要直接挂到空间面板的预览区。
• 调用 Sol 的 API 出现 400 错误提示“prompt_too_long”？4M token 的上限是总量，包括了输入、工具调用历史、系统提示。如果工具调用步骤很多，历史累积可能很快超出预期。建议使用会话压缩接口把早期步骤整理成摘要。
• 结构化输出的嵌套 AnyOf 在部分 SDK 里报错？目前只有新版 Python SDK 和 Node SDK 完整支持这一特性，旧版本需要升级。如果暂时没法升级，可以先退回到 JSON Schema 的oneOf写法。

7.2 现场两则让我印象深刻的 Demo 细节

发布会现场有两个细节，我觉得比 PPT 本身更能说明趋势。第一个是现场展示了用 dots 组织一个“家庭旅行计划”的场景：用户在画布上放了机票价格截图、酒店评价、天气预报、几个人的饮食偏好，模型自动生成了三个备选行程，并用连线标出了天气变化和行程调整之间的冲突。这个场景并不算硬核，但直观地展示了 dots 作为“AI 协作画布”的潜能。

第二个是直播演示了一个小型 SaaS 团队在 Spaces 里开发并上线一个小功能的完整过程。产品经理、设计师、前端、后端分别在不同区域加内容，模型能根据标签自动聚合每个人的进展，最后汇总成一份带着甘特图的进度状态。虽然明显有彩排痕迹，但工作流本身是真实合理的。我能明显感觉到，OpenAI 这轮主推的不再是“单个 AI 更聪明”，而是“一群人和一群 AI 如何更高效地围绕同一个目标协作”。

8. 结语：这次发布带给我的真实体会

整个 DevDay 看下来，我自己最大的感受是：模型能力已经不是唯一焦点，产品形态和工程底座的重要性正在快速上升。GPT-6.1 Sol 解决了“模型本身能不能做”的问题，dots 和 Spaces 解决的是“人怎么更好地用模型”的问题，而 API 层的一系列更新解决的是“生产环境能不能稳定跑”的问题。三个问题一起被回应，才是这次发布会真正值得关注的地方。

如果你是独立开发者，我建议先从 Codex CLI 和 Sol Mini 入手，成本低、见效快；如果你在带团队，认真把 Spaces 用起来，并建立一个围绕空间的知识管理习惯；如果你在做商业化产品，动态推理预算、缓存降本、按任务计费这三个点值得立刻评估。当然，所有新东西都需要实际踩一踩才知道合不合脚，这次发布的很多能力还在快速迭代中，我建议保持关注但不要盲目跟随。等 OpenAI 后续补齐更多文档和 SDK 示例以后，我会再综合写一份实际落地中的经验分享。