ChatGPT Work 功能从聊天扩展到网站、电子邮件和文档

OpenAI 于 7 月 9 日推出 ChatGPT Work，将 ChatGPT 从对话式助手转变为能够产出最终成果的智能体。首批 ChatGPT Work 功能涵盖网站、电子邮件工作流、文档分析、电子表格、演示文稿、报告和定时任务。

这次变化的意义远大于又一次模型升级。OpenAI 正在将快速对话与涉及多个来源、应用程序、决策和交付成果的长期任务区分开来。Work 可以持续运行数小时，将项目拆分为多个步骤，请求澄清，并允许用户在其运行过程中调整方向。

这使 ChatGPT 与人们已经用于完成知识工作的软件形成了更直接的竞争。Google Workspace、Microsoft 365、网站构建工具、自动化平台和专业 AI 助手如今都面临一个争夺相同任务的更广泛界面。

其承诺很直接：描述期望的结果，提供相关背景信息，然后获得可供审阅的成果。更困难的问题是，一个智能体能否可靠地在私有数据、可编辑文件、外部网站和影响重大的操作之间流转，而不会带来新的风险。

ChatGPT Work 功能将提示词转化为交付成果

ChatGPT Work 围绕已完成的项目而设计，而不是提供更长的对话式回答。

OpenAI 将 Work 描述为一个用于研究、分析以及创建文档、电子表格、演示文稿、报告和 Sites 的智能体。Codex 仍然是面向软件开发、代码仓库、测试和技术工作流的独立体验。

这种划分为 ChatGPT 提供了三种不同的工作模式。Chat 用于回答问题和头脑风暴。Work 用于处理长期项目并制作最终材料。Codex 则继续专注于软件工程。

这种区别十分重要，因为制作交付成果所需的不只是生成文本。智能体必须找到源材料、处理相互冲突的指令、保留格式、执行计算，并根据反馈修改结果。

OpenAI 表示，Work 可以将复杂项目拆分为更小的步骤，并独立完成这些步骤。用户可以跟踪其进度、回答问题、改变方向，并在运行期间批准重要操作。

该公司的 Work 公告称，该智能体可以在需要时持续处理一个项目数小时。它还可以在一系列相互关联的输出之间延续上下文。

营销任务可以说明这种差异。普通聊天机器人可能会根据粘贴的摘要起草一份营销活动简报。Work 则旨在收集客户研究资料、创建简报、制作营销材料，并针对不同市场进行调整。

这是从生成回答向执行工作流的转变。评判智能体的标准是其生成的文件、分析和操作能否构成一个连贯的结果。

OpenAI 使用为 Codex 开发的技术构建了 Work。这种关联解释了为何该产品强调规划、工具使用、文件操作和可见进度，而不是一次性给出精心润色的答案。

该公司表示，每周有超过五百万人使用 Codex。它还表示，超过一百万人使用 Codex 从事软件开发以外的工作。这些由公司公布的数据有助于解释 OpenAI 为何将智能体模式扩展到编程之外。

Work 可在 ChatGPT 网页端、移动端和桌面应用程序中运行。云端 Work 对话可以在这些平台之间同步，让用户可以在手机上开始一项任务，然后在其他设备上继续审阅。

桌面应用程序带来了一个重要差异。获得许可后，Work 可以使用云端会话无法直接访问的本地文件和桌面应用程序。

这种本地访问能力为文档密集型工作带来了更多可能性。同时也需要谨慎限定访问范围，因为桌面智能体可能会接触到当前任务之外的私密材料。

OpenAI 建议用户仅授予任务所需文件的访问权限。除非用户明确移动或分享，否则本地文件和输出内容仍会保留在计算机上。

Work 还可以在 ChatGPT Project 内运行。Projects 将相关对话、文件和指令保存在一起，为长期任务提供持久的上下文，而无需用户反复附加所有内容。

因此，该产品将 ChatGPT 中已有的多个理念整合到了一个面向任务的界面中。Projects 提供上下文，插件连接外部系统，Scheduled Tasks 提供周期性执行能力，而智能体负责协调工作流。

