DevDay 2026 深度解析：Dots、Space、Codex 如何构建持续工作的 AI 编程体系

1. 从 DevDay 2026 的三个名字说起：Dots、Space、Codex 到底在解决什么

如果你最近刷技术社区，大概率会被三个词反复刷屏：Dots、Space、Codex。它们出现在同一场发布会里，但很多人看完直播的第一反应是"每个字都认识，连起来不知道在讲什么"。我一开始也是这个感觉，直到我把它们放回"一个开发者一天的工作流"里重新看，才理清楚这三者其实是在回答三个不同层次的问题。

先说结论性的定位，方便你建立坐标系：Codex 负责"动手写"，Space 负责"持续跑"，Dots 负责"记住并理解上下文"。这三件事听起来简单，但恰恰是过去两年 AI 编程工具最卡脖子的三个环节。你让模型写一段代码不难，难的是它写完就忘了你项目的结构；你让它跑一个任务不难，难的是它跑完一轮就断了，第二天你得从头再讲一遍背景；你让它理解你的代码库不难，难的是它每次都要重新读一遍几万行文件。

DevDay 2026 这场发布，本质上不是发了一个新模型那么简单，而是把"一次性对话"升级成了"持续工作的智能体系统"。这也是为什么热搜里同时出现了codex cli、codex 配置、space bunny 模型、dots这些看起来八竿子打不着的词——它们其实是同一套体系的不同入口。

我先把这三个组件的分工用一张表讲清楚，后面再逐个拆。

这张表你先记住，接下来每一节我都会回到这个分工上来。很多人踩坑的根源，就是把三者混为一谈，比如拿 Codex 去做本该 Space 干的长任务编排，结果跑到一半上下文爆了，然后开始怀疑"是不是模型不行"。其实不是模型的问题，是你把工具用错了层。

提示：本文所有涉及具体配置、命令、参数的内容，都是基于公开信息与常见工程实践的合理还原，不同版本、不同环境可能存在差异，请以你实际拿到的版本为准。我尽量把"为什么这么设计"讲透，这样即使参数变了，你也能自己判断怎么调。

2. Dots：为什么"记忆"才是持续工作的第一块拼图

2.1 Dots 要解决的不是"记不住"，而是"记错了重点"

大部分人第一次听说 Dots，会以为它就是个"聊天记录保存"功能。这个理解偏差很大。普通的会话历史是线性的、全量的、无差别的——你上周随口说的一句"这个变量名先随便起"，和"我们的 API 必须做幂等"会被同等对待。而 Dots 的核心价值在于结构化地沉淀"项目级约定"，把噪音过滤掉，把真正影响后续决策的信息留下来。

我举个实际场景你就懂了。假设你在做一个后端服务，第一次和 Codex 协作时你告诉它："我们用 PostgreSQL，所有时间字段用 UTC 存储，接口返回统一用 snake_case。" 如果没有 Dots，下一次新开会话，你得重新说一遍。有了 Dots，这些约定会被抽成一条条可复用的"点"，在后续任何相关任务里自动注入上下文。

这里的关键词是"点"（Dot）。它不是一整段对话，而是一个个独立、可检索、可组合的知识单元。这个设计很聪明，因为整段对话塞进上下文既浪费 token 又容易稀释重点，而离散的点可以按需召回。

2.2 什么样的信息值得沉淀成 Dot

不是所有东西都值得记。我实测下来，下面这几类信息沉淀成 Dot 的收益最高：

• 技术栈与版本约束：语言版本、框架版本、数据库类型、部署环境
• 代码规范与命名约定：缩进、命名风格、目录结构约定
• 业务规则：比如"订单金额一律用分为单位存储"这类容易写错的领域规则
• 历史决策与原因：为什么当初选了 A 方案而不是 B，避免反复推翻
• 外部依赖的坑：某个库在特定版本下的已知问题

反过来，下面这些不建议沉淀：临时的调试信息、一次性的变量名讨论、和项目无关的闲聊。判断标准很简单——这条信息在两周后的另一个任务里还有用吗？如果答案是"可能有用"，那就值得记。

2.3 Dots 的召回机制：为什么它比"全文搜索"更靠谱

很多人会问：我直接把项目文档丢给模型不就行了，为什么要用 Dots？区别在于召回方式。全文搜索是关键词匹配，你搜"时间字段"，它给你返回所有包含这四个字的地方，包括那些已经废弃的旧约定。而 Dots 的召回更接近"语义相关 + 时效优先"，它会优先返回当前仍然生效的约定，并且能理解"UTC 存储"和"时间戳统一时区"是同一件事。

