ChatGPT Work 之后，再谈零 Token 设计
两个月前，我写了一篇《零 Token 设计》。
那篇文章的核心判断是：一个 AI 产品，不一定要在自己的 runtime 里烧 token。用户点一下就调一次模型、烧一次 token 的老逻辑，在用户已经有了自己的 agent workspace 之后，其实可以换一种做法。
更好的方式是，让用户在自己的 agent workspace 里完成推理，把结构化的结果写回产品。产品负责 schema、数据库、版本、展示和分发。说白了就是，让 agent 去干活，让产品把结果接住。
但那篇文章其实藏着一个我当时没说破的前提。
这套设计原来只属于少数人
不是每个人都有 agent workspace。
一个开发者可能已经装了 Codex、Claude Code 或者 OpenCode。他知道怎么开终端，知道 npx 是什么，也知道该把一段 quick start prompt 粘到哪里。
但对绝大多数普通用户来说，这件事太远了。他不会为了用一个小产品，先去装一个 coding agent，也不会在自己电脑上配一套新的工作环境。
所以零 Token 设计当时在架构上是成立的，但它其实只属于开发者。它是一个开发者的设计。
ChatGPT Work 本身就是那个 agent workspace
ChatGPT Work 出来之后，我意识到这个前提被填上了。
ChatGPT Work 已经不是原来那个聊天框。它可以读文件、连外部服务、跑多步骤的工作流，并且能持续工作更长时间。它本身就是一个 agent workspace。
更关键的是，它跑在云端，而且进了手机。过去只有开发者的电脑里才有 agent workspace，现在它出现在每一个人的手机里。
所以你不需要让手机自己去执行一条 npx 命令。真正的执行环境已经在 ChatGPT 背后的云端工作台里。
而 npx 的角色，其实彻底反了过来。以前，npx 是用户启动某项产品能力的入口；以后，npx 只是开发者把能力打包进去的一种方式，用户甚至不需要知道它存在。他只需要说一句话。
于是零 Token 设计，从一个面向开发者的架构，第一次变成了一个面向所有人的架构。
Raily 那个截图导入功能，不用做了
我之前做过一个高铁行程 App，叫 Raily。
当时有人给过我一个很合理的建议：为什么不加一个截图导入功能？用户在 12306 买完票，把订单截图传进 Raily，Raily 自动识别日期、车次、出发到达站、时间和座位，生成一条行程。
按以前的产品逻辑，这功能当然该做。我得在 Raily 里做图片上传、申请相册权限、接 OCR、解析字段、处理识别错误、加一个二次确认页，最后再把数据写进服务器。
但现在再看，这个功能根本不需要存在于 Raily 里。
用户买完票，直接把截图发给 ChatGPT：把这趟高铁加进我的 Raily。
ChatGPT 看懂截图。Raily Skill 把车次、时间、车站和座位转成 Raily 需要的数据结构，再调用 Raily 的接口写进服务器。Raily Skill 和 Raily App 共用同一套账户、同一个数据库、同一台服务器。
用户下一次打开 Raily，这趟行程已经在时间线上了。他没有打开 Raily，没有找导入按钮，没有重新上传一次截图，也没有去学 Raily 支持什么格式。
但 Raily 不会消失
这不代表 Raily 会被 ChatGPT 取代。
因为对话框不一定是查看铁路行程的最佳界面。用户还是需要一条清晰的时间线、不同城市之间的换乘、出发和到达提醒、车站信息、历史行程，甚至一张铁路旅行地图。这些体验，一个专门的垂直 App 可能比对话框做得更好。
真正变化的是，Raily 不再需要同时承担所有事情。ChatGPT 负责理解用户想干什么、负责把真实世界的输入接进来；Raily 负责把铁路行程展示到最好。
它们不是两个互相竞争的产品，而是同一个系统的两个界面。一个负责输入，一个负责展示，背后共用同一份数据。
这个逻辑不只适用于高铁 App。一个消费分析产品也一样：用户不用再下载 App、注册、拍小票、等 OCR、改错误、选类别，才能进到报表页。他可以直接在 ChatGPT 里拍一张小票说帮我记一笔，再打开网站看完整的月度图表，两边读的是同一份数据。
ChatGPT Work 会成为所有小产品的入口
所以这次真正的变化，不是截图导入变得更方便了。
而是 ChatGPT Work 可能成为以后所有小产品的入口。
过去，每一个产品都要自己建一套入口：注册、登录、上传、搜索、表单、帮助中心，再加一个新的 AI 聊天框，和一套自己的推理服务。每一个创业者，都在重复造这些几乎一样的东西。
但用户真正需要的，往往不是这些入口，而是产品背后的那点能力：一段行业规则、一套数据结构、一个稳定的执行流程，以及长期沉淀下来的状态。
ChatGPT Work 的意义，就是把这层通用的壳，从每一个产品里抽走。
于是未来的小产品，可能只需要四样东西：一套清晰的数据结构，一台可靠的服务器，一个能被 agent 调用的 Skill 或 Plugin，以及一个真正值得独立存在的展示界面。第一批用户，甚至可以完全通过 ChatGPT 来用你的产品。
先设计接口，再设计页面
到这一步，产品的结构会变。
以前是：用户打开 App，App 理解用户，App 调用 AI，App 写数据，App 展示结果。以后可能是：用户打开 ChatGPT Work，ChatGPT 理解用户，Skill 调用产品能力，产品服务器保存状态，App 展示结果。
所以创业者第一件要问的事，可能不再是我要做几个页面，而是：我的产品能不能被 agent 调用？能不能稳定地接收结构化结果？身份和权限能不能在 ChatGPT 和产品之间打通？Skill 和 App 能不能读写同一份数据？用户不打开我的产品时，它还能不能产生价值？
这也会改变产品分发的逻辑。过去我们问的是，怎么让用户多打开一次我的产品；以后我们要问的，可能是怎么让 ChatGPT 在正确的时候调用我的产品。
SEO 是让搜索引擎找到你的页面。未来可能会有另一种优化：让 agent 理解你的能力、信任你的接口，并在正确的场景里调用你。
再说回零 Token
这也是我想再写一次零 Token 设计的原因。
第一次写它的时候，我关心的是 token 成本，别让每个产品都重复承担一遍推理。但今天再看，零 Token 设计真正重要的，可能不是省了多少钱，而是它重新定义了一个产品应该在哪里发生。
过去，一个产品必须发生在自己的网站和 App 里。现在，一个产品可以发生在用户的 agent workspace 里。而 ChatGPT Work，把这个 agent workspace 从开发者的终端，搬到了所有人的手机。这一次，用户不需要装 Codex，不需要懂 npx，只需要打开 ChatGPT。
而当一个产品开始发生在 agent workspace 里，用户进入它的地方，也跟着搬了过去。产品在哪里发生，用户就在哪里进入，这两件事第一次重合了。
所以以后，别急着给每个产品再塞一个 chatbot，也别急着为每一种输入重做一个页面。该交给 agent 的就交出去，只把真正需要专业呈现的地方，留给一个好的 App。
以前，我们为每一个产品设计一个入口。以后，所有产品可能共用同一个入口。这个入口，就是 ChatGPT Work。