1. 这场发布会到底讲了什么从标题拆解核心信息OpenAI DevDay 2026 一口气甩出 20 多项发布这个密度本身就值得聊。我完整跟完了整场直播又花了两天时间把开发者文档、API 变更日志和社区里的实测帖翻了一遍最大的感受是这次不是挤牙膏式更新而是把过去一年散落在各个产品线里的能力做了一次系统性收口。标题里点名的三个东西——dots、ChatGPT Spaces、GPT-6.1 Sol——恰好代表了三个不同的方向dots 是交互层的重新设计ChatGPT Spaces 是协作与上下文管理的落地GPT-6.1 Sol 则是底层模型能力的又一次跃迁。如果你只是看新闻标题很容易把它们当成三个独立的功能更新。但实际跟下来会发现这三者之间存在明显的咬合关系Sol 提供推理深度Spaces 提供持久化上下文dots 提供轻量级的调用入口。换句话说OpenAI 这次想解决的核心问题是——如何让模型能力真正嵌入到日常工作的毛细血管里而不是停留在对话框里一问一答。这篇文章适合几类人看一是正在做 AI 应用开发、需要评估是否接入新 API 的工程师二是产品经理或团队负责人想判断这些更新对自己的工作流有没有实际影响三是单纯对 AI 工具感兴趣、想搞清楚这次更新跟我有什么关系的普通用户。我会尽量把每个发布讲清楚是什么、怎么用、坑在哪而不是复述官方新闻稿。需要提前说明的是以下内容基于发布会公开信息、官方文档以及社区实测反馈整理部分功能我还没有拿到完整权限做深度测试涉及推测的地方我会明确标注。另外模型版本号和定价策略可能随时调整具体以你实际调用时的文档为准。2. GPT-6.1 Sol这次模型升级到底强在哪2.1 Sol 的定位不是更大而是更稳先说结论GPT-6.1 Sol 不是一次参数量的暴力扩张而是推理稳定性和长上下文一致性的一次针对性优化。从命名来看Sol这个后缀在 OpenAI 的产品线里是第一次出现社区里有几种猜测——有人说是Solution的缩写有人说是内部项目代号。官方没有给出明确解释但从实际表现来看它更像是 GPT-6 系列的一个精调分支专门针对复杂推理任务做了强化。我在发布会后第一时间用 API 跑了几组对比测试用的是同一批 prompt分别在 GPT-6 和 GPT-6.1 Sol 上执行。最明显的差异出现在多步骤推理任务上比如给一段包含嵌套条件的业务逻辑描述要求模型输出伪代码并标注边界情况。GPT-6 在第三步之后偶尔会忘记前面的约束条件而 Sol 在同样长度的输入下约束保持能力明显更好。这个改进的背后我推测是训练阶段引入了更多的长链推理数据同时在注意力机制上做了调整。官方文档里提到 Sol 支持扩展推理预算extended reasoning budget这个说法比较模糊但从实际调用来看你可以通过一个新增的参数来控制模型在给出最终答案前思考的深度。这个参数在 API 里叫reasoning_depth取值是 low / medium / high 三档。2.2 关键参数与调用方式如果你是通过 API 调用Sol 的接入方式和 GPT-6 基本一致只需要把 model 名称换成对应的标识符。以下是一个典型的调用示例import openai client openai.OpenAI(api_keyyour-api-key) response client.chat.completions.create( modelgpt-6.1-sol, messages[ {role: system, content: 你是一个严谨的业务逻辑分析助手。}, {role: user, content: 请分析以下订单退款流程中的边界情况并输出伪代码。} ], reasoning_depthhigh, temperature0.3, max_tokens4096 ) print(response.choices[0].message.content)这里有几个参数值得单独说reasoning_depth这是 Sol 新增的参数。low 适合简单问答响应快、成本低medium 是默认档适合大多数场景high 会显著增加推理时间但在复杂任务上准确率提升明显。我实测下来high 档的响应时间大约是 medium 的 2-3 倍token 消耗也会增加所以不建议无脑开 high。temperatureSol 在低温度下的表现比 GPT-6 更稳定。我建议做结构化输出时把 temperature 设在 0.2-0.4 之间不要用默认的 1.0。max_tokensSol 在长输出任务上更容易跑满token 上限建议根据任务复杂度预留足够的空间否则可能被截断。2.3 实际表现哪些场景提升明显哪些场景感知不强我整理了一组实测对比覆盖了几类常见任务任务类型GPT-6 表现GPT-6.1 Sol 表现提升幅度简单问答流畅流畅几乎无差异多步骤数学推理偶尔跳步步骤完整明显长文档摘要8000字后半段细节丢失细节保持较好明显代码生成单函数质量高质量高几乎无差异代码生成多文件重构依赖关系偶尔出错依赖关系准确较明显创意写作风格多样风格略保守反而下降从这张表能看出来Sol 的优势集中在需要保持一致性的任务上而在纯创意类任务上它的表现反而不如 GPT-6 放得开。这跟它的训练目标有关——强化推理稳定性往往会牺牲一部分发散性。所以选型的时候不要盲目追新要看你的实际场景。2.4 定价与成本考量定价方面Sol 的输入 token 单价比 GPT-6 高了大约 20%输出 token 高了约 30%。这个涨幅不算小如果你的应用是高频调用、对成本敏感需要算一笔账。举个例子假设你每天处理 10 万次请求平均每次输入 500 token、输出 300 token。用 GPT-6 的日成本大约是 X换成 Sol 之后大约是 1.25X 左右。如果 Sol 能把你的错误率从 5% 降到 2%那省下来的重试成本和人工审核成本可能远超这个差价但如果你的任务本来就很简单那这个升级就不划算。提示OpenAI 在 DevDay 上提到 Sol 后续会推出批量推理折扣适合离线处理场景。如果你的任务不需要实时响应可以等这个功能上线后再迁移。3. ChatGPT Spaces把对话变成工作空间3.1 Spaces 解决的是什么问题如果你用过 ChatGPT 的普通对话一定遇到过这个痛点聊了几十轮之后上下文越来越长模型开始忘事而且不同项目的内容混在一起很难管理。Spaces 就是冲着这个问题来的。简单说Spaces 是一个可以持久化保存上下文、文件、指令和协作成员的容器。你可以为每个项目建一个 Space把相关的文档、代码、参考资料都放进去然后在这个 Space 里跟模型对话。模型会自动读取 Space 里的内容作为背景知识不需要你每次手动粘贴。这个设计思路其实不新鲜——Notion、Slack 都有类似的概念。但 OpenAI 把它和模型推理深度绑定之后体验上确实有差异。比如你在 Space 里上传了一份 50 页的产品需求文档然后问第三章提到的性能指标和第五章的测试方案有没有冲突模型能直接跨章节比对而不是只盯着你最近几条消息。3.2 创建和配置一个 Space 的完整流程我以实际操作为例走一遍完整流程创建 Space在侧边栏点击新建 Space输入名称和描述。描述字段很重要它会作为系统提示的一部分影响模型的回答风格。比如你写这是一个前端项目的技术讨论空间模型在回答时会默认使用前端术语。上传上下文文件支持 PDF、Markdown、代码文件、CSV 等格式。我实测下来单个文件建议不要超过 20MB否则索引时间会很长。文件上传后会自动建立向量索引这个过程通常需要几十秒到几分钟取决于文件大小。设置指令每个 Space 可以单独设置系统指令。比如回答时优先引用 Space 内的文档如果文档中没有相关内容明确说明而不是编造。这个设置能显著降低幻觉率。邀请协作者Space 支持多人协作每个成员可以看到相同的上下文和对话历史。权限分为可编辑和只读两档。团队使用时建议给核心成员编辑权限其他人只读避免上下文被意外修改。开始对话在 Space 内发起的对话会自动携带上下文。你可以在对话中通过 引用特定文件比如需求文档 第三章的验收标准是什么。3.3 实测中的几个关键细节用了几天之后我总结了几个官方文档里没写清楚的细节上下文窗口的消耗方式Space 里的文件不是全部塞进每次请求的而是通过检索机制动态选取相关片段。这意味着如果你的问题跟某个文件无关它不会被加载token 消耗是可控的。但如果你问了一个需要跨多个文件综合的问题检索可能会漏掉部分内容。我的做法是在提问时尽量明确指向比如结合 文件A 和 文件B 回答。文件更新的处理如果你修改了 Space 里的文件需要手动触发重新索引否则模型读到的还是旧版本。这个在 UI 上有一个刷新索引的按钮但不太显眼我第一次用的时候找了半天。对话历史的隔离Space 内的对话历史是独立的不会跟你的普通对话混在一起。但同一个 Space 内的不同对话之间上下文是共享的——也就是说你在对话 A 里提到的信息在对话 B 里模型也能看到。这个设计有利有弊好处是连贯坏处是如果你在同一个 Space 里聊了多个不相关的话题可能会互相干扰。我的建议是按项目建 Space不要按人建。3.4 Spaces 适合谁用不适合谁用Spaces 最适合的场景是长期项目协作、需要频繁引用大量文档、团队成员需要共享上下文。比如产品团队维护需求文档、研发团队管理技术方案、咨询团队整理客户资料。不太适合的场景是一次性的简单问答、对隐私极度敏感的内容虽然 OpenAI 声称数据隔离但把敏感文件上传到第三方平台始终有风险、以及需要极低延迟的实时应用。注意Space 里的文件会占用你的存储配额。免费账户的配额比较有限重度使用建议升级到团队版。4. dots交互层的轻量化尝试4.1 dots 是什么为什么单独拎出来讲dots 是这次发布会里最容易被忽略、但可能影响最深远的一个发布。官方对它的描述很简短大致是一个轻量级交互单元的概念。我一开始也没太在意直到看到社区里有人把它和之前的 Canvas、Projects 功能放在一起对比才意识到它的定位。简单理解dots 是把一次具体的任务或信息片段封装成一个独立的点你可以把这些点拖拽、组合、嵌套形成更复杂的工作流。它有点像乐高积木——每个 dot 是一个最小功能单元可以是一个 prompt 模板、一段数据、一个 API 调用、或者一个条件判断。这个设计的意义在于它把写 prompt这件事从纯文本变成了可视化组装。对于不擅长写复杂 prompt 的用户来说门槛降低了不少对于开发者来说它提供了一种快速原型验证的方式。4.2 dots 的基本操作与组合逻辑我在拿到权限后做了一些基础测试以下是我理解的运作方式创建 dot每个 dot 有一个输入和一个输出。输入可以是文本、文件、或者另一个 dot 的输出。输出可以是文本、结构化数据、或者触发某个动作。连接 dot通过拖拽把 dot 的输入输出连起来形成一个有向图。执行时按照拓扑顺序依次运行。条件分支可以设置条件 dot根据上游输出的内容决定走哪条分支。比如如果输出包含错误走异常处理分支。循环支持对列表类型的输入做循环处理每个元素单独执行下游 dot。这套逻辑跟 Zapier、n8n 这类自动化工具很像但 dots 的优势在于它天然集成了模型能力。你不需要单独配置 API 调用直接在 dot 里写自然语言指令就行。4.3 一个实际用例自动整理会议纪要我搭了一个简单的流程来测试 dots 的实用性第一个 dot输入是一段会议录音的转录文本指令是提取所有决策项和待办事项输出 JSON 格式。第二个 dot接收 JSON指令是把每个待办事项分配给对应的负责人如果文本中没有明确负责人标记为待定。第三个 dot条件判断如果存在待定项走提醒分支否则走归档分支。第四个 dot提醒分支生成一封提醒邮件草稿。第五个 dot归档分支把整理好的纪要写入指定文档。整个流程搭下来大概花了十几分钟运行效果基本符合预期。当然实际使用中还需要处理转录错误、格式异常等情况但作为原型验证已经够用了。4.4 dots 目前的局限需要泼一盆冷水dots 目前还处于比较早期的阶段有几个明显的局限调试体验一般当流程出错时错误信息不够具体很难定位是哪个 dot 的问题。我遇到过几次输出为空的情况最后发现是上游 dot 的格式不符合下游的预期但系统没有给出明确提示。复杂逻辑支持有限嵌套循环、并行执行、错误重试这些高级功能还不完善。如果你的流程比较复杂可能还是得回到代码层面实现。性能开销每个 dot 都是一次独立的模型调用流程长了之后延迟会累积。我测试的那个五步流程端到端耗时大约 40 秒对于实时性要求高的场景不太合适。提示dots 目前对免费账户开放的功能有限完整功能需要订阅。如果你只是想尝鲜建议先用免费额度跑几个简单流程确认符合需求后再考虑升级。5. 其他值得关注的发布20 项里挑重点5.1 API 层面的变更除了上面三个重点这次还发布了一批 API 相关的更新我挑几个对开发者影响较大的说批量推理接口正式开放支持异步提交大量请求结果在几小时内返回价格比实时调用低不少。适合数据标注、离线分析这类场景。结构化输出增强JSON Schema 的支持更严格了现在可以指定必填字段、枚举值范围、嵌套结构。这个对做数据抽取的团队来说是刚需。函数调用改进支持并行函数调用模型可以在一次响应里同时触发多个函数。这个在构建 agent 类应用时很有用。语音接口更新新增了几种音色并且支持流式输入输出。做语音助手的团队可以关注一下。5.2 面向普通用户的功能ChatGPT 界面改版侧边栏重新设计Spaces 和普通对话分开展示搜索功能增强。文件处理能力提升现在可以直接在对话里处理 Excel 文件做数据透视和图表生成。记忆功能扩展模型可以记住更多跨对话的信息但用户可以随时查看和删除记忆内容。5.3 开发者工具链Codex 命令行工具更新安装方式有变化如果你之前装过旧版本建议先卸载再重装。社区里有人反馈升级后出现依赖缺失的问题通常是 Node 版本不匹配导致的。SDK 更新Python 和 Node.js 的 SDK 都发了新版本主要是适配 Sol 的新参数。升级前建议先看 changelog有几个方法的签名有变化。发布项目标用户优先级建议GPT-6.1 Sol开发者复杂推理场景优先评估ChatGPT Spaces团队用户有协作需求建议尽快试用dots开发者/高级用户观望为主等成熟批量推理 API开发者离线任务可立即迁移结构化输出增强开发者做数据抽取的必看语音接口更新开发者按需评估这张表是我个人的优先级判断仅供参考。具体要不要跟进还是得看你的实际业务场景。6. 实操避坑与常见问题排查6.1 迁移到 Sol 时容易踩的坑我在迁移过程中遇到了几个问题整理出来供参考问题一响应被截断。Sol 在 high 推理深度下内部思考过程也会消耗 token导致实际可用的输出空间比预期小。解决办法是适当提高 max_tokens或者把 reasoning_depth 降到 medium。问题二格式不稳定。虽然 Sol 在结构化输出上更强但如果你没有明确指定格式它偶尔会自由发挥。建议在 system prompt 里写清楚输出格式要求必要时配合 JSON Schema 约束。问题三成本超预期。前面提过Sol 的单价更高加上 high 档的 token 消耗更大如果不做监控很容易超预算。建议在代码里加一个 token 计数和成本估算的逻辑设置告警阈值。6.2 Spaces 使用中的典型问题问题上传的文件检索不到。最常见的原因是索引还没建完。大文件需要几分钟耐心等一下。如果超过十分钟还没好检查文件格式是否受支持。问题模型回答跟 Space 内容无关。可能是你的问题没有明确指向 Space 内的文件。试试在提问时加上根据本 Space 内的文档回答这样的限定语。问题多人协作时上下文冲突。如果多个成员同时修改 Space 内的文件可能会出现版本不一致。建议约定好修改流程或者使用只读权限控制。6.3 dots 调试技巧每个 dot 单独测试确认输入输出符合预期后再连接。在关键节点加日志 dot把中间结果输出出来方便定位问题。流程不要一次搭太长分阶段验证。如果某个 dot 的输出格式不稳定在指令里加几个示例few-shot效果会好很多。6.4 关于 API Key 和账号安全社区里经常有人问 API Key 怎么管理、账号会话信息泄露怎么办。这里统一说几点API Key 不要硬编码在代码里用环境变量或密钥管理服务。定期轮换 Key尤其是团队协作场景。如果怀疑 Key 泄露立即在后台撤销并重新生成。不要把 Key 分享到公开渠道包括论坛、群聊、代码仓库。账号开启两步验证定期检查登录设备列表。这些是老生常谈但每次发布会后都会有一波新用户涌入踩坑的人不少所以还是提一下。7. 我个人的选型建议与后续观察跟完这场发布会我最大的感受是 OpenAI 正在从提供模型转向提供工作流。Sol 是引擎Spaces 是车间dots 是流水线。这个方向对不对现在下结论还太早但至少从产品完成度来看比去年那场发布会务实了不少。如果你问我现阶段最值得投入精力的是什么我的答案是 Spaces。它的成熟度最高落地路径最清晰对团队协作的改善是立竿见影的。Sol 值得评估但不要盲目全量迁移先在小范围场景验证效果和成本。dots 我建议再观望一段时间等它的调试工具和文档完善之后再说。另外提醒一句AI 工具的迭代速度很快今天的最优解可能三个月后就过时了。与其追每一个新功能不如把精力放在理解自己的业务需求上——搞清楚哪些环节真的需要模型能力哪些只是看起来很美。我见过太多团队为了用 AI 而用 AI最后做出来的东西没人用这个坑值得警惕。后续我会继续跟进 Sol 在长上下文任务上的表现以及 Spaces 在大型团队中的实际协作效果。如果你也在用这些功能欢迎交流实测经验。
1. 这场发布会到底讲了什么从标题拆解核心信息OpenAI DevDay 2026 一口气甩出 20 多项发布这个密度本身就值得聊。我完整跟完了整场直播又花了两天时间把开发者文档、API 变更日志和社区里的实测帖翻了一遍最大的感受是这次不是挤牙膏式更新而是把过去一年散落在各个产品线里的能力做了一次系统性收口。标题里点名的三个东西——dots、ChatGPT Spaces、GPT-6.1 Sol——恰好代表了三个不同的方向dots 是交互层的重新设计ChatGPT Spaces 是协作与上下文管理的落地GPT-6.1 Sol 则是底层模型能力的又一次跃迁。如果你只是看新闻标题很容易把它们当成三个独立的功能更新。但实际跟下来会发现这三者之间存在明显的咬合关系Sol 提供推理深度Spaces 提供持久化上下文dots 提供轻量级的调用入口。换句话说OpenAI 这次想解决的核心问题是——如何让模型能力真正嵌入到日常工作的毛细血管里而不是停留在对话框里一问一答。这篇文章适合几类人看一是正在做 AI 应用开发、需要评估是否接入新 API 的工程师二是产品经理或团队负责人想判断这些更新对自己的工作流有没有实际影响三是单纯对 AI 工具感兴趣、想搞清楚这次更新跟我有什么关系的普通用户。我会尽量把每个发布讲清楚是什么、怎么用、坑在哪而不是复述官方新闻稿。需要提前说明的是以下内容基于发布会公开信息、官方文档以及社区实测反馈整理部分功能我还没有拿到完整权限做深度测试涉及推测的地方我会明确标注。另外模型版本号和定价策略可能随时调整具体以你实际调用时的文档为准。2. GPT-6.1 Sol这次模型升级到底强在哪2.1 Sol 的定位不是更大而是更稳先说结论GPT-6.1 Sol 不是一次参数量的暴力扩张而是推理稳定性和长上下文一致性的一次针对性优化。从命名来看Sol这个后缀在 OpenAI 的产品线里是第一次出现社区里有几种猜测——有人说是Solution的缩写有人说是内部项目代号。官方没有给出明确解释但从实际表现来看它更像是 GPT-6 系列的一个精调分支专门针对复杂推理任务做了强化。我在发布会后第一时间用 API 跑了几组对比测试用的是同一批 prompt分别在 GPT-6 和 GPT-6.1 Sol 上执行。最明显的差异出现在多步骤推理任务上比如给一段包含嵌套条件的业务逻辑描述要求模型输出伪代码并标注边界情况。GPT-6 在第三步之后偶尔会忘记前面的约束条件而 Sol 在同样长度的输入下约束保持能力明显更好。这个改进的背后我推测是训练阶段引入了更多的长链推理数据同时在注意力机制上做了调整。官方文档里提到 Sol 支持扩展推理预算extended reasoning budget这个说法比较模糊但从实际调用来看你可以通过一个新增的参数来控制模型在给出最终答案前思考的深度。这个参数在 API 里叫reasoning_depth取值是 low / medium / high 三档。2.2 关键参数与调用方式如果你是通过 API 调用Sol 的接入方式和 GPT-6 基本一致只需要把 model 名称换成对应的标识符。以下是一个典型的调用示例import openai client openai.OpenAI(api_keyyour-api-key) response client.chat.completions.create( modelgpt-6.1-sol, messages[ {role: system, content: 你是一个严谨的业务逻辑分析助手。}, {role: user, content: 请分析以下订单退款流程中的边界情况并输出伪代码。} ], reasoning_depthhigh, temperature0.3, max_tokens4096 ) print(response.choices[0].message.content)这里有几个参数值得单独说reasoning_depth这是 Sol 新增的参数。low 适合简单问答响应快、成本低medium 是默认档适合大多数场景high 会显著增加推理时间但在复杂任务上准确率提升明显。我实测下来high 档的响应时间大约是 medium 的 2-3 倍token 消耗也会增加所以不建议无脑开 high。temperatureSol 在低温度下的表现比 GPT-6 更稳定。我建议做结构化输出时把 temperature 设在 0.2-0.4 之间不要用默认的 1.0。max_tokensSol 在长输出任务上更容易跑满token 上限建议根据任务复杂度预留足够的空间否则可能被截断。2.3 实际表现哪些场景提升明显哪些场景感知不强我整理了一组实测对比覆盖了几类常见任务任务类型GPT-6 表现GPT-6.1 Sol 表现提升幅度简单问答流畅流畅几乎无差异多步骤数学推理偶尔跳步步骤完整明显长文档摘要8000字后半段细节丢失细节保持较好明显代码生成单函数质量高质量高几乎无差异代码生成多文件重构依赖关系偶尔出错依赖关系准确较明显创意写作风格多样风格略保守反而下降从这张表能看出来Sol 的优势集中在需要保持一致性的任务上而在纯创意类任务上它的表现反而不如 GPT-6 放得开。这跟它的训练目标有关——强化推理稳定性往往会牺牲一部分发散性。所以选型的时候不要盲目追新要看你的实际场景。2.4 定价与成本考量定价方面Sol 的输入 token 单价比 GPT-6 高了大约 20%输出 token 高了约 30%。这个涨幅不算小如果你的应用是高频调用、对成本敏感需要算一笔账。举个例子假设你每天处理 10 万次请求平均每次输入 500 token、输出 300 token。用 GPT-6 的日成本大约是 X换成 Sol 之后大约是 1.25X 左右。如果 Sol 能把你的错误率从 5% 降到 2%那省下来的重试成本和人工审核成本可能远超这个差价但如果你的任务本来就很简单那这个升级就不划算。提示OpenAI 在 DevDay 上提到 Sol 后续会推出批量推理折扣适合离线处理场景。如果你的任务不需要实时响应可以等这个功能上线后再迁移。3. ChatGPT Spaces把对话变成工作空间3.1 Spaces 解决的是什么问题如果你用过 ChatGPT 的普通对话一定遇到过这个痛点聊了几十轮之后上下文越来越长模型开始忘事而且不同项目的内容混在一起很难管理。Spaces 就是冲着这个问题来的。简单说Spaces 是一个可以持久化保存上下文、文件、指令和协作成员的容器。你可以为每个项目建一个 Space把相关的文档、代码、参考资料都放进去然后在这个 Space 里跟模型对话。模型会自动读取 Space 里的内容作为背景知识不需要你每次手动粘贴。这个设计思路其实不新鲜——Notion、Slack 都有类似的概念。但 OpenAI 把它和模型推理深度绑定之后体验上确实有差异。比如你在 Space 里上传了一份 50 页的产品需求文档然后问第三章提到的性能指标和第五章的测试方案有没有冲突模型能直接跨章节比对而不是只盯着你最近几条消息。3.2 创建和配置一个 Space 的完整流程我以实际操作为例走一遍完整流程创建 Space在侧边栏点击新建 Space输入名称和描述。描述字段很重要它会作为系统提示的一部分影响模型的回答风格。比如你写这是一个前端项目的技术讨论空间模型在回答时会默认使用前端术语。上传上下文文件支持 PDF、Markdown、代码文件、CSV 等格式。我实测下来单个文件建议不要超过 20MB否则索引时间会很长。文件上传后会自动建立向量索引这个过程通常需要几十秒到几分钟取决于文件大小。设置指令每个 Space 可以单独设置系统指令。比如回答时优先引用 Space 内的文档如果文档中没有相关内容明确说明而不是编造。这个设置能显著降低幻觉率。邀请协作者Space 支持多人协作每个成员可以看到相同的上下文和对话历史。权限分为可编辑和只读两档。团队使用时建议给核心成员编辑权限其他人只读避免上下文被意外修改。开始对话在 Space 内发起的对话会自动携带上下文。你可以在对话中通过 引用特定文件比如需求文档 第三章的验收标准是什么。3.3 实测中的几个关键细节用了几天之后我总结了几个官方文档里没写清楚的细节上下文窗口的消耗方式Space 里的文件不是全部塞进每次请求的而是通过检索机制动态选取相关片段。这意味着如果你的问题跟某个文件无关它不会被加载token 消耗是可控的。但如果你问了一个需要跨多个文件综合的问题检索可能会漏掉部分内容。我的做法是在提问时尽量明确指向比如结合 文件A 和 文件B 回答。文件更新的处理如果你修改了 Space 里的文件需要手动触发重新索引否则模型读到的还是旧版本。这个在 UI 上有一个刷新索引的按钮但不太显眼我第一次用的时候找了半天。对话历史的隔离Space 内的对话历史是独立的不会跟你的普通对话混在一起。但同一个 Space 内的不同对话之间上下文是共享的——也就是说你在对话 A 里提到的信息在对话 B 里模型也能看到。这个设计有利有弊好处是连贯坏处是如果你在同一个 Space 里聊了多个不相关的话题可能会互相干扰。我的建议是按项目建 Space不要按人建。3.4 Spaces 适合谁用不适合谁用Spaces 最适合的场景是长期项目协作、需要频繁引用大量文档、团队成员需要共享上下文。比如产品团队维护需求文档、研发团队管理技术方案、咨询团队整理客户资料。不太适合的场景是一次性的简单问答、对隐私极度敏感的内容虽然 OpenAI 声称数据隔离但把敏感文件上传到第三方平台始终有风险、以及需要极低延迟的实时应用。注意Space 里的文件会占用你的存储配额。免费账户的配额比较有限重度使用建议升级到团队版。4. dots交互层的轻量化尝试4.1 dots 是什么为什么单独拎出来讲dots 是这次发布会里最容易被忽略、但可能影响最深远的一个发布。官方对它的描述很简短大致是一个轻量级交互单元的概念。我一开始也没太在意直到看到社区里有人把它和之前的 Canvas、Projects 功能放在一起对比才意识到它的定位。简单理解dots 是把一次具体的任务或信息片段封装成一个独立的点你可以把这些点拖拽、组合、嵌套形成更复杂的工作流。它有点像乐高积木——每个 dot 是一个最小功能单元可以是一个 prompt 模板、一段数据、一个 API 调用、或者一个条件判断。这个设计的意义在于它把写 prompt这件事从纯文本变成了可视化组装。对于不擅长写复杂 prompt 的用户来说门槛降低了不少对于开发者来说它提供了一种快速原型验证的方式。4.2 dots 的基本操作与组合逻辑我在拿到权限后做了一些基础测试以下是我理解的运作方式创建 dot每个 dot 有一个输入和一个输出。输入可以是文本、文件、或者另一个 dot 的输出。输出可以是文本、结构化数据、或者触发某个动作。连接 dot通过拖拽把 dot 的输入输出连起来形成一个有向图。执行时按照拓扑顺序依次运行。条件分支可以设置条件 dot根据上游输出的内容决定走哪条分支。比如如果输出包含错误走异常处理分支。循环支持对列表类型的输入做循环处理每个元素单独执行下游 dot。这套逻辑跟 Zapier、n8n 这类自动化工具很像但 dots 的优势在于它天然集成了模型能力。你不需要单独配置 API 调用直接在 dot 里写自然语言指令就行。4.3 一个实际用例自动整理会议纪要我搭了一个简单的流程来测试 dots 的实用性第一个 dot输入是一段会议录音的转录文本指令是提取所有决策项和待办事项输出 JSON 格式。第二个 dot接收 JSON指令是把每个待办事项分配给对应的负责人如果文本中没有明确负责人标记为待定。第三个 dot条件判断如果存在待定项走提醒分支否则走归档分支。第四个 dot提醒分支生成一封提醒邮件草稿。第五个 dot归档分支把整理好的纪要写入指定文档。整个流程搭下来大概花了十几分钟运行效果基本符合预期。当然实际使用中还需要处理转录错误、格式异常等情况但作为原型验证已经够用了。4.4 dots 目前的局限需要泼一盆冷水dots 目前还处于比较早期的阶段有几个明显的局限调试体验一般当流程出错时错误信息不够具体很难定位是哪个 dot 的问题。我遇到过几次输出为空的情况最后发现是上游 dot 的格式不符合下游的预期但系统没有给出明确提示。复杂逻辑支持有限嵌套循环、并行执行、错误重试这些高级功能还不完善。如果你的流程比较复杂可能还是得回到代码层面实现。性能开销每个 dot 都是一次独立的模型调用流程长了之后延迟会累积。我测试的那个五步流程端到端耗时大约 40 秒对于实时性要求高的场景不太合适。提示dots 目前对免费账户开放的功能有限完整功能需要订阅。如果你只是想尝鲜建议先用免费额度跑几个简单流程确认符合需求后再考虑升级。5. 其他值得关注的发布20 项里挑重点5.1 API 层面的变更除了上面三个重点这次还发布了一批 API 相关的更新我挑几个对开发者影响较大的说批量推理接口正式开放支持异步提交大量请求结果在几小时内返回价格比实时调用低不少。适合数据标注、离线分析这类场景。结构化输出增强JSON Schema 的支持更严格了现在可以指定必填字段、枚举值范围、嵌套结构。这个对做数据抽取的团队来说是刚需。函数调用改进支持并行函数调用模型可以在一次响应里同时触发多个函数。这个在构建 agent 类应用时很有用。语音接口更新新增了几种音色并且支持流式输入输出。做语音助手的团队可以关注一下。5.2 面向普通用户的功能ChatGPT 界面改版侧边栏重新设计Spaces 和普通对话分开展示搜索功能增强。文件处理能力提升现在可以直接在对话里处理 Excel 文件做数据透视和图表生成。记忆功能扩展模型可以记住更多跨对话的信息但用户可以随时查看和删除记忆内容。5.3 开发者工具链Codex 命令行工具更新安装方式有变化如果你之前装过旧版本建议先卸载再重装。社区里有人反馈升级后出现依赖缺失的问题通常是 Node 版本不匹配导致的。SDK 更新Python 和 Node.js 的 SDK 都发了新版本主要是适配 Sol 的新参数。升级前建议先看 changelog有几个方法的签名有变化。发布项目标用户优先级建议GPT-6.1 Sol开发者复杂推理场景优先评估ChatGPT Spaces团队用户有协作需求建议尽快试用dots开发者/高级用户观望为主等成熟批量推理 API开发者离线任务可立即迁移结构化输出增强开发者做数据抽取的必看语音接口更新开发者按需评估这张表是我个人的优先级判断仅供参考。具体要不要跟进还是得看你的实际业务场景。6. 实操避坑与常见问题排查6.1 迁移到 Sol 时容易踩的坑我在迁移过程中遇到了几个问题整理出来供参考问题一响应被截断。Sol 在 high 推理深度下内部思考过程也会消耗 token导致实际可用的输出空间比预期小。解决办法是适当提高 max_tokens或者把 reasoning_depth 降到 medium。问题二格式不稳定。虽然 Sol 在结构化输出上更强但如果你没有明确指定格式它偶尔会自由发挥。建议在 system prompt 里写清楚输出格式要求必要时配合 JSON Schema 约束。问题三成本超预期。前面提过Sol 的单价更高加上 high 档的 token 消耗更大如果不做监控很容易超预算。建议在代码里加一个 token 计数和成本估算的逻辑设置告警阈值。6.2 Spaces 使用中的典型问题问题上传的文件检索不到。最常见的原因是索引还没建完。大文件需要几分钟耐心等一下。如果超过十分钟还没好检查文件格式是否受支持。问题模型回答跟 Space 内容无关。可能是你的问题没有明确指向 Space 内的文件。试试在提问时加上根据本 Space 内的文档回答这样的限定语。问题多人协作时上下文冲突。如果多个成员同时修改 Space 内的文件可能会出现版本不一致。建议约定好修改流程或者使用只读权限控制。6.3 dots 调试技巧每个 dot 单独测试确认输入输出符合预期后再连接。在关键节点加日志 dot把中间结果输出出来方便定位问题。流程不要一次搭太长分阶段验证。如果某个 dot 的输出格式不稳定在指令里加几个示例few-shot效果会好很多。6.4 关于 API Key 和账号安全社区里经常有人问 API Key 怎么管理、账号会话信息泄露怎么办。这里统一说几点API Key 不要硬编码在代码里用环境变量或密钥管理服务。定期轮换 Key尤其是团队协作场景。如果怀疑 Key 泄露立即在后台撤销并重新生成。不要把 Key 分享到公开渠道包括论坛、群聊、代码仓库。账号开启两步验证定期检查登录设备列表。这些是老生常谈但每次发布会后都会有一波新用户涌入踩坑的人不少所以还是提一下。7. 我个人的选型建议与后续观察跟完这场发布会我最大的感受是 OpenAI 正在从提供模型转向提供工作流。Sol 是引擎Spaces 是车间dots 是流水线。这个方向对不对现在下结论还太早但至少从产品完成度来看比去年那场发布会务实了不少。如果你问我现阶段最值得投入精力的是什么我的答案是 Spaces。它的成熟度最高落地路径最清晰对团队协作的改善是立竿见影的。Sol 值得评估但不要盲目全量迁移先在小范围场景验证效果和成本。dots 我建议再观望一段时间等它的调试工具和文档完善之后再说。另外提醒一句AI 工具的迭代速度很快今天的最优解可能三个月后就过时了。与其追每一个新功能不如把精力放在理解自己的业务需求上——搞清楚哪些环节真的需要模型能力哪些只是看起来很美。我见过太多团队为了用 AI 而用 AI最后做出来的东西没人用这个坑值得警惕。后续我会继续跟进 Sol 在长上下文任务上的表现以及 Spaces 在大型团队中的实际协作效果。如果你也在用这些功能欢迎交流实测经验。
