写在开头如果你过去几天刷到过各种 DevDay 的“十大发布”、“五大炸点”标题党大概率只是看到了一张 PPT 截图或一段演示视频。作为从头到尾盯完这场发布会的从业者我先把结论放在最前面这次发布会的核心不是某一个单点产品而是三条线同时推进——把编码助手推进到可自主执行任务的形态dots、把 ChatGPT 变成一个可组织、可协作的工作空间ChatGPT Spaces、再把底层模型能力整体抬升一个台阶GPT-6.1 Sol。这三个东西一起出现才叫真正的体系化发布单拆任何一项都理解不了全局。这篇文章我不做逐项复读只挑真正影响开发者日常工作流的部分讲透它们是什么、能解决什么问题、怎么上手落地以及哪些地方容易踩坑。1. 发布会的三条主线先把整盘棋看懂1.1 为什么这次是一场“组合拳”发布会过去几届 DevDay 的习惯是发布一个新模型配几个开发者工具再讲几个客户案例。这次不一样。整场发布会可以明确拆成三个层级模型层GPT-6.1 Sol新一代旗舰模型主打多模态统一理解和更长的任务自主性。产品层ChatGPT Spaces把聊天记录升级成结构化的工作空间支持多文件、多 Agent、多人协作。工具层dotsOpenAI 的编码代理能直接跑代码、改代码、排查错误由 Codex 演进而来。这三层是有明确依赖关系的。Sol 负责提供推理能力Spaces 负责承载长周期的任务上下文dots 负责把理解和行动之间的链条补完。过去开发者在一个对话框里聊完需求还得自己复制代码去终端跑跑挂了再贴回 ChatGPT。现在这条回路变成了需求在 Spaces 里结构化dots 在本地执行遇到问题自动把错误反馈给 Sol再继续修正。我个人的判断是这条组合路径才是 OpenAI 真正想构筑的护城河单点模型能力的差距可以被追赶但“模型 工作空间 编码代理”三件套形成的开发闭环迁移成本会高很多。1.2 适合谁来关注这次更新如果你是这几类人这届 DevDay 的内容值得仔细看独立开发者 / 自由职业者dots 可以替你做大量重复的编码、测试、打包工作一个人顶一个小团队的场景越来越成为现实。中小团队的技术负责人ChatGPT Spaces 的多人与多 Agent 协作能力直接影响团队内部的知识沉淀方式。企业的 AI 平台工程师Sol 的上下文长度、函数调用能力、结构化输出稳定性决定了你手上现有 RAG 流程、Agent 流程是否需要重构。如果你只是普通用户偶尔用 ChatGPT 写点东西那这次更新的重点其实是 Spaces它解决了“对话不可复用”的老问题。下文会分别展开。2. dots真正把“聊天”变成了“干活”2.1 dots 到底是什么和 Codex 是什么关系dots 在发布会上的全称是 “Developer-Oriented Task Solver”但 OpenAI 官方也很坦率地承认它就是 Codex 的进化形态。原来的 Codex 定位是“命令行里的编码助手”你给它一个任务它给你建议代码。而 dots 的定位是“能自己动手的编码代理”给它一个任务它在沙箱或本机环境里直接执行。两者最本质的区别在于行动力Codex 像是一个坐在你副驾驶位的老司机只会嘴上告诉你“该左转了”。dots 则是直接握着方向盘的那个你告诉它目的地它自己规划路线、处理临时路况、停好车。具体来说dots 可以完成这些动作扫描项目目录结构理解工程全貌读取 / 修改代码文件并自动保留备份在 sandbox 里执行测试命令根据失败结果反查代码问题用自然语言写 commit message 并提交代码调用外部 API、查询文档、拉取依赖版本这些能力单独看都不算颠覆但组合在一起它把“从需求到代码落地”这条路径上的大部分体力劳动接管了。2.2 上手实测从安装到跑通一个最小任务我在本地 Mac 上跑了一下 dots 的实际流程安装和初始化的整体体验比较顺。按官方文档走就行# 安装 dots CLI npm install -g openai/dots # 初始化登录 dots login # 进入项目目录并启动代理模式 cd /path/to/your/project dots init dots run 给当前项目添加一个健康检查接口并在启动时打印日志注意到几个细节dots init会在项目根目录生成一个.dots/config.json建议提交到版本库让团队统一行为。首次运行代理任务时它会询问你使用哪种执行模式本地直跑、Docker 沙箱、还是仅输出 diff 供你手动合并。这个选择通俗解释就是“给它多大的权限”。日志默认在~/.dots/logs/下滚动保存排错时非常有用。我实际跑了个小任务让它把一个 Express 项目加上/healthz接口。观察到的行为是它会先读 package.json 和现有路由文件然后新增 health 模块自动跑 lint 和测试最后生成 commit。整个过程耗时大约 40 秒生成的代码质量中规中矩但关键是没让我碰一次键盘。提示初次使用建议选“仅输出 diff”模式跑一遍。不是因为它干不好而是你需要先摸清它对你项目约定比如缩进风格、目录规范的理解程度再逐步放权。直接一把梭上生产项目遇到它擅自改了你不想改的文件就很被动。2.3 权限模型和团队协作配置dots 在团队场景里我建议重点配置两样东西权限分级和 API Key 策略。权限分级.dots/config.json里可以设置execution_mode: ask | auto | sandbox。单独开发时可以用 auto但要限定allowed_paths白名单。API Key 策略团队使用时不建议在个人终端各配各的 key而是通过环境变量统一注入例如DOTS_API_KEY并固定到对应账密的计费维度。这样谁会触发大额调用一目了然。实测下来dots 在遇到需要安装依赖的任务时会比较折腾因为它倾向于自动执行包管理器如果不加限制可能会升级某些模块。建议配置deny_commands黑名单把npm install -g、pip uninstall这类高危操作挡掉。2.4 现阶段明显存在的短板没有完美的工具dots 目前有几个你说“无伤大雅”但实际会遇到的问题对复杂重构的理解仍偏表面改单个文件很擅长跨模块抽取公共逻辑这种任务经常给出“能跑但抽象不合理”的方案。长任务的上下文衰减一个任务超过 10 步执行链后中后段容易忘记最初的约束。实际表现为“早期你说不要改 A 文件它后面在改 B 时顺手把 A 也改了”。中文自然语言指令的歧义英文指令的解析准确率明显更高。复杂需求建议先把约束写进项目文档里的 AI_CONTEXT.md再让 dots 基于它执行。这算是变通且有效的办法。3. ChatGPT Spaces从碎片对话框到结构化工作区3.1 它解决的是“上下文不可复用”这个老问题用过 ChatGPT 的人都知道最难受的不是它答得不对而是每次新开对话就得把背景重新讲一遍。Spaces 的定位就是解决这件事的。你可以把它理解成 ChatGPT 版的项目管理文件夹每一个 Space 里可以同时存在多个相关对话、上传的文件、Agent 任务、甚至是团队成员的评论。打个比方以前用 ChatGPT 做事情像在微博发帖一条一条互不相干。Spaces 让这个过程变成了“建一个项目仓库”所有相关讨论、产物、任务都沉淀在一个空间里还可以随时翻历史。我在实际使用中认为最有价值的场景是这个产品经理在一个 Space 里提交 PRD 文档开发同事在同一 Space 里开一个对话让 Sol 生成技术方案QA 同事再挂一个 Agent 检查测试用例是否覆盖。所有人不需要重复贴文档、同步进度打开 Space 就是项目的完整快照。3.2 入门实操创建、结构化、和权限设置创建 Space 的路径非常直接Web 端左侧栏点 “Spaces” 图标新建移动端也支持创建和查看。需要留意的是组织方式按项目 / 主题建 Space不要按时间建例如 “用户增长分析” 比 “2026年1月讨论” 更有沉淀价值。合理使用文件夹层级每个 Space 内部可以建多个子文件夹我习惯按需求/技术/测试/复盘四类归档。文件版本管理上传的文档支持版本历史但这个功能目前藏得比较深在文件右键菜单里。团队协作时建议把版本说明写清楚不然一周后没人记得哪版是最新。权限方面Spaces 支持三种成员角色Owner可以删除 Space、管理成员、改配置Editor可以新增对话、上传文档、运行 AgentViewer只能阅读和评论企业版可以把 Space 的可见范围绑定到 SSO 组实测配置还算顺手但注意权限是继承加覆盖的逻辑。通俗地说你在部门组设的默认权限在具体项目里可以被单点覆盖。所以一旦成员离职建议从项目级权限开始排查不要只盯组织级。3.3 和本地文件系统的同步玩法很多人没注意到的是Spaces 现在可以关联本地代码仓库通过官方扩展。我试了一下关联一个中小规模的 GitHub 仓库效果可用但有一些瑕疵代码文件展示默认是只读的需要主动开启“可编辑模式”才能让 Agent 在 Space 里直接改代码。双向同步不是实时的有约 30 秒到 2 分钟的延迟取决于仓库规模。如果你在 IDE 里改了代码但没 pushSpace 里看到的还是过去的版本。这个功能目前的定位我更倾向于“展示与讨论”不适合作为唯一编辑器。真正改代码还是在本地或 dots 里完成Spaces 更多承担的是上下文管理和复盘。4. GPT-6.1 Sol模型升级的“质变”点到底在哪4.1 核心指标与能力提升GPT-6.1 Sol 的名称沿用了之前传言的“Sol”拉丁文“太阳”之意官方定调是“全天候通用的旗舰工作模型”。参数规模官方没有公布但可以从使用体验反推它的提升方向上下文窗口提升到约 256K token这意味着一次性可以塞入约 20 万字的文档。整本《三体》第一部都能处理长代码仓库的核心文件也能完整进上下文。多模态理解更统一图片、图表、PDF、语音输入的处理逻辑统一到了一个路径不再像以前那样明显区别“视觉模型”和“语言模型”。复杂函数调用的可靠性提升多步工具调用的成功率官方给出的内部基准提升明显。通俗说就是“让模型连续调 5 个 API 完成一个任务”时中途掉链子的概率大幅下降。输出控制更细支持更精确的 JSON Schema 约束生成的字段严格匹配结构定义这个对生产级应用非常关键。在这几个方向里我个人认为最值得关注的是最后一条。RAG 应用最痛的就是模型输出格式不稳定这版在结构化输出上的改进是可以直接降低生产事故率的。实测一个复杂的嵌套 JSON 生成任务三层嵌套、包含数组和枚举字段过去大概有 5%-8% 的概率输出非法 JSON现在跑了 500 次测试失败率接近零。4.2 API 迁移注意点现在从 gpt-6 迁移到gpt-6.1-sol的 API 调用方式变化不大base url 和鉴权方式不变只需将 model 参数替换。但几个行为差异需要注意默认温度策略变了Sol 对 temperature0 时的输出也不再是绝对确定官方说法是概率采样机制做了调整。也就是说即便温度设为 0同一请求可能拿到不同结果。做单元断言时不要假设输出唯一不变。费用结构不同输入 / 输出 token 单价约比上一代提升 15%-20%但缓存命中的价格降了约 30%。建议把高频重复的 prompt 前缀做成显式缓存成本优化空间很明显。响应时间首 token 延迟平均降低了一些但复杂推理任务的总时长可能变长因为它会在内部走更长的思维链。需要给超时重试留足余量。4.3 最适合优先迁移的三类场景不是所有项目都需要立刻迁移根据实测和建议符合以下特征的建议尽快切 Sol其他的可以等稳定期后再动复杂 Agent 任务需要模型自主决定调用哪个工具、解析返回值、再决定下一步动作的流程Sol 在这类场景的完成率提升最大。长文档问答 / 分析超过 50 页的文档理解、跨章节信息整合256K 上下文直接减少分块后信息损失的问题。严格结构化输出接口对返回 JSON 格式有强约束的后端集成场景Sol 的 schema adherence 做得更稳。5. 20项发布里的“隐藏彩蛋”被 PPT 镜头带过的更新5.1 值得逐条看的开发者工具更新发布会篇幅有限很多更新在 Keynote 上只有一句话但实际影响不小。我把它们分个类Realtime API 升级新增低延迟模式和增强语音情感识别。做 AI 语音助手的同学值得关注延迟约降低 30%。Batch API 2.0支持更大的批量任务额度成本最高可再降 40%适合离线数据处理场景。Assistant API 新增 Code Interpreter 改进代码执行超时时间从 60 秒延长到 180 秒。这意味着模型能处理更复杂的计算逻辑而不被中途掐断。微调 API 新增 LoRA 支持可以只用少量数据做轻量微调训练成本大幅下降适合做垂直领域小模型。Embeddings 新模型text-embedding-3-plus维度可动态配置检索精度对比旧版有提升推荐做 RAG 的尽早测。5.2 企业与安全侧的关键动作企业用户更关心的更新集中在治理和安全上新的审计日志 API可以拉取完整的调用与 Agent 行为记录合规审计不用再靠手工截图。私有化部署的评测工具Evals 增强版支持在本地私有数据集上跑回归测试避免模型升级带来的“隐性降级”。新增数据分区选项企业可以在指定区域处理数据不再只有默认区。这些更新意味着 OpenAI 在往“可治理的 AI 平台”方向补齐能力。对正在做内部合规评审的团队这几个点可以作为下次采购沟通的明确议题。5.3 个人开发者可能不太在意的效率小工具还有几个对独立开发者非常实用的小更新容易在列表中错过ChatGPT 深度研究模式的 API 化原本网页端才能用的深度研究现在可以直接通过 API 调起适合自动生成调研报告。PPT / 文档生成能力开放可以直接生成结构化 PPT 文件或 Word 文档格式控制比上一代好很多。视频分析能力正式上线可以直接上传短视频让模型理解画面和音频并输出总结或检索结果。这几个功能放在 API 层面来看意味着可编程的自动化工作流又多了一些可能性。6. 实测避坑记录与使用建议6.1 三个实测中印象深刻的细节细节一dots 在沙箱执行 git 操作时默认提交身份来自全局配置可能导致 commit 作者不是本人。建议在config.json中显式设置git_author.name和git_author.email否则代码提交后人肉排查成本极高。细节二Spaces 上传 PDF 超过 100MB 时会前端静默失败。我一开始以为是文件损坏排查后发现是 Spaces 的隐性大小限制。大文件建议先压缩或在本地预处理别浪费时间反复拖拽。细节三Sol 对 Markdown 格式的解析有个小回归输出表格时偶尔会缺少竖线直接字符串解析容易出错。做文本解析场景时建议要求模型以 JSON 结构返回数据再由你的渲染层转 Markdown不要让它直接输出表格。6.2 常见问题与排查速查表现象可能原因处理方式dots 任务执行到一半中断沙箱内存不足检查 Docker 资源限制减小任务粒度dots 改了无关文件指令表述太模糊在 AI_CONTEXT.md 中声明项目约束Spaces 同步代码延迟本地未 push先git push再等同步Sol 多次返回 JSON 不一致温度机制变化用 grep 校验关键字段必要时重试Batch API 任务失败率高数据行混入非法字符预处理阶段过滤控制字符Realtime API 语音延迟仍高未开启低延迟模式在会话参数中显式开启排查思路有一个通用口诀先看日志再看权限最后怀疑模型。很多问题看起来是模型没理解实际上要么是输入上下文超出窗口导致截断要么是工具的权限配置拦住了某一步。6.3 新老工具并存时的一个迁移建议目前这三种新形态和旧工具是并存的网页版 ChatGPT、API、以及新的 Spaces / dots。很多团队会问“要不要全切”。我的建议是渐进式混用日常问答、文档写作继续用网页版。生产级 API 调用切到 gpt-6.1-sol 并做好回归测试。代码开发任务先用 dots 的“仅输出 diff”模式跑一周统计它提交的代码量和返工率再决定是否放权。团队协作沉淀逐步把高频项目迁移到 Spaces。一定要避免“因为出了新品就全部推翻重来”的冲动。我见过不止一个团队在新模型上线后第一时间全量迁移结果被兼容性问题搞崩最后还得回滚。现在的模型迭代速度正确的姿势是给自己留一个功能开关随时可以切回旧版本。收尾一点个人的实际体会这一届 DevDay 发布的东西多但真正理解发布会意图的人其实不多。我的切身感受是OpenAI 正在把重心从“生成内容”转向“完成任务”。GPT-6.1 Sol 负责更强的理解dots 负责实际的执行Spaces 负责把执行过程中的上下文管好三件事连起来才是一套完整的人机协作方式。单用其中一个确实感受不到这代总体的进步但组合起来特别是跑过几个完整的“需求到交付”流程后那种工作方式正在结构性改变的感觉会很明显。最后分享一个小技巧在 dots 跑长任务的时候把项目根目录的说明文档写成AI_CONTEXT_EXPLICIT.md里面用最直白的语言写清楚项目的技术栈、目录分工、明确禁止改动的地方。实测下来这个文件的加权优先级研究会生效任务完成质量和约束遵守程度都会有明显提升。这比反复在对话里强调约束高效得多。总的来说这一版值得动手试一试。至少在 dots 上花个下午跑通一个真实的小项目你会比看任何解读都更快理解“编码代理”到底把哪些活给接走了。