这种组合正是 ChatGPT Work 功能背后的核心变化。OpenAI 不再要求用户手动组合彼此独立的研究、写作、文件处理和自动化会话。

现在，智能体试图接管从初始请求到可供审阅的输出之间的整个流程。这个流程能否保持准确且可控，将决定用户实际愿意委托多少工作。

ChatGPT Sites 增加构建和托管能力

ChatGPT Sites 将 Work 带入此前由网站构建工具、仪表板工具和轻量级应用平台占据的领域。

Sites 允许用户根据描述创建交互式网站和小型 Web 应用程序。用户可以要求 Work 构建网站，也可以直接在提示词中调用 Sites。

OpenAI 列出的预期使用场景包括仪表板、项目跟踪器、发布日历、原型、内部门户和交互式报告。这些示例侧重于功能性工作界面，而不是传统的公司主页。

用户可以在请求中添加文件、链接、数据、内容和设计限制条件。ChatGPT 会生成私密预览、接受修改，并在成果准备就绪后提供分享控制选项。

Sites 文档证实，部署后会生成一个可访问的 Site URL。用户可以将 Site 设为私密、与指定人员分享、在工作区内开放，或在获得许可时公开发布。

这使得 Work 能够构建和托管网站的说法基本属实。不过，Sites 是一个具有明确限制的托管运行环境，并不能替代所有托管平台。

OpenAI 表示，某些框架、私有网络、数据库、后台服务和托管模式可能无法运行。受支持的功能取决于运行环境以及该账户已启用的功能。

这一限定非常重要。发布仪表板或交互式报告比复杂的商业系统或受监管的客户门户更符合该产品目前的适用范围。

Sites 发布时不支持金融交易。根据 OpenAI 公布的限制，它也不能处理支付卡数据或受保护的健康信息。

开发者也不能假设每个生成的应用程序都会获得传统的基础设施控制能力。代码、存储、日志、部署环境和允许使用的集成仍受 Sites 平台管理。

部分环境支持自定义域名，但 Sites 不提供域名注册服务。用户必须已经拥有该域名，并通过域名提供商更新其 DNS 记录。

Enterprise 管理员可以获得对创建和发布功能的额外控制。Enterprise 工作区默认禁用公开发布，成员必须获得管理员授权后才能对外发布。

这一治理层降低了意外泄露的风险，但并未消除审查的必要性。生成的 Site 仍可能包含不应公开的源文本、文件、表单、链接或数据。

OpenAI 明确要求用户在发布前检查内容、访问设置、表单、身份验证行为、上传的文件和交互功能。生成的输出不应被视为天然安全。

这一审查要求揭示了 Sites 核心的权衡。降低发布难度的同一套系统，也降低了错误内容的发布门槛。

项目经理可以将电子表格和会议记录转化为实时状态门户。这样可以节省整理时间，但经理仍需对日期、职责和共享信息的准确性负责。

研究人员可以将研究结果转化为交互式报告。与静态文档相比，结果可能更好地传达证据，但每条引文、每个可视化内容和每项生成的解读仍需核实。

Sites 还可以随着底层信息的变化而更新。结合 Scheduled Tasks，这为从静态成果转变为持续维护的运营界面提供了路径。

例如，团队可以监控账户活动，并在每天早晨刷新销售指挥中心。另一个团队可以在出现新任务或日程变化时更新发布日历。

这些工作流给独立仪表板构建工具带来了压力，因为 ChatGPT 可以利用通过已连接工具获得的上下文创建界面。用户不需要手动传输每个数据点。

不过，专业平台在权限、测试、集成、分析、可靠性保障和复杂数据建模方面仍具有优势。目前，Sites 最直接参与竞争的是市场中的轻量级领域。

其早期最有力的用途，可能是替代那些从未值得投入完整开发项目的内部成果。许多团队仍通过电子表格、幻灯片和手动更新的页面进行协作。

ChatGPT Sites 为这些团队提供了一条更快捷的交互化路径。关键考验在于，生成的 Sites 在首次令人印象深刻的演示之后能否继续保持可靠。

电子邮件管理取决于已连接的应用程序和权限

