周报数字别再每周手算：让 AI 把系统导出数据变成固定加工流程

教程定位

这篇教程解决什么问题

很多运营助理和项目助理的周一上午是这样过的：从后台导出一份 CSV，打开表格软件，手动筛选出本周的数据，复制到汇总表，再算出支付订单数、支付金额、退款金额和渠道占比，最后把数字填进周报模板。这个过程看起来不难，但每个月总有那么一周数字对不上：上周明明报了 128 单，这周重新统计变成 131 单；退款单不知道为什么混进了支付金额；渠道名一会儿叫“小红书”、一会儿叫“小红书-种草”，透视表里就裂成两行。

这篇文章要解决的不是“教你怎么按按钮”，而是帮你建立一条可以复用的周报指标加工流程。你只需要把后台导出文件的脱敏样例、周报指标模板和口径说明交给 AI 助手，让它先产出字段映射、筛选条件、统计口径和异常检查清单，再由你逐项确认和回测。最后你手里会留下一份“周报指标加工流程”，里面写清楚每个数字从哪个字段来、用什么条件筛、怎么算、哪里容易错。下周、下下周，甚至换一个人来做，都能照着同一套规则把数字跑出来。

这篇文章的边界也很明确：AI 助手负责起草规则、指出歧义和设计检查点，不负责拍板口径，也不替你把最终数字填进周报。口径是对是错，只有你和业务负责人能确认。

使用场景

什么情况下最适合用这一套

你可能正在做这样的事：每周从 CRM、订单系统、项目管理工具、客服工单系统或报名后台导出一份 CSV，然后手工统计几个固定指标。指标通常不多，可能只有四五个，但每个指标背后都有隐藏口径。

典型的场景包括：

这些场景的共同点是：数据源稳定、指标固定、每周重复。但真正让人头疼的往往不是统计本身，而是导出文件的字段名变化、时间范围的口径差异、状态值的写法不统一，以及“测试单”“内部单”“退款单”混在数据里没有排除。

如果你只是每周把数字算出来填进周报，问题不会立刻暴露；可一旦数字和历史对不上，或者同事问你“这个数是怎么来的”，你就会发现自己答不上来：上周是按支付时间还是创建时间统计的？退款单到底算不算支付订单？“已支付”和“支付成功”是不是同一个状态？

AI 助手在这里的用处，是帮你在每周重复劳动开始前，先把这些问题变成一份明确的规则草案。它不会知道你公司的退款流程，也不会知道哪个渠道名才是标准写法，但它能快速识别字段、状态值和异常记录，把需要人确认的问题一次性摊在桌面上。

• 每周一导出上周订单，统计支付订单数、支付金额、退款金额和渠道分布。
• 每周从项目管理工具导出任务清单，统计新增任务、已完成任务、延期任务。
• 每周从客服系统导出工单，统计新开工单、已解决工单、平均处理时长。
• 每周从报名后台导出报名记录，统计新增报名数、付费报名数和来源渠道。
• 每周从广告后台导出投放数据，统计消耗、展示、点击和转化。

材料准备

开始前先把材料和边界备齐

开始之前，不要直接把整个导出文件原样丢给 AI 助手，也不要让它直接给你“本周数字”。你需要先准备四类材料。

第一类是脱敏导出样例。截取最近一次导出文件的 20 到 30 行，尽量覆盖不同状态、不同渠道、有退款、有空值和疑似测试单的记录。如果文件里有敏感信息，把客户名、手机号、订单号改成示例值，但保留字段结构和格式特点。你要告诉 AI 助手“这是截取的样例，不是完整文件”。

第二类是周报指标模板。把你要填的指标列出来，例如“支付订单数”“支付金额”“退款金额”“渠道占比”。每个指标最好附上单位和你理解的统计范围，例如“支付金额：按支付时间统计本周内完成支付的订单金额合计”。

第三类是口径说明。这是最容易被忽略、却最重要的一份材料。口径说明可以来自历史周报、交接文档，或者你从同事那里问到的约定。哪怕只有几句话也要写出来，例如“本周按支付时间统计，范围是周一 00:00 到周日 23:59:59”“测试单和内部单不计入”“退款单单独统计，不冲减支付金额”。如果口径本身没人说过，你也要诚实标注“口径未确认，需要业务方确认”，而不是让 AI 助手替你猜。

