1. 这场发布会到底讲了什么：从标题拆解核心信息
OpenAI DevDay 2026 一口气甩出了 20 多项发布，密度高到我在看直播回放的时候不得不暂停了三次做笔记。核心的几个名字先摆出来：dots、ChatGPT Spaces、GPT-6.1 Sol。这三个是整场的主轴，其余十几项发布基本都围绕它们展开，要么是配套能力，要么是底层支撑。
先说清楚这三个东西分别是什么定位，不然后面容易乱。
dots是这次最让我意外的一个东西。它不是模型，也不是一个独立 App，而是一套面向开发者的“原子化能力单元”体系。你可以把它理解成把过去那些大而全的 API 拆成了一个个极小的、可组合的功能点，每个 dot 只干一件事，但干得很干净。比如一个 dot 专门做结构化抽取，一个 dot 专门做多轮意图追踪，一个 dot 专门做代码补全的上下文裁剪。开发者按需拼装，而不是每次都调用一个巨型模型去干所有事。
ChatGPT Spaces则是面向使用侧的空间化组织方式。过去 ChatGPT 的对话是一条条线性的 thread，现在 Spaces 把对话、文件、工具、外部数据源组织成一个有边界的“空间”。一个 Space 可以是一个项目、一个团队、一个知识库，里面的上下文是持续存在的，不是每次开新对话就清零。
GPT-6.1 Sol是这次的旗舰模型。Sol 这个后缀不是随便起的，官方在台上强调的关键词是“solver”，也就是它被定位成一个偏推理、偏求解的模型，而不是单纯的语言生成器。上下文窗口、工具调用稳定性、长链推理的中间态保持，是它主打的三个方向。
适合谁来读这篇回顾？如果你是开发者，重点关注 dots 和 GPT-6.1 Sol 的 API 变化；如果你是重度 ChatGPT 用户，ChatGPT Spaces 会直接改变你的日常使用方式；如果你只是想知道行业在往哪走，那这三个东西的组合其实透露了一个很明确的信号：能力在原子化，上下文在空间化，模型在求解化。
下面我按“整体设计思路 → 核心细节 → 实操落地 → 问题排查”这个顺序，把这场发布会里真正值得动手复现的部分拆开讲。中间会穿插我自己试用的感受和一些踩坑记录。
2. 整体设计思路：为什么是这三个方向
2.1 从“大模型调用”到“能力原子化”的转变逻辑
过去两年大家调 API 的方式基本是固定的：把 prompt 拼好，丢给一个通用模型，等它返回。这个模式的问题在于，你为了让它干一件小事，往往要付出一个完整大模型调用的成本，而且输出格式还得靠 prompt 去约束，稳定性全靠运气。
dots 这套东西的出现，本质上是把“prompt 工程”往“能力编排”方向推。每个 dot 是一个预训练好的、职责单一的小单元，输入输出格式是固定的。你不再需要写一大段“请你扮演一个专业的抽取助手，从下面文本中提取……”这种话，直接调用对应的 dot，传参，拿结构化结果。
这么设计的好处很直接：延迟低、成本低、输出稳定。坏处也有，就是灵活性下降，遇到 dot 覆盖不到的场景还是得回退到通用模型。所以官方在台上也说了，dots 和 GPT-6.1 Sol 是互补关系，不是替代关系。
我个人的判断是，这套思路对做产品的团队价值最大。因为产品里 80% 的 AI 调用其实都是重复的、模式化的任务，用 dots 能把这部分成本和不确定性压下来，把通用模型留给真正需要“思考”的环节。
2.2 ChatGPT Spaces 解决的到底是什么痛点
用 ChatGPT 久了的人都有一个共同的烦恼：上下文是碎的。你上周聊的一个项目，这周想接着聊，得重新把背景贴一遍。文件传了又传，工具配置了又配置，每个新对话都是从零开始。
ChatGPT Spaces 就是冲着这个来的。它把“对话”升级成了“空间”，空间里可以挂载文件、挂载工具、挂载外部数据源，而且这些挂载是持久的。你在这个 Space 里开的每一个新对话，都自动继承这个空间的上下文。
这个设计背后的逻辑是：把上下文从“对话级”提升到“项目级”。对话是临时的，项目是持续的。对于做长期项目的人来说，这个改变是质变。你不用再维护一个巨大的“背景 prompt”，Space 本身就是背景。
2.3 GPT-6.1 Sol 的“求解”定位意味着什么
Sol 这个名字和“solver”的关联，官方没有明说，但从演示内容看，它的重心确实在推理链的稳定性上。过去的模型在做多步推理时，中间步骤容易“漂移”，走着走着就偏了。Sol 在演示里展示的是长链条任务中中间态的可保持性，比如一个需要调用七八次工具、跨越多个数据源的任务，它能记住自己走到哪一步、为什么走到这一步。
这对开发者意味着什么？意味着你可以把更复杂的任务交给它，而不用在每一步之间自己做状态管理。过去你要写一堆胶水代码来维护任务状态，现在模型自己扛了一部分。
这三个方向合起来看，其实是一条完整的链路：dots 提供原子能力，Sol 提供推理调度，Spaces 提供上下文容器。开发者用 dots 拼能力，用 Sol 做编排，用 Spaces 存上下文。这是一个完整的开发范式，不是三个孤立的功能。
3. 核心细节解析：每个发布背后的关键点
3.1 dots 的能力清单与调用方式
官方在台上没有把 dots 的全部清单列完，但从演示和文档片段能看出几个大类：
- 抽取类：从非结构化文本里抽结构化字段，比如从合同里抽甲乙方、金额、期限。
- 分类类：多标签分类、意图识别，输出是固定枚举。
- 改写类：润色、压缩、扩写、风格迁移。
- 代码类：补全、注释生成、上下文裁剪。
- 检索类：向量化、重排、相关性打分。
调用方式上，dots 走的是和主 API 一致的鉴权体系，但端点不同。大致形态是这样：
curl https://api.openai.com/v1/dots/extract \ -H "Authorization: Bearer $OPENAI_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "dot": "extract.contract.party", "input": "本合同由甲方某某科技有限公司与乙方某某信息技术有限公司签订...", "schema": { "party_a": "string", "party_b": "string" } }'注意这里的dot字段，它指定了你要调用哪个原子能力。schema字段是输出约束，模型会按这个结构返回。这个设计比过去靠 prompt 约束格式要可靠得多，因为 schema 是硬约束，不是软引导。
提示：dots 的计费和主模型是分开的，单价明显更低，但每个 dot 有独立的调用配额。做成本预估的时候别只算主模型的账。
3.2 ChatGPT Spaces 的结构与权限模型
Spaces 的结构大致分三层：空间 → 资源 → 对话。一个空间下可以挂多个资源（文件、数据源、工具），资源在空间内共享，对话继承空间的所有资源。
权限上，Spaces 支持个人空间和共享空间。共享空间可以邀请成员，成员对资源的访问权限可以单独配置。这一点对企业用户很关键，因为过去把敏感文件丢进对话里是有泄露风险的，现在可以在空间级别做管控。
我实际试下来的感受是，Spaces 最适合的场景是长期项目和团队协作。如果你只是偶尔问几个零散问题，Spaces 的价值体现不出来，反而多了一层管理成本。但如果你有一个持续几周甚至几个月的项目，把所有相关文件、数据、历史对话都放进一个 Space，体验是断崖式提升的。
3.3 GPT-6.1 Sol 的关键参数与能力边界
Sol 的几个关键参数，官方给了大致范围：
| 参数 | 数值/说明 |
|---|---|
| 上下文窗口 | 显著大于上一代，支持长文档整篇输入 |
| 工具调用 | 支持多工具并行调用与结果聚合 |
| 推理链保持 | 长链任务中间态可保持，减少漂移 |
| 输出格式 | 支持结构化输出约束 |
| 多模态 | 文本为主，图像理解能力保留 |
能力边界上，Sol 不是万能的。它在需要“求解”的任务上强，比如多步推理、工具编排、复杂条件判断。但在纯创意生成、风格化写作上，和上一代比提升没那么明显。所以选型的时候要看任务类型，别一股脑全上 Sol，成本不划算。
3.4 其余十几项发布的归类
20 多项发布里，除了三个主角，其余大致可以归成几类：
- API 侧：新的批量接口、更细的用量统计、更灵活的限流策略。
- 工具侧：Codex 相关的命令行工具更新，包括安装、登录、依赖处理。
- 平台侧：Spaces 的管理后台、团队协作功能。
- 生态侧：和第三方工具的集成点。
这些不是主角，但都是让主角能落地的基础设施。特别是 Codex 命令行工具的更新，对开发者日常影响很大，后面实操部分会细讲。
4. 实操落地：从零开始把新能力跑起来
4.1 环境准备与 Codex 命令行工具安装
先把基础环境搭好。这次 DevDay 之后，Codex 的命令行工具做了一次比较大的更新，安装方式和登录方式都有变化。
安装走 npm：
npm install -g @openai/codex装完之后登录，现在支持用 ChatGPT 账号直接登录：
codex login这条命令会拉起浏览器做授权，授权完成后本地会存一个凭证。这个方式比过去手动配 API key 要方便，而且额度是跟着账号走的。
注意：如果你在 Windows 上装，可能会遇到
missing optional dependency @openai/codex-win32-x64这个报错。这是可选依赖没装上导致的，解决办法是先卸载再重装：
npm uninstall -g @openai/codex npm install -g @openai/codex --force如果还不行，检查一下 npm 的 registry 和网络，有时候是拉包的时候超时导致可选依赖被跳过。
4.2 用 dots 搭一个结构化抽取流水线
假设你要做一个合同信息抽取的功能，过去你得写一大段 prompt，现在用 dots 可以拆成几步。
第一步，调用抽取 dot 拿到原始字段：
import requests def extract_contract(text): resp = requests.post( "https://api.openai.com/v1/dots/extract", headers={ "Authorization": f"Bearer {API_KEY}", "Content-Type": "application/json" }, json={ "dot": "extract.contract.party", "input": text, "schema": { "party_a": "string", "party_b": "string", "amount": "number", "deadline": "string" } } ) return resp.json()第二步，如果抽取结果里有不确定的字段，再调一个校验 dot 做二次确认。这种“抽取 + 校验”的组合比单次大模型调用要稳，因为每个 dot 的职责单一，出错概率低。
第三步，把结果写进你的数据库。整条链路里没有一次通用模型调用，成本和延迟都压下来了。
4.3 在 ChatGPT Spaces 里组织一个长期项目
Spaces 的实操不复杂，但有几个设置点值得注意。
创建 Space 之后，第一件事是把资源挂上去。资源可以是本地文件、也可以是外部数据源的连接。挂载之后，Space 里的所有对话都能访问这些资源。
第二件事是配置指令。Space 级别可以设一段常驻指令，相当于这个空间的“系统提示”。比如你可以写“本空间所有对话都围绕 XX 项目，回答时优先引用空间内文件”。这段指令会作用于空间内所有对话，不用每次重复。
第三件事是权限。如果是团队空间，把成员加进来之后，逐个配置资源访问权限。敏感文件可以只对部分成员开放。
我自己的用法是给每个长期项目开一个 Space，把需求文档、会议记录、代码片段都丢进去。之后问问题的时候，它自动就能引用这些背景，省掉了大量重复描述。
4.4 用 GPT-6.1 Sol 做多步工具编排
Sol 的多工具调用是这次比较实用的一个能力。举个场景：你要做一个“查天气 → 根据天气推荐穿搭 → 生成购物清单”的链路。
过去你得自己写代码串这三步，现在可以在一次调用里让 Sol 自己编排：
resp = client.chat.completions.create( model="gpt-6.1-sol", messages=[ {"role": "user", "content": "帮我根据今天的天气推荐穿搭并生成购物清单"} ], tools=[weather_tool, wardrobe_tool, shopping_tool], tool_choice="auto" )Sol 会自己决定先调哪个工具、拿到结果后再调哪个。你只需要把工具定义好，编排逻辑交给它。这个能力在复杂任务上省事很多，但要注意工具定义的描述要清晰，否则它可能选错工具。
提示：多工具编排的稳定性依赖工具描述的准确性。每个工具的功能、输入、输出都要写清楚，模糊的描述会导致 Sol 在编排时做出错误选择。
5. 常见问题与排查技巧实录
5.1 安装与登录类问题
| 问题现象 | 可能原因 | 解决办法 |
|---|---|---|
missing optional dependency | 可选依赖未安装 | 卸载后加--force重装 |
| 登录后仍提示未授权 | 凭证未刷新 | 重新执行codex login |
| 命令找不到 | 全局路径未生效 | 检查 npm 全局 bin 是否在 PATH |
| 安装超时 | 网络问题 | 换 registry 或重试 |
5.2 dots 调用类问题
最常见的是 schema 不匹配。你定义的 schema 和 dot 实际支持的字段对不上，会直接报错。解决办法是先查文档确认这个 dot 支持哪些字段，别自己臆造。
另一个是输入过长。dots 虽然便宜，但每个 dot 对输入长度是有限制的，超了会被截断。做长文本处理的时候要自己先分块。
5.3 Spaces 使用类问题
Spaces 最常见的问题是资源没生效。你挂了文件，但对话里引用不到。这通常是资源索引还没建完，等几分钟再试。如果一直不行，检查一下资源的权限设置，可能是当前对话没有访问权限。
还有一个是空间指令冲突。如果你在空间指令里写了很严格的约束，又在对话里给了相反的指令，模型会困惑。建议空间指令只写通用的背景，具体约束放在对话里。
5.4 Sol 编排类问题
Sol 在多工具编排时偶尔会陷入循环，反复调同一个工具。这通常是因为工具返回的结果没有让它满意，它想再试一次。解决办法是在工具描述里明确“如果结果已满足条件，不要再调用”，或者在代码层面加一个调用次数上限。
另一个是工具选择错误。比如你想让它查天气，它却调了穿搭工具。这基本是工具描述不够清晰导致的，把每个工具的适用场景写具体一点就能改善。
6. 我自己的使用体会与几个实用建议
这套东西我用下来，最大的感受是分工变清晰了。过去所有事都堆给一个大模型，现在可以按任务类型分派：模式化的任务给 dots，需要推理的给 Sol，需要长期上下文的放 Spaces。这个分工带来的直接好处是成本和稳定性都可控了。
几个实用建议。第一，别急着把所有东西都迁到新体系上，先挑一两个模式化程度高的场景试水，跑通了再扩。第二，Spaces 的资源管理要养成习惯，定期清理不用的文件，不然空间会越来越臃肿，检索质量会下降。第三，Sol 的工具描述值得花时间打磨，这是决定编排质量的关键，比调 prompt 的收益大得多。
最后分享一个小技巧：dots 和 Sol 可以组合用。先用 dots 做一轮粗筛和结构化，把干净的数据喂给 Sol 做推理，这样既省成本又提质量。我试过几个场景，这个组合比单用 Sol 的效果和成本都更好。