ChatGPT Work 可以管理电子邮件工作流的部分环节，但用户不应将其理解为对收件箱拥有不受限制的控制权。

Work 依靠插件及其底层应用程序访问 Gmail 和 Outlook 等服务。这些连接可以提供邮件、附件、联系人、日历信息和受支持的操作。

连接后，Work 可以在完成更大型任务时收集电子邮件上下文。它可以总结邮件会话、识别尚未回答的问题、提取承诺事项，或将附件内容整合到报告中。

该智能体还可以将电子邮件与其他来源连接起来。销售准备任务可以结合近期邮件、日历事件、CRM 记录、演示材料和公开的公司信息。

这种跨来源协调比单独的电子邮件摘要更有价值。智能体可以将邮件作为更广泛交付成果中的证据，而不只是对其进行压缩总结。

Scheduled Tasks 进一步扩展了这种模式。OpenAI 表示，Work 可以监控新邮件、更新文档或幻灯片，并与团队分享重要变化。

其中一个示例是在通过电子邮件收到新反馈时刷新演示文稿。另一个示例是按照周期性计划，将新的 Slack 活动转化为更新后的会议议程。

这些工作流将收件箱转变为事件来源。电子邮件成为持续流程中的一个输入，而不是工作最终堆积的地方。

不过，可用操作会因插件、账户、工作区政策和地区而异。连接电子邮件服务并不保证支持所有读取、起草、发送、编辑或归档操作。

插件权限将访问能力与审批行为区分开来。连接决定了哪些信息和操作在技术上可用。权限设置则决定 ChatGPT 在使用它们之前何时必须征得同意。

OpenAI 的默认方法允许执行许多读取操作，同时对重要变更请求批准。发送或编辑电子邮件被列为可能需要确认的操作。

管理员可以在托管工作区中实施更严格的控制。他们可以禁用应用、限制操作、配置角色访问权限，并决定成员何时必须批准变更。

个人用户也可以选择更严格的设置。要求任何变更都必须事先批准，比允许风险较低的修改自动执行提供了更强的控制力。

更安全的提示词不是“处理我的电子邮件”。OpenAI 建议避免模糊、开放式的指令，因为它们留下了过多的解释空间。

更好的任务会明确指定账户、时间范围、发件人、所需分类、输出格式，以及需要审核的操作。它还应说明智能体绝不能发送、删除或分享哪些内容。

例如，用户可以要求 Work 审查上一周的客户邮件并起草回复，但不要发送。该任务还可以要求单独列出含义不明确或敏感的情况。

这种结构可以让判断过程保持可见。它还可以限制因误解指令、缺少上下文或错误分类邮件而造成的损害。

电子邮件还带来了另一项重大风险：提示词注入。当外部内容中的恶意文本试图改变智能体的行为或诱使其泄露受保护的信息时，就会发生这种情况。

恶意邮件可能会指示智能体忽略用户的请求，并将私密内容转发到其他地方。由于 Work 会将邮件作为任务输入读取，因此它必须区分数据与命令。

OpenAI 表示，其智能体使用确认机制、监控、拒绝规则和自动审核来降低这种风险。该公司同时指出，这些防护措施并不能完全消除风险。

因此，用户应仅连接当前工作流所需的服务。他们应在批准之前检查收件人、附件、引用文本和拟执行的操作。

电子邮件管理还揭示了起草能力与操作权限之间的区别。撰写一封得体的回复是一项语言任务，而决定是否发送则可能涉及法律、财务、声誉或人际关系方面的后果。

Work 可以加速前一部分，并协助处理后一部分。但它不会将责任从运营该账户的个人或组织身上转移出去。

近期的实际价值在于边界明确的工作流。汇总特定邮箱、准备草稿、提取任务以及更新受控文档，都比自主收件箱管理更容易审核。

如果 OpenAI 能够让这些边界明确的工作流变得可靠，电子邮件将成为推动更广泛采用的有力切入点。如果用户遇到邮件放错位置或不安全的操作，信任就会迅速流失。

文档处理成为端到端工作流

文档方面的能力不只是摘要，因为 Work 可以将多种来源转化为可编辑的文件、电子表格、幻灯片和报告。

