用 ChatGPT 数据分析改造每周报表：减少反复交接

2026 年 9 月 10 日，OpenAI 在 ChatGPT Work 和 Codex 中加入了 Data。对企业来说，关键并不是又多了一个图表按钮，而是 ChatGPT 数据分析能把每周报表从分析师之间的反复交接，变成一条连通、可刷新，同时保留指标口径与人工签字确认的工作流。

ChatGPT Data 究竟是什么

Data 是 ChatGPT Work 和 Codex 中面向分析工作的插件。提出一个业务问题后，它可以在账户有权访问的数据源之间开展分析，并把结果制作成交互式仪表盘或报告。如果还不熟悉这两个工作界面，ChatGPT Work 评测解释了 Work 与 Codex 的分工边界。

它不是数据仓库，不会另建一份数据库副本，也无意取代所有 BI 工具。OpenAI 的 Data 配置指南建议连接数据仓库、提供语义层，并用 ChatGPT Sites 交付最终仪表盘。所谓语义层，就是企业认可的业务含义：哪些收入可以计入、客户何时算激活、哪些退款应排除，以及数据表之间是什么关系。

这套定义才是整个流程的支点。缺少它，Data 完全可能把一个错误数字解释得条理清晰。

传统报表流程通常是这样的：管理者提出问题，分析师寻找数据表、重写查询、导出结果、更新图表，再回答后续问题。每多一轮，就多一次交接。

用了 Data，管理者和分析师可以留在同一条对话里。Data 能查询获批的数据源，遵循团队的指标定义，展示筛选条件和证据，并在修订分析后生成仪表盘。分析师不必再充当工具之间的数字搬运工，而是负责定义指标、检查查询并批准结果。

它也不同于 ChatGPT Work 中的 Deep Research。Deep Research 用来汇集并引用来自网页、文件和受支持应用的证据；Data 则面向受治理的业务分析，处理已经连接的运营数据。前者产出带来源的研究简报，后者可以成为团队每周都会打开的常规指标报告。

ChatGPT 数据分析改变的是流程，不是真实数据源

真正有价值的变化，是报表交接次数减少了；风险则在于，一句对话式请求现在可以从数据仓库一路抵达共享仪表盘。

Data 可处理的来源包括 Amazon Redshift、ClickHouse、Databricks、Google BigQuery、MongoDB 和 Snowflake。它还可以读取 Google Drive 与 SharePoint 中的业务背景资料，并在相应连接可用时，与 Power BI、Tableau、Sigma、ThoughtSpot 等 BI 工具配合。具体能执行哪些操作，取决于每个工具以及用户本人的权限。

这些能力都不会让模型变成记录系统。OpenAI 建议，在采信结果前核对数据源、时间范围、筛选条件和指标定义。如果 Data 的答案与现有报告不一致，首先就该对照这四项。

最适合采用这套流程的，是已经在财务报告包、销售管道复盘、客户仪表盘、留存报告和经营复盘上付出大量交接成本的团队。没有获批数据源、稳定定义或 Data 访问权限，就无法形成常规工作流。一次性 CSV 也许能少点几下，但真正能支撑商业价值的是周期性报告。

本周就可能改变的四类工作

软件公司的财务负责人

财务负责人可以让 Data 从获批的数据仓库视图刷新每周营收与留存报告。请求中写明报告周期、对比周期和财务部门制定的指标定义，Data 就能起草差异说明，并展示每张图表背后的依据。

收益并不是自动完成关账，而是少在分析师、电子表格、演示文稿和财务负责人之间来回奔波。报告提交给管理层之前，财务仍须对数字签字确认。

营收运营负责人

RevOps 负责人可以使用获批的销售管道定义，以及其账户有权访问的 CRM 或数据仓库数据，调查各区域的管道为何发生变化。通过追问，还能分辨这究竟是真实的销售变化，还是筛选条件变更、同步延迟或记录未映射所致。

收益在于，从“数字变了”到“发生变化的是这个细分群体和这行源数据”，路径变短了。销售运营团队仍然负责销售阶段定义，也仍然决定是否调整预测。

代理商客户负责人

客户负责人可以基于获批的广告和电商数据制作客户业绩仪表盘，并在每周例会前让 Data 解释幅度最大的变化。品牌规范可以直接约束仪表盘样式，不必每次手工重做版式。