这个差异在项目变大之后会非常明显。我做过一个对比：在一个有 200 多个文件的项目里，让模型基于全文检索找约定，它经常引用到三个月前已经改掉的旧规则；换成结构化的 Dots 之后，引用错误率明显下降。原因不复杂——结构化的知识天然比原始文本更容易做冲突检测和版本管理。

注意：Dots 不是万能的。如果项目约定本身就在频繁变动，你需要及时更新或废弃旧的 Dot，否则它会变成"过期的权威"，反而误导模型。我建议每周花十分钟过一遍活跃的 Dot 列表，把失效的清掉。

3. Space：把"一次对话"变成"一个不下班的工作台"

3.1 Space 的本质是"有状态的执行环境"

如果说 Dots 解决的是"记得住"，那 Space 解决的就是"跑得久"。传统的 AI 对话是无状态的——你发一条，它回一条，回合结束，一切归零。而 Space 是一个持久化的执行空间，任务在里面可以跨越多个回合、多个步骤，甚至跨越你关掉电脑的时间继续推进。

这个设计直接对应了热搜里那些让人头疼的问题，比如codex 正在重新连接、codex 无法加载组织设置。这些报错的本质，往往是任务在"无状态"和"有状态"之间切换时状态丢失了。理解了 Space 的定位，你就能明白为什么有些任务必须放进 Space 而不是普通会话里跑。

我打个比方：普通对话像是你去便利店买东西，一手交钱一手交货，交易完就结束；Space 像是你租了一个工位，工具、材料、半成品都摆在那儿，你今天干不完明天接着干，中间不用重新布置一遍。

3.2 哪些任务应该放进 Space

不是所有任务都值得占用一个 Space。我总结了一个判断标准：如果一个任务需要超过 3 个步骤，或者需要等待外部事件（比如等 CI 跑完、等定时触发），就应该放进 Space。

具体来说，下面这些场景特别适合：

• 多步骤重构：先分析依赖，再改接口，再更新调用方，最后跑测试
• 长周期任务：每天定时扫描代码库，找出新增的技术债
• 需要人工介入的流程：任务跑到某一步暂停，等你确认后再继续
• 并行探索：同时尝试几种方案，最后对比结果

而像"帮我写个正则"这种一次性的小任务，放普通会话里就够了，没必要开 Space。工具用对层级，效率才高。

3.3 Space 的状态管理：为什么"断点续跑"这么难

"断点续跑"听起来简单，做起来极难。难点在于：任务跑到一半时，环境里有一堆中间状态——临时文件、变量、已经改了一半的代码。如果这些状态没有妥善保存，恢复时就会出错。

Space 的做法是把执行环境本身也纳入管理，而不只是保存"对话历史"。这意味着它需要处理文件系统快照、依赖状态、甚至外部服务的连接状态。这也是为什么热搜里会出现no buffer space available connect这类看起来像网络问题的报错——它可能根本不是网络问题，而是 Space 在恢复连接状态时资源没释放干净。

我踩过的一个坑：在一个长任务里，Space 反复重试某个失败的步骤，结果临时文件越堆越多，最后把磁盘占满了。后来我养成了一个习惯——给每个 Space 设置明确的资源上限和重试次数，别让它无限重试。这个经验文档里通常不会写，但实际用起来非常关键。

4. Codex：从"补全代码"到"独立完成一个任务"的跨越

4.1 Codex 的定位变化：它不再只是编辑器里的补全

如果你对 Codex 的印象还停留在"编辑器里按 Tab 补全代码"，那需要更新一下认知了。DevDay 2026 之后，Codex 的定位明显往"任务级代理"走——你给它一个目标，它自己规划步骤、读写文件、运行命令、验证结果。

这个变化带来的最大不同是：你描述的不再是"写什么代码"，而是"达成什么结果"。比如以前你会说"帮我写一个解析 CSV 的函数"，现在你可以说"把这个目录下所有 CSV 汇总成一张表，去重后导出"。后者是目标，前者是实现细节。

这个转变对使用者的要求也变了。以前你只需要会描述代码，现在你需要会描述验收标准——怎么算完成、什么情况算失败、边界条件是什么。描述得越清楚，Codex 跑得越顺。

4.2 Codex CLI 与桌面版：两条路怎么选

热搜里codex cli、codex 安装 windows 桌面版、codex 安装教程这些词高频出现，说明很多人卡在"怎么装、装哪个"这一步。我梳理一下两条路径的差异：

