ChatGPT Work 最强的不是回答问题，而是把浏览器、代码和文件放进同一任务
ChatGPT 正在出现一种不容易用“聊天机器人”概括的工作方式：同一个任务可以读网页、操作浏览器、运行代码、处理文件，并在较长时间内保留目标和进度。Simon Willison 在实际使用后，把这套能力分成了 Work Cloud 与 Work Local 两类；前者更像运行在云端的持续任务，后者则直接靠近本机代码、
作者：林岚｜OC 开发者生态编辑
ChatGPT 正在出现一种不容易用“聊天机器人”概括的工作方式：同一个任务可以读网页、操作浏览器、运行代码、处理文件，并在较长时间内保留目标和进度。Simon Willison 在实际使用后，把这套能力分成了 Work Cloud 与 Work Local 两类；前者更像运行在云端的持续任务，后者则直接靠近本机代码、终端和已登录浏览器。
一句话结论：它真正改变的不是回答质量，而是把原本分散在聊天窗口、浏览器、终端和文件系统里的动作编排成一条可继续的工作链；但“云端能做什么、本地能做什么、哪些能力依赖客户端”目前仍缺少一张足够清晰的官方矩阵。
Simon 的测试揭示了一个关键区别。普通对话的基本单位是一轮问答，用户要不断复制资料、粘贴结果并发出下一条指令；Work 的基本单位更接近“任务”。任务可以先收集材料，再生成文件，随后根据检查结果继续修改。失败也不必从头来过，因为目标、产物和过程状态仍在同一上下文中。
这种变化对开发工作尤其明显。本地模式能够直接看到项目文件、调用命令行工具，并利用浏览器里已有的登录状态完成无法靠公开 API 解决的步骤。云端模式则更适合让耗时工作脱离当前电脑继续运行。两者并不是简单的“联网版”和“离线版”：本地模式拥有更强的环境访问能力，也意味着更大的权限风险；云端模式隔离更清楚，却可能缺少本机凭据、私有网络和临时状态。
这里最容易被忽略的是权限边界。一个能读代码、运行命令、操作已登录网页的 Agent，拿到的并非抽象智能，而是用户真实工作的执行权。它可能接触源代码、Cookie、下载文件和内部系统。团队需要像管理 CI、自动化机器人和开发机权限那样管理它：任务按需授权，敏感动作保留确认，产物可追踪，凭据不要无差别暴露。
OpenAI 官方的 ChatGPT 学习页面已经把持久目标、网站、代码和连接器等工作方式放在同一产品叙事里，但截至目前，公开资料更像用例集合，而不是严格的 Work Cloud / Work Local 能力表。因此，Simon 对命名、额度和能力差异的描述应理解为实测观察，不应替代正式的产品承诺。尤其涉及价格、使用额度和可用平台时，用户仍应以自己账户中的界面和官方说明为准。
对工具开发者，这个方向也提出了新的产品问题。过去大家争夺的是“谁能给出更好的答案”，现在争夺的是谁能持续持有任务状态、把不同工具串起来，并在权限足够强时仍保持可审计。模型能力只是其中一层；浏览器控制、文件接口、失败恢复和授权设计，正在成为同样重要的产品基础设施。
关键事实
- Simon Willison 依据实际使用，把 ChatGPT 的工作能力概括为云端持续任务与本地环境任务两类。
- 本地任务可结合代码、终端、文件和已有浏览器会话，能力更强，权限面也更大。
- OpenAI 官方学习资料展示了多种工作流，但尚未提供与第三方概括完全对应的能力矩阵。
OC 判断
ChatGPT Work 的竞争对象不只是另一个聊天窗口，也包括脚本、RPA、IDE Agent 和轻量工作流平台。决定它能否进入日常生产的，不会只是模型跑分，而是任务能不能中断后继续、权限能不能解释、结果能不能复核。越接近真实执行，产品越需要把“它做过什么”说清楚。
为什么重要
- 对个人：长任务可以少做复制粘贴，但需要重新审视浏览器与本地文件授权。
- 对团队：应为 Agent 建立权限、日志和结果验收规则，而不是把它当成更聪明的输入框。
- 对行业：AI 产品的核心界面正在从对话框转向可持续、可执行的任务空间。
评论
围绕这篇文章补充信息、提出问题或分享观察。