第四类是历史周报。至少准备上周或上个月的周报数字，用来回测。你不需要把历史周报喂给 AI 助手，它是你人工核对时的参照物。

另外，建议你提前想清楚一个边界：AI 助手生成的映射、筛选和公式只是草案，最终要由你对照导出文件实际字段逐项确认，并且用历史数字回测通过后才能固定下来。涉及退款口径、内部单处理、金额含税与否这类业务判断，必须由业务负责人确认。

实操流程

按这套步骤把工作跑起来

第一步，把周报指标列成一张口径清单。不要只在脑子里想，要写下来。每行一个指标，包含四列：指标名、单位、时间范围、包含与排除条件。例如“支付订单数｜单｜本周（支付时间周一 00:00 至周日 23:59:59）｜状态为已支付且非测试单”。写不出来的地方就标“待确认”。这张清单是后面所有步骤的锚点。

第二步，检查导出文件的字段。打开导出的 CSV，先自己看一遍表头和前几行数据，确认有哪些字段、哪些字段可能和指标相关。常见的相关字段有订单号、创建时间、支付时间、状态、渠道、金额、退款金额。注意看有没有两个字段含义接近（例如“支付时间”和“更新时间”），有没有字段值有多种写法。这一步不需要你处理数据，只是建立对文件结构的基本认识。

第三步，把脱敏样例、周报指标口径清单和你的问题一起交给 AI 助手，请它先产出字段映射表。你要让它明确回答：每个指标对应哪个导出字段；如果导出字段不足以支持某个指标，缺什么；哪些字段存在歧义，需要人确认。不要在这一步就让它给最终数字。

第四步，让 AI 助手生成筛选条件和统计口径。你要特别提醒它使用固定的日期边界，例如“支付时间在 2026-07-27 00:00:00 到 2026-08-02 23:59:59 之间”，而不是“近 7 天”这种会随运行时间漂移的表达。同时让它列出每个状态值的处理方式：哪些算入、哪些排除、哪些需要标记待确认。

第五步，让 AI 助手设计异常检查清单。异常检查不是统计之后的装饰，而是加工流程的一部分。至少包含：空值检查、负数金额检查、重复订单号检查、状态值不在已知列表中的记录检查、金额为零的已支付订单检查、渠道名写法不一致检查。每一项都要写清楚“发现后怎么处理”，例如“标记出来交人工判断，不要自动丢弃”。

第六步，用上周或上月的数字回测。拿最近一周的导出文件，按 AI 助手给出的规则手动算一遍，和历史周报对比。如果支付订单数、支付金额这些核心数字对不上，先找差异原因：是时间边界错了，还是状态值漏了，还是历史周报本身口径不同。回测通过后，才把规则固化。

第七步，把流程固化成一份可复用文档。文档里包含口径清单、字段映射表、筛选条件、统计公式或操作步骤、异常检查清单，以及“本周围报取数记录”（哪天导的、用的哪个文件、谁确认的口径）。以后每周只需要照这份文档执行，遇到异常就在取数记录里追加说明。这样换人、换系统或换工具时，都不会从头再来。

输入示例

可以直接参考的输入材料

下面是一份脱敏后的订单导出 CSV 样例，以及一份周报口径说明。你可以把它替换成自己系统的真实文件结构。

周报口径说明：

订单号,创建时间,支付时间,状态,渠道,商品,订单金额,退款金额
SO20260728001,2026-07-28 09:12:33,2026-07-28 09:13:01,已支付,小红书,标准版,199.00,0.00
SO20260728002,2026-07-28 10:02:11,2026-07-28 10:05:40,已支付,小红书,专业版,499.00,0.00
SO20260728003,2026-07-28 11:20:05,,待支付,抖音,标准版,199.00,0.00
SO20260728004,2026-07-29 14:33:22,2026-07-29 14:34:00,已支付,抖音,标准版,199.00,0.00
SO20260729005,2026-07-29 15:01:09,2026-07-29 15:02:30,已退款,小红书,专业版,499.00,499.00
SO20260730006,2026-07-30 09:44:17,2026-07-30 09:45:02,支付成功,小红书,标准版,199.00,0.00
SO20260731007,2026-07-31 18:20:44,,已取消,抖音,标准版,199.00,0.00
SO20260801008,2026-08-01 10:10:10,2026-08-01 10:11:11,已支付,小红书,专业版,499.00,0.00
TEST20260801009,2026-08-01 11:00:00,2026-08-01 11:00:30,已支付,内部测试,标准版,0.01,0.00
SO20260802010,2026-08-02 23:58:59,2026-08-02 23:59:30,已支付,小红书,标准版,199.00,0.00