收益是减少重复制作演示文稿的时间。但代理商仍须确认，最终仪表盘里的每个数据维度是否都可以让客户看到。数据源访问权和仪表盘访问权不是同一层权限控制。

产品运营负责人

产品运营负责人可以跨产品分析数据和“活跃用户”定义文档，追踪留存率变化。Data 能比较同期群、列明时间窗口与筛选条件，再把核验过的分析整理成面向产品团队和管理层的报告。

收益是产品经理与分析师之间少几轮往返。如果团队对激活定义存在争议，Data 无法替他们拍板；必须先在语义层中解决分歧。

如何试点自动化周报

不要从高管仪表盘起步。先选一份负责人、数据源、定义和当前输出都已经明确的报告。

1. 1

   选定报告及其支持的决策

   挑一份周期性报告，并说清它要支持哪个决策。“每周营收报告”仍然太笼统；“在经营复盘前判断是否需要干预留存问题”才给分析设定了终点。

2. 2

   先确认权限，再写请求

   管理员进入 Workspace settings > Plugins > Data，选择哪些人可以安装插件，并启用所需的数据源连接。个人用户从插件目录安装 Data。在 Codex 中打开 Sources，选择 Use plugins，再选中已经安装的插件。数据源应用本身可能仍需单独配置和授权。

3. 3

   写下指标契约

   把获批数据源、指标定义、报告周期、对比基准、排除项和负责人都告诉 Data。还要指定语义视图或可信仪表盘：一旦定义冲突，以它为准。如果团队无法把这些内容写清楚，这条工作流还不适合自动化。

4. 4

   先私下运行一次

   以 @Data 开头，明确由哪个插件处理请求。要求它交付仪表盘及其计算过程，同时列出数据时效性、筛选条件、未匹配记录，以及任何可能改变答案的假设；并明确要求结果保持私密。

5. 5

   核验证据

   把支撑决策的关键数字与当前报告逐一对照，确认数据源、周期、筛选条件、定义和被排除的记录。如果有差异，先让 Data 解释清楚，不要因为新图表更美观就接受它。

6. 6

   先测量，再设定计划任务

   记录实际审核时间、Work 或 Codex 用量、数据仓库活动，以及所有 BI 成本。只有手动运行通过后，才设置云端刷新计划。ChatGPT Work 的计划任务会检查数据源并更新仪表盘；Site 本身不会执行计划任务。

下面这段起始请求可以按需调整：

@Data，请基于获批的财务语义视图，制作每周营收与留存报告。把最近一个完整周与前一个完整周进行比较。采用财务团队的定义，展示数据时效性、筛选条件、计算过程和未匹配记录，并解释幅度最大的变化。仪表盘须保持私密。不要发布、分享、联系任何人，也不要更改源数据。如果需要改用其他定义或数据源，请先询问我。

首次运行应该暴露薄弱的数据源和定义边界，而不是用一张完成度很高的仪表盘把问题遮住。

真正该算的成本账

OpenAI 尚未公布 Data 插件的单独价格，但这并不代表工作流免费。成本可能来自 Work 或 Codex 用量、数据仓库算力、继续保留的 BI 许可证，以及仍然不可省略的人工审核。

用一组具体的规划假设来算：一份每周报表目前需要 3.0 人时，综合用工成本为每小时 $80。全年运行 52 次，成本就是 $12,480。如果 Data 把制作和审核压缩到每次 0.75 人时，人工成本将降至 $3,120；按这套测算，释放的产能价值为 $9,360。

这些只是规划假设，并非 OpenAI 的基准数据。试点之后，应换成团队自己计时得到的数字。

ChatGPT 这一项采用明确的假设：每次刷新在 GPT-5.6 Sol 上使用 50,000 个输入 token、200,000 个缓存输入 token 和 10,000 个输出 token。OpenAI 当前的新 Enterprise 费率表对应的每百万 token 价格分别为 $4.00、$0.40 和 $20.00。照此计算，每次刷新为 $0.48，每年为 $24.96。

Business 和基于 credit 的 Enterprise 工作区使用另一套计量单位。当前的 credit 费率表显示，在 Work 和 Codex 中使用 GPT-5.6 Sol，每百万输入 token、缓存输入 token 和输出 token 分别消耗 100、10 和 500 credits。标准 Business 席位先使用套餐内额度，之后符合条件的工作可以消耗工作区另购的 credits。