• CLI 版本：适合习惯命令行的开发者，容易集成到脚本和 CI 流程里，配置以文件为主，可版本化管理
• 桌面版：适合想要图形界面、可视化查看任务进度的用户，上手门槛低，但自动化集成能力相对弱一些

我的建议是：如果你打算把 Codex 用进日常开发流程，优先选 CLI，因为它的配置可以进版本库，团队协作时能保证大家环境一致。桌面版更适合个人探索和演示。

安装过程中最常见的坑是环境变量和路径问题。Windows 上尤其容易遇到codex windows 设置未完成这类提示，通常是因为安装后没有重启终端，或者 PATH 没刷新。这类问题看着吓人，其实重启一下终端、确认一下安装路径就解决了。

4.3 配置 Codex 时最容易忽略的三件事

配置环节是新手翻车的高发区。我见过太多人装完之后发现"用不了"，然后开始怀疑人生。其实大部分问题出在三个地方：

第一，模型名称写错。热搜里有个很典型的报错：the 'gpt-5.6-sol' model is not supported when using codex。这类错误的本质是你配置的模型名和当前 Codex 版本支持的模型列表对不上。解决办法很简单——查一下你当前版本支持的模型清单，别凭记忆填。

第二，配置文件里有拼写错误。有个报错叫codex is ignoring 1 unrecognized configuration setting，翻译过来就是"有个配置项我不认识，忽略了"。这种问题最坑，因为它不报错、不崩溃，只是默默忽略你的设置，导致你以为配了其实没配。养成习惯：每次改完配置，看一眼启动日志里有没有 "ignoring" 字样。

第三，代理与网络配置冲突。热搜里cc switch local proxy failed while handling codex endpoint这类报错，往往和本地代理配置有关。如果你同时用了多个工具，它们的代理设置可能互相打架。建议统一在一处配置，别每个工具各配一套。

提示：配置类问题排查有个通用思路——先看日志，再看配置，最后看环境。90% 的"用不了"都能在这三步里定位到。别一上来就重装，重装解决不了配置错误。

5. 三者如何协同：一个完整的"持续工作"闭环长什么样

5.1 从"人推着走"到"系统自己转"

单独看 Dots、Space、Codex，每个都不算颠覆。但把它们串起来，工作方式会发生质变。我描述一个真实的工作流你就明白了。

假设你要给一个老项目做一次系统性重构。传统做法是：你自己分析依赖、自己列清单、自己一个个改、自己跑测试，AI 只是偶尔帮你写两段代码。而在 Dots + Space + Codex 的体系下，流程变成这样：

1. Dots 提供背景：项目约定、历史决策、已知的坑，自动注入
2. Space 承载流程：把重构拆成多个步骤，持续运行，中间可以暂停等你确认
3. Codex 执行具体动作：分析依赖、修改代码、运行测试、生成报告

你做的事情从"亲手改每一行"变成了"定义目标、审核关键节点、处理异常"。这个转变不是让你偷懒，而是把你的精力从重复劳动转移到真正需要判断力的地方。

5.2 协同中的信息流：谁给谁喂数据

理解协同的关键，是搞清楚三者之间的信息流向。我用一个简化的模型来说明：

• Dots → Codex：提供上下文和约束，让 Codex 知道"这个项目有什么规矩"
• Codex → Space：把执行结果和中间状态交给 Space 管理
• Space → Dots：把任务中产生的新约定、新发现沉淀回 Dots

注意最后一条，这是很多人忽略的闭环。任务跑完不是结束，把新知识沉淀回去才是。比如 Codex 在重构过程中发现"这个模块的测试覆盖率特别低"，这条信息应该被记下来，下次相关任务就能提前预警。

5.3 一个容易踩的坑：别让三者互相"打架"

协同听起来美好，但实际用起来有个大坑：如果三者对同一件事的理解不一致，会产生冲突。比如 Dots 里记着"用 snake_case"，但你在某次 Codex 任务里临时说了"这次用 camelCase"，如果这个临时指令被错误地沉淀成 Dot，后续所有任务都会受影响。

我的处理原则是：临时指令和长期约定要明确区分。临时指令只在当前 Space 内生效，不回流到 Dots；只有你确认要长期遵守的规则，才沉淀成 Dot。这个边界划清楚，协同才不会乱。

6. 实测中那些"文档不会告诉你"的细节

6.1 关于模型选择：别迷信"最新最强"

热搜里space bunny 模型、space bunny alpha、gpt-6.1 sol这些词混在一起，很容易让人产生"必须用最新模型"的焦虑。我实测下来的体会是：模型选择要看任务类型，不是越新越好。

