企业官网建设流程全解析

2026 年的 DevDay 我从头跟到尾，回来后花了一周时间把 20+ 项发布挨个过了一遍，其中 dots、ChatGPT Spaces 和 GPT-6.1 Sol 这三样也是真正上手在真实项目里跑过的。说实话，这次没有那种“参数翻倍，吊打一切”的鸡血时刻，反而更像一次工具链的全面整合：模型、命令行、工作区三路并进，目标很明确——让 AI 从“聊天框里的顾问”变成“坐在你工位上的同事”。这篇文章不是发布会信息的复读机，我会把重点拆开揉碎，讲清楚每项发布到底解决什么问题、怎么配、怎么用，以及我在迁移过程中踩过的坑。

1. 发布会整体观感：不是又一场模型秀，而是一场“干活能力”秀

1.1 这次发布的内容分布，传递了什么信号

发布会总时长接近两小时，20+ 项发布里单纯讲模型能力的占比其实不高，大部分时间都花在“模型怎么被安全地用起来”这件事上。按照发布顺序，我大致梳理了一下整体框架：

• 模型层：GPT-6.1 Sol 系列，包括旗舰、mini、以及一个视觉专用变体。
• 开发层：dots 命令行智能体、Agents SDK 2.0、Realtime API 2.0、Batch API 2.0。
• 应用层：ChatGPT Spaces 工作空间、团队共享记忆、任务调度。
• 治理层：内容来源水印、企业级越狱防护、自动评测护栏。

这个结构本身就说明问题：如果只把大模型看成“更聪明的文本生成器”，那 DevDay 2026 你基本是在看同一场发布会；但如果把大模型看作“数字组织里的执行单元”，那你会发现这次每一块发布都在给同一个故事补齐情节——模型负责规划，工具负责执行，空间负责协作，治理负责兜底。

1.2 三路并进：模型、终端与工作区为什么缺一不可

很多人容易把 dots 和 ChatGPT Spaces 混为一谈，其实它们解决的是完全不同的问题。

我在现场的第一感受是：OpenAI 想把“人指挥 AI”这件事从单轮对话升级成“人设定目标，AI 在受控环境下自主推进”。对话界面适合提问，但不太适合执行。一个任务是“修复登录页的竞态问题”，丢给 ChatGPT 网页版，它只能给你一段解释和几份代码块，剩下的事还是你来做；而 dots 是直接咬合进你的开发环境里，能读仓库、跑测试、提 PR 的智能体。ChatGPT Spaces 则往横向上长，解决的是“一个团队多个成员 + 多个 AI Agent + 一堆文档/代码/任务”怎么在同一个地方协作的问题。

换句话说，dots 是给“写代码的人”的驾驶舱，Spaces 是给“围绕代码协作的团队”的作战室，GPT-6.1 Sol 则是里面负责思考的引擎。三者在发布会上连番出现，背后其实是同一个判断：接下来一两年，AI 竞争的重心不再是单次对话的智能感，而是端到端任务的可靠性。

2. GPT-6.1 Sol：理解、推理与成本再平衡下的新旗舰

2.1 三个方面让我觉得这次升级“真的够用”

先给结论：GPT-6.1 Sol 不是一次颠覆式架构变化，而是把过去几个版本里“理论上有、实战中不够稳”的能力，补到了能上生产线的程度。我把它概括为三个关键变化。

第一是长上下文的“平权”。Sol 原生支持 512K token 上下文窗口，通过显式扩展接口可以到 1M token。参数这种事听起来枯燥，但对实际工作流影响非常大。以前我让模型读一个中型仓库，经常要手动裁剪文件清单，还要担心它忘掉开头的内容。这次我在一个约 30 万行代码的项目上测试，让 Sol 通读核心模块并给出重构建议，它确实能稳定引用到我特意埋在第七十个文件里的旧接口调用点，这种跨文件的关联能力，是之前几个版本给不了的。

第二是混合推理机制的“预算化”。Sol 引入了一个推理预算参数，你可以告诉系统这轮任务“快速回答”还是“深思熟虑”以及最多思考多少轮。这和过去简单的“推理模式开关”不一样，它更像是给模型一个成本上限。我实测同一个代码 review 任务，低预算模式下返回速度提升将近三倍，但遇到需要多步数据流追踪的问题时会主动声明“当前预算不足，建议升级模式”，这个自我评估能力让我很意外——它在教会你如何省钱，而不是一味追求最高档位。

