说实话，每年OpenAI DevDay我都带着“这又要改多少集成代码”的复杂心情去看。今年旧金山的现场，20多项发布同时砸下来，光是把幻灯片上的快捷键记清楚就已经够忙的了。但真正让我觉得必须坐下来写一篇完整回顾的，是三样东西：dots、ChatGPT Spaces，以及GPT-6.1 Sol。它们不是三个独立的功能点，而是同一套逻辑里的三层结构：Sol提供能力底座，dots提供开发者入口，Spaces提供协作入口。这篇回顾不打算把所有发布都面面俱到地复述一遍，那太像产品手册了。我更想把现场最关键的定位、上手步骤、实测感受和踩坑经验整理出来，给正在搭建AI研发流程的工程师、技术负责人，以及准备把ChatGPT塞进业务线的产品经理，提供一个可以直接参考的判断框架。
1. 开场三件套：dots、Spaces、Sol是怎么被定位的
1.1 从“模型发布会”变成“平台发布会”
前几年的DevDay，核心叙事是“我们出了一个更强的模型”。今年最大的观感变化在于，OpenAI把舞台中心从模型本身挪到了“开发生态”上。GPT-6.1 Sol当然很强，但整场活动里它的出场时间反而没有dots和Spaces多。这种编排其实很说明问题：单点模型的边际优势正在变小，真正能拉开差距的是模型外层的工具链、协作机制和部署体验。
具体来说，dots负责的是“开发者怎么和AI一起写代码、改代码、审代码”；Spaces负责的是“团队怎么把散落在各处的资料和对话沉淀成可复用的组织记忆”；Sol则负责在最底层提供推理能力，让前面两个工具里的任务真正跑得起来。这三个产品互为依托，你能明显感觉到发布会的主线不再是“看我们的模型多聪明”，而是“看你们的工作流可以被我们重构得多顺”。
对开发者的直接影响是：这次你不需要只盯着某一个新的API端点，而是要先想清楚自己的工作流里，哪些环节的人机协作能被dots承接，哪些项目知识该进Spaces，哪些复杂任务要交给Sol处理。后面我会逐个拆开讲。
1.2 为什么命名成Sol
Sol这个代号在命名上挺有意思，太阳的意思，官方表述是“让模型能力像日光一样覆盖所有工作场景”。从技术规格上看，GPT-6.1 Sol也确实走的是“重型全能旗舰”路线：上下文窗口扩展到1M tokens，能同时处理文本、图像、音频、视频输入，推理深度和工具调用准确率相比上一代GPT-5系列又有明显提升。
但别被参数和benchmark牵着走。我在现场最大的感受是，命名背后的产品定位才是关键。Sol不是只用来“聊天更聪明”的模型，它的重心在“更可靠的长时间任务执行”。比如一口气分析一份两百页的招股书，或者把整个代码仓库的结构读完后再给出重构建议，这种场景要求模型具备稳定的长上下文理解和多步规划能力，单单把上下文做长是不够的，还需要模型知道什么时候该停下来问人，什么时候该果断继续。Sol在这方面的表现，后续章节我会给出具体的实测判断。
2. dots：开发者想要的不是对话框，是自动化流水线
2.1 dots是什么，和代码助手有什么区别
dots在发布前就有不少消息说它是“Codex CLI的下一代”，但真正上手之后你会发现，它比CLI工具走得更远。dots的核心是一个“可编程的AI开发工作台”，你可以像搭流水线一样，把规划、写代码、跑测试、审查、提交这些环节拆成不同的任务节点，每个节点之间可以传递上下文，也可以并行执行。
现场演示时，OpenAI展示了用dots处理一个支付服务重构的过程：它先读取了仓库里的服务代码和测试文件，然后自动生成了一个重构计划，计划里明确标出了哪些函数要改、哪些测试需要同步更新；确认之后，dots才开始动手改代码，改完自动跑单测和静态检查，最后给你一份diff级别的审查报告。整个过程中，你随时可以打断它、让它换方案。
这就和普通的AI编程助手拉开了差距：普通助手是你问一句它答一句，dots更像是你给它定义了一个工作流，它在这个工作流里充当可调的执行引擎。登录方式上，dots支持直接用ChatGPT账号登录，团队使用时也可以走企业级SSO。如果你受够了来回复制粘贴代码片段，dots值得花一个下午认真体验。
2.2 三个核心原语：plan / act / review
理解dots的关键，是抓住它的三个核心原语：plan（规划）、act（执行）、review（审查）。
plan阶段，dots会先分析任务描述、仓库结构、相关文件，然后输出一份可执行计划。这个计划不是流水账，它会包含具体的文件改动路径、依赖影响范围和潜在风险点。act阶段才是真正动代码的部分，dots会按计划逐步修改文件、运行命令、处理报错，并且在遇到模糊需求时停下来向你提问。review阶段则是对改动的最终把关，它会重新审视diff，检查测试覆盖率，甚至能发现你代码里的并发隐患。
这三个原语最大的价值，是把“AI写代码”从不可控的黑盒变成了一个可预期、可回溯的流程。你可以单独跑plan来预览方案，也可以让plan和act连续执行，但把review单独设为人手确认。在我自己的项目里，最常用的组合就是“act+review自动跑，plan必须人工确认”，既保证了效率，又把最终决定权留在自己手里。
2.3 实操配置：从一个普通项目接入dots
说了这么多，直接看怎么接入。假设你手头有一个Node.js项目，想用dots来辅助重构一个模块。先安装CLI并登录：
npm install -g @openai/dots dots login登录完成后，在项目根目录初始化工作流定义文件：
dots init这会生成一个dots.yaml，你可以把它理解为工作流的配方文件。我常用的最小配置大概长这样：
workspace: root: . include: - "src/**/*.ts" - "test/**/*.ts" exclude: - "node_modules/**" tasks: refactor_payment: description: "重构支付模块，拆分订单服务与支付网关调用" steps: - plan: model: gpt-6.1-sol temperature: 0.2 - act: run_tests: true max_retries: 3 - review: require_human_approval: true关键参数在于plan里的model，我建议对复杂任务直接指定gpt-6.1-sol，它的长上下文和规划能力应付多文件改动明显更稳。act里的run_tests务必开启，否则dots改完代码你可能还要手动跑一遍测试，效率反而下降。max_retries控制它在测试失败后的自我修复次数，设太高容易在同一个坑里反复打转，我实测3次比较合适。
配置保存后，运行这个任务只需要一行命令：
dots run refactor_payment现场实测中，一个中等复杂度的模块重构，从plan到review大概耗时几分钟，期间我可以去干别的活，跑完回来只看最终的diff和审查意见。这种体验和之前“逐轮聊天、手动应用patch”的流程相比，完全是两个量级。
2.4 避坑：不要让它一次处理太大需求
dots很好用，但绝不是万能的。我第一天就踩了个坑：把一个涉及十几个文件、横跨三个微服务的大需求直接丢给它，结果plan阶段生成了两百多行计划，执行到一半开始出现上下文漂移，前面的决策和后面的实现渐渐对不上，最后不得不中断重来。
后来我把大需求拆成多个小任务，每个任务聚焦一个模块或一个改动点，任务之间通过README或规范文档传递状态，跑起来就顺畅很多。另外，一定要在配置里设好资源预算，比如单任务执行上限、并行任务数、总耗时上限。dots支持在CLI里设置这些配额，目的是防止它在失控时疯狂烧token。我的建议是：第一次跑任何新任务，都把并行度设成1，确认整个流程稳定后再往上加。
3. ChatGPT Spaces：把“聊天记录”升级成“组织记忆”
3.1 Spaces的定位
如果你和我一样，曾经把重要的项目讨论放在ChatGPT的某个历史会话里，三个月后再回去翻，就会发现根本找不到上下文。Spaces要解决的就是这个问题。它把“一次性对话”改造成“持久化协作空间”，每个Space可以看作一个独立的项目工作区，里面既有聊天记录，也有文件库、知识库、任务列表和成员权限。
现场使用时，你可以为部门、项目或临时攻坚组创建独立的Space。比如给客服团队开一个“售后知识库空间”，把产品文档、常见问题、历史工单全部导入，团队成员就可以在一个地方同时和AI助手对话、搜索内部文档、生成回复草稿。整个过程不再依赖某个人的聊天记录，所有内容都在Space里沉淀下来，新成员加入后也能直接看到之前的全部上下文。
3.2 与普通ChatGPT会话的区别
用一张表来说清楚Spaces和普通会话的本质差异：
| 维度 | 普通ChatGPT会话 | ChatGPT Spaces |
|---|---|---|
| 上下文生命周期 | 临时，关闭即散 | 持久化，长期累积 |
| 协作方式 | 单人或单一对话 | 多人共享、角色分工 |
| 知识来源 | 模型内部知识 | 可挂载外部数据源 |
| 权限管理 | 基本没有 | 细粒度角色权限 |
| 与API的关系 | 无 | 支持通过API创建和写入 |
| 适用场景 | 快速问答、临时写作 | 项目协作、团队知识管理 |
Spaces本质上是在ChatGPT上长出了一个“内容管理系统”。你可以在里面维护一份持续更新的项目wiki，让AI助手基于这份wiki回答问题，而不是每次都靠模型背知识。对于企业用户而言，更有价值的是Spaces可以和内部的资料库打通，把散落在Confluence、Notion、GitLab Issues里的内容聚合成一个可检索的知识网络。
3.3 权限模型与知识检索
权限方面，Spaces支持三种角色：管理员（管理空间配置和成员）、编辑者（可写入内容和发起对话）、阅读者（只能查看和提问）。管理员可以设置数据保留期，比如让自动摘要和索引日志只保留30天，也可以开启“零数据保留”模式，确保内容和模型训练完全隔离。这一点对金融、医疗等合规要求高的行业尤其重要。
知识检索这块，Spaces默认采用混合检索，既有基于向量相似度的召回，也有关键词精确匹配。你可以针对每个Space单独配置数据源，并限定AI助手的回答范围。比如只让它参考当前Space文件库里的资料，不允许它自由调用外部信息。我在测试时特意把一份内部API文档放进Space，然后让助手回答关于接口参数的问题，它给出的答案全部来自文档内容，并且会标注引用来源，准确率比直接问通用模型高很多。
3.4 从零搭建一个团队Space
搭建流程不复杂，但有几个细节值得注意：
- 创建Space，命名时建议带清晰的负责人和用途前缀，比如
[客服]售后FAQ知识库-李xx，避免团队里出现几十个“未命名空间”。 - 添加成员并分角色。核心维护者给编辑者权限，普通成员给阅读者权限，管理员只留1到2个人。
- 配置数据源，按目录或标签导入文档。注意一次别导入太多，分批进行，否则知识索引可能超时。
- 导入历史文档时，顺手让AI生成一份摘要并置顶，后续成员进来先读摘要就能快速上手。
- 邀请AI助手加入Space，并用自然语言告诉它“你是客服团队的助手，回答时优先引用资料库内容，无法找到时明确说不知道”。
实测下来，一个20人左右的团队，用一到两周就能把常用文档和讨论迁移进Spaces。迁移初期最花时间的是文档整理，但这部分工作做了以后，团队的重复提问会明显减少，算是比较划算的长期投资。
4. GPT-6.1 Sol的能力解析与基准解读
4.1 模型规格与关键参数
GPT-6.1 Sol的规格表，我根据现场公开信息整理了一份重点参数对比：
| 能力项 | GPT-5.2（上一代） | GPT-6.1 Sol |
|---|---|---|
| 上下文窗口 | 400K tokens | 1M tokens |
| 输入模态 | 文本、图像、音频 | 文本、图像、音频、视频 |
| 多步推理能力 | 较强 | 明显增强（长任务稳定性更好） |
| 函数调用准确率 | 基准线 | 提升约15%（现场演示数据） |
| 延迟 | 中高 | 支持低延迟模式，首token更快 |
| 价格 | 基准线 | 输入略降，输出略升 |
参数表格只是参考，我更关注的是Sol在实际任务里的稳定性。1M上下文的意义不只是能塞更多文字，而是让模型可以全程“记住”长文档的关键结构。现场演示里，Sol读取了一份上百页的年报，然后回答关于某项业务在特定年份的财务数据来源问题，不仅答对了，还能准确说出数据在第几页。这种深度定位能力，是此前模型很难做到的。
4.2 能落地的场景不是“写得更快”，而是“想得更深”
Sol最值得关注的不是它“生成文本快”，而是它在复杂场景下的“想得更深”。举三个我实际测试过的场景：
第一，合同审查。把一份三十页的采购合同丢给Sol，它能同时提取付款条款、违约责任、保密期限、争议解决机制，并且把明显不利于我方的内容标出来，给出修改建议。之前用GPT-5系列做类似工作，需要在多个会话里分段喂，最后再手动拼接结果，现在一次性处理完，输出结构还相当完整。
第二，跨文件代码重构。Sol在理解多文件依赖关系上的表现比前代更稳。我在一个完全没接触过的开源仓库里让它找出某个功能模块的全部调用链，它给出的结果和人工排查基本一致，并且能指出隐藏在测试文件里的间接依赖。
第三，长文档问答。Sol对于那种“答案不在同一段落、需要跨章节联想”的问题，正确率提升非常明显。你可以把它理解成一位能通读整本书的助理，问它问题时它不只是检索关键词，而是真的理解内容之间的逻辑关联。
4.3 API升级：你第一行代码要改什么
对开发者来说，最实际的问题是API调用哪里变了。如果你的应用当前用的是gpt-5.2，切换到Sol时主要改三处：
from openai import OpenAI client = OpenAI() response = client.chat.completions.create( model="gpt-6.1-sol", messages=[ {"role": "user", "content": "分析这份合同中的风险条款，并输出JSON格式的建议"} ], # 新增：控制推理深度 reasoning_effort="high", # 新增：要求返回结构化引用 citations={"enabled": True} ) print(response.choices[0].message.content) # 新增字段：响应里会多出reasoning_tokens和citations第一个变化是模型名从gpt-5.2改成gpt-6.1-sol。第二个变化是新增了reasoning_effort参数，可以控制模型在回答前做多少“思考”。这个参数类似给模型设定一个努力刻度，需要深度分析时设成high，简单问答设成low可以明显降低延迟和成本。第三个变化是citations参数，开启后模型会在回答里返回引用来源标记，特别适合需要溯源的企业场景。如果你是老用户，改完这三处，绝大多数代码直接就能跑起来，兼容性做得相当好。
5. 20+ 项发布里，真正值得花时间的5项
5.1 结构化输出终于不再“偶尔抽风”
过去让模型输出JSON，跑测试时总有那么一两条不符合Schema。这次OpenAI升级了结构化输出模式，承诺在JSON Schema约束下做到完全合规，背后的实现思路是在解码阶段就强制匹配Schema，而不是在生成后做校验修复。
我的经验是，凡是涉及给下游系统传参数的场景，比如让模型调用函数、写数据库、发消息，都要把response_format设为structured_output。API写法如下：
response = client.chat.completions.create( model="gpt-6.1-sol", messages=[{"role": "user", "content": "提取这条物流信息的发货人和收货人"}], response_format={ "type": "structured_output", "schema": { "type": "object", "properties": { "sender": {"type": "string"}, "receiver": {"type": "string"} }, "required": ["sender", "receiver"] } } )这看起来只是接口层面的加强，但落到生产环境就是“不用再写那堆校验重试代码”和“必须写那堆校验重试代码”的天壤之别。如果你的业务里有大量的模型输出JSON解析，这个更新值得立刻跟进。
5.2 Realtime API支持“边说边想”
语音交互场景这次也有大升级，Realtime API的延迟降到300毫秒以内，这个数字已经接近真人对话的自然停顿感。更重要的是它支持边识别边处理，用户说上半句时，模型已经可以开始预测后续内容，并且支持随时打断和多次工具调用。
这对于语音客服、语音助手类产品是实打实的红利。之前做语音智能体，最大的痛点是人机对话的等待感太明显，用户说完话要等两秒才得到回应，体验远不如真人。现在配合Sol的推理能力，模型可以在听的同时进行工具调用，比如边听用户报订单号，边查询订单系统，等用户说完时结果基本已经出来了。
5.3 Batch API降价35%
离线批处理任务的调用价格又降了35%，而且批处理队列的吞吐上限大幅提升。如果你的业务里有大量“批量总结、批量分类、批量抽取”的需求，优先考虑走Batch API，它不追求实时响应，适合做数据清洗、历史记录分析这类对时效不敏感的任务。
我的建议是，能离线跑的就别走实时接口，Budget允许省一点是一点。尤其在企业级项目里，批量处理往往占据调用大头，这个降价项对公司整体bill的影响比新模型本身更直接。
5.4 微调与蒸馏变得更便宜
微调方面，LoRA的可训练层更多，蒸馏流程也简化了。你可以用Sol作为教师模型，在私有数据上生成一批高质量样本，再用这些样本微调一个更小的模型，部署成本更低，推理速度更快。我在一个内部工具上试了这种流程，小模型的问答效果和直接调Sol差距不大，但单次调用成本降了一个数量级。
需要注意的是，蒸馏的效果高度依赖教师模型生成样本的质量。你喂给大模型的指令必须足够清晰，生成的样本才值得用来训练小模型。这一步偷懒，后面小模型的输出质量会非常不稳定。
5.5 评估工具上线
第五个值得关注的更新是官方评估工具的正式上线。以前我们评估模型效果基本靠人工抽样，既费时又不稳定。现在OpenAI把评估工具做进了API和开发者平台，你可以在CI流水线里配置回归测试集，每次更换模型或更新prompt时自动跑一轮评估，比对输出差异。
我在项目里实际接了一份50条测试用例，覆盖了客服问答、意图识别、报告生成三类场景。每次改完prompt都能快速看到分数变化，比过去靠感觉判断“好像变好了”要靠谱得多。对团队来说，评估工具是保障模型长期稳定性的基础设施，越早接入越好。
6. 安全、隐私与账号保护：你必须知道的几条底线
6.1 会话JSON泄露怎么办
这一节想认真聊聊安全问题，因为最近看到不少开发者习惯把ChatGPT会话内容或带有访问令牌的JSON导出文件分享到公共渠道。严格来说，这类文件一旦泄露，账号就有被接管的风险，攻击者可能直接读取你的聊天记录、调用你的API额度，甚至修改账号绑定信息。
万一已经发生了泄露，按下面的顺序紧急处理：
- 立即进入账号设置，在“安全”页面里撤销所有活跃会话，让泄露的会话令牌当即失效。
- 重新生成所有API Key，旧的全部作废，并检查最近一周的API调用流水，确认是否存在异常消耗。
- 开启两步验证，同时检查账号绑定的邮箱和手机号是否有被篡改的痕迹。
- 如果泄露的JSON里包含了项目代码、内部文档等敏感信息，建议同步排查相关下游系统是否需要轮换密钥。
这个流程我在一次演练环境里完整跑过，从发现泄露到全部处理完大约需要20分钟。如果你还没有检查过账号的安全设置，我建议现在就打开设置页确认一遍，别等出问题再折腾。
6.2 API Key的管理与成本控制
再聊一下API Key。我见过太多把Key硬编码在前端代码里的案例，这种做法的风险非常大，任何能看到前端源码的人都能直接盗用你的账单。最稳妥的方式是把Key放在后端服务中，由服务端接收前端请求，再统一调用OpenAI API。这样前端永远接触不到真实Key，即使被抓包，也只是访问你的后端接口。
成本控制方面，建议给Key配置月度消耗上限，并开启异常检测报警。OpenAI开发者平台支持按项目划分独立的Key和额度，把不同业务线拆开管理，出问题时能迅速定位是哪个模块在烧钱。另外，建议团队内部约定禁止共享Key，每条Key只绑定一个负责人。热词里提到的“分享OpenAI API key”这类做法，一定不要尝试。共享Key不仅会让账单分不清责任，也会让权限回收变得极其困难。
6.3 数据与合规
企业用户最关心的是数据安全。这次DevDay再次强调了平台级的数据保护承诺，包括零数据保留选项、静止和传输加密，以及企业版的管理员审计日志。如果你的业务涉及敏感个人信息，建议在初始化API调用时就明确设置data_retention策略，并要求模型输出中开启引用溯源。
另外，如果你们公司有内部数据合规规范，记得让法务和技术团队一起审一遍Spaces和数据源挂载的配置，确认哪些文档允许进入知识库，哪些数据只能留在企业本地系统里。技术上的控制项再多，也替代不了组织层面的流程规范。
7. 我的整体判断与上手建议
7.1 这次发布对普通开发者的影响
先说结论：不是所有更新都需要立刻使用，但有两件事建议尽早动手。一是把dots跑通，哪怕只在一个个人项目里用它做代码重构审查，也能让你提前适应“AI执行、人审批”的新协作方式。二是建议把团队的常用文档迁进一个Spaces，让新成员不再追着老同事要资料，这种知识管理的收益是持续累积的。
至于GPT-6.1 Sol，如果你没有长上下文或复杂多步推理的刚需，不着急迁移。普通问答场景下，你现有的模型已经够用，盲目升级只会平白增加成本。按需评估、按场景选型才是稳妥的做法。
7.2 团队落地路线图
如果是一个5到10人的产品团队，我建议按这个节奏推进：
第一周，选择两个最频繁的人工操作流程，用dots把它们定义成自动化任务，比如“依赖包升级后的测试修复”“接口文档变更后的调用方同步”。先让人工确认plan和review，跑通信任边界。
第二到第三周，搭建第一个Spaces，把项目相关的设计文档、会议纪要、客户反馈全部导入，并明确负责人维护知识索引。
第四周开始，针对核心业务场景评估GPT-6.1 Sol，挑一个痛点最明显的任务，配上结构化输出和评估工具，跑一轮效果对比，用数据决定要不要迁移。
我个人在实际操作中的体会是，这轮发布最值得借鉴的并不是某个单独的功能，而是OpenAI把“模型能力”拆解成“开发入口＋协作空间＋推理底座”的思路。你完全可以借用同样的分层逻辑，重新审视自己团队的AI应用架构，把工具链和工作流一起升级。最后再分享一个小技巧：注册一个专门的项目账号来试验dots和Spaces，跟主力开发账号分开，权限隔离之后，你在测试时能放开手脚很多。