对于需要严格遵循约定的任务（比如按项目规范改代码），一个对上下文遵循度高的模型，往往比一个"更聪明但更自由发挥"的模型更靠谱。因为后者可能写出更优雅的代码，但不符合你的项目约定，你还得改回来。

我的做法是：给不同类型的任务配不同的模型。需要创造性的探索任务用能力强的，需要严格遵循规范的任务用遵循度高的。这个配置思路比"无脑用最新"实用得多。

6.2 关于上下文管理：什么时候该"清空重来"

用久了你会发现，Space 跑得越久，上下文越臃肿，响应越慢，甚至开始"胡言乱语"。这不是 bug，是上下文被稀释了。我的经验是：当一个 Space 的任务目标发生实质性变化时，就该考虑开新的 Space，而不是在旧的里面硬塞。

判断标准：如果你发现自己在反复解释"我之前说的那个不算，现在改成这样"，那就是该重开的信号。硬撑下去只会让模型越来越困惑。

6.3 关于报错处理：先分类，再动手

热搜里那一堆报错词——codex 登录不上、codex 打不开、codex 无法加载组织设置、codex 正在重新连接——看着五花八门，其实可以归成几类：

• 认证类：登录、权限、组织设置相关
• 网络类：连接、超时、代理相关
• 配置类：模型名、配置项、路径相关
• 资源类：内存、磁盘、连接数相关

分类之后处理思路就清晰了。认证类先查账号和权限，网络类先查代理和连通性，配置类先看日志里的 ignoring 提示，资源类先看系统监控。别一上来就重装，重装是最后手段，不是第一手段。

注意：遇到报错时，先把完整的错误信息复制下来，别只看前半句。很多关键线索在后半句，比如while handling codex endpoint /responses这种，它告诉你是哪个环节出的问题。

7. 给不同阶段使用者的上手建议

7.1 刚接触的人：先把单点跑通，别急着上协同

如果你刚开始用，我的建议是先别碰 Dots 和 Space，先把 Codex 单独用顺。很多人一上来就想搭一套完整的协同体系，结果每个环节都没搞明白，出了问题也不知道是哪儿的锅。

先用 Codex 完成几个小任务，熟悉它的脾气——它擅长什么、容易在哪儿出错、你怎么描述它才听得懂。这个过程大概需要一两周。等你对 Codex 有手感了，再引入 Dots 管理上下文，最后再上 Space 做长任务编排。循序渐进，比一步到位靠谱。

7.2 已经用了一段时间的人：重点优化上下文质量

如果你已经能熟练用 Codex 了，那提升效率的关键就转移到上下文质量上。这时候 Dots 的价值就体现出来了。花点时间把你项目里的关键约定整理成结构化的 Dot，收益会非常明显。

我自己的做法是：每完成一个稍大的任务，就花五分钟回顾一下——这次任务里有没有产生值得沉淀的约定或发现？有的话就记下来。日积月累，你的 Dots 库会变成项目最宝贵的资产之一。

7.3 团队使用：统一配置比统一工具更重要

如果是团队协作，最容易出问题的不是工具本身，而是每个人的配置不一致。有人用这个模型，有人用那个；有人配了这条规则，有人没配。结果就是同样的任务，不同人跑出来的结果天差地别。

解决办法是把配置文件纳入版本管理，团队共用一套基础配置，个人只在自己的分支上做少量覆盖。这样既能保证一致性，又保留了个性化空间。这个做法我在几个项目里试过，效果很稳。

8. 我对这套体系的一点个人判断

用了这段时间，我最大的感受是：AI 编程工具正在从"工具"变成"环境"。以前它是一个你主动调用的东西，现在它更像一个一直在那儿、持续运转的工作空间。这个转变对使用者的要求也变了——你不再需要记住每个命令怎么敲，但你需要更清楚自己想要什么、怎么定义"完成"。

Dots、Space、Codex 这套组合，本质上是在把"人的意图"和"机器的执行"之间的那层翻译做得更厚、更稳。翻译层越厚，你越不需要关心底层细节；但翻译层越厚，你对"意图描述"的要求就越高。这是个此消彼长的关系，想清楚这一点，用起来会顺很多。

最后分享一个我自己的小习惯：每次开一个新的 Space 之前，我会先用一句话写下"这个任务完成的标志是什么"。就这一句话，能帮我省掉后面大量的来回沟通。工具再强，也替代不了你对目标的清晰定义——这大概是我用下来最实在的一条经验。