Snowflake 一项假设每周刷新时启动一次 X-Small 仓库，且运行时间不超过其 60 秒最低计费时长。Snowflake 的计费方式是：X-Small 连续运行每小时消耗一个 credit，每次启动至少按 60 秒计费，之后按秒计费。Data 可能会发起更多查询、让仓库保持更长时间的活跃状态，或者使用更大规格的仓库。真实账单要看仓库历史记录，而不能只看这个下限。

在 OpenAI 推荐的配置中，Power BI 并不是必选项。Microsoft 目前列出的 Power BI Pro 价格是按年付费时每位用户每月 $14，但已有许可证可能属于沉没成本，而且实际结账价格会因地区而异。不要仅仅因为 Data 能连接 BI，就额外购买一个席位。

决策公式很直接：

年度价值 = 报告运行次数 × 节省的人时 × 综合用工成本，再减去新增的 Work 用量、数据仓库算力、新增 BI 许可证和剩余审核成本。

如果采用这套工作流会促使团队新购 ChatGPT 席位，就把席位成本算进去。如果 ChatGPT 席位和 BI 工具本来就在付费，则采用边际成本。试点的目的，就是用观察到的数字替换每一个假设。

权限陷阱出现在查询之后

Data 查询沿用已连接账户的现有权限，包括表级、行级和列级限制。安装 Data 插件并不会自动获得数据仓库连接，而连接数据仓库也不会让用户越过授权角色的范围。

发布会形成第二道权限边界。OpenAI 表示，分析所用的数据会被复制到已经发布的 ChatGPT Site 中。Site 随后采用自己独立的受众设置；只要账户和管理员允许，受众可以是指定人员、整个工作区、具名外部查看者，或公众。

实际后果是：无权运行源查询的人，仍有可能进入 Site 的受众范围，看到已经复制进去的数据。因此，要把仪表盘的字段和受众当成一次新的发布来审核，而不是把 Site 视为自动继承数据仓库权限的实时窗口。

新建 Site 最初仅限其所有者和工作区管理员访问，直到有人更改权限。Enterprise 默认关闭公开发布，但这只是一项控制；一旦允许向指定外部人员或整个工作区分享，受众范围仍会扩大。

必须坦白的限制

目前各套餐的可用范围还不够清晰，无法做出适用于所有人的承诺。插件目录覆盖多个 ChatGPT 套餐，但每个插件都受套餐、工作区、角色、地区、产品界面、上线进度和套餐所含功能的影响。Data 指南也没有给出精确的可用套餐清单。在围绕它采购之前，先确认目标账户和工作区里是否真的出现了 Data。

Sites的价格也仍不明确。它正面向 ChatGPT 工作区、Plus 和 Pro 账户进行公开测试，具体仍受灰度开放和控制设置影响。测试期内，只有不超过各套餐专属限额的用量才包含在内；OpenAI 表示，完整定价信息仍有待公布。

自动化同样消耗用量。受支持的 Work 和 Codex 自动化，会按照适用费率表计入模型活动。OpenAI 的仪表盘工作流说明，云端任务可以在笔记本电脑关机后继续执行，而桌面任务要求电脑保持开机且应用持续运行。应有意识地选择运行方式，并同时关注两边的用量记录。

Data 也修复不了薄弱的业务逻辑。语义层缺失、KPI 定义有争议、账户权限不完整、数据源陈旧，或工具不支持所需操作，都会留下缺口。仪表盘或许能让缺口看起来更漂亮，却不会让它缩小。

周一就做这一步

如果团队每周都在重做同一份报告，能够说清负责人和获批数据源，而且指标定义稳定，就值得本周行动。如果目标工作区尚未出现 Data、数据源连接还没通过审核，或两个团队仍用不同方法计算 KPI，那就先等一等。如果现有 BI 刷新已经能以很少的人工交接，把核验过的报告送到正确的人手里，那么这次变化对团队影响不大。

周一，挑一份本来就要交付的报告，先通过 Data 私下运行。第一步是记录当前制作时间；然后给 Data 提供获批视图和指标契约，把所有会影响决策的关键数字与现有报告逐一对照，并记录 Work 用量、数据仓库活动和审核时间。只有结果通过检查，而且 Site 受众有明确负责人之后，才可以设置计划任务或发布。

想继续阅读用通俗语言拆解 AI 如何改变工作流成本的实操指南，可以订阅邮件通讯。