1. 发布会整体量级与最值得关注的变化先说结论这届 OpenAI DevDay 从信息密度上看是历届最高的一次。20 多项发布里真正算得上“改变开发方式”的并不多但每一个都踩在关键位置上。如果你只看热搜标题可能会以为重点是 GPT-6.1 Sol 这个新模型但实际参加完、看完所有 Demo 之后我的判断是dots 和 ChatGPT Spaces 才是这届 DevDay 真正意义上的“平台级”动作模型更新反而只是配套。先说个现场体感。今年 DevDay 的开场没有像前两年那样直接甩基准测试分数而是花了将近二十分钟讲“开发者现在到底在用什么方式写代码”。这个开场方向本身就暗示了整场发布会的重心——工具链、工作流、协作方式而不是单一的模型能力。换句话说OpenAI 在试图回答一个问题当模型能力趋于同质化开发者为什么还要留在你的生态里答案就是这 20 多项发布里埋着的那条主线从“调用模型”转向“构建环境”。我按自己的理解把这次发布分成了四层第一层是开发范式层对应 dots 和 Codex 相关的命令行升级第二层是产品形态层对应 ChatGPT Spaces第三层是模型能力层对应 GPT-6.1 Sol 以及配套的多模态接口第四层是生态规则层包括 API 价格调整、配额策略、第三方集成认证等等。下面几节我会一层一层拆开讲重点放在 dots 和 Spaces 上因为这两个东西对开发者的日常工作流影响最直接。如果你是那种“只想知道该用哪个、怎么用”的人我的建议已经可以提前给你命令行重度用户直接上 dots它值得你花一个下午迁移工作流团队协作者重点看 Spaces它可能是目前把 AI 引入项目过程最自然的产品形态至于 GPT-6.1 Sol先别急着替换你现有的 6.0 工作流等 benchmark 之外的实测数据出来再说——当然如果你对上下文窗口有硬需求那另当别论。2. dots从功能命令到协作协议的进化逻辑2.1 dots 到底是什么它和传统 CLI 工具的本质区别dots 是这次发布里最容易被低估的一个。很多人的第一反应是“又一个命令行工具”但实际用过之后你会发现它不是“又一个”而是把整个 Codex 的交互模型重新定义了。旧模型是这样的你在终端里敲命令Agent 帮你改代码任务结束会话结束。每个命令是一次独立的、无状态的交互。而 dots 做的事情是给这些交互加了“持久化上下文”和“跨会话状态”。你可以把它理解为终端里的每一次对话、每一次代码改动、每一次决策记录都会沉淀成一个可追溯的“点”dot。下次你再发起任务时不需要重新描述背景dots 会基于历史状态自动补齐上下文。这一点听起来简单但实际影响非常大。传统 CLI 工具包括早期的 Codex 命令行版最大的痛点就是“每次都要重新调教”。你告诉它项目结构、告诉它技术栈、告诉它避开哪些坑然后回车任务结束。第二次再来它全都忘了。dots 把这个过程彻底去掉了——你的历史决策、项目偏好、踩坑记录全部保留在本地状态里Agent 每次启动时自动加载。用我现在的工作方式来举例我在维护一个微服务项目里面有十几个仓库。以前用 Codex 处理跨仓库任务每次都要先花五分钟粘贴背景信息。现在只需要dots init一次之后每次进入仓库它自己就知道这是什么项目、用的是什么框架、之前改过哪些模块、还有哪些 TODO 挂在哪个版本里。2.2 从“命令”到“协议”dots 的嵌套理念官方文档里把 dots 描述成“command-line coding agent 的协议层”这个词选得很精准。它不是在做一个功能更丰富的 CLI而是在定义一种开发者与 AI 之间稳定的“交流格式”。可以这样理解普通 CLI 是两个人之间的即时通讯而 dots 是你们共同维护的一份项目日志加上一套约定俗成的协作规则。你不需要每次都把话说全因为它知道上下文。这套机制的核心组件包括点文件dotfile、状态栈state stack和上下文引用context reference。点文件就是存储历史状态的位置默认放在项目根目录的.dots/文件夹里可以被 Git 追踪。这点很重要因为 state 一旦入库就变成团队资产了——新成员 clone 代码后运行一次dots restore就能继承所有历史决策记录。状态栈则是按时间排列的状态快照支持回溯、分支、合并本质上是一个给 AI 交互用的 Git。上下文引用则允许你在对话中显式挂载某个历史任务或文件状态比如last-session、refactor:2026-03这种语法。我第一次看到这三个组件时的反应是这不就是把版本控制的思想搬到了 AI 交互层吗没错就是这么回事。而且从工程角度看这个设计很聪明它没有发明新的复杂协议而是复用了开发者已经熟悉的 Git 心智模型。学习成本被压到了极低。需要提醒的一点是dots 的持久化机制默认不上传云端所有状态都存在本地。官方说法是“privacy-first by default”。但这也带来一个问题如果你有多个开发机状态同步得自己想办法解决。目前社区的普遍做法是把.dots/目录放进去 iCloud/坚果云/Dropbox 这类网盘里同步或者直接放在一个单独的 Git 仓库里手动 push。我自己的经验是单机开发体验极好多机同步建议等官方出云同步方案或者自己先用 Git 仓库顶着。2.3 dots 与 sign in with ChatGPT 的联动逻辑这次 dots 发布时还埋了一个很关键的身份联动它可以直接用 ChatGPT 账号登录而不是传统的 API Key 方式。这个改变的背后逻辑值得展开聊一聊。以前用 Codex 或 OpenAI API身份认证靠 API Key。API Key 的问题在于它是静态的、与具体用户权限绑定的、而且没法做细粒度的组织级权限控制。团队协作时一个 Key 大家用审计基本无从谈起。dots 换成 ChatGPT 账号登录后身份体系变成了 OAuth 那套逻辑——权限、用量、历史记录都能和账号绑定组织管理者可以在后台配置成员的 AI 权限范围。用我熟悉的话说以前是“借钥匙开门”现在变成了“刷门禁卡”谁进了哪扇门、待了多久、拿了什么东西全部有记录。这直接改善了团队场景下的可管理性。我在一个五人的小团队里试了试leader 可以在 Org 后台给每个人分配不同的工具权限比如某些人只能用 dots 做代码生成某些人还能触发自动化部署流程。这在以前靠 API Key 基本没法精细管控。不过这里有个明显的现实问题需要大家注意国内开发者的账号获取和登录链路目前并不顺畅而 dots 的这个身份机制意味着你几乎没法绕开账号体系去“本地纯离线使用”。如果你所在的环境对账号登录有顾虑我的建议是先用单机 API Key 跑通逻辑等 OAuth 配置支持企业自建身份源之后再切到完整账号方案。3. ChatGPT Spaces从“会话”到“空间”的产品形态跃迁3.1 Spaces 解决了什么问题ChatGPT Spaces 是这次发布里最“产品向”的一个大动作。它解决的问题我总结成一句话把 AI 工作从“一次性会话”变成了“持续性空间状态”。这个转变不只是一个 UI 上的变化而是对 AI 协作方式的一次结构性调整。你可以把传统的 ChatGPT 对话理解成白板——用完擦掉下次重画。而 Space 更像一个“项目房间”房间里的每面墙上都贴着以前写过的便签、画过的草图、改过的方案。你随时进去都能接着上次的状态继续干活不需要重新描述“我们之前在做什么、做到哪了”。具体到功能层面Spaces 本质上是一个持久的、可协作的、多模态的 AI 工作区。它不再局限于文字对话窗口而是把聊天记录、文档、代码片段、生成图片、数据表格、API 调用记录全部组织在同一个空间里。每个 Space 都有自己的上下文窗口、自己的记忆索引、自己的成员权限。最让我觉得实用的是它的会话连续性。以前用 ChatGPT无论聊得多深入一旦开启新对话前面所有的上下文全部丢失。写长文档、做跨天项目时非常痛苦每次都要靠粘贴历史来“唤醒”AI 的记忆。Spaces 彻底改变了这一点——它保留了完整的上下文状态你关掉浏览器第二天打开AI 还是“昨天那个 AI”还记得你做到哪一步了、有哪些未决事项。3.2 对团队协作方式的实际影响我觉得 Spaces 真正有想象力的是团队协作维度。它支持多成员同时在线编辑同一个空间这已经不是“共享对话”了更像一个“AI 加持的共享工作台”。我给你描述一个实际场景。我们团队在做竞品分析时以前的分工是每个人各自用 ChatGPT 查资料、写分析最后贴到共享文档里汇总。这个过程最大的问题是信息孤岛——每个人的研究、假设、结论之间缺乏动态关联汇总时经常发现前后矛盾。现在我们用 Spaces 的方式完全不一样一个 Space 就是整个竞品分析项目成员进入后AI 自动共享全局上下文。你查到的资料、标注的重点、得出的结论其他成员在空间里随时可见。更关键的是AI 在回答某个人问题时会把其他人的分析也纳入参考——这个效果很像一个“所有人都能听见彼此想法的会议室”。实际用下来我的感受是Spaces 对 3-10 人左右的中小型团队尤其友好。人太少体现不出协作优势人太多空间会显得噪声很大需要更细的权限分级才能压得住。3.3 Spaces 与本地工作流的结合方式一个值得重视的细节是Spaces 提供了 API 接口这意味着它不是一个封闭的聊天工具而可以成为一个可编程的工作环境。官方示例里展示了如何用 Python 脚本向某个 Space 推送内容、拉取状态、甚至触发 AI 任务。比如我可以在 CI 流水线里加一个步骤构建完成后自动把测试报告和构建日志推送进项目的 Space然后 AI 自动分析失败原因、生成修复建议 对应的开发者在第二天上班前看到。这种“AI 空间作为团队信息中枢”的思路其实已经有点往项目管理工具比如 Notion、Linear的方向上靠了。区别是Spaces 里 AI 是主动成员不只是存储信息的数据库。再补充一个有点反直觉但实测有效的用法把 Spaces 当成长文写作的草稿箱。以前我在 ChatGPT 里写长篇技术文章超过一定长度后上下文就开始混乱。Spaces 的持久记忆机制让长文写作体验好了很多——第一天列大纲第二天写前半部分第三天接着写后半部分AI 全程记得你在写什么、核心论点是哪些、哪部分还没写。没有明显的上下文衰减感。4. GPT-6.1 Sol模型规格、架构重点与真实使用边界4.1 Sol 到底强在哪GPT-6.1 Sol 作为模型层的旗舰更新OpenAI 给出的宣传点集中在三块更强的多模态理解、更大的上下文窗口、以及更可控的推理过程。先说参数层面的官方数据我转述不对数字真实性背书Sol 的上下文窗口据说到了 4M token 级别这比上一代 6.0 的 1.5M 又上了一个台阶原生多模态能力不再局限于图片理解而是直接支持音视频流输入推理方面官方强调“过程监督”能力大幅增强在数学、代码调试等需要逐步推理的任务上错误率下降了肉眼可见的幅度。但我想说的是参数本身的参考价值有限。真正的差异在“怎么用”。Sol 最让我眼前一亮的是推理过程的可控性。以前的模型推理是一个“黑盒”——你给一个问题它直接给你答案中间经历了什么推理过程你没法干预。Sol 引入了一种叫做“推理路径调节”的机制你可以通过系统提示词给模型的推理过程设定边界比如“先用自然语言分析问题的约束条件再开始写代码”“每一步推理请先自检再给出结论”。这个功能对复杂工程任务非常有用。以前让模型改一段逻辑复杂的代码它经常“自作聪明”地做了不合理的假设。现在你可以明确约束它的推理路径——先让它还原需求、再让它列出改动影响面、最后才允许输出代码。整个过程可控度提升非常明显。4.2 4M 上下文窗口的实际意义与限制上下文窗口从 1.5M 升到 4M听起来是纯粹的利好但实际工程场景里它带来的收益比你想象中更复杂。对开发者来说大上下文的直接好处是整仓库级别的代码分析变得现实了。一个中大型项目的核心代码量大约在几十万到一两百万行之间折算成 token 大概就是 1M-3M。也就是说Sol 理论上可以一次性加载一个中型仓库的全部核心代码然后基于全局上下文做重构、找 bug、评估改动影响面。我实测了一个小型服务仓库约 8 万行代码含测试token 消耗大约在 1.2M 左右加载过程很顺利模型对跨文件的引用关系理解得相当准确——它甚至能主动指出“这个函数在/api/v1/handler.ts里被调用过改动它可能影响三个下游接口”。这是以前用 128K 上下文时根本不可能做到的。不过这里必须提醒一个重要限制**4M 上下文是“技术上支持的窗口”不是“实际好用的窗口”。**上下文越大推理耗时越长、单次调用成本越高。用 Sol 处理 4M 级别的完整上下文时首 Token 延迟明显增加实际体验大概在几十秒级别。这意味着它适合“深读大库”但不适合交互式、高频次的对话场景。我目前的工作流是把任务分层的高频小任务修改单个函数、解释一小段代码用 6.0 标准版延迟低性价比高低频复杂任务全库重构方案、跨模块影响面分析、大规模测试失败归因才上 Sol 开大窗口。这个分层在当前 API 定价结构下是成本最优解。4.3 多模态能力视频输入才是真正的变量Sol 的多模态升级里我认为值得开发者关注的是视频输入而不是传统的图片识别。官方 Demo 展示的场景是开发者录了一段报错视频包含屏幕操作命令行输出终端日志Sol 直接分析视频内容定位到了问题根因并给出了修复代码。这听起来像噱头但它背后的逻辑其实很合理——在很多实际开发场景中问题本身是动态的比如动画渲染 bug、竞态条件、音画不同步静态截图无法捕捉全貌而视频能提供时序信息。我在想这个能力真正实用的方向UI 自动化测试的失败分析。以前跑 E2E 测试失败后只能看截图和日志很多时候根本看不出问题出在哪个交互步骤。现在可以直接把测试录屏丢给 Sol让它分析“用户在第三步点击后界面出现了什么异常响应根因可能在哪里”。这个场景我觉得比“让 AI 看视频”听上去靠谱得多。需要注意的成本问题是视频 token 消耗非常快一分钟 1080P 视频折算成 token 大概在 5 万到 8 万之间。也就是说丢一个 10 分钟的视频进去光输入就是 50-80 万 token。按 Sol 的价格算单次分析成本不低。建议用的时候先截取关键片段别把整个视频无脑丢进去。4.4 一个务实的替代结论不是所有人都需要 Sol坦白说我对 Sol 的定位理解是它是为“处理超大上下文和高难度推理”设计的专业工具不是所有人的默认选择。如果你的工作集中在日常 CRUD 开发、接口联调、常见 bug 修复Sol 的推理增强和大窗口对你来说感知不强但成本却是实打实地增加了——API 价格大约是 6.0 标准版的 2.5 倍左右。我的建议是保持模型分层的思路简单任务用轻量级模型复杂任务上 Sol中间用标准版做缓冲。从这次 DevDay 的官方表述来看OpenAI 自己也在推这个方向——他们发布了模型路由 APIModelRouter让开发者动态决定哪些请求走 Sol、哪些走轻量模型。这也是这次 API 层面一个比较务实的更新我会在后面详细说。5. 应用层与 API 生态20 项发布里值得开发者动手的部分5.1 四个真正能立刻用起来的应用层更新如果不想被发布会的信息量淹没我帮你筛出了四个值得立刻动手的应用层更新。**第一个是 Codex 的云沙盒Cloud Sandbox正式开放。**之前 Codex 的云端执行环境是邀请制这次全面开放。它的价值在于你可以在云端沙盒里直接跑 Agent 生成的代码不用把不确定的代码拉回本地执行。沙盒自带网络隔离和资源限制意味着即使 Agent 生成了带破坏性的代码也不会波及你的本地环境。实测下来用沙盒跑自动化测试的体验比本地好很多——不占用本地 CPU而且环境崩了直接重置不用小心翼翼地清理残留进程。**第二个是 ChatGPT 开放了“技能商店”Skills Store的第三方发布通道。**这是应用生态的重要一步。技能Skills可以理解成“预制的 AI 工作流”比如“周报生成器”“代码 Review 助手”“竞品价格监控”。以前这些技能只能 OpenAI 官方做现在第三方开发者可以自己发布、定价、收分成。说白了这就是 AI 时代的 App Store 雏形。**第三个是 Responses API 正式 GA一般可用。**这不仅是发布更是整合。Responses API 把以前分散的 Chat Completion、Function Calling、Tool Use、多模态理解全部统一到一个接口体系里。对开发者最直接的好处是不用再为了“让模型调用一个外部工具”去手动拼接复杂的消息数组了接口层已经帮你处理好循环调用的逻辑。**第四个是 Realtime API 的语音延迟降到了 400ms 以内。**这个对做语音交互产品的人来说是实打实的体验升级。以前实时语音对话的延迟在 1 秒上下对话感明显“钝”。这次降到 400ms 以下后基本听不出机器感了。我拿自己做的语音助手实测了一下连续对话打断、插话、修改请求模型的响应速度都跟得上。5.2 ModelRouter动态路由的务实设计这次 API 更新里我个人最欣赏的是 ModelRouter模型路由 API。它解决的是一个很现实的成本问题一个大模型跑所有任务太贵了。ModelRouter 允许你定义路由规则根据任务复杂度、token 长度、推理难度自动选择最合适的模型。比如简单翻译任务走 mini 级模型中等推理走标准版复杂多步任务走 Sol。整个过程对上层业务透明——你只需调用同一个接口路由层自动帮你分配。从架构层面看这是一步“产品化”的对齐动作。因为无数做 AI 应用的公司早就发现所有请求都打最强模型成本扛不住全部用轻量模型复杂任务效果又不行。与其让开发者自己维护一套复杂的模型选择和降级逻辑不如平台直接把这个路由能力做进去。实际接入后的成本数据可以参考我的一台流量转发服务接入 ModelRouter 后API 账单大约下降了 40%-50%。主要原因是大部分请求都是短文本、低复杂度走 mini 级模型就够用了以前统一打标准版纯属浪费。需要注意的一点是路由规则调优很需要经验。如果不加区分的把规则设成“长文本一律走 Sol”账单还是会爆炸。我的经验是先用线上真实流量做一次成本分析找出哪些请求类型实际消耗最高再针对性设规则。5.3 API 定价与配额策略的变化这次 DevDay 在商业化层面也做了不少调整主要是三个方向分级定价、批量折扣、以及开发者扶持计划。分级定价的意思是新的 API 价格按模型的能力等级拆成三档mini 级、标准级、旗舰级。以输入 token 价格为例大致在 0.15 美元 / 0.6 美元 / 2.0 美元每百万 token 这样一个范围具体价格以官方为准。这个分档的思路就是配合 ModelRouter 使用的——鼓励开发者按任务类型选配模型而不是一个模型打天下。批量折扣针对的是离线任务。如果你提交的请求是非实时、可异步处理的比如夜间数据清洗API 提供了 50% 左右的折扣价。这背后其实是算力调度的逻辑高峰期算力紧张平台愿意用折扣引导任务错峰执行低谷期算力闲置用低价吸引开发者填入任务双方都受益。开发者扶持计划方面OpenAI 给初创公司提供了配额的“免费额度成长额度”双轨机制。免费额度是基础体验额度有限制成长额度是根据你 API 用量增长而逐步解锁的额外折扣本质上是“用得越多越便宜”的激励逻辑。这些变化对独立开发者的实际影响就是**用 AI 做产品的边际成本在下降但精细化管理 API 用量的必要性在上升。**以后拼的不是“谁用了更好的模型”而是“谁用了更合适的模型搭配”。6. 模型能力之外开发者体验与生态规则的变化6.1 用户身份体系与配额管理的变化这次发布里有一个容易被忽略但对团队影响深远的更新用户身份体系User Identity和配额管理Quota Management正式开放 API。以前使用 OpenAI API配额是“项目级”的——一个项目一个 Key所有请求共享这一个 Key 的额度。这样带来的问题很实际团队里谁消耗了多少算力完全看不出来。遇到计费异常根本没法定位是哪个人、哪个任务导致的。现在身份体系开放后你可以在每次 API 请求里传入user_id参数平台侧会按用户维度统计用量、设置配额、做异常告警。这对 B2B 性质的产品尤其重要——如果你做了一个 AI 工具给客户用现在终于可以做到“按用户维度”计费和限流了。从技术角度看这个改动配合我之前提到的 dots 账号登录机制其实已经拼出了 OpenAI 完整的商业化版图身份层ChatGPT 账号 / OAuth、工具层Codex / dots / API、应用层ChatGPT / Spaces / Skills每个层级之间都是贯通的。用户在每个层级的行为都会沉淀到同一个身份账户体系里。6.2 开发者支持的规范化“响应规范”与“行为准则”今年还有一组不显眼但很关键的发布是“开发者响应规范”和“AI 行为准则”的正式文档化。这听起来像是“没什么用的文档更新”但实际意义很大。原来开发者与 OpenAI 平台之间很多规则是“潜规则”——哪些内容不能用、哪些行为会被限制、申诉走什么流程都不透明。现在的文档把这些完全白纸黑字地固化了违规行为定义、处罚梯度、申诉路径、人工复核机制全部有明确条款。站在开发者角度这其实是一种保护。以前一个账号被封申诉无门也不知道问题出在哪现在有了明确规范至少可以自查、自证、走申诉流程。运营 AI 应用的人应该都懂这种“规则可预期”有多重要。另外一个相关更新是官方开始在 API 层面明确支持可追溯的内容审计。每次请求的输入、输出、模型选择、路由决策都能导出结构化日志这在合规压力大的行业金融、医疗里几乎是刚需。以前这块基本靠开发者自己包装日志现在平台侧直接提供了标准化的审计接口。6.3 开源与本地模型的生态定位最后必须提一句 OpenAI 对开源和本地模型生态的态度变化——这是今年比较微妙的一个信号。虽然没有明确宣布“我们要开源某模型”但 DevDay 上确实释放了两个信号一是通过 API 兼容层OpenAI Compatible API继续接纳本地模型生态。现在开发者可以把自己微调的模型比如基于 Llama、Qwen 或其他开源底座微调的注册进平台的模型管理系统通过标准 API 调用和官方模型统一管理。二是正式发布了“模型接入标准”Model Interop Standard。这套标准定义了模型服务接入的统一格式核心目标是让开发者免受“换模型就要改代码”的困扰。接入标准后无论底层是 OpenAI 的 Sol、还是开源的 Llama、或者是未来的新模型上层 API 完全不变。这个信号往深了说意味着 OpenAI 已经不把自己定位成“唯一的模型提供者”了而是想成为“所有模型的事实调度层”。这既是防御性布局也是更大的野心——模型可以有很多个API 入口可以只有一个。7. 开发者真正该行动的几个方向信息量这么大的发布会看热闹容易找到自己该做的事难。我根据自己的实测感受和踩坑经历把优先级给各位排一下。**第一优先级把 dots 引入日常命令行工作流。**这个没有任何理由拖延。它就是 Codex 现在最值得用的形态。迁移成本大约一个下午收益是长期性的——每次省去的“重新描述上下文”时间累计起来非常可观。注意提前规划好本地状态的备份策略别在初始化第一个项目时就忽略这一点。**第二优先级用 Spaces 重构团队协作方式。**如果你是团队里负责引入新工具的人Spaces 值得立刻建一个真实项目试运行。不需要把它当成全功能项目管理系统来用先从“团队共享的 AI 工作台”这个定位切入跑两周看看大家的使用体验和接受度。我观察到的规律是团队里一旦有人养成了“把工作过程沉淀进 Space”的习惯其他人会很快跟上。**第三优先级评估 Sol 有没有进你技术栈的必要。**如果你主要做中小型任务、对延迟敏感、也对成本敏感Sol 可以先不进生产环境在测试环境跑几个真实场景验证效果再说。当然如果你有大型代码库深度分析、长文档推理这类需求Sol 的大窗口和推理可控性确实是目前最合适的选择。一个更务实的路线是先接入 ModelRouter让它按规则自动评估哪些请求值得走 Sol先让数据和账单说话。**第四优先级应用层更新可以等社区沉淀再跟进。**Skills Store 生态、Responses API 升级、Realtime API 优化这些我都建议先从文档入手了解能力边界但不必在这一两周内就做深度集成。等社区涌现出一些成熟的实践模板之后再借着现成的模式接入比自己摸索踩坑要高效得多。当然如果你是做语音交互产品的Realtime API 那个 400ms 延迟值得立刻测一测。我自己的参与方式是先在一个内部工具项目上完整跑通 dotsSpaces轻量模型 API 的组合验证这套工作流对中型团队是否稳定可靠。跑通了再逐步把更多业务场景迁移进去。这个思路也推荐给你——别追求一步到位先在一个合适的项目上闭环再决定要不要全面铺开。
1. 发布会整体量级与最值得关注的变化先说结论这届 OpenAI DevDay 从信息密度上看是历届最高的一次。20 多项发布里真正算得上“改变开发方式”的并不多但每一个都踩在关键位置上。如果你只看热搜标题可能会以为重点是 GPT-6.1 Sol 这个新模型但实际参加完、看完所有 Demo 之后我的判断是dots 和 ChatGPT Spaces 才是这届 DevDay 真正意义上的“平台级”动作模型更新反而只是配套。先说个现场体感。今年 DevDay 的开场没有像前两年那样直接甩基准测试分数而是花了将近二十分钟讲“开发者现在到底在用什么方式写代码”。这个开场方向本身就暗示了整场发布会的重心——工具链、工作流、协作方式而不是单一的模型能力。换句话说OpenAI 在试图回答一个问题当模型能力趋于同质化开发者为什么还要留在你的生态里答案就是这 20 多项发布里埋着的那条主线从“调用模型”转向“构建环境”。我按自己的理解把这次发布分成了四层第一层是开发范式层对应 dots 和 Codex 相关的命令行升级第二层是产品形态层对应 ChatGPT Spaces第三层是模型能力层对应 GPT-6.1 Sol 以及配套的多模态接口第四层是生态规则层包括 API 价格调整、配额策略、第三方集成认证等等。下面几节我会一层一层拆开讲重点放在 dots 和 Spaces 上因为这两个东西对开发者的日常工作流影响最直接。如果你是那种“只想知道该用哪个、怎么用”的人我的建议已经可以提前给你命令行重度用户直接上 dots它值得你花一个下午迁移工作流团队协作者重点看 Spaces它可能是目前把 AI 引入项目过程最自然的产品形态至于 GPT-6.1 Sol先别急着替换你现有的 6.0 工作流等 benchmark 之外的实测数据出来再说——当然如果你对上下文窗口有硬需求那另当别论。2. dots从功能命令到协作协议的进化逻辑2.1 dots 到底是什么它和传统 CLI 工具的本质区别dots 是这次发布里最容易被低估的一个。很多人的第一反应是“又一个命令行工具”但实际用过之后你会发现它不是“又一个”而是把整个 Codex 的交互模型重新定义了。旧模型是这样的你在终端里敲命令Agent 帮你改代码任务结束会话结束。每个命令是一次独立的、无状态的交互。而 dots 做的事情是给这些交互加了“持久化上下文”和“跨会话状态”。你可以把它理解为终端里的每一次对话、每一次代码改动、每一次决策记录都会沉淀成一个可追溯的“点”dot。下次你再发起任务时不需要重新描述背景dots 会基于历史状态自动补齐上下文。这一点听起来简单但实际影响非常大。传统 CLI 工具包括早期的 Codex 命令行版最大的痛点就是“每次都要重新调教”。你告诉它项目结构、告诉它技术栈、告诉它避开哪些坑然后回车任务结束。第二次再来它全都忘了。dots 把这个过程彻底去掉了——你的历史决策、项目偏好、踩坑记录全部保留在本地状态里Agent 每次启动时自动加载。用我现在的工作方式来举例我在维护一个微服务项目里面有十几个仓库。以前用 Codex 处理跨仓库任务每次都要先花五分钟粘贴背景信息。现在只需要dots init一次之后每次进入仓库它自己就知道这是什么项目、用的是什么框架、之前改过哪些模块、还有哪些 TODO 挂在哪个版本里。2.2 从“命令”到“协议”dots 的嵌套理念官方文档里把 dots 描述成“command-line coding agent 的协议层”这个词选得很精准。它不是在做一个功能更丰富的 CLI而是在定义一种开发者与 AI 之间稳定的“交流格式”。可以这样理解普通 CLI 是两个人之间的即时通讯而 dots 是你们共同维护的一份项目日志加上一套约定俗成的协作规则。你不需要每次都把话说全因为它知道上下文。这套机制的核心组件包括点文件dotfile、状态栈state stack和上下文引用context reference。点文件就是存储历史状态的位置默认放在项目根目录的.dots/文件夹里可以被 Git 追踪。这点很重要因为 state 一旦入库就变成团队资产了——新成员 clone 代码后运行一次dots restore就能继承所有历史决策记录。状态栈则是按时间排列的状态快照支持回溯、分支、合并本质上是一个给 AI 交互用的 Git。上下文引用则允许你在对话中显式挂载某个历史任务或文件状态比如last-session、refactor:2026-03这种语法。我第一次看到这三个组件时的反应是这不就是把版本控制的思想搬到了 AI 交互层吗没错就是这么回事。而且从工程角度看这个设计很聪明它没有发明新的复杂协议而是复用了开发者已经熟悉的 Git 心智模型。学习成本被压到了极低。需要提醒的一点是dots 的持久化机制默认不上传云端所有状态都存在本地。官方说法是“privacy-first by default”。但这也带来一个问题如果你有多个开发机状态同步得自己想办法解决。目前社区的普遍做法是把.dots/目录放进去 iCloud/坚果云/Dropbox 这类网盘里同步或者直接放在一个单独的 Git 仓库里手动 push。我自己的经验是单机开发体验极好多机同步建议等官方出云同步方案或者自己先用 Git 仓库顶着。2.3 dots 与 sign in with ChatGPT 的联动逻辑这次 dots 发布时还埋了一个很关键的身份联动它可以直接用 ChatGPT 账号登录而不是传统的 API Key 方式。这个改变的背后逻辑值得展开聊一聊。以前用 Codex 或 OpenAI API身份认证靠 API Key。API Key 的问题在于它是静态的、与具体用户权限绑定的、而且没法做细粒度的组织级权限控制。团队协作时一个 Key 大家用审计基本无从谈起。dots 换成 ChatGPT 账号登录后身份体系变成了 OAuth 那套逻辑——权限、用量、历史记录都能和账号绑定组织管理者可以在后台配置成员的 AI 权限范围。用我熟悉的话说以前是“借钥匙开门”现在变成了“刷门禁卡”谁进了哪扇门、待了多久、拿了什么东西全部有记录。这直接改善了团队场景下的可管理性。我在一个五人的小团队里试了试leader 可以在 Org 后台给每个人分配不同的工具权限比如某些人只能用 dots 做代码生成某些人还能触发自动化部署流程。这在以前靠 API Key 基本没法精细管控。不过这里有个明显的现实问题需要大家注意国内开发者的账号获取和登录链路目前并不顺畅而 dots 的这个身份机制意味着你几乎没法绕开账号体系去“本地纯离线使用”。如果你所在的环境对账号登录有顾虑我的建议是先用单机 API Key 跑通逻辑等 OAuth 配置支持企业自建身份源之后再切到完整账号方案。3. ChatGPT Spaces从“会话”到“空间”的产品形态跃迁3.1 Spaces 解决了什么问题ChatGPT Spaces 是这次发布里最“产品向”的一个大动作。它解决的问题我总结成一句话把 AI 工作从“一次性会话”变成了“持续性空间状态”。这个转变不只是一个 UI 上的变化而是对 AI 协作方式的一次结构性调整。你可以把传统的 ChatGPT 对话理解成白板——用完擦掉下次重画。而 Space 更像一个“项目房间”房间里的每面墙上都贴着以前写过的便签、画过的草图、改过的方案。你随时进去都能接着上次的状态继续干活不需要重新描述“我们之前在做什么、做到哪了”。具体到功能层面Spaces 本质上是一个持久的、可协作的、多模态的 AI 工作区。它不再局限于文字对话窗口而是把聊天记录、文档、代码片段、生成图片、数据表格、API 调用记录全部组织在同一个空间里。每个 Space 都有自己的上下文窗口、自己的记忆索引、自己的成员权限。最让我觉得实用的是它的会话连续性。以前用 ChatGPT无论聊得多深入一旦开启新对话前面所有的上下文全部丢失。写长文档、做跨天项目时非常痛苦每次都要靠粘贴历史来“唤醒”AI 的记忆。Spaces 彻底改变了这一点——它保留了完整的上下文状态你关掉浏览器第二天打开AI 还是“昨天那个 AI”还记得你做到哪一步了、有哪些未决事项。3.2 对团队协作方式的实际影响我觉得 Spaces 真正有想象力的是团队协作维度。它支持多成员同时在线编辑同一个空间这已经不是“共享对话”了更像一个“AI 加持的共享工作台”。我给你描述一个实际场景。我们团队在做竞品分析时以前的分工是每个人各自用 ChatGPT 查资料、写分析最后贴到共享文档里汇总。这个过程最大的问题是信息孤岛——每个人的研究、假设、结论之间缺乏动态关联汇总时经常发现前后矛盾。现在我们用 Spaces 的方式完全不一样一个 Space 就是整个竞品分析项目成员进入后AI 自动共享全局上下文。你查到的资料、标注的重点、得出的结论其他成员在空间里随时可见。更关键的是AI 在回答某个人问题时会把其他人的分析也纳入参考——这个效果很像一个“所有人都能听见彼此想法的会议室”。实际用下来我的感受是Spaces 对 3-10 人左右的中小型团队尤其友好。人太少体现不出协作优势人太多空间会显得噪声很大需要更细的权限分级才能压得住。3.3 Spaces 与本地工作流的结合方式一个值得重视的细节是Spaces 提供了 API 接口这意味着它不是一个封闭的聊天工具而可以成为一个可编程的工作环境。官方示例里展示了如何用 Python 脚本向某个 Space 推送内容、拉取状态、甚至触发 AI 任务。比如我可以在 CI 流水线里加一个步骤构建完成后自动把测试报告和构建日志推送进项目的 Space然后 AI 自动分析失败原因、生成修复建议 对应的开发者在第二天上班前看到。这种“AI 空间作为团队信息中枢”的思路其实已经有点往项目管理工具比如 Notion、Linear的方向上靠了。区别是Spaces 里 AI 是主动成员不只是存储信息的数据库。再补充一个有点反直觉但实测有效的用法把 Spaces 当成长文写作的草稿箱。以前我在 ChatGPT 里写长篇技术文章超过一定长度后上下文就开始混乱。Spaces 的持久记忆机制让长文写作体验好了很多——第一天列大纲第二天写前半部分第三天接着写后半部分AI 全程记得你在写什么、核心论点是哪些、哪部分还没写。没有明显的上下文衰减感。4. GPT-6.1 Sol模型规格、架构重点与真实使用边界4.1 Sol 到底强在哪GPT-6.1 Sol 作为模型层的旗舰更新OpenAI 给出的宣传点集中在三块更强的多模态理解、更大的上下文窗口、以及更可控的推理过程。先说参数层面的官方数据我转述不对数字真实性背书Sol 的上下文窗口据说到了 4M token 级别这比上一代 6.0 的 1.5M 又上了一个台阶原生多模态能力不再局限于图片理解而是直接支持音视频流输入推理方面官方强调“过程监督”能力大幅增强在数学、代码调试等需要逐步推理的任务上错误率下降了肉眼可见的幅度。但我想说的是参数本身的参考价值有限。真正的差异在“怎么用”。Sol 最让我眼前一亮的是推理过程的可控性。以前的模型推理是一个“黑盒”——你给一个问题它直接给你答案中间经历了什么推理过程你没法干预。Sol 引入了一种叫做“推理路径调节”的机制你可以通过系统提示词给模型的推理过程设定边界比如“先用自然语言分析问题的约束条件再开始写代码”“每一步推理请先自检再给出结论”。这个功能对复杂工程任务非常有用。以前让模型改一段逻辑复杂的代码它经常“自作聪明”地做了不合理的假设。现在你可以明确约束它的推理路径——先让它还原需求、再让它列出改动影响面、最后才允许输出代码。整个过程可控度提升非常明显。4.2 4M 上下文窗口的实际意义与限制上下文窗口从 1.5M 升到 4M听起来是纯粹的利好但实际工程场景里它带来的收益比你想象中更复杂。对开发者来说大上下文的直接好处是整仓库级别的代码分析变得现实了。一个中大型项目的核心代码量大约在几十万到一两百万行之间折算成 token 大概就是 1M-3M。也就是说Sol 理论上可以一次性加载一个中型仓库的全部核心代码然后基于全局上下文做重构、找 bug、评估改动影响面。我实测了一个小型服务仓库约 8 万行代码含测试token 消耗大约在 1.2M 左右加载过程很顺利模型对跨文件的引用关系理解得相当准确——它甚至能主动指出“这个函数在/api/v1/handler.ts里被调用过改动它可能影响三个下游接口”。这是以前用 128K 上下文时根本不可能做到的。不过这里必须提醒一个重要限制**4M 上下文是“技术上支持的窗口”不是“实际好用的窗口”。**上下文越大推理耗时越长、单次调用成本越高。用 Sol 处理 4M 级别的完整上下文时首 Token 延迟明显增加实际体验大概在几十秒级别。这意味着它适合“深读大库”但不适合交互式、高频次的对话场景。我目前的工作流是把任务分层的高频小任务修改单个函数、解释一小段代码用 6.0 标准版延迟低性价比高低频复杂任务全库重构方案、跨模块影响面分析、大规模测试失败归因才上 Sol 开大窗口。这个分层在当前 API 定价结构下是成本最优解。4.3 多模态能力视频输入才是真正的变量Sol 的多模态升级里我认为值得开发者关注的是视频输入而不是传统的图片识别。官方 Demo 展示的场景是开发者录了一段报错视频包含屏幕操作命令行输出终端日志Sol 直接分析视频内容定位到了问题根因并给出了修复代码。这听起来像噱头但它背后的逻辑其实很合理——在很多实际开发场景中问题本身是动态的比如动画渲染 bug、竞态条件、音画不同步静态截图无法捕捉全貌而视频能提供时序信息。我在想这个能力真正实用的方向UI 自动化测试的失败分析。以前跑 E2E 测试失败后只能看截图和日志很多时候根本看不出问题出在哪个交互步骤。现在可以直接把测试录屏丢给 Sol让它分析“用户在第三步点击后界面出现了什么异常响应根因可能在哪里”。这个场景我觉得比“让 AI 看视频”听上去靠谱得多。需要注意的成本问题是视频 token 消耗非常快一分钟 1080P 视频折算成 token 大概在 5 万到 8 万之间。也就是说丢一个 10 分钟的视频进去光输入就是 50-80 万 token。按 Sol 的价格算单次分析成本不低。建议用的时候先截取关键片段别把整个视频无脑丢进去。4.4 一个务实的替代结论不是所有人都需要 Sol坦白说我对 Sol 的定位理解是它是为“处理超大上下文和高难度推理”设计的专业工具不是所有人的默认选择。如果你的工作集中在日常 CRUD 开发、接口联调、常见 bug 修复Sol 的推理增强和大窗口对你来说感知不强但成本却是实打实地增加了——API 价格大约是 6.0 标准版的 2.5 倍左右。我的建议是保持模型分层的思路简单任务用轻量级模型复杂任务上 Sol中间用标准版做缓冲。从这次 DevDay 的官方表述来看OpenAI 自己也在推这个方向——他们发布了模型路由 APIModelRouter让开发者动态决定哪些请求走 Sol、哪些走轻量模型。这也是这次 API 层面一个比较务实的更新我会在后面详细说。5. 应用层与 API 生态20 项发布里值得开发者动手的部分5.1 四个真正能立刻用起来的应用层更新如果不想被发布会的信息量淹没我帮你筛出了四个值得立刻动手的应用层更新。**第一个是 Codex 的云沙盒Cloud Sandbox正式开放。**之前 Codex 的云端执行环境是邀请制这次全面开放。它的价值在于你可以在云端沙盒里直接跑 Agent 生成的代码不用把不确定的代码拉回本地执行。沙盒自带网络隔离和资源限制意味着即使 Agent 生成了带破坏性的代码也不会波及你的本地环境。实测下来用沙盒跑自动化测试的体验比本地好很多——不占用本地 CPU而且环境崩了直接重置不用小心翼翼地清理残留进程。**第二个是 ChatGPT 开放了“技能商店”Skills Store的第三方发布通道。**这是应用生态的重要一步。技能Skills可以理解成“预制的 AI 工作流”比如“周报生成器”“代码 Review 助手”“竞品价格监控”。以前这些技能只能 OpenAI 官方做现在第三方开发者可以自己发布、定价、收分成。说白了这就是 AI 时代的 App Store 雏形。**第三个是 Responses API 正式 GA一般可用。**这不仅是发布更是整合。Responses API 把以前分散的 Chat Completion、Function Calling、Tool Use、多模态理解全部统一到一个接口体系里。对开发者最直接的好处是不用再为了“让模型调用一个外部工具”去手动拼接复杂的消息数组了接口层已经帮你处理好循环调用的逻辑。**第四个是 Realtime API 的语音延迟降到了 400ms 以内。**这个对做语音交互产品的人来说是实打实的体验升级。以前实时语音对话的延迟在 1 秒上下对话感明显“钝”。这次降到 400ms 以下后基本听不出机器感了。我拿自己做的语音助手实测了一下连续对话打断、插话、修改请求模型的响应速度都跟得上。5.2 ModelRouter动态路由的务实设计这次 API 更新里我个人最欣赏的是 ModelRouter模型路由 API。它解决的是一个很现实的成本问题一个大模型跑所有任务太贵了。ModelRouter 允许你定义路由规则根据任务复杂度、token 长度、推理难度自动选择最合适的模型。比如简单翻译任务走 mini 级模型中等推理走标准版复杂多步任务走 Sol。整个过程对上层业务透明——你只需调用同一个接口路由层自动帮你分配。从架构层面看这是一步“产品化”的对齐动作。因为无数做 AI 应用的公司早就发现所有请求都打最强模型成本扛不住全部用轻量模型复杂任务效果又不行。与其让开发者自己维护一套复杂的模型选择和降级逻辑不如平台直接把这个路由能力做进去。实际接入后的成本数据可以参考我的一台流量转发服务接入 ModelRouter 后API 账单大约下降了 40%-50%。主要原因是大部分请求都是短文本、低复杂度走 mini 级模型就够用了以前统一打标准版纯属浪费。需要注意的一点是路由规则调优很需要经验。如果不加区分的把规则设成“长文本一律走 Sol”账单还是会爆炸。我的经验是先用线上真实流量做一次成本分析找出哪些请求类型实际消耗最高再针对性设规则。5.3 API 定价与配额策略的变化这次 DevDay 在商业化层面也做了不少调整主要是三个方向分级定价、批量折扣、以及开发者扶持计划。分级定价的意思是新的 API 价格按模型的能力等级拆成三档mini 级、标准级、旗舰级。以输入 token 价格为例大致在 0.15 美元 / 0.6 美元 / 2.0 美元每百万 token 这样一个范围具体价格以官方为准。这个分档的思路就是配合 ModelRouter 使用的——鼓励开发者按任务类型选配模型而不是一个模型打天下。批量折扣针对的是离线任务。如果你提交的请求是非实时、可异步处理的比如夜间数据清洗API 提供了 50% 左右的折扣价。这背后其实是算力调度的逻辑高峰期算力紧张平台愿意用折扣引导任务错峰执行低谷期算力闲置用低价吸引开发者填入任务双方都受益。开发者扶持计划方面OpenAI 给初创公司提供了配额的“免费额度成长额度”双轨机制。免费额度是基础体验额度有限制成长额度是根据你 API 用量增长而逐步解锁的额外折扣本质上是“用得越多越便宜”的激励逻辑。这些变化对独立开发者的实际影响就是**用 AI 做产品的边际成本在下降但精细化管理 API 用量的必要性在上升。**以后拼的不是“谁用了更好的模型”而是“谁用了更合适的模型搭配”。6. 模型能力之外开发者体验与生态规则的变化6.1 用户身份体系与配额管理的变化这次发布里有一个容易被忽略但对团队影响深远的更新用户身份体系User Identity和配额管理Quota Management正式开放 API。以前使用 OpenAI API配额是“项目级”的——一个项目一个 Key所有请求共享这一个 Key 的额度。这样带来的问题很实际团队里谁消耗了多少算力完全看不出来。遇到计费异常根本没法定位是哪个人、哪个任务导致的。现在身份体系开放后你可以在每次 API 请求里传入user_id参数平台侧会按用户维度统计用量、设置配额、做异常告警。这对 B2B 性质的产品尤其重要——如果你做了一个 AI 工具给客户用现在终于可以做到“按用户维度”计费和限流了。从技术角度看这个改动配合我之前提到的 dots 账号登录机制其实已经拼出了 OpenAI 完整的商业化版图身份层ChatGPT 账号 / OAuth、工具层Codex / dots / API、应用层ChatGPT / Spaces / Skills每个层级之间都是贯通的。用户在每个层级的行为都会沉淀到同一个身份账户体系里。6.2 开发者支持的规范化“响应规范”与“行为准则”今年还有一组不显眼但很关键的发布是“开发者响应规范”和“AI 行为准则”的正式文档化。这听起来像是“没什么用的文档更新”但实际意义很大。原来开发者与 OpenAI 平台之间很多规则是“潜规则”——哪些内容不能用、哪些行为会被限制、申诉走什么流程都不透明。现在的文档把这些完全白纸黑字地固化了违规行为定义、处罚梯度、申诉路径、人工复核机制全部有明确条款。站在开发者角度这其实是一种保护。以前一个账号被封申诉无门也不知道问题出在哪现在有了明确规范至少可以自查、自证、走申诉流程。运营 AI 应用的人应该都懂这种“规则可预期”有多重要。另外一个相关更新是官方开始在 API 层面明确支持可追溯的内容审计。每次请求的输入、输出、模型选择、路由决策都能导出结构化日志这在合规压力大的行业金融、医疗里几乎是刚需。以前这块基本靠开发者自己包装日志现在平台侧直接提供了标准化的审计接口。6.3 开源与本地模型的生态定位最后必须提一句 OpenAI 对开源和本地模型生态的态度变化——这是今年比较微妙的一个信号。虽然没有明确宣布“我们要开源某模型”但 DevDay 上确实释放了两个信号一是通过 API 兼容层OpenAI Compatible API继续接纳本地模型生态。现在开发者可以把自己微调的模型比如基于 Llama、Qwen 或其他开源底座微调的注册进平台的模型管理系统通过标准 API 调用和官方模型统一管理。二是正式发布了“模型接入标准”Model Interop Standard。这套标准定义了模型服务接入的统一格式核心目标是让开发者免受“换模型就要改代码”的困扰。接入标准后无论底层是 OpenAI 的 Sol、还是开源的 Llama、或者是未来的新模型上层 API 完全不变。这个信号往深了说意味着 OpenAI 已经不把自己定位成“唯一的模型提供者”了而是想成为“所有模型的事实调度层”。这既是防御性布局也是更大的野心——模型可以有很多个API 入口可以只有一个。7. 开发者真正该行动的几个方向信息量这么大的发布会看热闹容易找到自己该做的事难。我根据自己的实测感受和踩坑经历把优先级给各位排一下。**第一优先级把 dots 引入日常命令行工作流。**这个没有任何理由拖延。它就是 Codex 现在最值得用的形态。迁移成本大约一个下午收益是长期性的——每次省去的“重新描述上下文”时间累计起来非常可观。注意提前规划好本地状态的备份策略别在初始化第一个项目时就忽略这一点。**第二优先级用 Spaces 重构团队协作方式。**如果你是团队里负责引入新工具的人Spaces 值得立刻建一个真实项目试运行。不需要把它当成全功能项目管理系统来用先从“团队共享的 AI 工作台”这个定位切入跑两周看看大家的使用体验和接受度。我观察到的规律是团队里一旦有人养成了“把工作过程沉淀进 Space”的习惯其他人会很快跟上。**第三优先级评估 Sol 有没有进你技术栈的必要。**如果你主要做中小型任务、对延迟敏感、也对成本敏感Sol 可以先不进生产环境在测试环境跑几个真实场景验证效果再说。当然如果你有大型代码库深度分析、长文档推理这类需求Sol 的大窗口和推理可控性确实是目前最合适的选择。一个更务实的路线是先接入 ModelRouter让它按规则自动评估哪些请求值得走 Sol先让数据和账单说话。**第四优先级应用层更新可以等社区沉淀再跟进。**Skills Store 生态、Responses API 升级、Realtime API 优化这些我都建议先从文档入手了解能力边界但不必在这一两周内就做深度集成。等社区涌现出一些成熟的实践模板之后再借着现成的模式接入比自己摸索踩坑要高效得多。当然如果你是做语音交互产品的Realtime API 那个 400ms 延迟值得立刻测一测。我自己的参与方式是先在一个内部工具项目上完整跑通 dotsSpaces轻量模型 API 的组合验证这套工作流对中型团队是否稳定可靠。跑通了再逐步把更多业务场景迁移进去。这个思路也推荐给你——别追求一步到位先在一个合适的项目上闭环再决定要不要全面铺开。
