ChatGPT 开始测试把 Chat 与 Work 入口合并，并让 ChatGPT 与 Codex 共用同一份额度。这让重度聊天用户和重度 Codex 用户都开始担心额度被对方吃掉。文章梳理这次调整的实际变化、各方分歧的焦点，并给出可操作的额度管理、任务分层与备用方案建议。
OpenAI 向部分用户发出通知，将在接下来一段时间内小范围测试把 ChatGPT 里的 Chat 与 Work 两个入口合并，同时让 ChatGPT 和 Codex 的使用量从同一份额度中扣除。Codex 在桌面端仍然是独立体验，但额度不再是两套账。通知里还提到：Instant 模型不限量、不占额度；合并后的剩余用量和重置时间可以在设置里的 Usage 页面查看；额度用完后可以等重置、升级套餐或购买 credits 继续使用符合条件的功能。
消息一出，反应明显分成两派。一类用户觉得早该如此，来回切换入口太麻烦，聊天额度常年用不完，正好补贴写代码；另一类用户则担心自己主要用聊天、语音或深度研究，合并后会被代码任务挤占。争议的核心其实不是“合不合并”，而是合并之后那口池子到底有没有变大。
这次调整到底改了什么
把通知拆开看，变化和不变的部分可以列清楚：
| 项目 | 调整前 | 调整后 |
|---|---|---|
| Chat 与 Work 入口 | 分开的两个标签页 | 小范围测试合并为一个连贯体验 |
| ChatGPT 与 Codex 额度 | 各自独立计算 | 共用同一份额度 |
| Codex 桌面端 | 独立体验 | 仍然是独立体验 |
| Instant 模型 | 不限量 | 仍然不限量，不占额度 |
| 用量查看 | 分别查看 | 设置 → Usage 查看合并剩余用量与重置时间 |
| 额度耗尽 | 等待重置或升级 | 等待重置、升级或购买 credits |
需要特别注意的是，通知说的是“in the coming weeks”，也就是分批推进，不同账号看到的状态可能不一致。具体哪些档位、哪些地区、什么时间生效，应以账号内实际显示和官方最新说明为准。
两派观点各自的道理
支持合并：入口统一，闲置额度可以补贴代码
支持者的理由很实际。产品线此前确实偏碎：Chat、Work、Codex 各有一套入口和额度，普通用户很难分清什么时候该用哪个。合并后在同一处从“聊想法”过渡到“让它动手做”，减少了复制粘贴和来回切换的成本。
对以 Codex 为主的人来说，聊天额度原本经常闲置，合并后理论上可以把这部分闲置算力用起来，整体可用量未必比过去少。有用户就提到，以前为了省 Codex 额度，会先在聊天里把问题聊清楚，再回到 Codex 干活，合并后这一步可以省掉。
担心的一方：聊天不再是“免费区”
另一边的担忧同样成立。聊天并不等于低消耗：长对话、大附件、PDF 与数据文件、联网搜索、深度研究、高推理强度，都会实打实消耗算力。语音、图片、视频类交互背后还有索引和预处理成本。过去这些消耗走的是另一套额度，现在统统从同一口池子里出。
对以聊天为主的用户，尤其是把语音模式当日常工具的人，这意味着原本“用不完”的余量可能被代码任务吃掉。而对中低档订阅的用户来说，如果合并后总量没有相应增加，实际感受就接近额度被削。
真正的分歧点：池子有没有变大
两派其实不矛盾。合并本身只是记账方式的变化，用户真正在意的是合并后的总容量与原来两套额度之和相比是什么关系。
- 如果总量大于或等于原来两者之和，多数人会是受益者；
- 如果总量不变，那么对单侧重度用户就是零和博弈，谁用得多谁吃亏；
- 如果总量还减少了，那无论怎么解释都会被当成变相降配。
通知里“大多数用户不需要比以前更频繁地等待重置”的表述，是一种偏乐观的预期，但并没有给出量化口径。所以在官方给出更明确的说明之前，把它当成“可能不变、也可能略变”的不确定项更稳妥。
不同用法受到的影响不一样
| 使用画像 | 主要影响 | 建议关注点 |
|---|---|---|
| 轻度聊天 + 重度 Codex | 大概率受益，闲置额度被利用 | 合并后总量是否覆盖原有代码用量 |
| 重度聊天 + 轻度 Codex | 风险较高，聊天余量被共享 | 长对话、附件、深度研究的消耗速度 |
| 语音 / 深度研究重度用户 | 单次任务消耗高，感知明显 | 是否有不计入额度的轻量模型可用 |
| 纯聊天用户 | 可能被迫为不需要的能力买单 | 套餐性价比是否仍然成立 |
| 多供应商并行用户 | 影响有限，可随时切换 | 各平台额度与成本的对比 |
可操作的应对方案
1. 先量出自己的用量基线
不要凭感觉判断。花一周时间记录：
- 每天大概发起多少次对话、多少次代码任务；
- 哪些操作集中在附件、联网搜索、深度研究、高推理强度上；
- 额度大概在周期的第几天见底，重置时间是什么时候。
有了这条基线，合并后第一周就能判断自己是变好还是变差，而不是被情绪带着走。
2. 按任务类型分层
- 轻量问答、改写、翻译：优先用不限量的 Instant，不占额度；
- 需要推理的复杂问题：集中起来一次问清，避免用多轮短对话反复试探；
- 代码任务：交给 Codex，把需求、上下文、验收标准一次写全；
- 深度研究、大附件分析：当成“高消耗任务”，排在额度刚重置、周期初做。
核心思路是把额度当预算：重活前置，轻活下沉，别让高消耗模型去干本该 Instant 干的活。
3. 减少单次任务的浪费
- 上传文件前先裁剪，避免每次都带一份完整大文档；
- 长对话及时开新会话，减少无效上下文反复计费；
- 任务拆成可验证的小步，失败时只重跑出错的那一步；
- 提示词里写清输出格式，减少来回返工；
- 观察后台是否还有自动化的 agent 步骤在消耗额度，别只盯着自己发的那几句话。
4. 长任务要保证会话不中断
额度被浪费的常见原因不是模型太贵，而是任务跑到一半断了：本地机器休眠、合盖、网络抖动、浏览器标签被回收，都会让已经消耗的算力白费，重跑又要再扣一次。如果经常跑长耗时的代码任务，可以考虑把执行环境放到一台长期在线的机器上，例如整机放在新加坡机房的独享远程 Mac，按月租用、远程连接，网络环境相对稳定，适合长时间挂着运行 Claude Code 这类工具。这只是减少中断的一种可选做法，本地机器状态良好、任务不长时没必要折腾。
5. 准备备选路径
- 保留一个第二供应商的订阅，作为额度见底时的临时替代；
- 对用量波动大的场景，评估按量计费的 API 是否比订阅更划算；
- 团队或高频使用场景，关注官方是否有更高档位或企业方案；
- 把非紧急的批量任务挪到额度重置后的窗口期执行。
几个容易踩的坑
不要买共享账号或代充。 额度收紧时，这类交易会变多。风险包括账号被回收或封禁、聊天记录与代码泄露、付款纠纷，且违反平台条款。合规范的做法是调整用法、升档或改用 API。
不要相信“无限”的宣传。 不限量通常只针对特定模型或特定模式，重推理、附件、深度研究这类能力依然计入额度。看清哪些操作不占用量，比记住“无限”两个字有用。
不要把入口合并理解成功能合并。 Codex 在桌面端仍是独立体验，合并的主要是额度与入口，不是把代码能力塞进聊天窗口。
关注生效节奏。 分批测试意味着你的账号可能先变、也可能后变，别拿别人的截图推断自己的状态，以设置页显示为准。
小结
这次调整的本质是把两套独立的用量账本并成一套。对以 Codex 为主、聊天额度长期闲置的用户，大概率是好事；对重度聊天、语音和深度研究用户，则需要更精细地管理消耗。短期内最值得做的三件事：记录一周用量基线、把轻重任务分层、给长任务准备一个不掉线的执行环境。至于合并后总量究竟如何变化，官方口径还在推进中，建议以账号内的 Usage 页面和最新公告为准，再决定是否调整套餐。