企业官网建设流程全解析

说实话，DevDay 2026 的回放我一开始是想用 1.5 倍速刷完就算的，毕竟 "20+ 项发布" 这种标题，这几年已经见过太多。但玻璃窗外的现场直播我越看越不对劲，dots、ChatGPT Spaces、GPT-6.1 Sol 这三样东西拼在一起，根本不像是往我们熟悉的那张 AI 功能表上又加了三行，而是把过去两年做应用时的默认前提改掉了。

这篇复盘是我在发布会结束两周、自己动手在工程里把它们用起来之后才落笔的。我不会把 20 多个发布项目全都给你念一遍，那样没有意义；我想做的是把我认为"真正改变了开发方式"的东西拆开讲清楚，顺便把那些 PPT 上好看、实际用起来烫手的细节也交代一下。如果你这两天刚准备看录像，又不打算花三个小时全刷完，那我把省时间的结论放在最前面：重点看 dots，然后是 GPT-6.1 Sol 的长期任务表现，最后才是 ChatGPT Spaces；剩下的那些，大多数可以当发布会彩蛋看。

1. 把 Keynote 回放连看两遍，我判断重心不在模型榜单上

1.1 开场十分钟，舞台上的信号就不太寻常

本届 DevDay 的开场没有延续"参数规模又涨了多少、榜单又刷了几条"的传统套路。主讲人只花了很少的时间讲基准测试，然后把大量精力放在一个问题上：当一个人要和 AI 连续协作好几天、甚至跨数周完成一个复杂目标时，我们需要什么样的工具？

这个问题的答案，后来慢慢浮现成了两个方向。第一个方向是"更长的记忆与状态"，对应的是 GPT-6.1 Sol 那套把任务视为可跨会话延续的设计；第二个方向是"更灵活的编排层"，也就是 dots。

说实话，我一开始对集市里那种氛围感是持怀疑态度的，因为大模型发布这两年，台上讲"agent 协作""多步骤任务"的次数太多了，每次都是演示五分钟，开发者回去踩坑三个月。但这次不同，他们在舞台上直接给了一个从工单导入、到自动排查、到生成回复草稿、再到人工确认的完整流程，而且中途故意暂停，把其中一个步骤改掉，让后面的流程自动跟着调整。这个动作看起来简单，其实是把过去最头疼的"过程中修改目标"问题拿到了台面上。

1.2 20 多项发布，到底是谁的发布会

细数一下，这次能叫得上名字的发布确实超过了 20 项，但我把它拆成四层之后，思路就清晰了：

• 模型层：GPT-6.1 Sol 以及配套的评估框架、长任务评测集；
• 编排层：dots 空间、dots API、任务可视化与审计日志；
• 产品层：ChatGPT Spaces、搜索工具的开放接口、实时语音能力的降价与新端点；
• 基础设施层：Codex CLI 的定位升级、多平台原生支持、缓存与结构化输出改进。

如果只看模型层，会产生"这次不过是一次常规大版本升级"的错觉。可真正影响我们这些写代码的人工作方式的，反而是编排层和产品层。就拿我的实际体验说，过去做一个稍微像样的 agent 应用，需要自己处理对话状态、文件记忆、任务间跳转、失败重试以及权限管理，这一套下来通常要好几周。而 dots 把其中很大一部分变成了公共基础设施，我只需要描述"空间里有哪些资料、任务要拆成几个步骤、每一步谁来执行"，剩下的编排工作由平台完成。

1.3 我的总体判断

连看两遍回放之后，我最大的感受是：这场发布会不再是"给你一个更聪明的模型，剩下的你自己编"，而是"给你一个可以让模型在其中持续工作的环境"。模型聪明程度当然重要，但在实际工程里，真正拖后腿的往往是上下文断裂、任务中断、协作混乱。GPT-6.1 Sol 解决的是前两个问题，dots 解决的是后两个问题，ChatGPT Spaces 则是把它们同时带到多人团队里的容器。

这也是我写下这篇长文的原因。我不会在这里复述所有演示画面，我打算从每个工具"它到底解决什么、我拿它跑了什么、有哪些坑"这个角度来写，尽量让你看完就能判断自己要不要立刻上手。