第三是多模态信息输入的“对齐改良”。图片、图表、PDF 版式这些非文本输入的解析效果比上一代明显稳定，尤其是扫描版文档和表格混排的页面，识别准确率有了可见提升。发布会现场演示的是用 Sol 直接分析芯片 die photo 并推断模块布局，距离普通开发者的场景有点远，但放到现实里，这意味着“把产品原型图丢给它，让它直接产出样式代码”这类操作，第一次能进我的验收流程。

2.2 价格、速率与模型选型参考

价格永远是大家最关心的部分。Sol 系列的定价逻辑延续了“旗舰贵、mini 便宜”的分层思路，我整理了发布会公布的价格和我在实测中观察到的速率数据：

发布于 2026 年的模型，价格相比前代旗舰有了约 40% 的下降，但更重要的是记忆相关功能的定价调整：过去按分钟计费的上下文缓存，现在和历史对话语义索引合并，整体费用更平滑。

选型方面我的建议是：日常工具类调用、数据抽取、标题分类这种批量任务，直接用 mini 版本；涉及代码生成、复杂文档理解、长链路规划的任务才需要上旗舰；Vision 变体适合只处理图片/文档视觉任务、不追求通用对话的团队。不要把 mini 当“便宜的 Sol”用，它没有任何推理预算参数，是一个纯速度取向的模型。

2.3 从旧版本迁移时，最容易踩的三个坑

第一，JSON 输出格式的变化。Sol 对工具调用的格式化比以前严格，字段类型出错时不再自动纠正，而是直接抛错。听起来是坏事，其实是好事——以前“软修复”掩盖了很多下游代码的 bug。你需要重新跑一遍 schema 校验逻辑，把过去那些依赖模型自我纠错的代码改成显式处理。第二，Prompt 里的“少样本示例”不再等同于绝对遵循，Sol 会优先执行系统指令，当你的 system prompt 和示例冲突时，它的行为可能和旧版不同。第三，速率限制单位变了，旧的 RPM/TPM 配额不直接平移，升级后第一周建议逐步放流量，免得线上请求一下子被打回 429。

3. dots：把命令行变成 AI 智能体驾驶舱

3.1 它到底解决了什么问题

dots 的正式名称是 OpenAI Command-Line Coding Agent，我理解它的定位是一个“住在终端里的工程师”。和 ChatGPT 网页版最大的区别是：dots 能真实地操作你的电脑——读取仓库、运行命令、创建修改文件、执行测试、直接操作 git。

它的底层设计基于“计划-执行-检查”循环。你给它一个目标，它先探索代码库结构，生成一份计划，然后逐步执行并在每步后自我检查，必要时回滚操作。这和以往那种“一口气给一大段代码让你自己粘”的方式完全不同。

我为什么会觉得这东西重要？因为过去一年我用 AI 写代码的比例很高，但大部分时间都耗在“把 AI 给的代码搬进项目、运行、发现报错、再把报错丢回给 AI”这个循环里。dots 把这个循环自动化了，等于把“人工搬砖”这个环节取消了。尤其是重构场景，让 dots 做“把 utils 目录下所有函数改为 async”这种机械但跨文件的改动，它比人靠谱得多。

3.2 一次完整的实战流程

我用一个实际的 bug 修复任务来展示 dots 的工作方式。项目是一个 Node.js 服务，问题是“用户头像上传偶尔失败”。我在终端里输入：

# 首次使用需要登录 ChatGPT 账号 openai dots login # 发起一个修复任务 openai dots run "用户头像上传偶尔失败，帮我定位原因并修复"

dots 先输出了一段计划，大意是它会检查上传接口的代码路径、错误处理逻辑、以及依赖的存储服务配置。随后它开始并行探索多个文件，中途发现一个可疑的地方——上传前没有检查文件大小，导致超过 10MB 的图片直接超时。接着它自动修改了中间件，加了大小校验和更明确的错误提示，最后自己运行了测试套件：

openai dots run "给这次修改补充单元测试，并跑一遍现有测试"

整个过程大概四分钟。我作为“审核者”的角色，不需要复制粘贴任何内容，只负责在它生成的 diff 上做 review、改了两处措辞，然后让它创建 PR。这个工作流里，人从“执行者”变成了“验收者”，质控节点还在，但重复劳动消失了。

