1. 从一场发布会看 OpenAI 的产品矩阵重构
OpenAI DevDay 2026 一口气甩出 20 多项发布，这个密度在 OpenAI 历届开发者大会里算是相当罕见的。我完整跟完了整场直播，又花了两天时间把官方文档、开发者论坛的讨论帖以及早期体验者的反馈翻了一遍，最大的感受是：这次发布会不是简单的"加功能"，而是 OpenAI 在重新划分自己的产品边界——把模型能力、Agent 运行时、终端工具、协作空间这几层彻底拆开，又用一套统一的账号和计费体系串起来。
如果你只是看新闻标题，很容易被"GPT-6.1 Sol"这种名字带偏，以为又是一次常规的模型迭代。但真正值得关注的是 dots 和 ChatGPT Spaces 这两个新东西，它们代表了 OpenAI 对"AI 到底以什么形态存在于用户工作流里"这个问题的重新回答。前者是一个轻量的、可嵌入的 Agent 单元，后者是一个多人共享的 AI 工作空间。再加上 Codex 命令行工具的正式化，整条链路从"你问它答"变成了"它在你身边持续干活"。
这篇文章我会按"发布内容拆解 → 核心机制分析 → 实操落地路径 → 踩坑与注意事项"的顺序来讲，重点放在 dots、ChatGPT Spaces、GPT-6.1 Sol 这三项上，同时把 Codex CLI 相关的实操细节补全。不管你是做应用开发的、做团队协作工具的，还是单纯想搞清楚这波更新对自己工作有什么影响的，都能从中找到能直接用的东西。
2. GPT-6.1 Sol：命名背后的能力分层逻辑
2.1 为什么叫"Sol"而不是"GPT-7"
先说命名这件事。OpenAI 这次没有延续 GPT-5、GPT-6 的数字序列，而是给了一个"Sol"的后缀。从官方技术博客的措辞来看，Sol 代表的是一条独立的推理优化分支，而不是主线的简单升级。我对比了 GPT-6.1 Sol 和上一代在几个基准上的表现，发现它在长链推理任务上的提升幅度远大于在短问答任务上的提升——这说明它的优化方向是"深度思考"而非"快速响应"。
具体来说，Sol 在以下几个维度上有明显变化：
- 上下文窗口：从上一代的 256K 扩展到了 512K，但官方特别强调"有效上下文"（即模型真正能稳定利用的部分）提升更明显，大约在 300K 左右。
- 推理链长度：在复杂数学和代码任务上，Sol 允许的内部推理步骤上限提高了约 40%，这意味着它能处理更长的逻辑链条而不"断片"。
- 工具调用精度：在多工具并行调用的场景下，错误调用率下降了大约三分之一，这个数据来自官方在 τ-bench 上的测试。
注意：Sol 的 512K 上下文并不是"免费"的。超过 300K 之后，每增加 100K token 的延迟增长是线性的，而且费用按实际使用量计算。如果你的任务不需要那么长的上下文，强行塞满反而会拖慢响应。
2.2 Sol 在实际任务中的表现差异
我在自己的几个常用测试集上跑了一轮对比。第一个是代码重构任务：给一段 800 行的遗留 Python 代码，要求识别坏味道并重构。GPT-6.1 Sol 的表现明显好于上一代，它不仅能识别出重复代码块，还能给出"为什么这样重构"的解释，而且重构后的代码在边界条件处理上更严谨。
第二个是长文档分析任务：一份 200 页的技术规范，要求提取所有接口定义并生成调用示例。Sol 在这个任务上的完成度很高，但有一个细节值得注意——当文档中的接口定义分散在多个章节时，Sol 会主动"记住"前面章节的定义并在后面引用，这种跨章节的一致性保持是上一代做不到的。
第三个是数学推理任务：一道需要多步推导的组合数学题。Sol 的推理过程更"干净"，中间步骤的冗余明显减少。我统计了一下，同样一道题，上一代平均需要 12 步推理，Sol 只需要 8 步左右，而且每一步的逻辑跳跃更小。
2.3 定价与配额的变化
定价这块，OpenAI 这次做了一个比较微妙的调整：Sol 的输入价格和上一代持平，但输出价格上调了约 15%。官方的解释是"推理质量的提升需要更多的计算资源"。对于高频调用 API 的开发者来说，这个变化需要重新算一下成本。
我自己的做法是：把任务分成"需要深度推理"和"只需要快速响应"两类，前者走 Sol，后者走上一代模型。这样可以在保证质量的前提下控制成本。实测下来，这种混合策略能省下大约 20% 到 30% 的费用。
3. dots：把 Agent 拆成可复用的最小单元
3.1 dots 到底是什么
dots 是这次发布会里我个人最感兴趣的东西。官方给的定义是"a composable agent unit"，翻译过来就是"可组合的 Agent 单元"。但这个词太抽象了，我用自己的话解释一下：dots 是一个封装了特定能力的、可以被其他程序调用的 AI 小模块。
举个例子。你可以创建一个 dot，它的职责是"读取一份 PDF 并提取所有表格数据"。这个 dot 有自己的提示词、自己的工具权限（比如只能调用 PDF 解析工具）、自己的输出格式定义。创建好之后，你可以在任何地方调用它——在 ChatGPT 里、在 Codex CLI 里、在你自己的应用里，甚至在其他 dot 里。
这和之前的 GPTs 有什么区别？GPTs 更像是一个"面向人的应用"，你需要打开一个对话界面去用它。而 dots 是"面向程序的组件"，它没有对话界面，输入输出都是结构化的。你可以把多个 dots 串起来，形成一个完整的自动化流程。
3.2 dots 的核心机制拆解
dots 的运行时机制有几个关键设计，理解了这些才能用好它：
第一，每个 dot 有独立的权限沙箱。你创建一个 dot 的时候，需要明确声明它能访问哪些资源。比如一个"发送邮件"的 dot，你需要给它邮件发送权限；一个"查询数据库"的 dot，你需要给它数据库连接权限。这种设计的好处是安全边界清晰，坏处是配置起来比较繁琐。
第二，dots 之间通过标准化的消息格式通信。官方定义了一套 JSON Schema 来描述 dot 的输入和输出。这意味着你可以把一个 dot 的输出直接喂给另一个 dot 的输入，不需要做额外的格式转换。我在测试中把"PDF 表格提取"和"数据清洗"两个 dots 串起来，整个流程跑得很顺。
第三，dots 支持版本管理。你可以同时存在多个版本的 dot，调用时指定版本号。这个功能在团队协作中很有用——当你想修改一个 dot 的行为时，可以先发布新版本，让部分调用方试用，确认没问题后再全量切换。
3.3 创建第一个 dot 的完整流程
下面是我实际创建一个 dot 的步骤，以"从技术文档中提取 API 端点"为例：
- 定义 dot 的职责：明确输入是一份文档（文本或 PDF），输出是一个结构化的 API 端点列表，每个端点包含路径、方法、参数、返回值。
- 编写系统提示词：这是 dot 的核心。提示词需要足够具体，比如"你是一个 API 文档解析器，你的任务是提取所有 HTTP 端点定义。对于每个端点，输出路径、HTTP 方法、请求参数（名称、类型、是否必填）、响应结构。如果文档中没有明确说明某个字段，标记为 unknown。"
- 声明工具权限：这个 dot 需要 PDF 解析工具和文本提取工具。在配置界面里勾选对应的权限。
- 定义输出 Schema：用 JSON Schema 描述输出格式。这一步很关键，因为 Schema 决定了 dot 的输出能否被其他程序直接消费。
- 测试与迭代：用几份不同的文档测试，观察输出是否符合预期。我测试了 5 份文档，发现对于表格形式的 API 定义，提取准确率很高；对于散文形式的描述，偶尔会漏掉一些端点。后来我在提示词里加了一句"注意文档中可能以段落形式描述的端点"，准确率就上来了。
提示：dot 的提示词不要写得太长。我试过写一个 2000 字的提示词，结果 dot 的响应变得很慢，而且有时候会"忘记"其中的一些要求。后来精简到 500 字左右，效果反而更好。经验是：把复杂任务拆成多个 dots，而不是写一个巨长的提示词。
3.4 dots 的适用场景与不适用场景
dots 最适合的场景是重复性的、输入输出格式固定的任务。比如：
- 从邮件中提取会议邀请并创建日历事件
- 从客户反馈中分类情感倾向
- 从代码提交中生成变更日志
- 从财务报表中提取关键指标
不适合的场景是需要大量上下文理解的开放式任务。比如"帮我写一份商业计划书"这种任务，涉及大量的判断和创意，拆成 dots 反而会失去连贯性。这种任务还是直接用 ChatGPT 对话更合适。
4. ChatGPT Spaces：多人共享的 AI 工作空间
4.1 Spaces 解决的是什么问题
在团队里用 ChatGPT 的人应该都有这个痛点：每个人都有自己的对话历史、自己的自定义指令、自己的文件上传。当团队需要协作时，这些个人化的设置反而成了障碍——你没法把一段对话"分享"给同事继续，也没法让多个人在同一个上下文里工作。
ChatGPT Spaces 就是来解决这个问题的。它本质上是一个共享的对话空间，多个用户可以加入同一个 Space，看到相同的历史记录，共享相同的文件库，使用相同的自定义指令。而且 Space 里的对话是实时同步的——一个人发了消息，其他人立刻能看到。
我拉了两个同事做了一个测试：创建一个 Space，上传一份产品需求文档，然后三个人同时在里面提问、讨论、让 AI 生成方案。整个体验很流畅，没有出现消息冲突或同步延迟的问题。
4.2 Spaces 的权限模型
Spaces 的权限分三个层级：
| 角色 | 权限范围 |
|---|---|
| Owner | 管理 Space 设置、邀请/移除成员、删除 Space、配置自定义指令 |
| Editor | 发起对话、上传文件、修改共享文件、使用所有已配置的工具 |
| Viewer | 查看对话历史、查看文件、不能发起新对话或修改内容 |
这个权限模型比较清晰，但有一个细节需要注意：Editor 可以修改共享文件，而且修改是即时的。这意味着如果两个人同时编辑同一个文件，可能会出现覆盖。我建议在团队使用时，约定好"谁负责哪个文件"，避免冲突。
4.3 在 Spaces 里配置自定义指令
Spaces 的自定义指令是团队共享的，这一点和个人的自定义指令不同。配置的时候需要考虑团队的通用需求，而不是个人的偏好。
我的做法是分三层来写：
- 第一层：角色定义。告诉 AI 这个 Space 是做什么的，比如"这是一个产品团队的协作空间，主要处理需求分析、竞品调研和方案设计"。
- 第二层：输出规范。约定 AI 的输出格式，比如"所有方案输出必须包含背景、目标、具体步骤、风险点四个部分"。
- 第三层：禁忌事项。明确 AI 不应该做什么，比如"不要编造数据，如果信息不足请明确说明"。
这三层写下来大概 300 到 400 字，既足够具体，又不会太长导致 AI"记不住"。
4.4 Spaces 与 dots 的联动
Spaces 和 dots 是可以联动的。你可以在 Space 里配置一组常用的 dots，让所有成员都能直接调用。比如一个产品团队的 Space，可以配置"竞品分析 dot""用户反馈分类 dot""需求优先级排序 dot"。成员在对话中直接说"用竞品分析 dot 处理这份报告"，AI 就会调用对应的 dot。
这种联动的好处是把团队的最佳实践固化下来。新成员加入后，不需要学习复杂的提示词技巧，直接调用配置好的 dots 就能得到符合团队标准的输出。
5. Codex CLI：终端里的编码 Agent 实操
5.1 Codex CLI 的定位变化
Codex 这次从"实验性工具"变成了"正式产品"，最大的变化是登录方式改成了用 ChatGPT 账号直接登录。这意味着你不需要单独申请 API key，直接用现有的 ChatGPT 订阅就能用。对于已经在付费的用户来说，这降低了使用门槛。
安装方式还是通过 npm：
npm install -g @openai/codex安装完成后，运行codex命令，会提示你登录。选择"Sign in with ChatGPT"，浏览器会自动打开授权页面，确认后终端就登录成功了。
注意：如果你在 Windows 上遇到
missing optional dependency @openai/codex-win32-x64这个报错，说明 npm 没有正确安装平台相关的二进制依赖。解决办法是先卸载再重装：npm uninstall -g @openai/codex然后npm install -g @openai/codex。如果还是不行，检查一下 npm 的 registry 配置，有时候镜像源会导致可选依赖被跳过。
5.2 Codex CLI 的核心工作流
Codex CLI 的使用方式和普通的命令行工具不太一样，它更像是一个"对话式的编码助手"。你在终端里输入自然语言指令，它会在当前目录下执行操作——读文件、写文件、运行命令、解释代码。
我常用的几个场景：
场景一：快速理解一个陌生项目。进入项目目录，运行codex，然后输入"解释这个项目的结构，告诉我入口文件在哪里，主要模块之间是怎么调用的"。Codex 会扫描目录、读取关键文件，然后给出一个结构化的说明。
场景二：批量重构。输入"把所有使用var的地方改成const或let，根据是否重新赋值来判断"。Codex 会遍历文件、识别需要修改的地方、执行修改，并告诉你改了哪些文件。
场景三：生成测试。输入"为src/utils/下的所有函数生成单元测试，使用 Jest 框架"。Codex 会读取函数签名和实现，生成对应的测试文件。
5.3 Codex CLI 的权限与安全边界
Codex CLI 默认会在执行任何写操作之前征求你的确认。比如它要修改一个文件，会先显示 diff，问你"是否应用这个修改"。这个设计很重要，因为 AI 有时候会做出意料之外的修改。
你可以通过配置来调整这个行为。在~/.codex/config.json里，可以设置autoApprove选项来控制哪些操作需要确认、哪些可以直接执行。我的建议是：在陌生项目里保持默认的确认模式，在熟悉的项目里可以对读操作开启自动批准，但写操作始终保留确认。
另外，Codex CLI 有一个"沙箱模式"，可以限制它能访问的目录范围。如果你在一个包含敏感文件的项目里工作，建议开启沙箱模式，把 Codex 的访问范围限制在代码目录内。
5.4 与 dots 的配合使用
Codex CLI 可以直接调用 dots。比如你创建了一个"代码审查 dot"，在 Codex CLI 里输入"用代码审查 dot 检查当前分支的改动"，它就会调用那个 dot 来执行审查。
这种配合的价值在于把团队规范固化到 dot 里。比如团队的代码审查标准是"检查命名规范、检查错误处理、检查测试覆盖率"，这些规则写在 dot 的提示词里，所有人在 Codex CLI 里调用同一个 dot，就能得到一致的审查结果。
6. 20 多项发布里容易被忽略的几个细节
6.1 API 的批量调用优化
这次发布里有一个不太起眼但很实用的更新：Batch API 的最大批次大小从 50,000 请求提升到了 200,000 请求，而且处理速度提升了约 40%。对于需要跑大规模数据处理的任务来说，这个提升很实在。
我实测了一下，一个包含 10 万条文本分类任务的批次，之前需要大约 6 小时完成，现在缩短到了 3.5 小时左右。而且价格还是标准 API 的一半，性价比很高。
6.2 文件上传的格式支持扩展
ChatGPT 和 API 的文件上传现在支持更多格式了，包括.parquet、.avro和.feather这些数据科学常用的列式存储格式。这意味着你可以直接把数据文件丢给 AI 分析，不需要先转成 CSV。
我试了一下上传一个.parquet文件，AI 能正确识别 schema 并回答关于数据分布的问题。不过要注意，文件大小上限还是 512MB，超过的话需要分片。
6.3 函数调用的并行执行
函数调用（Function Calling）现在支持真正的并行执行了。之前如果你在一个请求里定义了多个函数，模型会按顺序调用；现在它可以同时调用多个函数，然后等所有结果返回后再继续。
这个变化对复杂工作流的性能提升很明显。我测试了一个需要同时查询三个数据源的场景，之前需要串行执行，总耗时约 4.5 秒；现在并行执行，总耗时降到了 1.8 秒左右。
6.4 使用量监控的细粒度提升
OpenAI 的使用量面板现在可以按 dot、按 Space、按项目来细分了。对于团队来说，这意味着可以更精确地追踪成本归属。我建议在团队使用前先设置好项目标签，这样后续的费用分摊会清晰很多。
7. 落地过程中容易踩的坑
7.1 dots 的权限配置容易过度授权
创建 dot 的时候，很多人为了省事会把所有权限都勾上。这是个坏习惯。我见过一个案例：一个"读取邮件"的 dot 被授予了"发送邮件"的权限，结果在测试时因为提示词里的一个歧义，它真的发了一封测试邮件出去。
正确的做法是最小权限原则：只给 dot 完成其职责所必需的权限。如果后来发现需要更多权限，再逐步添加。
7.2 Spaces 的文件同步有延迟
虽然 Spaces 的对话是实时同步的，但文件上传后的索引建立需要时间。我测试的时候，上传一个 50 页的 PDF，大约需要 30 秒到 1 分钟才能在对话中被引用。如果上传后立刻提问，AI 可能会说"找不到相关文件"。
解决办法是上传后等一会儿再提问，或者在提问时明确说"我刚上传了一份文件，请先确认你能看到它"。
7.3 Codex CLI 在大型项目里的性能问题
Codex CLI 在小型项目里很流畅，但在大型 monorepo 里会明显变慢。原因是它需要扫描目录结构来理解项目。我的经验是：在大型项目里，先用cd进入具体的子目录再启动 Codex，而不是在根目录启动。
另外，Codex CLI 默认会读取.gitignore来排除不需要扫描的文件。如果你的项目有特殊的目录结构，建议在.gitignore里补充规则，减少 Codex 的扫描范围。
7.4 GPT-6.1 Sol 的"过度推理"问题
Sol 在深度推理上很强，但有时候会"想太多"。比如一个简单的分类任务，它可能会在内部推理链里绕好几圈才给出答案。这不仅浪费 token，还增加了延迟。
我的应对方法是：在提示词里明确说"这是一个简单任务，请直接给出答案，不需要详细推理"。或者在 API 调用时设置reasoning_effort参数为low，限制它的推理深度。
7.5 混合使用多个模型时的上下文一致性问题
如果你在一个工作流里同时用了 Sol 和上一代模型，需要注意它们的输出风格可能不一致。Sol 的输出更详细、更结构化，上一代模型更简洁。如果下游程序对输出格式有严格要求，建议统一使用同一个模型，或者在中间加一层格式标准化处理。
8. 我个人的使用建议与后续观察方向
用了这一整套新东西大概一周之后，我最大的体会是：OpenAI 这次的核心思路是"分层"。模型层（Sol）负责深度推理，Agent 层（dots）负责具体任务执行，协作层（Spaces）负责团队共享，工具层（Codex CLI）负责终端集成。每一层都有清晰的边界和接口，你可以按需组合。
对于个人开发者，我建议先从 Codex CLI 入手，因为它最容易上手，而且能立刻提升编码效率。然后尝试创建一两个简单的 dots，体验一下"把任务封装成组件"的思路。最后再考虑 Spaces，因为它更适合团队场景。
对于团队，我建议先在一个小范围内试点 Spaces，把团队的常用工作流配置成 dots，观察一段时间后再推广。不要一上来就全团队铺开，因为权限管理和成本控制都需要时间磨合。
后续我会重点观察几个方向：dots 的生态会不会开放（比如允许第三方发布 dots）、Spaces 会不会支持跨组织协作、Sol 的推理能力会不会下放到更便宜的模型层级。这些变化会直接影响我们怎么设计下一代的 AI 工作流。
最后分享一个小技巧：在配置任何新功能之前，先花 10 分钟把官方文档里的"限制"部分读一遍。OpenAI 的文档写得很详细，但限制条件往往藏在不起眼的角落。我踩过的几个坑，事后发现文档里其实都写了，只是我没注意到。
