ChatGPT Classic进入停服倒计时

OpenAI 已经给旧版 ChatGPT 桌面客户端定下终点：ChatGPT Classic 将于 2027 年 1 月 30 日停止服务。

11 月 2 日起，仍在使用 ChatGPT Classic 的用户陆续在应用内看到停用横幅。按照提示，用户可以直接前往新版 ChatGPT 桌面应用的下载页面；使用同一个 ChatGPT 账号登录后，完整聊天记录将随账号保留，原有对话可以继续进行。(ithome.com)

从今天（2026 年 11 月 3 日）计算，Classic 距离正式停服只剩 88 天。这不是一次普通的版本更新，而是 OpenAI 在清理一套已经与其智能体战略脱节的旧产品架构。

ChatGPT Classic是什么

ChatGPT Classic 是 OpenAI 旧版 ChatGPT 桌面应用在产品重组后的名称。

OpenAI 在今年 7 月推出新的 ChatGPT 桌面应用后，将原来的 ChatGPT 客户端改名为 ChatGPT Classic；原有 Codex 桌面应用则通过更新变成新版 ChatGPT，并在同一个窗口内提供 Chat、ChatGPT Work 和 Codex 三套体验。(ithome.com)

这套命名一度让用户相当困惑，因为电脑上可能同时出现两个名称近似、定位却不同的 ChatGPT 图标：一个是以传统对话为核心的 Classic，另一个是加入智能体工作流和编程环境的新版应用。

| 产品 | 核心定位 | 主要能力 | 2027 年后的状态 | |---|---|---|---| | ChatGPT Classic | 传统桌面对话客户端 | 日常聊天、历史对话、既有企业功能 | 2027 年 1 月 30 日停服 | | Chat | 快速对话与信息处理 | 问答、搜索、写作、分析 | 保留，并将吸收部分 Work 能力 | | ChatGPT Work | 长时间、多步骤任务执行 | 调用文件与插件、生成网站和演示文稿、操作网页 | 正在与 Chat 合并测试 | | Codex | 软件开发智能体 | 处理代码库、本地文件、终端与开发工具 | 继续作为独立体验保留 |

迁移本身不复杂，产品变化才是重点

普通用户完成迁移只需要下载新版应用，并使用原来的 ChatGPT 账号登录。

OpenAI 表示，用户的完整聊天记录会跟随账号进入新版应用，因此这次切换并不是传统软件升级中常见的“导出文件—重新导入”流程。聊天历史主要保存在账号体系中，而不是绑定在某一份本地应用安装包里。(ithome.com)

Codex 用户的迁移路径略有不同，因为原来的 Codex 桌面应用会直接更新为新版 ChatGPT。更新后，现有 Codex 任务和项目应当继续保留，用户也可以把 Codex 设置为应用启动后的默认视图，并继续使用 Codex 图标。

真正需要注意的是，Codex 的历史记录不会与普通 ChatGPT 对话彻底混在一起。新版应用虽然共用一个外壳，但 Codex 仍是独立视图，其项目结构、任务流程和历史记录继续按照开发工作流组织。

这种设计是合理的，因为编程智能体与聊天机器人的上下文结构并不相同。普通聊天通常围绕一条对话线程展开，而 Codex 任务还需要关联代码仓库、文件修改、终端命令、差异对比和项目状态；强行塞进普通聊天列表，只会让信息架构更加混乱。

Classic退役是一次产品收口

ChatGPT Classic 停服的直接原因，是它已经无法承载 OpenAI 正在推进的智能体功能。

Classic 代表的是第一阶段 ChatGPT：用户提出问题，模型在聊天框里返回答案。新版桌面应用代表的则是第二阶段 ChatGPT：用户描述目标，模型读取文件、调用工具、操作网页，并持续工作直到交付结果。

两者的差别类似于“搜索框”和“操作系统”。搜索框只需要接收输入并展示答案，而智能体平台还要管理任务状态、工具权限、本地文件、后台执行、项目上下文和人工审核。继续维护两个底层逻辑不同的桌面客户端，对 OpenAI 没有太大意义。

Classic 在过渡期内仍能获得模型更新、安全补丁和错误修复，但一些新的智能体功能已经只在新版应用提供。换句话说，Classic 此前虽然没有立即停服，实际上早已进入功能冻结式维护阶段。

OpenAI 选择提前约三个月公布截止日期，也说明此次迁移涉及的不只是个人用户。企业和学校可能需要重新部署安装包、调整终端管理策略、核对本地文件权限，并验证新版应用是否符合组织现有的安全与治理要求。