2. dots：值得从二十多项发布里单独拎出来研究的"编排界面"

2.1 一句话定位

dots 最准确的定义，不是聊天界面，也不是工作流画布，而是一个带记忆、带权限、可审计的"任务编排空间"。它把每个可以被独立执行、验证、回滚的子任务抽象成一个点，这些点之间可以互相引用结果，也可以由不同角色（人或 AI）分别完成。

我试着用一个生活化的比喻来说：以前让 AI 干活，就像只有一个厨师在灶台上，什么都得排队等他，他忘了之前步骤你就得重新说；dots 则是把一间厨房分成了几个灶位，备菜、炖汤、摆盘同时进行，哪个灶位出问题就单独关掉，不用整个厨房停下来。

在实际使用中，dots 给每个任务点都保留了独立的上下文、输入输出、状态标签以及操作日志。这意味着我可以随时跑到中间某个点，改掉它的参数，后面的任务点会基于新结果继续跑，而不是全部推倒重来。这几乎是目前最贴近真实团队协作方式的 AI 编排层。

2.2 我回到公司后搭的第一个 dots 空间

现场的演示看得很爽，但真正让我决定立刻上手的是一个小实验。周五下午，我把自己手头一个挺麻烦的数据清洗任务搬进了 dots：

• 空间里挂了三个数据源：一个导出 CSV、一个线上数据库、一个包含历史口径说明的文档；
• 我拆出五个任务点：数据接入、字段标准化、异常值识别、业务规则校验、生成报告草稿；
• 中间第 3 步"异常值识别"跑完，我发现阈值设得太激进，于是只重置了这一个点，改完参数让它重跑；
• 后续两步自动读取了新的异常标注结果，没有重跑前两步。

整个过程大概花了 40 分钟，其中 30 分钟是我想清楚任务拆成几个点。而如果用传统方式，线程状态、临时文件、上下文同步这些问题足够让我忙到晚上。

这里我贴一下当时的 Python 伪代码，帮大家理解 dots API 的实际长什么样子：

from openai_dots import DotsSpace, Task, attach space = DotsSpace.create( name="report-clean-2026Q1", description="季度数据清洗与报告生成", default_model="gpt-6.1-sol", ) attach( space, sources={ "raw_csv": "s3://.../2026Q1_raw.csv", "spec_doc": "https://.../口径文档.docx", }, permissions=["data-reader", "reviewer"], ) t1 = Task.create( space=space, kind="ingestion", instruction="清洗CSV并统一字段名，按spec_doc里的口径做类型映射", ) t2 = Task.create( space=space, kind="validation", instruction="结合历史同环比，标记异常值，阈值按3sigma", depends_on=[t1], ) report = Task.run( space=space, start_at=t2, wait=True, on_approval="pause-before-send", )

2.3 好用的地方和仍然需要人盯着的地方

dots 让我最舒服的是"审计友好"。每个任务点的输入输出和状态变化都有记录，我不用再靠聊天记录去猜 AI 之前到底看到了什么。如果某个报告数字跟预期不一致，我可以直接往后翻关键节点的日志，而不是把整个 conversation 重新读一遍。

但也要提醒大家，dots 不是万能的。任务点与任务点之间虽然能传递结果，但如果你一开始的业务逻辑就描述得含糊，后面再漂亮的编排也救不回来。我试过把"分析一下数据"这种模糊任务丢进去，结果它给我产出一堆空泛结论；改成"对比过去 12 个月月度环比，给出异常波动月份及可能原因"之后，质量立刻就不一样了。编排工具只是把人的思考过程显性化，并不会替代思考本身。

另一个要注意的是 token 成本。dots 为了让每个任务点拥有完整上下文，会在任务交接时带上必要的中间结果。如果中间结果非常庞大，比如把一整个 CSV 都塞给下一个点，费用会上升得很快。我的习惯是两个大任务点之间先做一次字段筛选，只传真正需要的列，成本能明显降下来。

3. GPT-6.1 Sol 的升级重点不是更大，而是多了一个"时态"

3.1 它解决的，其实是不存在"跨天对话"这件事的尴尬

