ChatGPT Work 不是新标签，而是一套工作运行时

我看到截图里的 ChatGPT“Work”标签时，直觉是：这大概是给不写代码的人准备的 Codex。读完 Simon Willison 的《Understanding ChatGPT Work》后，我觉得这个判断只对了一半。

它确实在把一部分开发者能力换成更日常的入口，但真正值得警惕、也更值得期待的变化是：聊天窗口开始拥有运行时的形状。它不只回答问题，还能继续运行、访问网页、保留文件、部署结果，甚至把任务交给别的 Agent。

这时，我们面对的就不再是“哪个模型更会聊天”，而是一个更具体的问题：一个会持续行动的工作环境，究竟应该把哪些边界告诉用户？

一个标签，藏着两种系统

Willison 先做了一件很重要的拆分：Work 不是一个完全统一的产品。云端 Work 可以在网页或移动端继续运行；桌面端的 Work Local 则能接触本机文件和程序，更像把 Codex 换了一层面向普通工作的外壳。原文主要讨论前者。

这一区分看似只是部署位置不同，实际却决定了“工作”两个字意味着什么。云端任务可以在你关掉电脑之后继续，适合长时间研究、定时检查和等待外部结果；本地任务则更靠近你的文件、应用和开发环境。同一个标签下面，至少有两套不同的信任边界。

OpenAI 的官方文档把 Work 解释成“把真实工作委托给 ChatGPT”，并强调文件、插件、已批准工具和可审阅的最终结果。这个说法抓住了产品方向，却还没有替用户回答：它具体在哪里运行？哪些东西会留下来？哪些动作会越过当前会话？

原文这张截图很有意思。界面上只是一个轻巧的 Chat / Work 切换，但切换之后，变化的并不是对话气泡的颜色，而是任务可以连接到多少外部状态。入口极简，后面的权限图却一点也不简单。

真正增加的，是一条能跑起来的回路

如果只看产品名称，很容易把 Work 理解成“更强的 Chat”。但把原文列出的能力放在一起看，会得到另一幅图：模型先生成计划，再运行代码、访问互联网、控制浏览器、读写文件，最后交付一个报告、站点或持续更新的结果。

这里最关键的不是某个单点功能。联网代码执行本身像一个工具，无头 Chrome 也像一个工具；持久文件、Sites、子 Agent 和定时任务分别看也没有那么惊人。真正改变产品性质的是：这些执行原语可以在同一个任务里互相传递结果。

比如，Agent 可以先从网页收集资料，再用代码整理数据，随后生成一个网站，把网站部署出去，之后还可以让定时任务继续更新它。输出物不再是对话结束时的一段文字，而是一个会被访问、被修改、被再次调用的外部对象。

原文里最能说明这件事的，是让 Work 打开一个网站并返回截图。自然语言请求只是起点，真正发生的是浏览器启动、页面加载、动作执行和结果回传。官方浏览器文档也明确把 Work 的浏览器描述为可以读取网页并采取行动的独立云端设备。

Sites 的截图则把这条回路推到了交付端：Work 不是只告诉你“可以做一个网站”，而是把页面真的做出来、部署出去，让它成为下一轮工作的输入。当交付物开始拥有地址、状态和后续维护需求，聊天就已经越过了聊天产品的边缘。

我在《Codex 突破千万周活的背后：当代码变成隐形燃料，AI 的终局是消解“程序员”里写过，代码正在从岗位专属工具退到工作接口的背后。现在看 Work，我更愿意把这句话再推进一步：代码只是运行时的燃料，真正需要重新理解的是整条工作回路。

产品文档应该先回答五个问题

官方文档倾向于从任务类型解释 Work：适合做简报、演示文稿、分析、工作流和可审阅文件。这对第一次上手的人很友好，但对一个拥有外部行动能力的系统来说，还不够。

用户在把任务交出去之前，至少应该能得到五个答案：