新版ChatGPT仍然不够简洁

新版 ChatGPT 桌面端的方向是正确的，但第一版交互并不成熟。

新版应用同时加入 Chat、Work 和 Codex 后，用户必须先理解三者的边界，才能决定一项任务应该从哪里开始。对于熟悉 AI 编程工具的开发者，这套划分尚可理解；对于只想继续打开 ChatGPT 对话的用户，它反而增加了选择成本。

Chat 是快速响应的对话模式，Work 是能够长时间执行复杂任务的智能体，Codex 则专注软件开发。这种产品划分在 OpenAI 内部可能对应不同的模型调度、工具权限和计费方式，但用户通常并不关心后台究竟由哪套系统完成任务。

用户真正关心的是一句更简单的问题：我提出目标后，ChatGPT 能不能自动选择合适的工作方式？

OpenAI 接下来准备合并 Chat 与 Work，实际上是在承认当前的信息架构过度暴露了内部实现。未来数周，小部分用户将率先获得合并后的界面，在同一条交互链路中完成从讨论想法到执行任务的全过程。(ithome.com)

例如，用户可以先让 ChatGPT 讨论一个产品落地页的结构，再导入品牌文件和数据，让它直接制作网站；也可以先分析一份销售报告，再要求它生成演示文稿并在网页系统中录入结果。用户不必在开始任务前判断应该选择 Chat 还是 Work，而是由系统根据任务复杂度决定是否进入智能体执行流程。

Chat与Work合并，比Classic停服更重要

Chat 与 Work 合并意味着 OpenAI 正在淡化“聊天模式”和“智能体模式”的人为边界。

早期 AI 智能体产品通常会单独提供一个入口，因为智能体运行成本更高、执行时间更长，也更容易产生不可逆操作。用户需要主动进入 Agent、Deep Research 或 Work 等模式，相当于明确告诉系统：“这次不只是回答问题，而是替我完成任务。”

这种模式选择机制便于控制成本和风险，却破坏了连续体验。用户可能先在普通聊天里讨论半小时，直到需要调用工具时才发现应该切换到 Work；切换后又要重新解释目标、上传文件或整理上下文。

合并后的 ChatGPT 更接近一套动态执行系统。简单问题可以即时回答，复杂任务则在同一对话中升级为多步骤工作流，用户负责审核关键节点，而不是负责挑选产品入口。

这也是 OpenAI 与 Anthropic、Google 等厂商竞争的核心战场：模型能力仍然重要，但决定高频使用率的因素，正在从单次回答质量转向任务能否连续完成。谁能减少模式切换、上下文搬运和人工复制粘贴，谁就更可能成为真正的工作入口。

Codex为什么没有一起合并

Codex 继续保持独立，是因为软件开发仍然需要一套高度专业化的操作界面。

编程任务不仅要生成文字，还要读取代码仓库、修改多个文件、运行测试、检查终端输出、审阅差异，并在失败后回滚或重新执行。普通 ChatGPT 对话界面很难同时容纳这些信息。

Codex 也需要更明确的权限边界。让模型解释一段代码，与允许模型修改本地仓库、执行命令或访问开发工具，是完全不同的安全等级。独立视图可以让文件范围、网络访问和命令执行状态更加可见。

因此，新版应用虽然把 Codex 放进 ChatGPT 的统一外壳，OpenAI 却没有把它降级成一个普通标签页。对开发者来说，这比形式上的“全部合并”更务实：账号、客户端和部分配额可以统一，但开发工作区必须保持专业性。

共享额度可能比客户端迁移更敏感

共享额度是 ChatGPT 与 Codex 共同消耗同一使用配额的机制。

OpenAI 计划用共享配额取代 ChatGPT 和 Codex 目前相对独立的使用限制。实际消耗将根据模型和任务复杂度计算，高级模型、长时间运行和多步骤任务会占用更多额度；套餐中标记为“无限即时”的使用，则不会消耗这部分共享配额。(ithome.com)

| 额度机制 | 当前模式 | 计划中的模式 | |---|---|---| | ChatGPT 使用限制 | 与 Codex 相对独立计算 | 与 Codex 共用一个额度池 | | Codex 使用限制 | 单独显示和重置 | 与 ChatGPT 任务共同消耗 | | 复杂任务成本 | 主要在对应产品内体现 | 按模型与任务复杂度动态扣减 | | 无限即时使用 | 按套餐规则提供 | 不占用共享额度 |