过去我们用 system prompt 定风格、用 few-shot 给例子、用 RAG 喂资料，但这一切都建立在"每次对话都是一个独立事件"的前提上。你让 AI 昨天做了一半的事，今天想让它接着做，你必须把昨天的结论和未完成的步骤重新描述一遍。这在短任务里还能忍，在持续几周的项目里就是灾难。

GPT-6.1 Sol 这次引入的"时态状态"（官方并没有用这个词，但我认为最贴切），核心是让模型能够在被明确定义的上下文中保存任务进度、中间假设、已完成子目标以及长短期记忆，并且在下一次会话中恢复。我不打算把它的实现细节吹成玄学，就说我实际观察到的东西：

• 同样一个多步骤任务，GPT-6.1 Sol 在中断 24 小时后恢复时，不需要我重新提供前置结论；
• 它在遇到前后矛盾的信息时，会倾向先问我一句"你确认要覆盖之前的判断吗"，而不是闷头按新信息跑；
• 它的输出开始自带"版本感"，同一个任务流里两次生成的结果不再完全互不相干。

这三点听起来不惊天动地，但放到 agent 工程里，是把"演示能跑"变成"生产能跑"的关键差异。

3.2 我拿实际模型对比跑了一遍

我把自己平时最常用的三组任务在 GPT-5.x 和 GPT-6.1 Sol 上各跑了一段时间，结果整理成下面的表，注意这是我自己业务里的实测值，不代表官方数据：

表格里那个"约 -6%"其实挺有意思。长文档提取场景下，GPT-6.1 Sol 因为理解跨章节引用的能力更强，不需要我像以前那样把相关段落反复塞进上下文，反而省了不少 token。这说明单纯看单价或者看上下文窗都不够，要看单位任务的实际投入。

3.3 部署和使用上的几个注意点

首先，模型在 API 里的调用方式和以前不太一样。最核心的一点是，你不再需要维护一个长长的对话历史来充当记忆，只要在请求里带上一个状态标识，模型会从它的持久化上下文里恢复。这对开发者来说是个好消息，也意味着要重新审视一下过去那些"把历史塞进 prompt"的代码，很多轮可以删掉了。

不过这也带来新的坏习惯风险。我见过身边有人为了省事，把所有任务都放同一个状态标识里跑，结果不同业务的数据互相污染。我的建议是：一个业务线建一个独立空间或标识，宁可多开几个，也不要混在一个长上下文里。它的持久化能力应该被当作一种"项目文件夹"来规划，而不是当成一个无限大的垃圾桶。

另外，GPT-6.1 Sol 在短小、单轮、高并发任务上并没有比上一代有压倒性优势。如果你的场景就是"每条请求独立翻译一句话"，换模型的意义不大，甚至可能因为更大的状态开销而更贵。选型的时候一定要分清长时态和短时态的边界。

4. ChatGPT Spaces 与 20+ 发布的黄金、白银、青铜清单

4.1 ChatGPT Spaces 到底是什么

如果说 dots 是为 AI 调度设计的，ChatGPT Spaces 则是给"人"设计的协作外壳。简单来说，它是个带权限管理、共享上下文、可绑定模型和工具的持久工作区。团队可以在这个空间里放项目文档、数据连接、对话记录、agent 配置，然后给不同成员分配查看、编辑、执行权限。

我目前的使用方式是把它当作"项目驾驶舱"：每天早上进空间看昨天的 agent 进度，在共享对话里给某个任务点补指令，或者直接在空间里挂载新的数据源，让整个团队都看到最新状态。以前这些东西散落在各个文档、聊天群和本地脚本里，现在总算聚到一处了。

4.2 三分钟建一个团队空间的实际步骤

我建议你拿到权限后先按下面的流程跑一遍，建一个最小空间：

1. 在 ChatGPT 界面或 API 控制台里选择"新建 Spaces"；
2. 填写项目名、描述、以及可选的初始上下文文档；
3. 设置成员权限，我通常会为 AI 执行任务建立一个独立角色，避免 AI 误改重要配置；
4. 绑定数据源或工具，例如代码仓库、数据库只读账号、网络搜索接口；
5. 设置 token 预算和审批策略，比如"超过某个成本阈值必须有人工确认"。