它运行在哪里？ 是云端环境，还是我的电脑？任务会不会在我离线后继续？
它能读写什么？ 当前会话的文件、跨会话的持久目录、插件连接的数据，边界分别是什么？
它能访问哪些信任域？ 浏览器打开的网页、登录后的账户和外部 API，是否被分开管理？
状态会留下多久？ 文件、登录态、定时任务和部署结果由谁保存，怎样撤销？
哪个动作必须停下来？ 发送信息、付款、改权限、部署公开站点或把数据带出当前环境时，谁拥有最终决定权？

这五个问题比“Work 适合什么工作”更接近用户真正需要的心智模型。Willison 之所以后来让 Work 自己生成工具和 Skills 参考站，正是因为光看产品文档里的用途描述，很难知道系统实际拥有的动作集合。

这不是要求公司把所有内部实现细节都公开，而是要求它把用户会承担后果的边界说清楚。模型名可以变，界面也可以变，但运行位置、持久性、外部副作用和停止条件必须是可理解的产品信息。

安全问题来自组合，不来自某个按钮

Willison 用“lethal trifecta”提醒读者：当 Agent 同时接触私有数据、未受信任内容，又拥有把信息传出去的通道时，提示注入就不再只是“网页里藏了一句恶意指令”。它可能变成一条完整的行动链：读取、理解、拼接、发送。

按原文描述，Work 恰好把这三个方向放进了同一个工作环境：持久文件让数据可以跨会话存在，浏览器让外部页面进入上下文，联网工具和部署能力又提供了向外行动的路径。风险不是某一个按钮危险，而是能力之间能否闭环。

OpenAI 的浏览器文档已经给出了两个有价值的缓冲层：网页内容应被当作不受信任上下文，登录、提交、付款、改权限和删除数据等后果性动作需要确认。但我不认为“会弹确认框”就等于边界设计完成了。确认解决的是某一次动作是否继续，权限分级解决的则是它根本能不能看到、能不能写、能不能带走。

Auto-review 文档把这个区别说得更清楚：另一个审查 Agent 可以替代人工处理某些边界请求，但它不是权限授予，不会自动扩大沙盒、网络或可写目录。这个原则也应该成为 Work 类产品的底层常识：审查谁，不等于允许什么。

这里也要保留不确定性。原文并没有拿到 Work 完整的系统提示词和工具描述，关于它如何防御 prompt injection 仍然是开放问题。我们可以根据公开文档建立风险模型，却不能把某一套 Codex 的安全说明直接当作 Work 的全部实现。

把 Work 当运行时，用户就知道怎么交接

读完这篇文章后，我对“把任务交给 Agent”有了一个更具体的分级。在这个仓库的双线发布管线里，文章、图片、CDN、博客和微信草稿并不是一串无差别的自动化步骤：它们在不同节点接触不同的外部系统，因此我会把状态、Gate 和失败出口分开记录。

这套经验可以迁移到 Work 类产品上：

只读任务：搜索、整理、比较公开资料，可以自动执行，但要保留来源。
可逆任务：生成草稿、临时文件、内部报告，允许 Agent 连续工作，但结果先进入可审阅区。
需确认任务：发送邮件、修改共享文档、登录后提交表单、部署公开站点，在动作前冻结并交给人确认。
需承担责任的任务：付款、改权限、删除数据、公开敏感信息或代表组织作最终承诺，不应只靠一个“继续”按钮完成。

这不是把人重新安排成每一步都点击批准的监工。好的运行时应该让大多数低风险工作顺畅通过，把真正改变信任域、持久状态或外部世界的动作单独标出来，并把证据、影响范围和回滚方式一起交给决策者。

所以，ChatGPT Work 给我的最大启发不是“以后不用写代码了”，也不是“又多了一个模型入口”。它提醒我：当聊天开始拥有文件、网络、浏览器和时间，用户需要的就不再只是更自然的对话，而是一张足够诚实的能力地图。

你愿意把哪一类工作交给一个可以持续运行、访问网页并保留文件的 Agent？你会在哪个节点要求它停下来？