共享额度的优点是资源更灵活。只使用 ChatGPT、不使用 Codex 的用户，不必看着一部分开发额度闲置；开发者也可能在某段时间把更多资源集中用于 Codex，而不是被两个独立上限卡住。

共享额度的风险是可预测性下降。一次大型代码重构或长时间 Work 任务可能消耗较多配额，随后影响用户进行其他高阶任务；如果 OpenAI 不提供清晰的消耗明细，用户很难判断究竟是哪一个任务用掉了额度。

OpenAI 目前只表示，多数用户等待额度重置的频率不会高于现在，但尚未公布不同套餐的统一额度数值、复杂任务的具体权重，以及 ChatGPT 与 Codex 分别消耗多少资源。对于开发者和团队用户，这些数字比“共享”这个概念本身更重要。

一个真正可用的共享额度系统至少应该显示三项信息：每个任务的实际消耗、下一次重置时间，以及不同模型或执行模式的预估成本。如果缺少这些数据，共享额度很容易变成用户无法审计的黑箱。

企业用户不要等到最后一周

企业用户应该在 2027 年 1 月前完成新版应用的兼容性验证。

第一项检查是账号与历史记录。管理员需要确认员工使用的是受组织管理的工作账号，而不是分散的个人账号，否则即使聊天历史能够随账号保留，也可能进入错误的工作空间。

第二项检查是本地权限。新版 ChatGPT 和 Codex 可以接触本地文件、代码仓库、终端与其他工具，企业应重新评估允许访问的目录、网络范围和插件，并避免直接沿用传统聊天客户端的低风险假设。

第三项检查是关键工作流。依赖快捷键、桌面悬浮窗口、读取屏幕内容或特定系统集成功能的用户，应逐项验证新版是否提供等价能力，而不是看到“聊天历史会迁移”就认定所有功能都会迁移。

第四项检查是额度管理。频繁使用 Codex 和 Work 的团队需要观察共享额度上线后的消耗情况，尤其是长任务、并行任务和高级模型是否会迅速占满公共额度池。

个人用户可以这样迁移

个人用户现在迁移，比等到 2027 年 1 月 30 日当天更稳妥。

1. 在 ChatGPT Classic 中确认当前登录账号和工作空间。
2. 通过应用内横幅进入新版 ChatGPT 下载页面。
3. 安装新版应用，并使用完全相同的账号登录。
4. 检查最近对话、置顶内容和 Projects 是否正常出现。
5. 如果使用 Codex，单独检查 Codex 视图中的任务和项目。
6. 测试常用快捷键、文件上传、本地工具和插件。
7. 在确认核心工作流无误后，再卸载 ChatGPT Classic。

同时保留两款应用一段时间是更稳妥的做法。OpenAI 当前允许新旧客户端并行安装，用户可以先用新版处理日常工作，再把 Classic 作为短期对照，直到确认聊天、项目和本地功能都能正常使用。

这次退役说明ChatGPT正在变成什么

ChatGPT Classic 的退役标志着 ChatGPT 正从“模型聊天客户端”转向“通用智能体工作台”。

过去，OpenAI 的产品结构主要围绕模型组织：不同模型提供不同速度、推理能力和价格。现在，产品结构开始围绕任务组织：Chat 处理即时交流，Work 负责长流程交付，Codex 负责专业开发，而桌面应用负责连接本地环境。

这次调整的方向没有问题，因为用户不应该为了完成同一件事，在聊天窗口、智能体页面和编程工具之间反复搬运上下文。但 OpenAI 仍需解决两个现实问题：新版客户端的交互复杂度，以及共享额度的透明度。

如果 Chat 与 Work 的合并足够自然，新版 ChatGPT 会比 Classic 更有价值。用户可以从一个问题开始，在同一上下文中让系统继续查资料、处理文件、生成交付物并执行操作，ChatGPT 才真正从回答工具变成工作平台。

如果共享额度缺少清晰规则，新版应用也可能让用户产生新的成本焦虑。尤其对同时使用 Codex 和 ChatGPT 的开发者而言，统一入口固然方便，但统一额度意味着一次重型任务可能影响整套产品的可用性。

ChatGPT Classic 值得怀念的地方是简单、轻量和目标明确，但它所代表的纯聊天时代确实正在过去。OpenAI 现在需要证明的，不是能否把三个产品塞进一个窗口，而是能否让复杂能力在用户几乎察觉不到的情况下自然发生。

参考来源

• IT之家：ChatGPT Classic 官宣“退役”，2027 年 1 月底正式停服 —— 整理停服日期、聊天记录迁移、Chat 与 Work 合并测试及共享额度等信息。