ChatGPT 已经允许用户上传文件并提出问题。Work 将这种能力扩展为多阶段的制作流程，可以保留模板、修改输出并协调多种格式。

用户可以从指令、源材料或现有模板开始。他们可以指定哪些内容必须保持不变，包括公式、布局、品牌元素、幻灯片顺序和表格结构。

文件创建指南指出，Work 支持可编辑文档、电子表格、演示文稿、报告和分析。实际可用性仍取决于文件类型、应用、套餐和工作区配置。

原生 Google Docs、Sheets 和 Slides 工作流需要相应的 Google Workspace 应用。桌面端集成有所不同，并非每种格式在所有界面上都能获得完全相同的支持。

这意味着，“汇总海量文档集合”应被理解为一项目标工作流，而不是不受限制的技术保证。集合规模、文件兼容性、来源访问权限和上下文质量仍会影响结果。

一个实用的区别是检索与综合。检索负责定位段落或事实，而综合则将它们组合成新的结构、识别关系，并解释哪些内容值得关注。

一项设计良好的 Work 任务应同时定义这两个阶段。它应说明哪些来源具有权威性、如何处理冲突，以及每项结论必须附带哪些证据。

假设某个产品团队正在审查数百份访谈笔记、支持工单和规划文档。笼统的摘要可能会归纳出宽泛的主题，却掩盖不同客户群体之间的差异。

更好的工作流会要求 Work 保留来源引用、区分反复出现的投诉与个别请求，并识别缺乏足够证据的说法。随后可以将输出制作成按优先级排列的报告或演示文稿。

已经在使用可搜索知识库的团队，可能会受益于将来源发现与最终成果生成分开。这样更容易检查哪些内容进入了分析过程。

电子表格带来了额外要求。一本看起来正确的工作簿仍可能包含失效的公式、不匹配的数据区域、隐藏的假设，或基于不完整数据构建的图表。

用户应指定所需的工作表、公式、列、图表和验证检查。他们还应在分享决策之前，将重要输出与原始数据进行比较。

OpenAI 表示，其财务团队使用 Work 查找源数据，将其导入 Excel 或 Sheets，进行核对、制作幻灯片并验证结果。据该公司称，这一流程将某些月末工作从数天缩短至数小时。

这是 OpenAI 内部的案例，而不是独立基准测试。它展示了预期的工作流，但不能证明每个组织都能取得相同结果。

演示文稿工作流遵循类似的模式。Work 可以将源文件整合成结构化的幻灯片，使用现有的演示文稿母版，并在收到反馈后修改叙事结构。

困难之处通常不在于生成单张幻灯片，而在于决定故事中应包含哪些内容、保留证据、保持视觉一致性，以及避免得出缺乏依据的结论。

Work 尝试在整个交付成果中协调这些决策。用户可以请求修改，而无须在聊天机器人、电子表格、文档编辑器和演示工具之间手动搬运文本。

这种协调能力给专业写作和演示助手带来了压力。当通用智能体可以在多种输出格式之间传递上下文时，这些工具的单项功能就不再那么重要。

专业工具仍有竞争空间。它们可以提供更深入的控制、更高的模板还原度、特定领域的审核、更可预测的格式，以及更清晰的审计记录。

相比之下，ChatGPT Work 依靠广度展开竞争。其优势在于能够从混合来源开始，并在同一个项目中生成多个相互关联的输出。

广度也会增加验证负担。一个错误可能从来源摘要进入电子表格，然后再进入幻灯片、Site 或外发电子邮件。

即使早期的解读有误，最终成果也可能看起来十分精致。视觉质量可能会让薄弱的分析更具说服力，而不是更加准确。

用户应在工作流中设置审核检查点。当风险足够高时，来源提取、分析、计算、叙事和发布都应分别获得批准。

这种审核模式类似于良好的人类项目管理。只有预期结果、约束条件、证据和决策权都清晰明确时，委派才能发挥最佳效果。

对于知识工作者而言，最直接的好处是减少组装工作。Work 可以收集信息并生成第一个完整版本，让用户专注于判断。

