正文
GPT-5.6 从有限预览走到正式发布时，最容易被当成背景消息的有两件事：OpenAI 给它起了 Sol、Terra、Luna 三个名字；同一天，Codex App 开始并入新的 ChatGPT 桌面 App。
一件事看起来像命名，一件事看起来像产品整合。把它们放在一起看，反而能读出 OpenAI 对下一代工作方式的判断：模型不再只是一张能力榜，开发者也不再只是在聊天框和终端之间来回切换。
以下关于 GPT-5.6 发布的描述保留 2026-07 的背景；此后模型与入口已有更新，实际可见模型仍受套餐、工作区和管理员策略影响。
三个名字，三种使用方式
过去的模型选择常常很粗糙：要么开最强模型，要么找一个便宜的替代品。Sol、Terra、Luna 把这件事摆得更直白。它们是长期能力层级，不是三个彼此隔绝的产品。
| 模型 | 我会把它放在哪里 |
|---|---|
| Sol | 复杂重构、疑难 Bug、权限和数据迁移等失败代价高的任务。它的 API 价格也是三者最高，适合把时间花在真正需要判断力的地方。 |
| Terra | 日常功能、测试补齐、PR 初审和边界清楚的修复。它更像团队默认会落到的主力档。 |
| Luna | 仓库扫描、日志归类、固定格式改写和其它可批量验收的小任务。它负责把重复工作做快、做便宜。 |
三者都拥有很长的上下文窗口，差别主要在能力、吞吐和价格。Sol 的 API 别名仍是 gpt-5.6，Terra 和 Luna 则让“够用”成为一个更容易单独选择的选项。
界面中的推理强度、速度选项和模型名称代表不同维度。具体可选项与含义会随产品和版本变化，应以当前模型选择器及官方说明为准。
Codex 进了 ChatGPT，开发方式却没有变成聊天
OpenAI 公告里说得很具体：合并的是 Codex App 和新的 ChatGPT 桌面 App。更新后的应用里同时有 Chat、Work 和 Codex，原来的 Codex 项目还能继续用，开发者也可以把 Codex 保持为默认视图。
这不是 Codex 消失，更不是“所有 Codex 模型都被 GPT 替代”。Codex 仍然是那个能进仓库、看 diff、跑终端命令和交回验证结果的 Coding Agent。变化在于，它被放进了一个更大的工作台里。
ChatGPT Work 用同一套 Agent 方法处理文档、表格、浏览器和连接器里的长任务。一个人在上午用 Work 整理需求和资料，下午切进 Codex 改仓库，过程里的上下文开始有机会留在同一处。这个入口上的变化，比应用换了一个图标更值得关注。
模型在变，工作台才是这次发布的重点
模型能力的靠拢其实比这次 App 合并更早。OpenAI 在 GPT-5.4 发布时就提到，主线 GPT 已经吸收了 GPT-5.3-Codex 的 Coding 能力，并同时进入 ChatGPT、API 和 Codex。
GPT-5.6 把这条线又往前推了一步。通用模型开始同时具备代码、工具调用、Computer Use 和长任务能力；API 里的 multi-agent 也把并行执行带到了更广的场景。
不过，同一个模型放进不同工作台，结果依然会不同。Codex 拿得到仓库、文件、终端、审批和测试工具；普通聊天不会自动知道一个项目的现状。模型名相同不等于工作方式相同，仓库规则、权限边界和验收标准仍然决定了 Agent 最后交回什么。
把最强模型留给真正难的任务
我更喜欢把这三层当成一支小团队，而不是一张排行榜。Terra 先处理绝大多数稳定的工程任务，Sol 接手需要跨模块判断或承担较高风险的部分，Luna 则把那些重复、可验证的工作压到最低成本。
这套分工比“永远使用最强模型”更接近真实开发。最强模型能写出更长的计划，却不一定值得拿来补每一个类型；最便宜的模型能跑很快，也不该替你改权限或设计迁移方案。把模型放对位置，团队才看得见它究竟省下了多少返工。
标准 ChatGPT 对话里，符合条件的付费账号主要会接触到 Sol 的推理档位。Terra 和 Luna 更常出现在 Work、Codex 与 API。想让三层都进入日常开发，终端和 API 工作流会比单纯换聊天模型更重要。
这次合流会给开发者留下什么
GPT-5.6 最有意思的地方，不是又多了一款“最强模型”，而是它把模型分层和工作台整合放在了同一张发布清单里。以后开发者选择的会越来越像工作方式：哪类任务需要深想，哪类任务适合批量跑，哪些动作必须留在能看见 diff、测试和审批的环境里。
Codex 并入 ChatGPT 之后，聊天、资料整理、浏览器操作和真实仓库开发会靠得更近。那不代表 AI 可以替代工程流程。相反，工具越接近一个完整工作台，项目规则、权限和最后的人工判断就越值得被认真保留。
ChatGPT 更新到 GPT-6，Codex 为什么不一定同步
2026 年 10 月 7 日，OpenAI 在 GPT-6 与 Intelligent UI 发布说明中明确表示，这次 Chat 更新没有同时改变 Work 和 Codex 使用的模型。那是该次发布当时的范围，不意味着此后两个入口永远停留在同一版本。
同名模型也要连同产品入口一起理解。Chat 面向对话，Work 处理多步骤任务，Codex 面向仓库与软件开发；它们可用的工具、权限、推理档位和上下文都可能不同。API 模型标识和订阅界面的显示名称也不应直接画等号。
| 比较项 | 应记录什么 |
|---|---|
| 入口 | Chat、Work、Codex 桌面 / CLI，还是 API。 |
| 模型 | 界面显示名称或 API 返回的模型标识；看不到快照时标记未知。 |
| 任务环境 | 仓库状态、工具权限、推理档位和客户端版本。 |
| 时间与条件 | 测试日期、套餐、工作区策略及可见额度。 |
截至 2026 年 11 月 2 日，OpenAI Work 与 Codex 说明将 GPT-6.1 Sol、Terra 等列为 Work 和 Codex 的模型，实际显示仍取决于套餐和工作区。选择器显示 Default 时，也不应擅自断言某次请求具体用了哪个快照。要比较编程质量与成本，可以查看 GPT-6.1 Terra、Sol、Astra 的 Codex 选型。
GPT-5.5 退役：把模型选择从“设置项”变成可盘点的依赖
OpenAI 此前通知 GPT-5.5 的产品退役安排。Codex 更新记录明确指出，2026-10-14 起，使用 ChatGPT 登录的 Codex 不再提供 GPT-5.5；OpenAI API 和以 API Key 认证的 Codex 会话不受这一具体措施影响。
对使用 ChatGPT 登录 Codex 的团队，当时的建议提到 gpt-5.6-sol；此后 Codex 更新记录建议在可用时使用 gpt-6.1-sol。这不是简单地在模型选择器里改一次，因为模型名可能被写进 workspace 默认值、保存的模型设置、自定义 Agent、scheduled task 和脚本。
先区分受影响入口
| 入口 | 是否受本次退役影响 | 优先动作 |
|---|---|---|
| ChatGPT / ChatGPT Work / Codex，使用 ChatGPT 登录 | 是 | 盘点模型设置与自动化，核对当前可用的替代模型。 |
| OpenAI API | 否 | 不要因为这次产品退役盲目替换 API 模型；分别核对 API 生命周期。 |
| 自定义 Agent 和 scheduled task | 可能 | 查看每个保存配置是否固定选择 GPT-5.5。 |
| 脚本与运行手册 | 可能 | 搜索模型 ID、默认值和失败回退逻辑。 |
迁移前怎么盘点
先从工作区配置和仓库脚本开始搜索：
rg -n --hidden -g '!node_modules' -g '!\.git' 'gpt-5\.5|GPT-5\.5' .然后逐项检查：
- Codex workspace 默认模型和保存的模型设置。
- Custom Agent、Skills 或任务模板里的模型选择。
- Scheduled tasks 的模型与 reasoning 配置。
- CI、shell 脚本或内部封装是否假定 GPT-5.5 可用。
- 任务失败时是否会无提示地回退到不同能力、成本或权限边界的模型。
替换后不能只看“任务启动成功”
迁移后使用一组固定验收任务，至少覆盖：小型修复、跨文件重构、测试失败诊断和带审批的工具调用。记录模型、reasoning 档位、工具调用、耗时、token 或额度消耗，以及最终验证结果。
尤其要确认两件事：
- 目标替代模型是否对该工作区和套餐可用。
- 原任务中显式选择的模型、reasoning 或权限设置没有在迁移时被静默改成默认值。
如果团队依赖 Terra 或 Luna 承接高吞吐任务，不要把这次退役理解为“所有任务都改成 Sol”。当前 Codex 更新记录建议在可用时使用 gpt-6.1-sol；具体的成本分层仍应按任务风险和可用性验证。
迁移后的验收清单
- [ ] 已搜索工作区、仓库和自动化中的 GPT-5.5 引用。
- [ ] 已更新 ChatGPT 登录 Codex 的保存模型与默认模型。
- [ ] 已核对 custom agents 与 scheduled tasks。
- [ ] 已在目标工作区验证所选替代模型可用。
- [ ] 已对代表性任务比较工具调用、验证结果和成本。
- [ ] 已记录失败回退，不让关键任务静默换到未知模型。