Work 不只是把 ChatGPT 变成更长一点的聊天窗口。真正决定体验好坏的，是 Projects、Scheduled Tasks、Sites 和桌面端切换有没有一起配好。
- 01先读摘要，判断是否与你的场景相关。
- 02再看来源，保留继续查证的路径。
- 03最后看步骤、风险和可复用动作。
真正会把 ChatGPT Work 用顺手的人，往往不是最早点开 Work 的那批人，而是最早把 Projects、Scheduled Tasks、Sites 和桌面端切换一起配清的人。Work 能做长任务，但长任务一旦缺上下文、缺复查点、缺交付出口，很快就会退化成“看着很忙，结果还是要自己补”。如果你今天准备把 Work 放进日常研究、运营或交付流程，先把入口和回滚线画好，比直接堆更多任务重要。
适用场景
- 你经常要让 ChatGPT 连续处理一个主题，过程里既有资料整理，也有最终交付。
- 你需要把同一批文件、说明和历史聊天反复带进多个任务，而不想每次重新贴上下文。
- 你想让 ChatGPT 定时追踪一组变化，比如产品更新、竞品变动、每周复盘或固定产出。
- 你准备把 Work 的成果直接变成可分享的网址、轻量页面或内部展示稿。
不适用场景
- 你只是偶尔问一个短问题，答案出了就结束，这类任务留在 Chat 更轻。
- 团队还没有确定谁能开 Work、谁能发 Site、谁能批准重要动作，却想先全面铺开。
- 你需要严格的数据驻留、金融交易、支付处理或儿童面向站点，这些都不适合用 Sites 当快捷交付层。
- 你打算把 Work 当成“自动替你做决定”的黑盒，而不是一个需要验收和复查的执行面。
先看这轮更新到底改变了什么
先把时间线记清。OpenAI 在 2026 年 7 月 9 日把 ChatGPT Work 正式带到产品线里，明确说明 Work 可以研究、分析、连接文件和应用，并产出文档、表格、演示、报告以及 Sites。同一天，Sites 进入 public beta，并且 Business 与 Enterprise 用户开始具备对外公开发布能力。到 2026 年 7 月 16 日，桌面端又增加了更明确的 Chat / Work 切换、Projects 入口和跨设备继续 Work 的能力。对操作者来说，变化不是“多了一个按钮”，而是原本分散在聊天、项目、桌面和站点里的能力，被串成了一条更完整的工作流。
第二个关键点是权限边界。Work 在桌面端能碰到本地文件和桌面应用，但前提是你显式授权；Enterprise 工作区里，Work 和公开发布 Sites 也都受 role-based access controls 影响。也就是说，个人用户的“我能不能用”和团队管理员的“谁能在哪用”是两套问题，必须分开设计。
开通前准备
- 先确认账号或工作区是否已经拿到 Work 和 Sites。付费计划之外，Free 和 Go 在当前窗口不可用。
- 整理一个真实项目作为试点：包括说明文档、示例文件、验收标准和一个明确的交付目标。
- 决定试点是在 web、mobile 还是 desktop 进行。若涉及本地文件，直接走桌面端更稳。
- 如果你处在 Enterprise 工作区，先确认管理员是否允许 Work，以及 Sites 是否允许公开发布。
- 准备一个回滚规则：哪些任务仍退回 Chat，哪些交付不能通过 Sites 直接发布。
步骤一：先区分 Chat、Work 和 Codex 的职责
很多人第一次用 Work，会把所有请求都丢进去，结果任务拖得很长，自己也不知道哪里该打断。一个更稳的做法是先按输出类型分工：快速问答、摘要、一次性讨论留在 Chat；需要多轮执行、要看进度、要协调资料的任务给 Work；代码仓、命令和开发环境保持在 Codex。只要角色分工一开始就混了，后面无论 Projects 还是 Scheduled Tasks 都会越配越乱。
- Chat 适合单轮决策、短解释、简单比较和即时参考。
- Work 适合有过程、有产物、有复查点的长任务。
- Codex 适合仓库、终端、测试、diff 和技术实现，不要让 Work 去充当代码工作台。
步骤二：把 Projects 当成上下文仓，而不是标签页
Projects 最值钱的地方不是“把聊天分组”，而是让 Work 能持续吃到同一套文件、说明和历史上下文。试点时，最好每个 Project 只服务一个明确主题，例如“7 月内容周报”“产品上新追踪”“客户站点方案”。别把不相关任务塞进同一个 Project，否则 Work 每次都要在错误上下文里重新判断。
- 先为试点主题创建单独 Project，并上传会被反复引用的文件。
- 把固定说明写成项目级约束，例如交付格式、禁区、命名方式和验收标准。
- 在 Project 里分别创建 Chat 和 Work：Chat 用来快速确认边界，Work 用来真正执行。
- 每次新建 Work 任务时，明确说明它要继承 Project 的哪些资料，避免默认全吃。
步骤三：Scheduled Tasks 只接“可验证”的重复工作
Scheduled Tasks 很容易让人兴奋，因为它看起来像自动化。但对多数团队来说，最容易失控的正是它。不要一上来让它盯一切变化，而是只接三类任务：固定周期整理、固定条件检查、固定格式输出。原因很简单，可验证的重复任务更容易验收，也更容易在出错时回退。
- 适合：每周站点更新汇总、每周 YouTube 数据复盘、固定来源的版本变化监控。
- 不适合：没有明确成功标准的舆情追踪、依赖大量登录态的网站操作、需要高频人工判断的敏感任务。
- 第一次启用时，把周期拉长一点，例如周更先于日更，避免噪音压过价值。
步骤四：Sites 只承担“已经验收过”的公开交付
Sites 是这轮变化里最容易被低估的出口。它让 Work 产出的内容能直接变成可访问的网址，这对报表、内部导航页、活动页原型和简单资源页非常有吸引力。但正因为“能直接发出去”，它更需要上线门槛。一个实用顺序是：先在 Work 里做出私有预览，再确认访问范围、表单行为、链接、图片和是否包含不该公开的资料，最后才切到对外访问。
- 描述要交付的页面类型，同时把内容边界写进去，例如只允许静态说明页，不要开放留言或收集敏感数据。
- 在私有预览里检查文案、链接、表单、交互和图片，不满意先在同一对话里迭代。
- 若要公开发布，重新确认受众范围。Enterprise 默认关闭公开发布，不能假设成员天然有权限。
- 发布后用另一账号或无痕窗口实际打开一次，确认访问体验符合预期。
步骤五：把桌面端切换设计成“任务切换”而不是“设备切换”
桌面端 2026-07-16 的更新，核心价值不是界面更漂亮，而是 Chat 和 Work 能在同一 Recents 里被整理、筛选和继续执行。如果你要用本地文件、桌面应用或想跨设备续跑，桌面端现在比过去顺手得多。真正该设计的是：什么任务留在云端 Work，什么任务必须落在本地 Work。
- 云端 Work：资料主要来自网页、云文件、跨设备继续做的任务。
- 本地 Work：需要访问本地文件、截图、下载件或桌面应用的任务。
- 切换规则写清后，团队成员才不会一半人在 web 开任务，一半人在 desktop 找不到上下文。
可直接复用的上线模板
试点主题：
使用入口：Chat / Work / Codex
Project 名称：
Project 内固定文件：
Scheduled Task 周期：
交付类型：文档 / 表格 / 报告 / Site
Site 访问范围：自己 / 工作区 / 公开
桌面端是否需要本地文件：
审批点：
回滚方式：
首轮复查日期：实际例子：把每周增长复盘做成一条 Work 流水线
一个三人内容团队每周都要整理搜索流量、YouTube 数据和下一周排期。以前做法是把截图、表格和聊天散在三个地方。改成 Work 后，团队先建了“每周增长复盘”这个 Project，把站点清单、指标说明和周报模板放进去；再让 Work 每周五生成初版复盘，最后把复盘做成一个仅工作区可见的 Site。这样做的价值不在“更炫”，而在每周都走同一条可复核路径，谁接手都能继续。
验收清单
- 团队已经写清 Chat、Work 和 Codex 的分工。
- 试点 Project 只承载一个明确主题，没有把多个无关任务混在一起。
- Scheduled Tasks 有固定周期、固定输入和固定输出，不靠临时发挥。
- Sites 在公开前已检查访问范围、表单、链接、文件和敏感内容。
- 桌面端与云端 Work 的使用边界已说明清楚。
- 每条自动化或半自动化任务都有回滚方法。
常见坑
- 把所有任务都塞进 Work，最后每条任务都拖得很长却没有明确产物。
- Projects 只用来“归档聊天”，没有把固定文件和验收标准放进去。
- Scheduled Tasks 一上来就追太多源，结果团队每周只是在处理噪音。
- Sites 预览通过就直接公开，没有做第二账号访问测试。
- 桌面端和 web 混用，却没人说得清本地文件到底存在哪一侧。
排错路径
- 看不到 Work：先确认计划类型和工作区权限，而不是反复刷新页面。
- 桌面端没有 Projects：更新桌面应用后重登，再确认是否使用了正确工作区。
- Sites 不能公开发布：先查是否处在 Enterprise 且管理员未开放公开权限。
- Work 任务上下文混乱：检查是不是把太多不相关文件塞进一个 Project。
- Scheduled Task 结果不可用：回到任务定义，把输入源和验收格式收窄。
后续维护建议
更新日期：2026-07-25。接下来最值得固定的是三次复查：试点第 3 天看任务是否真的省时，第 7 天看哪些步骤还在手动补，第 30 天看哪些 Project 值得保留、哪些 Scheduled Task 应该停掉。Work 的长期价值，不是因为它功能多，而是你能不能把每条执行线压缩成团队能重复、能交接、能回滚的习惯。