又是一年的 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+ 项发布背后的主线逻辑

发布会第一个环节就是一口气过发布清单，现场大屏幕滚动得很快，我记了下笔记，大致分成五类：

看完这五类内容，我最大的感受是：今年的关键词是“生产环境”。去年大家还在讨论模型能不能写代码，今年官方已经把重心挪到了模型怎么在团队里干活、审批怎么走、账怎么算、权限怎么管。这其实是很务实的转向，因为过去一年里，单纯靠某一个模型能力的提升已经很难打动企业客户，企业真正要的是可交付、可审计、可维护的完整链路。

另一个细节值得注意：发布会全程没有公布什么“人类水平 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 和上一代模型的实际对比

我把我自己项目上的对比结果整理成了表格，仅供参考，不同场景差异会很大。

我的结论是：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-scripts=true，导致 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 里协作跑一两周，把流程跑顺了、把坑踩明白了，再逐步铺开。工具体验是主观的，但效率提升是可以被记录的。这也是我现在正在做的事情。