周报周期：2026-07-27（周一）00:00:00 至 2026-08-02（周日）23:59:59。
支付订单数：按支付时间统计，状态为已支付或支付成功，排除测试单和内部单。
支付金额：支付订单对应的订单金额合计，不含退款冲减。
退款金额：状态为已退款的订单，其退款金额合计。
渠道分布：按渠道字段统计支付订单数和支付金额。
待确认：渠道“小红书”和“小红书-种草”是否算同一渠道；状态“已支付”和“支付成功”是否同一口径。

提示词

可复制使用的提示词

下面的提示词可以复制后替换方括号里的内容。要点是：先让它给规则，不给最终数字；把“待确认”单列出来。

如果你已经确定口径，并且只需要 AI 助手帮忙检查，可以用第二个更短的提示词：

你是一个数据处理助理。我会给你三份材料：后台导出文件的脱敏样例、周报指标口径说明、我对字段的初步理解。

请只做以下事情，不要直接给我最终的周报数字：
1. 输出字段映射表：每个周报指标对应导出文件里的哪个字段；如果字段不足以支持指标，明确写“缺什么”。
2. 输出筛选条件：用固定的时间边界（例如 2026-07-27 00:00:00 至 2026-08-02 23:59:59），不要使用“近 7 天”；列出每个状态值的处理方式。
3. 输出统计口径：每个指标的计算规则，用我能看懂的文字描述，不要假设我懂公式。
4. 输出异常检查清单：至少包括空值、负数、重复订单号、未知状态、金额为零、渠道名写法不一致，并说明发现后应该标记还是排除。
5. 单独列出一份“需要人工确认的问题”，例如状态词不统一、渠道名不统一、测试单识别规则。

如果材料中有无法判断口径的地方，直接写“无法判断，需要业务方确认”，不要替我编造规则。

导出文件样例：
[在这里粘贴脱敏 CSV 样例]

周报口径说明：
[在这里粘贴你的口径说明]

我有一份周报口径和导出文件样例。请扮演复核者，只指出我的口径里可能造成每周数字漂移的地方，例如时间边界、状态词、排除规则、金额含税与否、重复单号。不要修改我的口径，也不要给最终数字。

输出样例

AI 应该输出到什么程度

下面是使用上面提示词后可能得到的结果形态。注意：这不是标准答案，只是一份需要你逐项确认的草案。

拿到这份草案后，你要做的不是直接照抄，而是回到第六步，用历史周报回测，并把“需要人工确认的问题”拿去问业务负责人。

一、字段映射表
- 支付订单数：来源字段“状态”，统计范围为“已支付”和“支付成功”；同时依赖“支付时间”判断是否属于本周。
- 支付金额：来源字段“订单金额”，筛选条件为“状态已支付或支付成功”且“支付时间在本周范围内”。
- 退款金额：来源字段“退款金额”，筛选条件为“状态为已退款”。
- 渠道分布：来源字段“渠道”。

二、筛选条件
- 支付时间边界：2026-07-27 00:00:00 至 2026-08-02 23:59:59（含端点）。
- 排除：TEST 开头的订单号、渠道为“内部测试”的订单、状态为“待支付”和“已取消”的订单。
- 需确认：“已支付”与“支付成功”是否合并统计。

三、统计口径
- 支付订单数：满足筛选条件的订单行数。
- 支付金额：满足筛选条件的“订单金额”合计。
- 退款金额：状态为“已退款”的“退款金额”合计。
- 渠道分布：按“渠道”字段分组，分别统计订单数和金额。

四、异常检查清单
- 空值：支付时间为空但状态为已支付的记录，需人工确认。
- 负数：订单金额或退款金额为负的记录，需人工确认。
- 重复单号：同一订单号出现多行时，需确认是否拆分订单。
- 未知状态：不在已知状态列表中的值，需列出原始值。
- 金额为零：已支付但金额为零或极小的记录，需确认是否测试单。
- 渠道名：同一渠道出现多种写法时，需确认标准名称。

