1. 从DevDay 2026的发布清单说起这次到底更新了什么OpenAI DevDay 2026 一口气甩出了 20 多项发布密度高到我在看直播回放的时候不得不暂停好几次做笔记。核心的几个大件是 dots、ChatGPT Spaces 和 GPT-6.1 Sol。如果你只扫了一眼新闻标题可能会觉得又是一堆新名词但真正把发布内容拆开看会发现这次的主线其实非常清晰OpenAI 在把 ChatGPT 从一个对话工具往工作空间方向推同时把开发者侧的 Agent 能力做了一次系统性的收口。先说 dots。dots 是这次发布里最容易被误读的一个东西。很多人第一反应是这不就是个新的模型代号吗但从现场演示和后续文档来看dots 更像是一个轻量级的结构化信息单元——你可以把它理解成 ChatGPT 内部用来承载一个可复用的知识片段或任务片段的容器。它可以是文本、可以是一段配置、可以是一个带参数的动作模板。dots 的出现本质上是解决了一个老问题以前我们在 ChatGPT 里积累的对话经验散落在各个会话里没法沉淀、没法复用、没法组合。dots 就是把这些碎片变成可命名、可引用、可组合的积木。ChatGPT Spaces 则是把这些积木放进了一个房间里。Spaces 不是简单的文件夹它更像是一个带上下文记忆和权限边界的工作区。你可以在一个 Space 里放一组 dots、挂载特定的文件、设定这个空间的行为规则然后让 ChatGPT 在这个空间里持续工作。这个设计对团队协作场景的意义很大——以前多人共用一个 ChatGPT 账号上下文是混的现在可以按项目、按职能划分 Space每个 Space 有自己的记忆和边界。GPT-6.1 Sol 是模型侧的更新。Sol 这个后缀值得注意它不像之前的 turbo、mini 那样直接描述规格而更像是一个面向特定工作负载优化的版本标识。从现场给出的 benchmark 和延迟数据看Sol 在长上下文推理和工具调用链的稳定性上有明显提升尤其是在多步 Agent 任务里中断率和幻觉率都压下来了。这对做 Agent 开发的团队来说是实打实的成本下降——因为 Agent 任务失败重试的 token 消耗往往比单次推理本身还贵。把这三个东西放在一起看DevDay 2026 的意图就很清楚了dots 是原子Spaces 是容器Sol 是引擎。三者组合起来就是 OpenAI 对下一代 AI 工作流的完整回答。下面我按这个逻辑把每个部分拆开讲透包括我实际跑下来的一些观察和踩过的坑。2. dots 到底是什么结构化信息单元的落地逻辑2.1 从对话碎片到可复用积木的转变在 dots 出现之前我们在 ChatGPT 里沉淀知识的方式基本只有两种要么把好的对话存进自定义指令要么手动复制粘贴到一个文档里。这两种方式都有硬伤。自定义指令是全局的改一个地方影响所有对话手动复制则完全脱离了 ChatGPT 的运行时下次要用还得重新贴回去。dots 解决的就是这个沉淀-复用的断层。一个 dot 本质上是一个带元数据的结构化片段它有自己的名字、描述、内容体以及可选的参数定义。你可以把它想象成一个函数——定义一次到处调用。比如你可以定义一个叫周报生成器的 dot里面封装了周报的格式模板、语气要求、必填字段下次在任何对话里只要引用这个 dotChatGPT 就知道该怎么按你的规范生成周报。这个设计的关键在于引用机制。dots 不是复制粘贴而是引用。这意味着你更新了 dot 的内容所有引用它的地方都会同步生效。这一点对维护一套长期使用的提示词体系来说价值非常大。我以前维护过一套十几个提示词模板散落在各个文档里改一次要翻半天如果当时有 dots这就是一个统一管理的问题。2.2 dots 的参数化设计与实际用法dots 支持参数化这是它区别于普通提示词模板的核心。一个 dot 可以定义若干输入参数调用时传入具体值。举个实际例子我定义了一个叫代码审查的 dot参数包括language、strictness、focus_area。调用的时候传入languagepython、strictnesshigh、focus_areasecurity它就会按安全优先的高严格度标准来审查 Python 代码。这种参数化带来的好处是可组合性。你可以把多个 dots 串起来用——一个负责提取需求一个负责生成代码一个负责审查形成一条流水线。在 ChatGPT Spaces 里这种组合是可以持久化的不需要每次重新描述。提示dots 的参数命名建议用英文小写加下划线虽然界面支持中文但在跨 Space 引用和后续可能的 API 调用场景下英文命名兼容性更好。实际使用中我发现一个细节dots 的内容体对格式是有偏好的。纯文本的 dot 最稳定Markdown 格式的 dot 在渲染时偶尔会出现层级错乱尤其是嵌套列表超过三层的时候。如果你的 dot 里需要复杂结构建议用简洁的 Markdown避免过深的嵌套。2.3 dots 与现有提示词工程的差异很多人会把 dots 和传统的 prompt template 混为一谈但两者在工程化程度上有本质区别。传统 prompt template 是字符串替换dots 是带语义的引用。区别在于dots 在 ChatGPT 的运行时里是被理解的而不是被拼接的。这意味着当你在对话里引用一个 dot 时ChatGPT 不是简单地把 dot 的内容插进上下文而是把它作为一个有结构的对象来处理。这个差异在复杂任务里会体现得很明显——比如你引用一个带条件的 dotChatGPT 会根据当前对话的上下文判断该走哪个分支而不是机械地执行。从工程角度看dots 更接近配置即代码的思路。它把提示词从散落的文本提升到了可版本化、可引用、可组合的资产这个层面。对个人用户来说这可能只是个便利性提升但对团队来说这是提示词管理从手工作坊走向工程化的一步。3. ChatGPT Spaces把对话变成可持续的工作区3.1 Spaces 的定位不是文件夹是带记忆的边界ChatGPT Spaces 最容易被低估的地方是它的边界属性。表面上看它像是一个把对话分组的功能但真正重要的是它给每个 Space 划定了独立的上下文记忆和权限范围。在没有 Spaces 之前ChatGPT 的记忆是账号级的。你在 A 项目里聊的内容可能会在 B 项目的对话里被想起来这在很多场景下是干扰。Spaces 把这个记忆隔离了——每个 Space 有自己的记忆池A Space 里积累的上下文不会污染 B Space。这个设计对同时处理多个项目的用户来说是刚需。权限边界则是面向团队的。一个 Space 可以设定哪些成员可以访问、哪些可以编辑 dots、哪些只能使用。这就把 ChatGPT 从个人工具变成了团队协作平台。我实际测试下来Space 的权限粒度目前还比较粗主要是可管理和可使用两档但已经足够覆盖大多数小团队的需求。3.2 在 Space 里组织 dots 和文件的实操方法一个 Space 里可以挂载三类东西dots、文件、以及对话历史。这三者的组织方式决定了这个 Space 好不好用。我的做法是按职能而不是按项目来建 Space。比如我有一个内容生产Space里面放了选题生成、大纲撰写、初稿润色、事实核查四个 dots挂载了品牌调性文档和几个参考案例文件。这样无论我在做哪个具体项目只要进这个 Space整套内容生产的工具链就是现成的。文件挂载有个细节要注意Space 里的文件是会被检索的但检索是基于语义的不是全文索引。这意味着文件名和文件内的标题结构很重要。我试过把一堆命名混乱的文件丢进去结果 ChatGPT 检索时经常找错文件后来把文件名规范化成类型-主题-日期的格式检索准确率明显提升。注意Space 的文件挂载有数量上限超过之后新文件不会被检索到但界面不一定有明显提示。建议定期清理不再需要的文件保持 Space 精简。3.3 多人协作场景下 Spaces 的实际表现团队用 Spaces 最直接的好处是上下文对齐。以前团队里每个人用 ChatGPT 都是各聊各的好的提示词和经验没法共享。现在把常用的 dots 放进共享 Space新人进来直接就能用团队沉淀下来的工作流不用从零摸索。但实际用下来也有几个坑。第一是 dots 的编辑冲突——如果两个人同时改一个 dot后保存的会覆盖先保存的目前没有版本历史。所以我们的做法是约定谁负责哪个 dot避免多人同时编辑。第二是 Space 的记忆会随着使用不断增长时间长了之后 ChatGPT 在这个 Space 里的响应会变慢因为要检索的上下文变多了。我们的应对是定期归档旧对话保持活跃上下文在一个合理规模。第三点是权限管理的现实问题。Space 的权限目前不支持只读某几个 dot这种细粒度控制要么能管理整个 Space要么只能使用。对需要精细权限控制的团队来说这还是个限制。不过对大多数中小团队这个粒度已经够用了。4. GPT-6.1 Sol模型侧更新对开发者的实际影响4.1 Sol 版本在 Agent 任务链上的稳定性提升GPT-6.1 Sol 最值得说的不是它在单个 benchmark 上高了多少分而是它在多步 Agent 任务里的稳定性。做 Agent 开发的人都知道最头疼的不是单次推理质量而是任务链跑到第五步、第八步的时候突然跑偏——要么忘了前面的约束要么调错了工具要么开始编造不存在的信息。Sol 在这方面的改进是实打实的。我拿之前一个跑了经常失败的多步任务做了对比测试任务是读取一份需求文档拆解成任务列表为每个任务生成代码骨架然后自查代码是否符合需求。用之前的模型这个链条跑到第三步左右经常出现需求遗漏换成 Sol 之后连续跑了十次只有一次在最后自查环节漏了一个次要需求点。这个稳定性提升对 Agent 应用来说直接意味着重试成本的下降。从技术角度看这种稳定性提升大概率来自两方面一是长上下文里的关键信息保持能力增强二是工具调用的决策更保守——Sol 在不确定的时候更倾向于追问而不是猜测。后者对 Agent 场景特别重要因为一次错误的工具调用可能比一次追问的代价大得多。4.2 长上下文推理的成本结构变化Sol 在长上下文场景下的表现也值得单独说。官方给出的数据是上下文窗口进一步扩大但更关键的是有效上下文的比例提升了——也就是说在很长的输入里模型真正能用上的信息比例更高了。这对成本结构的影响是双面的。一方面单次调用的 token 消耗可能因为上下文变长而增加另一方面因为任务成功率提升重试次数减少总体成本反而是下降的。我算过一笔账一个原本需要平均 2.3 次重试才能成功的任务如果重试降到 1.2 次即使单次成本上升 20%总成本还是降了大约 35%。提示如果你的应用里有大量长上下文任务建议在切换到 Sol 之后重新做一次成本测算不要只看单次调用的价格要把重试率一起算进去。4.3 从旧版本迁移到 Sol 需要注意的兼容性问题迁移到 Sol 不是改个模型名就完事。我实际迁移的时候遇到几个问题这里列出来供参考。第一是输出格式的稳定性。Sol 在结构化输出比如 JSON上比之前的版本更严格有时候会因为格式不够规范而拒绝输出而不是像以前那样勉强给一个格式有瑕疵的结果。这对依赖解析输出的应用来说需要在前置提示里把格式要求写得更明确。第二是工具调用的参数风格。Sol 在调用工具时参数的填充更倾向于最小必要也就是说它不会像以前那样把可选参数也填上。如果你的工具函数依赖某些可选参数的默认值需要检查一下这些默认值是否合理。第三是温度参数的敏感度。Sol 对 temperature 的变化比之前的版本更敏感同样的 temperature 值输出的多样性可能和以前不一样。建议迁移后重新校准一遍 temperature 设置不要直接沿用旧值。5. 20 项发布里容易被忽略但值得关注的几个5.1 开发者侧 API 的几处实用改动除了三个大件这次发布里还有几处 API 层面的改动虽然不起眼但很实用。一个是流式输出的粒度控制更细了现在可以按语义块而不是按 token 来接收流式结果这对做实时 UI 的应用来说渲染体验会好很多。另一个是函数调用的错误返回更结构化以前工具调用失败往往只给一个笼统的错误信息现在会区分参数错误权限错误超时等类型方便做针对性的重试逻辑。还有一个改动是速率限制的调整。新的速率限制策略从固定窗口改成了滑动窗口这对突发流量的容忍度更高了。以前固定窗口下如果在一个窗口末尾打满配额下一个窗口开始时会有一段不可用的空档滑动窗口下这个问题基本消失了。5.2 与 Codex 相关的命令行工具更新这次发布里和 Codex 相关的更新也值得单独提一句。命令行侧的 coding agent 能力有增强主要体现在对项目结构的理解更深了——它现在能识别出项目里的依赖关系在修改一个文件时会主动检查受影响的上下游文件。这个能力对重构类任务特别有用以前让 agent 改一个函数签名它经常只改定义不改调用方现在这种情况少多了。不过实际用下来这个能力在大型项目里还是有限制。项目文件数超过一定规模后agent 对全局依赖的把握会下降还是需要人工指定范围。我的经验是把任务拆小每次只让 agent 处理一个模块内的改动成功率最高。5.3 这些更新对普通用户的实际意义对不写代码的普通用户来说这次发布里最直接能感受到的可能是 ChatGPT Spaces 带来的体验变化。以前 ChatGPT 用久了会记忆混乱现在按 Space 隔离之后每个工作场景的上下文都干净了。dots 则让我常用的那套问法可以存下来复用不用每次重新打一遍。GPT-6.1 Sol 对普通用户的影响相对间接主要体现在回答质量的稳定性和长对话的连贯性上。如果你经常做需要多轮深入讨论的任务比如写长文、做复杂规划Sol 带来的体验提升会比较明显。6. 实际用下来的一些经验和建议6.1 上手顺序建议先 Spaces 后 dots如果你刚开始接触这套东西我的建议是先建 Space再往里填 dots。原因是 Space 是容器先有容器才知道该往里放什么。很多人一上来就急着定义一堆 dots结果发现没有合适的 Space 来组织它们最后 dots 散落各处反而更乱。建 Space 的原则是一个 Space 对应一类持续性的工作。比如日常写作代码开发数据分析各建一个。不要按临时项目建 Space因为项目会结束Space 会变成垃圾。按职能建Space 就能长期复用。6.2 避免把 dots 做成万能模板我见过不少人把 dot 设计得特别复杂一个 dot 里塞了十几个参数、覆盖好几种场景。这种万能 dot实际用起来很难用因为每次调用都要想清楚该传什么参数反而增加了认知负担。好的 dot 应该是单一职责的——一个 dot 只做一件事做透。需要组合的时候用多个 dot 串起来而不是把复杂度堆在一个 dot 里。这跟写代码是一个道理函数要小职责要单一。6.3 迁移和长期维护的注意事项最后说几个长期维护的点。第一dots 和 Spaces 目前都没有版本历史所以重要的 dot 建议在外部留一份备份比如存在自己的文档里。第二Space 的记忆会随时间增长建议每隔一段时间清理一次不再需要的对话保持 Space 的响应速度。第三模型版本更新后建议对关键的 dots 做一次回归测试确认输出质量没有因为模型变化而下降。我在实际使用中最大的体会是这套东西的价值不在于单个功能有多强而在于它们组合起来形成的工作流。dots 提供可复用的能力单元Spaces 提供有边界的运行环境Sol 提供稳定的执行引擎。三者配合才能把 ChatGPT 从一个很聪明的聊天对象变成一个能持续干活的协作系统。这个转变才是 DevDay 2026 真正想传达的东西。