这里要专门说一句：权限不是摆设。Spaces 的权限模型比以往任何聊天项目都更接近真实协作系统，如果你图省事给所有成员开成管理员，那 AI 的误操作也没有任何缓冲。我吃过一次亏，让 AI 自动执行一个"整理文件"任务，结果它顺手把别人的历史文件也归档了。后来我规定所有涉及删除、移动、批量修改的操作，必须人工确认，才彻底不慌了。

4.3 其余发布里，哪些值得你花时间

我把 20 多项发布按我自己的标准分成了三档，整理成下表：

这里面有几个细节我想展开提一下。Codex 这次被重新定位成"命令行编码 agent"之后，我在 Windows 机器上安装时遇到了一个很典型的报错，内容大意是 missing optional dependency @openai/codex-win32-x64，要我用 reinstall codex 的命令重新装一遍。这个问题我在社区里看到不少人碰到，实际上就是安装器的平台依赖没拉全，重装、清掉缓存或者从其它终端安装通常能解决，不用因此怀疑功能本身。

另外，搜索工具开放 API 其实比表面上重要。以前给 agent 接"联网找资料"这个能力，要么用通用搜索的零散接口，要么自己爬网页再清洗，质量很不稳定。官方把搜索 API 开放之后，agent 的引用来源和最新性都有了统一入口，配合 GPT-6.1 Sol 的长时态，做"持续跟踪行业动态"这类任务会顺手很多。

至于青铜档，我不否认它们在体验上有价值，但它们不会改变你写代码的方式，这里就不浪费篇幅了。

5. 回看两周之后，留在我工程栈里的就这三样

5.1 第一样：把任务拆成 dots 空间，成为新默认

这两周我已经把三个正在跑的项目迁移到了 dots 的思路上，迁移本身并不复杂，因为不需要大改模型调用，只需要把原本一个长 prompt 的任务改写成"若干任务点 + 每点明确输入输出"的格式。真正难的是我自己要忍得住：以前我很喜欢把需求一口气写进 prompt 里，让模型自己发挥，现在必须在第一步就把边界说清楚。

这种"先说清，再开工"的习惯，短期看起来多花了时间，长期节省的时间是惊人的。因为我们团队里现在不论谁接手某个业务，只要打开空间看任务点，就知道这个任务的逻辑链路长什么样，不用再去翻聊天记录猜当时的意图。

5.2 第二样：API Key 与权限的卫生习惯

如果你最近打算试用新模型和 dots，我特别想提醒一件事：OpenAI 的 API Key 应该在官方控制台的 API Keys 页面独立创建，按项目分别命名，该开只读权限的就别给全部权限，该走代理走的按你们公司的规范走，不要把 Key 直接写在仓库里、前端代码里、或者粘贴到聊天工具里。

我理解大家爱分享新东西的心情，但"分享 Key"这件事千万不要做。一是成本风险不可控，二是出现隐私泄露时根本没法追溯。正确的做法是把 Key 放到环境变量或专门的密钥管理服务里，然后给每个 Key 设置用量上限，让它最大也只能跑你允许的那个量。我见过太多因为随意贴 Key 导致的惨案，这个习惯一定得在一开始就立住。

5.3 第三样：给新能力留出两周观察期

最后一条经验可能听起来不够"极客"，但它特别实用：面对一次 20 多项的发布，千万不要全部接入生产。我会给自己定一个两周的观察期，第一周只在新模型或新 API 上跑非核心任务，看看稳定性、成本和真实效果；第二周再把表现最好的一两个能力切到核心流程。

我自己在这次 DevDay 之后也是这么做的。第二周我把 GPT-6.1 Sol 接了一个重要的定时报告任务，前三天正常运行，第四天发现它在某个边界输入上产生了幻觉式结论。因为那个任务里有审批节点，所以没有直接出事故，但这个发现告诉我：新模型的长时态能力虽然强，依然不能省略人工校验环节。等我把边界输入的例子补进空间里的校验规则之后，它运行到现在没有出过问题。

如果你现在正准备上手这些新玩意，我劝你也别急着删掉原来的回退方案。新模型、新编排层、新协作空间，叠在一起确实能产生很大的想象空间，但工程稳定性的基本盘始终是可控、可审计、可回滚。先在一个小空间里跑通流程，确认它真的能接手你的脏活、累活和需要连续作业的活，再放心地把它请进主力流程里。