1. 这场发布会到底讲了什么从标题拆出四条主线先把标题拆开看。OpenAI DevDay 2026 全程回顾20 多项发布三个被点名的重点dots、ChatGPT Spaces、GPT-6.1 Sol。热搜词里还夹着一堆开发者日常关心的东西——API key、价格、命令行编码代理、语音兼容接口、账号会话安全。把这些信息拼在一起这场发布会的画像其实很清楚它不是单纯发一个新模型而是把模型、产品形态、开发者工具链、账号与计费体系一次性往前推了一大步。我先把四条主线摆出来后面每一节都围绕它们展开。第一条主线是模型层。GPT-6.1 Sol 是这次的主角。名字里的 Sol 不是随便起的代号从发布节奏看它承担的是主力推理模型的角色而不是某个垂直场景的试验品。热搜里同时出现 API key、API 价格说明大家第一反应是这东西怎么接、多少钱。第二条主线是产品形态层。ChatGPT Spaces 把 ChatGPT 从一个对话框变成一个可以放东西的空间。这个变化看着小实际影响很大因为它改变了用户组织上下文的方式。第三条主线是开发者工具层。dots 和 Codex 相关的命令行工具是这次最容易被低估的部分。热搜里welcome to codexcommand-line coding agentmissing optional dependency openai/codex-win32-x64这些词全是开发者踩坑时才会搜的说明已经有人上手了。第四条主线是账号与安全层。热搜里泄露了 openai 账号会话 json 怎么办这条特别扎眼。每次大版本发布账号体系一动会话凭证的处理就容易出问题。这条我会单独用一节讲清楚。提示本文所有涉及具体参数、价格、命令的地方都是基于公开信息和常见工程实践的合理还原。发布会现场细节以官方文档为准我写的是一个从业者拿到这些信息后会怎么理解、怎么用。适合谁看三类人。第一类是正在评估要不要把业务迁到新模型上的技术负责人第二类是天天跟 API 打交道、关心价格和兼容性的开发者第三类是普通 ChatGPT 用户想知道 Spaces 到底值不值得用。三类人的关注点不一样我会分开讲。2. GPT-6.1 Sol主力模型换代开发者最该关心什么2.1 Sol 这个代号背后的定位逻辑OpenAI 给模型起代号一向有讲究。早期用 GPT-3、GPT-4 这种纯数字后来开始加后缀比如 turbo、o 系列。Sol 这个词本身是太阳的意思从命名习惯推断它大概率代表的是一个通用主力定位而不是像 o 系列那样偏重推理链、也不是像 mini 那样偏重轻量。为什么这么判断看热搜词的结构。如果 Sol 是个垂直模型热搜里应该出现大量Sol 适合什么任务Sol vs 某某这类对比词。但实际热搜里出现的是openai api keyopenai api 价格openai compatible speech——这些全是接入层和成本层的词。这说明大家默认 Sol 是要被大规模接入生产环境的而不是拿来玩玩的。对开发者的实际含义是你现有的调用代码大概率只需要改模型名不需要改请求结构。这是 OpenAI 一贯的兼容策略——新模型尽量复用旧的 chat completions 或 responses 接口格式。我实测过几次模型换代真正需要改代码的地方通常只有三处模型名、max_tokens 上限、以及某些新参数是否被支持。2.2 接入前必须搞清楚的三个参数不管你用哪种语言调 API有三个参数是换代时最容易出问题的。第一个是模型标识符。GPT-6.1 Sol 在 API 里的字符串大概率是类似gpt-6.1-sol这种形式。别想当然写成gpt-6.1很多 404 错误就是这么来的。我的习惯是先把模型名写进一个环境变量代码里只引用变量这样换代时改一处就行。第二个是上下文窗口。新模型通常会扩大上下文但扩大不等于免费。上下文越长单次请求的 token 消耗越大成本上升是线性的甚至超线性的。我一般会先查清楚窗口上限然后在代码里设一个软上限比如只用 60% 的窗口留出余量给输出。第三个是输出 token 上限。这个参数在不同模型上默认值不一样。如果你不显式设置可能会遇到输出被截断的情况。下面是一个典型的调用示例import os from openai import OpenAI client OpenAI(api_keyos.environ[OPENAI_API_KEY]) resp client.chat.completions.create( modelos.environ.get(MODEL_NAME, gpt-6.1-sol), messages[ {role: system, content: 你是一个严谨的技术助手。}, {role: user, content: 解释一下向量数据库的索引原理。} ], max_tokens2048, temperature0.3 ) print(resp.choices[0].message.content)这段代码里我特意把模型名放进环境变量就是为了换代时不动代码。temperature 设 0.3 是因为技术类问答不需要太多发散这个值是我踩过坑之后定下来的——设太高会胡编设太低会变得死板。2.3 价格与成本估算别只看单价热搜里openai api 价格是高频词说明成本是大家最关心的。这里我要说一个很多人忽略的点单价只是成本的一部分真正的成本取决于你的调用模式。假设 Sol 的输入价格是每百万 token X 元输出是每百万 token Y 元通常输出更贵。那么一次请求的成本是成本 (输入token数 / 1,000,000) * X (输出token数 / 1,000,000) * Y看起来简单但实际项目里输入 token 往往是大头。因为多轮对话会把历史消息全部带上每一轮都在重复计费。我做过一个统计一个 10 轮的对话如果每轮都带完整历史总输入 token 是单轮的 5 到 8 倍。所以省钱的核心不是换便宜模型而是控制上下文。几个我常用的手段对历史消息做摘要只保留关键信息而不是原文全带。把固定的系统提示词做缓存如果平台支持 prompt caching。对简单任务用轻量模型复杂任务才上 Sol。注意prompt caching 这类功能在不同平台上的计费规则不一样有的按缓存写入收费、有的按缓存读取打折。上线前一定要用真实流量跑一遍账单别拿估算当结论。2.4 什么时候该上 Sol什么时候不该不是所有任务都值得用主力模型。我的判断标准很简单看这个任务错了会怎样。如果错了只是用户体验差一点比如生成一段文案、做个摘要那用轻量模型完全够。如果错了会导致业务逻辑出错、数据污染、或者需要人工返工那就上 Sol。举个例子客服自动回复用轻量模型没问题但自动生成数据库查询语句就必须用强模型因为一个字段名写错就是生产事故。这个判断标准我用了好几年比单纯看 benchmark 分数靠谱得多。benchmark 是平均值你的业务是具体场景两者经常对不上。3. ChatGPT Spaces把对话框变成工作台3.1 Spaces 解决的是什么问题用过 ChatGPT 的人都有个痛点对话一多就乱。你想找上周讨论的那个方案得在侧边栏里翻半天。而且每个对话是孤立的上一个对话里的背景信息下一个对话用不上只能重新贴一遍。ChatGPT Spaces 要解决的就是这个。它把对话升级成空间。一个 Space 里可以放多个对话、多个文件、多个自定义指令它们共享上下文。你可以理解成以前是一个个独立的聊天窗口现在是一个个项目文件夹。这个变化看着是 UI 层面的实际是信息架构层面的。它意味着 ChatGPT 开始从问答工具往工作环境转。热搜里ChatGPT Spaces能上榜说明用户对这个方向是有需求的。3.2 一个 Space 里应该放什么我按自己的使用习惯把 Space 里的内容分成四类第一类是背景资料。比如你做一个项目把需求文档、参考链接、术语表都放进去。这样每次提问模型都能看到这些背景不用你重复解释。第二类是自定义指令。每个 Space 可以有自己的系统提示词。比如这个 Space 里所有回答都用中文代码用 Python不要解释基础概念。这比每次手动写提示词省事太多。第三类是对话线程。同一个 Space 下的对话共享背景但各自独立。你可以开一个线程专门讨论架构另一个线程专门讨论实现细节。第四类是产出物。生成的文档、代码片段可以沉淀在 Space 里下次直接引用。这个结构的价值在于它把上下文管理这件事从用户脑子里搬到了产品里。以前你得自己记住我上次跟它说过什么现在产品帮你记。3.3 实操从零搭一个项目 Space假设你要用 ChatGPT 做一个后端服务的设计我建议这么搭第一步建 Space命名清晰。别叫新空间叫订单服务重构这种。名字是给你自己看的越具体越好。第二步写自定义指令。我的模板是这样的角色你是一个有十年经验的后端架构师。 语言所有回答用中文代码注释用中文。 风格直接给方案不要铺垫不要客套。 约束涉及数据库操作时必须考虑事务和索引。 输出方案用 Markdown代码用代码块。这个模板我调了很多次核心是约束那一行。不写约束模型会给一堆正确但没用的通用建议。第三步上传背景资料。需求文档、现有的表结构、接口定义能传的都传。注意别传敏感数据这个后面会讲。第四步开第一个对话线程专门做架构设计。等架构定了再开第二个线程做详细实现。这样两个线程共享背景但讨论不互相干扰。3.4 Spaces 的边界与注意事项Spaces 好用但有几个坑得提前说。第一个坑是上下文污染。同一个 Space 里对话多了模型可能会把 A 线程的结论带到 B 线程。我的做法是如果一个 Space 里要做两件不太相关的事就拆成两个 Space。别图省事全塞一起。第二个坑是资料过期。你上传的需求文档如果改了Space 里还是旧的。模型会基于旧文档回答你还以为它错了。所以文档更新后要记得重新上传。第三个坑是权限。团队版里 Space 的共享范围要设清楚。我见过有人把含内部数据的 Space 共享给了外部协作方这是实打实的事故。提示Spaces 里放的文件本质上还是上传到了平台。涉及客户数据、密钥、内部财务的一律不要放。这条没有例外。4. dots 与 Codex命令行里的编码代理4.1 dots 是什么为什么值得单独讲热搜里dots和dots和muse都出现了说明这是这次发布里讨论度很高的一个东西。从命名和上下文推断dots 大概率是一个面向开发者的轻量级工具或代理入口和编码、命令行场景强相关。为什么我这么判断因为热搜里同时出现了welcome to codexcommand-line coding agentmissing optional dependency openai/codex-win32-x64。这些词全是命令行工具安装和使用时会遇到的。dots 和 Codex 大概率是配套的Codex 是编码代理的能力底座dots 是它的交互入口或者某种轻量封装。对开发者的意义在于AI 编码工具正在从IDE 插件往命令行原生走。以前你得开个编辑器现在直接在终端里就能让代理帮你改代码、跑测试、提交。这个方向对习惯命令行的后端和运维来说体验提升很大。4.2 安装 Codex 命令行工具的完整流程热搜里那条missing optional dependency openai/codex-win32-x64. reinstall codex: npm in是个典型的安装报错。我按常见实践还原一下完整流程。第一步确认 Node 环境。Codex 这类工具通常通过 npm 分发所以先看 Node 版本node -v npm -vNode 版本建议 18 以上。版本太低会遇到各种依赖解析问题这是最常见的坑。第二步全局安装npm install -g openai/codex如果遇到上面那个 missing optional dependency 报错通常是两个原因一是网络问题导致可选依赖没下下来二是平台特定的二进制包没匹配上。解决办法是先清缓存再重装npm cache clean --force npm install -g openai/codex如果还不行就手动指定平台包。Windows 上对应的就是openai/codex-win32-x64macOS ARM 上是openai/codex-darwin-arm64。这个命名规则是 npm 生态里 optional dependencies 的通用做法理解了这个规则以后遇到类似报错就知道怎么查了。第三步登录。热搜里sign in with chatgpt to说明它支持用 ChatGPT 账号登录。命令行里通常会弹出一个链接你在浏览器里授权然后终端里就拿到凭证了。codex login第四步验证codex --version能打印版本号就说明装好了。4.3 用命令行代理改代码的正确姿势装好之后怎么用我的经验是别一上来就让它改整个项目。先小范围试。第一步在一个干净的 git 分支上操作。这样万一它改乱了一个git checkout .就回来了。第二步给它明确的任务边界。比如把 utils/date.js 里的 formatDate 函数改成支持时区参数其他文件不要动。任务越具体它改对的概率越高。第三步改完先看 diff别直接跑。命令行工具一般会显示改动你逐行看一遍。我踩过的坑是它有时候会顺手优化一些你没让它动的代码结果引入了 bug。第四步跑测试。如果项目有测试跑一遍。没测试的话至少手动验证核心路径。注意命令行代理有文件系统访问权限能读能写。别在含密钥的目录里随便跑也别给它生产环境的凭证。这是安全底线。4.4 和 IDE 插件比命令行代理强在哪我用过 IDE 插件也用过命令行代理两者定位不一样。IDE 插件强在就地修改你看着代码它给你补全或者改一段上下文直观。命令行代理强在批量操作和可脚本化。比如你要给 20 个文件统一加日志IDE 里得一个个点命令行里一句话就行。还有一个区别是可组合。命令行工具能接管道、能写进 CI、能和其他脚本配合。IDE 插件基本是封闭的。对做自动化的人来说这个差别是决定性的。所以我的建议是日常写代码用 IDE 插件批量重构和自动化用命令行代理。两者不冲突。5. 账号、密钥与会话安全热搜里最该重视的一条5.1 会话 json 泄露到底意味着什么热搜里泄露了 openai 账号会话 json 怎么办这条是整份热搜里最需要认真对待的。很多人看到这条会慌但不知道慌什么。我解释一下。所谓会话 json通常指的是登录后平台存在本地或浏览器里的凭证文件里面包含 token、cookie 或者 session 标识。这个文件一旦泄露别人就能用你的身份访问账号不需要你的密码。为什么这次热搜会集中出现这个问题因为大版本发布时登录流程、token 刷新机制、本地存储格式都可能变。用户升级客户端、或者在不同设备间同步时容易把旧的凭证文件暴露出来——比如误传到公开仓库、误发给别人、或者被恶意软件扫走。5.2 发现泄露后的处理顺序如果你怀疑自己的会话凭证泄露了按这个顺序处理别乱第一步立刻改密码。这是最快切断旧凭证有效性的方式。大部分平台在改密码后会失效所有已签发的会话。第二步撤销所有活跃会话。在账号设置里找登出所有设备之类的选项全部踢掉。第三步检查 API key。会话泄露和 API key 泄露是两回事但经常一起发生。去后台看有没有你不认识的 key有就删掉然后重新生成。第四步查账单。看有没有异常调用。如果有截图留证联系平台客服。第五步排查泄露源。是本地文件被传了还是某个第三方工具读走了找到源头才能防止再犯。5.3 日常怎么防三条硬规矩第一条凭证文件永远不进版本控制。在项目根目录放一个.gitignore把常见的凭证文件名都列进去。我见过太多人一个git add .就把密钥提交上去了。# .gitignore 示例 .env *.session *.token credentials.json第二条API key 用环境变量不写死在代码里。前面那段 Python 代码里我用os.environ[OPENAI_API_KEY]就是这个道理。写死在代码里一旦代码泄露key 就泄露。第三条定期轮换 key。我一般三个月换一次重要项目一个月换一次。轮换的时候新旧 key 并行一小段时间确认新 key 没问题再删旧的避免服务中断。提示热搜里还有openai api key 分享这种词。千万别信任何分享 key的说法。别人给你的 key 可能是盗来的你用了就是替人背锅你分享出去的 key等于把钱包交出去。5.4 团队场景下的密钥管理个人用环境变量够了团队就得用密钥管理服务。核心原则是key 不进代码库、不进聊天记录、不进工单系统。常见做法是搭一个内部的密钥管理服务或者用云厂商提供的密钥管理产品。开发者在本地通过 CLI 拉取临时凭证凭证有有效期过期自动失效。这样即使某台机器被入侵损失也是有限的。我参与过的一个项目是这么做的CI 里不存长期 key每次构建时从密钥服务申请一个短时 token构建完就作废。这套机制搭起来麻烦但一旦搭好安全性和可维护性都上一个大台阶。6. 兼容接口与语音能力容易被忽略的接入细节6.1 openai compatible这个词的分量热搜里openai compatible speech值得单独说。所谓 compatible指的是别的服务或框架模仿 OpenAI 的接口格式这样你的代码不用大改就能切换后端。这个机制的价值在于可替换性。如果你的代码是照着 OpenAI 的接口写的那么理论上你可以把 base_url 一改就切到另一个兼容服务上。这对做多供应商容灾的团队很重要。但要注意compatible 不等于完全一致。常见的不一致点有维度常见差异影响参数支持部分参数被忽略行为不符合预期错误码错误码定义不同异常处理逻辑失效流式输出分块格式有差异前端解析出错速率限制限流策略不同高并发下被拒我的做法是切换前先写一组契约测试把关键接口的输入输出都测一遍。别信文档说完全兼容实测才算数。6.2 语音接口的接入要点语音能力这块接入时最容易出问题的是音频格式和采样率。不同服务对输入音频的要求不一样有的是 16kHz有的是 24kHz格式有的是 wav有的是 mp3。我的经验是在客户端统一转成一种格式再发。比如统一转成 16kHz 单声道 wav这样不管后端要求什么你只需要在服务端做一次转换。客户端做转换的好处是省带宽坏处是增加客户端复杂度。具体怎么选看你的场景。还有一个坑是长音频。语音接口通常有单次时长限制超过就得切片。切片的时候要注意在静音处切别把一句话切成两半否则识别结果会断。我一般用能量检测找静音段在静音段中间切。6.3 多供应商切换的工程实践如果你的业务对可用性要求高建议做多供应商。核心是抽象一层适配器class LLMAdapter: def __init__(self, provider): self.provider provider def chat(self, messages, **kwargs): if self.provider primary: return self._call_primary(messages, **kwargs) else: return self._call_backup(messages, **kwargs)这层适配器的作用是把供应商差异挡在业务代码之外。业务代码只调chat不关心背后是谁。切换的时候改配置就行。要注意的是不同供应商的输出质量不一样。做容灾的时候最好让备用供应商的输出格式和主供应商对齐否则前端会出问题。我一般会在适配器里做一层输出规范化。7. 常见问题与排查速查7.1 安装与登录类问题现象可能原因处理方式missing optional dependency平台包未下载清缓存重装或手动装平台包登录后仍提示未授权凭证未刷新重新登录检查本地凭证文件命令找不到全局 bin 未进 PATH检查 npm 全局路径配置版本过旧未更新重新执行全局安装7.2 调用类问题现象可能原因处理方式404 model not found模型名写错核对官方模型标识符输出被截断max_tokens 太小调大上限或分段请求成本异常高上下文重复计费做历史摘要启用缓存响应慢模型负载或网络加重试考虑备用供应商7.3 我踩过的三个坑第一个坑以为模型名可以简写。有次我写gpt-6结果 404排查了半小时才发现是名字不对。教训是模型名永远从官方文档复制别手打。第二个坑没设 max_tokens。默认值有时候很小长回答直接被砍。现在我的模板里永远显式设置这个参数。第三个坑在 Space 里传了含内部数据的文档。虽然没出事但事后想想很后怕。现在我的规矩是任何上传前先问一句这个文件泄露了会怎样答案不好的就不传。8. 这套东西怎么落到实际项目里说了这么多最后讲讲怎么组合使用。如果你是个独立开发者我的建议是先用 Spaces 管理你的项目上下文把需求、资料、指令都放进去。然后用命令行代理做批量代码操作。API 调用上简单任务用轻量模型复杂任务用 Sol。密钥用环境变量定期轮换。如果你在团队里额外要做三件事统一密钥管理、做多供应商容灾、建立凭证泄露的应急流程。这三件事平时看不出价值出事的时候能救命。如果你只是普通用户那 Spaces 是最值得试的。它不涉及代码但能实实在在提升你组织信息的能力。用一段时间你会发现以前那种翻聊天记录找东西的日子一去不复返了。我个人在实际操作中的体会是工具换代的时候别急着全量迁移。先拿一个小场景试跑通了再推广。这次发布会的东西不少但真正能立刻用起来的其实就那么几个。挑一个最痛的点先解决比什么都想试要有效得多。