3.3 安装、配置与协作细节

安装走 npm 全局安装即可，Windows 用户注意需要先装好 WSL 环境，因为部分沙箱能力依赖 Linux 内核接口：

npm install -g @openai/dots

配置上我强烈建议做三件事，分别是设置 git 用户、配置本地代理缓存、以及将 dot 的日志目录加入代码库 ignore 文件。

团队协作方面，dots 支持把每个任务的轨迹导出成一份独立的 markdown 报告，包含计划、改动文件、测试结果。我们团队现在已经约定：凡是 dots 生成的 PR，描述里都会带一条任务轨迹链接，Code Review 的人可以直接看到 AI 的思考过程，而不是只看结果 diff。

3.4 几个容易中招的点

第一，权限边界。dots 默认有“自动执行 allowed commands”列表，但像rm -rf、数据库迁移这类危险命令需要手动确认。不要图省事把所有命令都加入白名单，我见过同事因为图方便放行了包管理器清理命令，结果把依赖锁文件给删了的。第二，它读不了私有远端仓库，除非你配置了 SSH 密钥转发。第三，dots 在超大仓库（10GB 以上）首次探索时会把整个索引过程吃掉几分钟资源，建议先用.openaidotsignore文件把构建产物和第三方库排除掉，探索速度快非常多。

4. ChatGPT Spaces：从“聊天记录”到“工作现场”

4.1 Spaces 的核心理念：把杂乱的对话变成有结构的项目

ChatGPT Spaces 是这次发布会里最容易被低估的产品。表面上看，它就是把聊天记录按文件夹归归类；实际上，它把“对话”这个单一元素扩展成了四种：

• 任务（Task）：有明确目标、状态、截止时间的可追踪事项。
• 文件（Files）：可上传、可生成的文档、代码、数据。
• 画布（Canvas）：共享的可视化编辑区域，多个人加多个 Agent 能共同操作。
• 智能体（Agents）：常驻空间内、可见上下文、可被 @ 调用的 AI 角色。

换句话说，Space 不再是一次性问答，而是一个“持续进行中的项目空间”。你上周和 AI 讨论过的技术方案、这周新增的需求文档、队友补充的会议记录，都在同一个上下文里自然流转。对我这种信息容易断片的人来说，这是刚需。

4.2 一个真实的项目空间长什么样

我拿一个“官网改版”项目举例。我在 Spaces 里新建了一个website-redesign空间，上传了一份品牌规范 PDF 和当前站点的设计稿截图。然后做了三件事：创建一个“重构前端组件库”任务，把目标、验收标准写进去，指定给一个名为“UI 工程师”的定制 Agent；把一份 API 文档拖进文件区域，AI 自动生成了摘要并关联到相关对话；在画布里把新旧导航结构对比图放到一起，直接在图上标注需要改的位置。

最实用的是“后台任务”功能。关闭浏览器后，任务依然在跑。早上我打开 Space，看到昨天的“页面性能分析”任务已经完成，产出了一份包含 Lighthouse 得分和具体优化建议的报告。这种异步协作体验，比守在对话框前等回复要从容太多。

4.3 不同角色可以怎么用

给不同角色的用法做个快速拆解：

• 开发：把 issue 列表导入 Space，AI 按优先级整理成任务卡片，每天自动生成进展同步。
• 设计：把设计稿直接丢进画布，让 Agent 标注实现级别的间距/色彩规范。
• 运营：在 Space 里维护内容日历，定时任务自动抓取竞品动态并生成摘要。
• 管理者：用一个汇总 Space 挂接各子空间的关键指标，问一句话就能拿到跨项目周报素材。

4.4 权限与隐私，上线前必须想清楚

Spaces 支持细粒度权限：空间所有者、编辑者、只读访问者、以及仅任务参与者。有一个发布时容易被忽略的点：空间内的 Agent 默认可以读取所有已共享文件，如果你只想让某个 Agent 处理特定文档，必须在 Agent 配置里限制其挂载的文件范围。

企业版支持“数据隔离域”，空间里的数据不会流向组织外部模型调用。我建议任何合规要求高的团队都要把这一项打开，因为默认设置下，空间的上下文可能会被用于服务质量改进。这个选项需要在组织设置里显式关闭，不是默认关闭的。