长期价值取决于 OpenAI 能否在整个流程链中保留信息来源。读者需要知道哪些来源支持某项说法，以及哪些内容是智能体推断得出的。

缺少这种可见性，文档自动化就有可能制造出经过精心包装的不确定性。有了这种可见性，Work 就会成为连接零散信息与可审核行动的实用桥梁。

主要竞争对手是现有工作工具栈

ChatGPT Work 通过争夺各类套件和单点解决方案之间的协调角色，对它们形成压力。

OpenAI 不只是在增加另一款文档编辑器或网站构建工具。它希望 ChatGPT 成为用户描述目标并协调实现目标所需工具的地方。

这使 Work 面临两种成熟方案的竞争。第一种以生产力套件为工作中心；第二种通过自动化平台和人工交接组合各种专业应用。

Microsoft 和 Google 已经掌握了许多底层文档、日历、电子邮件账户、会议和权限。它们的优势来自原生访问能力、熟悉的界面和现有的管理控制。

ChatGPT 则将这些系统视为协调层。插件让它可以检索上下文并执行受支持的操作，而无须用户放弃那些保存其数据的应用。

网站构建工具也面临着来自 Sites 的类似挑战。如果 OpenAI 能通过一个提示词满足轻量级内部项目的需求，就无须与所有高级功能逐一匹敌。

自动化平台同样面临压力，因为 Scheduled Tasks 可以监控变化并运行工作流。其吸引力在于用户可以用对话方式描述目标，而无须手动配置每一个步骤。

然而，对话式设置可能会隐藏可视化自动化工具所呈现的复杂性。即使用户看不到，触发器、故障处理、重试、权限和数据转换仍然存在。

因此，可靠性成为 OpenAI 宏大承诺面临的首要挑战。灵活的智能体很容易在演示中胜出，但实际运营工作要求它在反复运行时保持可预测的行为。

传统软件通过字段、公式、访问控制和明确的工作流来编码规则。智能体则解读自然语言目标，这使其更具适应性，但也带来了歧义。

核心权衡是灵活性与控制力之间的取舍。Work 可以在没有新配置界面的情况下响应变化的上下文，但这种自由也使结果更难复现。

组织很可能会从可逆任务开始。研究、起草、内部报告和私有原型允许用户在结果产生外部后果之前进行检查。

在涉及财务承诺、受监管数据、公开沟通和破坏性文件操作时，采用速度会放缓。这些领域需要更严格的验证和更有限的权限。

OpenAI 自己的文档反复强调审核和批准。用户可以监控进度、调整任务方向，并确认会影响外部系统的操作。

这种人为控制不是暂时的不便，而是产品运行模式的一部分，尤其是在智能体跨越风险等级不同的工具时。

因此，最恰当的比较不是人类员工与自主机器之间的比较，而是协调式智能体工作流与碎片化人工工作流之间的比较。

如果 Work 能够在让重要决策保持可见的同时，减少搜索、复制、格式调整和重复更新，它就能成功。如果用户把节省下来的时间都用于审核隐藏错误，它就会失败。

产品的广泛范围也改变了团队组织上下文的方式。将所有可用文件一股脑放进同一个工作区，可能会增加干扰并暴露不必要的数据。

结构化的AI 知识库可以帮助区分可信来源、工作草稿和受限材料。清晰的边界能让智能体输出更容易评估。

企业还出于其他原因需要关注这些边界。管理员需要了解智能体可以访问哪些应用程序、可以执行哪些操作，以及输出内容存储在哪里。

OpenAI 为插件、浏览器访问、网络访问、角色和重要操作提供工作区控制。它还为 Work 对话和操作提供合规日志记录。

这些功能至关重要，因为一个智能体可以跨越通常由应用程序强制实施的边界。在一个系统中看似无害的读取操作，可能会为另一个系统中的发布操作提供敏感上下文。

因此，竞争优势可能来自治理能力，而非原始模型质量。企业会青睐那些能够受到约束、可供检查并能与现有政策集成的系统。

凭借 ChatGPT 庞大的用户群和源自 Codex 的智能体技术，OpenAI 已经抢占先机。Microsoft 和 Google 则对许多工作场所系统拥有更深入的控制权。

