又是一年的 OpenAI DevDay。今年我坐在现场感受和去年很不一样。往年发布会都是“模型迭代 花式 demo”今年官方一口气放出了 20 项发布但真正让人眼前一亮的并不是某一个参数而是三条产品线面向开发者的智能体协作标记工具 dots、全新形态的 ChatGPT Spaces 工作空间以及新一代旗舰模型 GPT-6.1 Sol。这三样东西放在一起指向一个清晰的方向OpenAI 不再只想把模型卖给你而是想把从“写代码”到“团队协作”再到“模型调用”的整条链路全部打通。我自己是重度使用 Codex CLI 和 ChatGPT API 的开发者这次最关心的就是这三件事dots 能不能解决智能体理解代码库上下文的老问题Spaces 能不能让团队分工变得清楚Sol 在复杂工程里的表现是不是真的对得起价格。这篇文章不打算复述发布会 PPT只聊我实测后的真实感受、关键设计和避坑经验如果你正在评估是否跟进这批新功能这篇应该能帮你省下不少试错时间。1. 今年 DevDay 给人的整体观感不再炫技开始讲落地1.1 20 项发布背后的主线逻辑发布会第一个环节就是一口气过发布清单现场大屏幕滚动得很快我记了下笔记大致分成五类发布方向典型内容核心目标模型底座GPT-6.1 Sol 旗舰模型、轻量版模型提升推理上限拉低延迟成本开发者工具dots、Codex CLI 更新、SDK 重构让 AI 编码智能体贴近真实工程协作产品ChatGPT Spaces、共享上下文、团队席位从个人助手走向团队工作台API 平台Responses API 增强、Batch 2.0、语音接口统一调用范式降低集成成本企业治理管理控制台升级、审计日志、数据隔离解决规模化落地里的合规问题看完这五类内容我最大的感受是今年的关键词是“生产环境”。去年大家还在讨论模型能不能写代码今年官方已经把重心挪到了模型怎么在团队里干活、审批怎么走、账怎么算、权限怎么管。这其实是很务实的转向因为过去一年里单纯靠某一个模型能力的提升已经很难打动企业客户企业真正要的是可交付、可审计、可维护的完整链路。另一个细节值得注意发布会全程没有公布什么“人类水平 AGI”之类的宏大叙事更多的时间花在了演示具体工作流上。比如现场有一个 demo用 dots 把一个仓库里的历史决策记录变成智能体可读的上下文然后让 Codex 在同一个分支上完成重构整个过程没有一次人工粘贴代码。这种“把细节做透”的演示比参数更让我兴奋。1.2 三件套之间的定位关系dots、ChatGPT Spaces、GPT-6.1 Sol 不是三个孤立产品而是一条链路Sol 是能力底座dots 解决“智能体如何理解代码库上下文”的问题Spaces 解决“多人多会话如何组织协同”的问题。一句话理解Sol 负责聪明dots 负责记忆Spaces 负责协作容器。我在现场脑子里的图景是这样的一个团队在 Spaces 里建了一个项目空间里面放了共享上下文、需求文档、代码仓库的引用工程师在本地用 Codex CLI 干活dots 会把仓库里标注过的待办、设计决策、评审意见同步给智能体遇到复杂问题需要更强推理时Spaces 后台的 Agent 会自动路由到 Sol整个过程的对话记录、改动记录、用量账单都沉淀在 Spaces 里。这三个产品咬合得很紧密单独用其中一个体验都差一截但搭配起来就很顺。这也是我给团队的建议别只看单点功能要把它们当成一套组合拳来评估。2. dots让 Codex 真正“看见”你的代码库2.1 dots 是什么——从 Codex CLI 的局限说起如果你已经用上过 Codex CLI就是那个命令行编码智能体直接 sign in with ChatGPT 就能用大概率遇到过这样的尴尬你让它改某个模块它虽然能读文件但对仓库里的历史包袱一无所知——为什么这里要这么写、哪个 TODO 是上个季度欠下的技术债、某个函数为什么不能随便动。传统做法是你在对话里粘贴一堆上下文但贴得越多对话越乱智能体反而抓不住重点。dots 就是冲着这个问题来的。它本质上是一层“结构化上下文标记”在仓库里用统一的格式留下短小的记录包括待办、决策、约束、评审意见dots 会把这些记录收集起来变成 Codex 自动读取的上下文。你可以把 dots 理解成给代码库写“便利贴”但比便利贴聪明的是它有序、可检索、并且智能体会主动吃进去。我拿一个身边的例子说明。我们有个老项目接口层一直是单体最近要拆服务。这种跨模块的重构最怕 Codex 拆到一半把某个公共依赖改坏了。以前我得在 prompt 里写一大段“不要动 auth 模块order 服务依赖 XX 接口”现在只需要在仓库里放一个 dot写明约束Codex 每一次调用都会自动看到不会忘。2.2 dots 的两种核心用法现场演示把 dots 分成了两类用途我实际用下来觉得这个分类很实用。第一类叫“给智能体留的上下文”。这类 dot 通常放在仓库根目录.codex/dots/下一个文件对应一个主题。比如auth-constraints.dot.md写授权模块的边界tech-debt.dot.md写已知的坑。Codex CLI 在启动会话时会扫描这些文件并自动加载。这一类的关键是“稳定”记录的是长期有效的约束和背景不会一天一变。第二类叫“工作流里的即时指令”。这类 dot 更像是一个短命的接力棒。比如我开了一个分支准备重构先在这个分支里写一个rework-plan.dot.md把目标、步骤、验收标准列清楚然后让 Codex 一步步执行。做完之后这个文件可以删掉或者归档进长期记录。它解决了过去最烦的问题你没法让一个命令行智能体“记住”你上个小时聊过的需求有个文件在上下文就不会丢。两类用途的本质差异是生命周期前者陪仓库走很久后者跟着任务走完就退场。我建议团队一开始先用第一类把稳定约束沉淀下来再逐步尝试第二类因为第二类对团队的文档习惯要求更高。2.3 实操示例给本地分支加一个 dot 并让 Codex 执行下面是一个完整的实操流程我复现一下发布会上的基本思路加上自己的简化。第一步在仓库里建目录并写一个 dot 文件。mkdir -p .codex/dots cat .codex/dots/rework-plan.dot.md EOF --- id: rework-order-service type: task status: active owner: lisha created_at: 2026-05-04 --- # 订单服务拆分任务 目标将 order 模块从单体接口层拆出独立服务。 约束 - 不得改动 auth 模块的对外签名 - 所有数据库迁移必须向后兼容 - 关键路径日志保留现有字段 验收标准 - 通过现有集成测试 - 拆分后 API 延迟不高于原有 p99 EOF第二步在 Codex CLI 里发起任务。注意 Codex 会自动加载.codex/dots/下的文件不需要你手动粘贴内容。codex 按 rework-order-service 这份 dot 执行订单服务拆分每完成一步就更新该文件的状态字段第三步执行过程中Codex 会定期回读这个 dot更新status和进度说明。我实测下来多步任务里它能保持思路连贯不会做着做着忘了初始约束。这就是 dots 和普通注释文档最大的区别不是给人看的参考而是智能体工作流的一部分。文件格式上现场演示用的是 YAML front-matter 加 Markdown 正文。这个设计我猜是有意为之front-matter 负责结构化字段状态、负责人、更新时间正文负责写给人看也写给模型看的自然语言。给想要复现的读者的提示front-matter 里的字段不要自创太多先按id / type / status / owner / created_at这几个走因为官方工具对这套初始字段的解析最稳。2.4 dots 的避坑要点我踩过的坑主要有三个。第一不要往 dot 里写“对话式”内容。比如“我记得上次好像有个 bug……”这种模糊描述模型读了也不知道该干嘛。dot 要像写 issue 一样给足信息目标、约束、验收标准缺一个都容易翻车。第二避免把 API Key、数据库连接串这类机密写进 dot。dots 文件在仓库里是明文存在的一旦仓库泄露这些信息就全暴露了。安全边界要自觉守住。第三不要一个仓库堆上千个 dot。dot 的初衷是精简上下文不是建知识库。我建议每个仓库长期保留的 dot 控制在 10 个以内内容多的分类放在子目录里Codex 按需加载。堆太多会让上下文膨胀反而影响智能体的专注度这是官方在技术环节里反复强调的。3. ChatGPT Spaces从“聊天的 AI”到“干活的 AI”3.1 Spaces 到底解决什么问题过去用 ChatGPT 最难受的一点是会话碎成一片今天聊这个模块的设计明天聊另一个模块的 bug两个会话之间没有记忆想复用之前聊出的结论只能来回翻历史记录。团队协作就更难人和人的会话互相看不见一个需求聊完谁跟进、做到哪一步全靠口头同步。ChatGPT Spaces 就是来收拾这片碎片的。它本质上是项目级工作空间一个 Space 里可以聚合多个会话、共享文档、任务清单、成员权限还可以挂 Agent 自动化任务。你可以把它理解成“AI 时代的项目文件夹”但不是那种把文件丢进去就完事的文件夹而是文件、对话、任务之间能互相引用的活空间。现场给的一个数据我印象很深官方调研显示企业用户平均每周要在 AI 工具里开几十个会话但大多数结论没有被二次使用。Spaces 的出发点就是把“产出”沉淀下来让对话结果变成可复用资产而不是用完即弃的聊天记录。3.2 Spaces 里到底有什么我用了几天之后把它拆成四个核心组成部分。共享上下文Shared Context相当于 Space 的“记忆区”。你可以把项目背景、代码仓库说明、需求文档丢进去Space 里所有会话和 Agent 在启动时都默认拥有这段背景不用每次重复粘贴。文件和任务区用来放产出物。实测下来这里的文件可以直接被会话引用比如你在会话里说“基于任务区里那份迁移方案写一个评审清单”它能直接定位文件不再需要上传附件。成员与权限。Space 可以邀请成员按角色分配权限管理员能改配置普通成员只能对话和编辑文件还可以设置只读访客。我们的做法是让研发和产品在同一个 Space 里协作产品提需求研发改文件权限上分清楚互相不越界。内置 Agent。这是和增强模型配合最紧的一个功能。你可以在 Space 里创建一个 Agent给它固定的角色说明和可用工具然后发布成一个可复用的“同事”。比如我们建了一个“代码评审 Agent”默认加载仓库 dot 里的约束每次新代码进来它可以自动跑一遍评审清单。这个玩法很上头等于把团队的流程规范直接变成了自动化。3.3 团队协作实操用 Spaces 跑一个小迭代我建议团队按下面这个流程起步比较简单也不容易乱。第一步建 Space把共享上下文写清楚。我习惯于放三样东西项目背景两三段话说清业务、仓库地址和分支策略、对外接口不变的红线。第二步成员分工。把项目核心成员都拉进来先别急着设置太多细粒度权限用一个默认角色就好跑起来之后发现确实有人只看不改再调成只读。第三步把需求拆成任务。直接在任务区写卡片每张卡片关联一个会话。会话里聊出的结论如果有效可以一键转成任务备注。这样从需求到结论到任务全程在同一个页面不再需要截图聊天记录。第四步引入 Agent 做重复劳动。比如让“评审 Agent”每天晚上跑一遍当天合并的代码输出评审意见到 Space 的共享文档。这个动作把团队规范执行从“靠人提醒”变成“靠系统兜底”。这套流程跑了一周后我们明显感觉到两个变化新成员进入项目的上手速度快了很多因为共享上下文里什么都有跨职能沟通的返工少了因为结论都沉淀在任务卡片里而不是散落在各自的消息列表里。3.4 Spaces 的安全边界和数据隔离今年企业用户对数据安全特别敏感官方在这块给了不少承诺。我的理解是Space 的安全边界以“空间”为单位不同 Space 的数据互相隔离成员身份、API Key 授权都绑定在 Space 级别上。也就是说你在 A 空间授权的工具B 空间看不到A 空间的成员也不能越权访问 B 空间的内容。这里有一个实操建议给“外部协作项目”和“内部研发项目”分别建 Space内外部不混用。哪怕流程上稍微麻烦一点也不要让外部人员的访问范围扩散到内部代码库。另外如果 Space 里挂了好几个 Agent每个 Agent 的工具权限都要按最小权限原则配置能用只读就不用读写这是目前团队出问题概率最低的做法。4. GPT-6.1 Sol底座模型到底强在哪4.1 Sol 的核心变化作为压轴发布的 GPT-6.1 Sol官方没有用“接近人类智能”这种话术而是给了非常具体的能力指标。我印象最深的有三块。上下文能力Sol 的原生长上下文来到了 2M token 级别现场演示直接喂了一整个大型代码仓库的多个关键模块让它跨文件推理。老实说2M 对绝大多数项目来说已经“塞得下整个家底”了过去那种“复制粘贴关键代码”的操作终于可以退出历史舞台。推理和代码能力官方称 Sol 在代码推理、复杂多步工具调用上的表现相比上一代 GPT-6 有明显提升尤其在多文件跨模块重构场景里它能够更好地执行长期任务。我自己实测了一个“按 dot 拆分服务”的任务确实比之前模型少了很多步骤拆到一半不会突然忘记前面的约束。多模态和实时交互Sol 把音频、图像、文本输入做了统一处理可以一边看截图一边改代码。现场演示里开发人员截了一个测试失败的报告然后直接在会话里问 Sol 原因它读完图片里的报错信息给出了排查方向。对我这种经常要处理日志和报错截图的人来说这个功能很实在。4.2 和上一代模型的实际对比我把我自己项目上的对比结果整理成了表格仅供参考不同场景差异会很大。项目上一代旗舰GPT-6GPT-6.1 Sol长文档理解约 1M 上下文长文档后有轻微遗忘2M 上下文长对话稳定性明显更好跨文件重构会偶尔改坏公共接口对接口约束的记忆更稳改动更保守多步工具调用偶尔断了要继续提醒长链路任务执行更连续响应速度重推理请求偏慢首字延迟降低复杂任务提升更明显多模态只能读文本图像、音频输入原生支持价格输入约 1 美元/百万 token输入略有上调但缓存和批量价更划算我的结论是Sol 不是那种“所有场景都更快”的简单升级它的强项在复杂推理和长上下文协同上。如果你日常只是写写小函数、改改文案可能感受不到太大差别但如果你做的是大型仓库重构、跨系统架构梳理、长周期智能体的运行Sol 的稳定感和连续性会明显值回票价。4.3 开发者算账API 价格与成本结构今年 API 定价一公布现场开发者交流群里立刻就开始对账。我按自己的用量估算了一下长上下文场景下Sol 的缓存读取价格定得很有竞争力意味着高频轮询同一个代码库或文档的场景用缓存模式能省出一大截成本。批量任务的价格也有新的优惠档位。Batch 2.0 支持把非紧急任务打包处理价格明显低于实时调用。我打算把每天的代码评审、测试生成这类不追求秒回的请求扔进批量队列结合 Spaces 里的 Agent 每晚自动跑一遍成本上会从容很多。给团队的算账建议先统计自己的调用模式。如果大部分请求是“同一批文件反复问”优先开缓存如果任务允许延迟几分钟用批量只有聊天类、交互类请求才走实时档。把这个三层结构搭好之后再评估 Sol 的账你会发现真实成本比挂牌价亲民不少。4.4 什么时候该升 Sol什么时候不必升级升级模型不是无脑操作我给三句话的判断标准。需要升级你的任务里存在多轮推理、多文件交互、需要严格遵循约束的工程场景。这类任务 Sol 能明显减少你和模型之间的来回沟通等于省了时间。不必急着升级轻量级文本生成、简单问答、QA 阶段的小修小改。这些场景用轻量版模型响应快、价格便宜没必要让旗舰模型跑小任务。谨慎观望你的应用重度依赖某些第三方 SDK 或工具兼容性。大版本升级总会带来一些边界行为变化如果你的应用是生产环境核心路径我建议先在灰度环境跑一周再决定是否全量切换。这是常规建议但确实是最容易翻车的地方。5. 其他值得留意的 13 项更新5.1 API 与平台层面的变化除了三大主角今年还有一批平台级更新对开发者的日常影响可能更大。Responses API 增强了工具调用和结构化输出的控制之前要靠自己拼 JSON 的场景现在有更直接的接口Batch 2.0 改进了任务管理和重试策略大批量离线处理的稳定性比原来好很多。还有一个值得关注的点是语音接口的标准化方向。官方明确提出了兼容语音接口的规范让同一套语音逻辑可以对接不同的服务商。虽然现场演示很短但方向很清楚语音交互正在从“API 大模型附带功能”变成“平台基础能力”。如果你在做语音相关的产品值得持续跟进这套兼容规范的落地。另外今年 SDK 做了一次较大的重构长尾 API 的文档和调用方式梳理得更整齐。老项目升级时需要注意部分接口的参数默认值可能有调整建议先在测试环境验证。还有就是工具包版本要锁定别在升级中间态里配来配去容易踩兼容坑。5.2 企业治理与数据安全相关更新企业控制台今年明显补了很多课审计日志更细按 Space 的数据保留策略更清晰管理员可以给不同 Space 设置不同的数据留存周期。对于要做合规审计的团队这些功能是实打实的加分项。这里要提醒所有开发者朋友今年开始官方反复强调 API Key 和账号会话的安全管理。原因很简单AI 产品里沉淀的会话数据往往包含代码片段、业务数据和个人信息一旦泄露影响范围远大于单纯的密码泄露。我建议团队立刻做三件事给 API Key 设置定期轮换机制按最小权限分配而不是共用一个 Key开启用量异常告警。宁可多花几分钟配置也不要等到账单异常或数据泄露了再补救。6. 现场朋友问得最多的几个问题含避坑实录6.1 Codex 在 Windows 上安装报错怎么办现场好几个人问到了同一个报错我直接贴出来missing optional dependency openai/codex-win32-x64. reinstall codex: npm install -g codex这个错误的核心原因是Codex CLI 在 Windows 上依赖一个平台相关的二进制包如果 npm 安装时这个 optional dependency 没装上CLI 就起不来。常见诱因有两个npm 配置里设置了ignore-scriptstrue导致 postinstall 脚本没有执行或者网络原因导致二进制包下载失败。解决步骤如下# 1. 检查 npm 是否忽略了脚本 npm config get ignore-scripts # 如果是 true先关掉 npm config set ignore-scripts false # 2. 清掉缓存后重装 npm cache clean --force npm install -g codex # 3. 如果还是报错手动装平台依赖包 npm install -g openai/codex-win32-x64装完之后执行codex --version确认版本然后用codex login完成 sign in with ChatGPT 的授权。Windows 用户一定不要跳过这一步直接跑命令会得到各种奇奇怪怪的“module not found”。6.2 账号会话数据泄露了怎么应急第二个高频问题是如果 ChatGPT 账号的会话数据 JSON 被泄露了怎么办。处理这件事的核心是“按泄露级别处置”。如果只是会话内容泄露先登录账号把相关会话删除或归档并在账号安全设置里撤销所有第三方应用授权。如果是会话里包含 API Key、支付信息这类敏感数据除了改密码还要立刻轮换所有关联的 API Key并检查用量页面有没有异常调用记录。如果涉及代码和业务数据及时通知团队做内部评估必要时重置仓库访问凭据。这里多说一句任何公开群里分享的所谓“免费 API Key”“共享账号会话”都不要碰。你永远不知道里面埋了什么雷轻则被偷用量重则被读取到真实业务数据。API Key 的安全使用原则就一条自己的 Key 自己保管不截图、不转发、不贴到公共平台。6.3 大批量会话文件怎么管理有些朋友习惯把 ChatGPT 的会话用 JSON 导出来做备份或迁移数据量一大就头疼。我的个人经验是不要用散落的 JSON 做长期管理而是定期把它们导入到本地目录按时间加主题分文件夹再用脚本批量做一次脱敏把邮箱、手机号、API Key 之类的替换掉之后再做归档。这个流程看似多花了几步但能在“数据可用”和“数据安全”之间找到平衡。尤其是团队协作时归档文件里的敏感字段一定要提前脱敏别等到要分享给同事时才发现文件里带了不该带的东西。回到开头那句话今年 DevDay 最触动我的一点是 OpenAI 终于把“模型 工具 协作 成本”放到了同一张桌上谈。我自己这几天的实操体会是Sol 适合跑重活dots 适合沉淀约束Spaces 适合组织协作单个拿出来都是好功能但真正值钱的是把它们串起来的那条工作流。最后给各位一个非常具体的建议不要一上来就把全团队搬进新工具先选一个小项目一个人负责维护 dots另外两三个人在 Spaces 里协作跑一两周把流程跑顺了、把坑踩明白了再逐步铺开。工具体验是主观的但效率提升是可以被记录的。这也是我现在正在做的事情。