我原来有一条很顺手的工作路径。
ChatGPT 用来探索。一个想法还没长出边界时，我在里面问、试、删掉一半，再把剩下的东西收紧。
Codex 用来进入本地项目。它读仓库、跑命令、改文件、看日志。任务开始碰到代码和真实工作区，我会自然地切过去。
最近我用 Work 做完了一次完整的云端任务：调研、判断和一份 PPT。交付物没有问题。
卡住我的，是新的桌面入口。
同一个任务开始前，我得先回答一个额外问题：它应该进 Chat、Work，还是 Codex？
三个入口，各自有合理的职责
OpenAI 给出的分工很清楚。Chat 处理快速问题、搜索和讨论；Work 负责调研、分析与交付文档、表格、演示文稿、报告和站点；Codex 面向代码、测试、命令和仓库。
这个拆分单看没有问题。问题会出现在一个任务不按产品边界生长的时候。
我想研究一个主题，先在 Chat 里找问题。判断变得具体后，我想在 Work 里整理资料、产出一份可分享的文档。文档一旦需要站点、数据或脚本，我又要回到 Codex。
任务没有变。人被迫先替任务选队列。
连续性被拆成了用户的手工活
官方说明也写得很直接：Work 的云端对话可以跨网页、手机和桌面同步；Codex 仍是独立视图，它的历史与 ChatGPT 历史分开。本地聊天则留在电脑上。
这些边界对产品实现、权限控制和使用场景都有理由。用户面对的结果是另一回事。
每一次跨入口，我都要重新交代：我在做什么，前面查过什么，哪些判断已经做过，哪些文件可以碰，最后要交付给谁。模型会努力补全，项目也能继续推进。可这个动作本身已经被拆碎了。
系统在管理不同种类的工作。用户在维护同一个任务的生命线。
入口越来越多，路由成本也越来越高
过去，选择工具大多是选择能力：写字用文档，写代码开编辑器，开会进视频软件。
Agent 工具带来了另一层选择：你还得判断任务的上下文要放在哪里，哪一段历史可以被继承，哪一个环境拥有文件和权限，之后能不能从手机继续。
这会产生一个很隐蔽的成本。任务刚开始时，人会为了避免选错入口而缩小目标。原本可以先展开的工作，变成“先在这里问两句看看”。原本应该直接进入项目的想法，被留在一段孤立对话里。
我希望产品把任务放在入口前面
一个更顺的工作区不需要把 Chat、Work 和 Codex 混成同一种东西。它们当然可以有不同权限、不同环境和不同执行方式。
任务应该成为第一层对象。
我能在一个任务里先聊天，再发起调研，再进入本地仓库。系统明确告诉我：哪些内容能带过去，哪些只留在本地，哪些需要我重新授权。任务历史也应该能显示这些转换，而不是只留下几段彼此看不见的聊天记录。
这样，入口仍然存在，但它不再要求用户在开始工作前替系统完成一次路由。
我不介意 Work、Chat 和 Codex 各自存在。我也不期待所有上下文都能无条件共享。
我在意的是，当一个任务需要跨过它们时，谁负责让它保持完整。