专业厂商保有领域专业知识和更具针对性的审核流程。自动化平台则提供明确的逻辑和成熟的运营工具。

ChatGPT Work 试图凌驾于这三类厂商之上。它为目标提供统一界面，同时依赖这些厂商的系统提供数据、操作和最终格式。

这一定位很有价值，但在商业博弈中难度很大。应用程序提供商可以限制集成、强化自有智能体，或将最佳操作能力保留给原生体验。

下一阶段的胜负，不会取决于哪个产品能制作出最令人惊艳的示例演示文稿，而会取决于它在真实工作流中的重复使用情况。

ChatGPT Work 推出后需要关注什么

三个信号将表明 ChatGPT Work 功能会成为日常基础设施，还是仍然只是一种偶尔使用的生产工具。

第一个信号是重复任务的完成质量。一份成功的报告并不如以下表现重要：当来源、日期和格式发生变化后，定期生成的版本是否仍然正确。

用户应警惕那些会悄然累积的故障，包括遗漏邮件、使用过期文件、公式损坏、权限错误，以及不受支持的 Site 行为。

可靠的系统还需要具备实用的恢复能力。Work 应识别受阻步骤、解释缺失的访问权限、保留已完成的工作，并避免不必要地重新启动整个项目。

第二个信号是 OpenAI 如何发展审批和溯源机制。用户需要清晰的证据，说明相关主张源自何处、哪些文件发生了变化，以及执行了哪些外部操作。

审批请求必须出现在有意义的决策节点。确认次数过多会让自动化变得繁琐，而确认次数过少则会让错误逃过审核。

云端浏览器限制表明 OpenAI 正在谨慎地分阶段开放网页操作。发布时，云端浏览功能可用于受支持的公共页面，但无法登录或完成付款。

这一限制削弱了部分自动化主张，但也在系统发展过程中缩小了风险敞口。当已连接的应用能够直接执行任务时，它们仍然是首选途径。

第三个信号是 Microsoft、Google、自动化厂商和网站平台的竞争回应。原生提供商可以提供相似的智能体行为，同时为自家应用程序提供更深入的访问能力。

应关注这些公司是否会改进跨应用规划、可编辑交付成果、后台执行和权限控制。它们的回应将揭示 Work 的哪些部分最直接地威胁到了现有使用模式。

OpenAI 的推出过程同样需要密切关注。ChatGPT Work 和 Sites 正在逐步上线，访问权限取决于地区、账户、工作区设置和产品界面。

Sites 目前处于公开测试阶段，发布初期还存在额外的地域限制。部分组织无法使用演示中描述的同一组功能组合。

用户在围绕这些功能设计工作流之前，应先确认自己的账户中有哪些能力可用。拥有 Work 并不意味着每个插件、文件格式、Site 功能或操作都可用。

合适的第一个项目应是用户已经熟悉的项目。熟悉的任务有助于更轻松地判断来源缺失、假设薄弱、格式错误和不必要的步骤。

从边界明确的成果和清晰的审核标准开始。明确所需来源、最终格式、禁止执行的操作，以及智能体必须请求批准的节点。

月度报告、会议准备资料包、研究综合分析或私有项目跟踪器都可以作为切合实际的测试。每种任务都有明确的结果，同时不要求立即执行公开或财务操作。

然后比较完整的工作流，而不仅仅是生成速度。衡量准备时间、修正时间、来源覆盖率、格式质量，以及监督运行过程所需的精力。

ChatGPT Work 功能代表了 OpenAI 从回答问题转向协调知识工作的最明确尝试。网站、电子邮件、文档、电子表格和演示文稿如今都被纳入由一个智能体主导的工作流中。

此次发布并未让每个工作流都实现自主运行。它创造了一个新的委派层，其价值取决于访问权限、准确性、权限管理和审核。

最重要的是一个实际问题：哪个重复性项目需要耗费数小时进行搜索、复制、核对和格式整理，却不涉及不可逆的决策？

那就是测试 ChatGPT Work 的最佳场景。为它设定一个熟悉的成果、限制其权限、检查每个来源，并判断最终交付成果是否真正减少了工作量。