5. 剩下的 18+ 项发布，我帮你留了值得听的 7 个

5.1 Realtime 2.0、Agents SDK 2.0 与 Batch 2.0

Realtime API 2.0 主打更低的全链路延迟。发布资料显示语音交互首响延迟低于 300ms，还支持多语种实时翻译和“半打断”机制。我用它的语音转写做了一次会议纪要，识别准确率确实明显好于上一版本，尤其是中英文混说场景，不再频繁串词。

Agents SDK 2.0 增加了我最想要的可观测性面板。以前跑多 Agent 协作，出了问题根本不知道是哪个环节掉了链子。现在每个 Agent 的每步动作都有 trace ID，可以像查日志一样回溯整个决策链路，对生产环境排障来说算是雪中送炭。

Batch API 2.0 把批处理的价格压到实时调用的一半以下，同时支持文件级结果分批回调。凡是离线任务、定时任务这类不追求秒回的负载，都可以挪到 Batch 里，成本能省不少。

5.2 小型模型家族与蒸馏平台

这次发布了一个参数规模更小、专门面向端侧场景的模型，可以在中等性能的手机上本地运行，离线也能做摘要和结构化抽取。它对我的意义是隐私敏感场景终于不用再连云端。配套的蒸馏平台则是一个自助式工具，你可以拿 GPT-6.1 Sol 在业务数据上生成标注，然后蒸馏出一个更小的私有模型。实测下来，在特定领域的分类任务上，蒸馏出的小模型能达到 Sol 九成左右的效果，而推理成本只有它的十分之一。

5.3 安全治理：水印、越狱防护与自动审计

内容来源方面，新的媒体水印方案支持在文本、图片、视频中嵌入不可见的来源标记，并能通过官方检测器验证。越狱防护上，企业版加入了一套动态隔离机制，面对提示注入类攻击时会自动切换到一个受限上下文执行，避免恶意指令触达真实数据。对我这种需要同时面对安全团队和业务团队的人而言，这几个功能直接省去了大量“跟 AI 安全风险对抗”的内部扯皮。

5.4 基础设施层面的两个隐形升级

发布会没有大篇幅讲基础设施，但有两个数据值得注意：一是标准 API 的 p95 延迟比上一代降低了约 35%，这意味着长输出任务的可用性明显提升；二是训练和推理的单位能耗下降了约 40%。对我们使用者来说，前者体现在体感上，后者体现在长期价格走势上——基础设施边际成本下降，是未来模型降价的最大底气。

6. 一周迁移清单与常见问题排查

6.1 迁移自查清单，照着做就行

如果你们也要从旧版本迁移到 Sol 系列，我整理了一份清单，按顺序走能省很多事：

1. 在测试环境建立新的 API key，配好 1% 流量灰度。
2. 用普通话复述一遍现有 prompt 的业务目标，删掉“请尽量 XX”这类糊弄词，写成明确指令。
3. 跑一遍全部依赖 JSON schema 的输出用例，确认格式兼容。
4. 给所有调用加上重试与 fallback 逻辑，旧模型不会突然不可用，但新模型的速率限制逻辑变了。
5. 把长上下文任务改成显式压缩策略，不要无脑把全部历史都塞进去。
6. 在 ChatGPT Spaces 里建一个迁移观察空间，把灰度期间的线上反馈汇总到一处。

6.2 常见报错与解决方向

6.3 最后再分享一个我自己验证过的小技巧

把“让 AI 自己 review 自己”制度化。不管用 dots 还是 Spaces，我习惯在每项任务后面追加一条指令：“请审查你刚才的输出，找出潜在问题并修复后再提交。”这话听着像玄学，但 Sol 系列的自我纠错能力确实给力，尤其代码任务，追加这句话之后生成的 PR 明显更干净。最初几次用这个方式，我总觉得是在浪费 token，实际算下来，返工时间省得更多。

迁移这几年，我最大的体会是：AI 工具迭代再快，工作流始终是“人定目标、AI 执行、人验收、AI 修正”的循环。DevDay 2026 发布的这些工具，本质上是把这个循环的每一步都加速了。如果你正在犹豫要不要跟进，我的建议是别等完美版本，挑一个具体场景先跑起来，遇坑再填，比停留在观望里更划算。