五、需要人工确认的问题
1. “已支付”和“支付成功”是否同一口径。
2. “小红书”和“小红书-种草”是否合并。
3. TEST 开头的订单号是否全部属于测试单。
4. 退款单是否还保留在“支付订单数”里。

人工验收

人要怎么检查和改到可用

AI 助手给出的映射和规则再漂亮，也不等于口径正确。以下检查点是你必须在固定这套流程之前完成的：

第一，抽查原始数据。从导出文件里手工挑出 10 行，按筛选条件判断每一行该不该计入，再和 AI 助手的结果对照。重点看边界记录：周一 00:00 前支付、周日 23:59:59 后支付、支付时间为空、状态为“支付成功”的记录。

第二，和历史周报对账。用上周或上月的数字做一次完整回测。核心指标差异超过 5% 时，不要直接“以 AI 结果为准”，要找出差异来源。常见原因是时间边界不同、状态词漏了、退款单被算进支付金额。

第三，确认时间边界。检查你的后台导出文件里的时间是不是你所在时区的时间。如果系统存的是 UTC，导出后没有转换，周一 00:00 的边界会整体偏移。这个错误在手工统计时也容易犯，在固定流程里尤其要写清楚。

第四，确认状态和排除规则。把导出文件里出现的所有状态值列出来，逐一确认：哪些计入支付订单、哪些计入退款、哪些排除。不要只凭“看起来像”判断。测试单的识别规则也要确认：是按订单号前缀、渠道名、金额，还是某个专门字段。

第五，把草案转成自己工具里可执行的形式。AI 助手给的是文字规则，你需要把它变成表格软件里的筛选条件、透视表字段或脚本参数。转换时逐项对照字段名，防止列名对不上导致统计结果偏差。

第六，记录口径变更。任何一次口径调整，都要在流程文档里注明日期、变更内容和确认人。否则三个月后你会再次面对“上周 128 单、这周 131 单”的困惑。

失败反例

这些失败反例要提前避开

**反例 1：直接把完整导出文件丢给 AI，不给口径说明。** 看起来省事，实际最危险。AI 助手没有你的业务背景，会按它自己的理解猜时间边界、猜状态词、猜退款怎么算。结果通常是一份看起来很专业的统计规则，但里面每一个关键口径都是猜的。正确做法是先写口径清单，哪怕只有三行。

**反例 2：让 AI 用“近 7 天”或“本周”做筛选条件。** 这两个表达看起来没问题，但会随执行时间漂移：周二跑和周日跑，统计范围不一样；跨月跨年时尤其容易错。正确做法是使用固定的起止时间，并明确含不含端点。

**反例 3：把 AI 生成的公式直接覆盖原始列或原始文件。** 一旦覆盖，原始数据就找不回来了，后续想查“为什么这个数是 131”也无从下手。正确做法是始终保留原始导出文件，在副本或新列上加工，并在流程文档里写明数据来源文件。

**反例 4：漏掉退款单、取消单和测试单。** 如果“支付金额”里混进了已退款订单，或者测试单金额 0.01 元被算进订单数，周报数字就会虚高。正确做法是把状态值和排除规则逐项列出来，让异常检查清单专门盯这几类记录。

**反例 5：只让 AI 给最终数字，不要规则。** 这周拿到一个数，下周再算一遍，方法可能完全不一样，数字对不上也无从排查。正确做法是让 AI 先给字段映射、筛选条件、统计口径和异常检查，最终数字由你按规则算出来并留档。

主题边界

它和相邻主题的区别

这篇文章和“乱表清洗规则”不同：那篇文章解决的是字段混乱、合并单元格、空行和手写备注这类结构问题，重点在“把表变干净”；本文假设导出文件结构基本规整，重点在固定周期报表的取数口径和可复用加工流程。

它也不同于“两张表对不上”的对账文章：对账解决的是两个数据源之间的差异核对，本文只有一张导出表，解决的是这张表到周报指标之间的加工规则。

它更不是“周报怎么写”或“周报汇报”的文章：本文不教你组织汇报语言、突出亮点或包装进展，只负责把数字来源和计算规则固定下来。周报里的分析判断，仍然要由你结合业务情况完成。

最后，它和探索性的数据分析文章也不一样：数据分析通常从一个问题出发，尝试不同角度；本文处理的是每周重复、口径固定的任务，追求的是稳定、可追溯、可交接。