订单明细导出来很乱？先洗成周报能用的分析底表

教程定位

这篇教程解决什么问题

这篇文章解决一个很具体的问题：电商后台导出的订单明细不能直接拿来做销售额、件单价、退款率，因为里面常常混着合并单、退款单、测试单、赠品单、空白字段和口径不明的金额列。你要做的不是马上写周报，而是先把原始订单表洗成一张“能被透视表、BI 或 SQL 稳定读取”的订单分析底表。

读完以后，你会得到两样东西：第一，一份可以交给 AI 辅助整理的订单清洗规则清单；第二，一套适合周度分析的底表字段结构。AI 可以帮你识别字段含义、提出清洗逻辑、生成字段映射和异常检查清单，但它不能替你确认业务口径。尤其是退款是否按支付时间还是退款时间统计、合并单拆不拆、测试账号是否完整排除，都必须由运营或数据负责人抽样核验。

本文不讲周报怎么写，也不讲渠道归因、投放 ROI 或复购分析。这里只做一件事：把乱糟糟的订单导出表，整理成后续统计能放心使用的底表。

使用场景

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

周一上午 10 点，你准备做上周销售周报。后台导出的订单 CSV 打开后，看起来有几千行，字段很多：订单号、子订单号、商品名称、SKU、实付金额、商品金额、优惠金额、退款金额、订单状态、支付时间、发货时间、买家备注、收货人、账号标签。

你原本想直接透视“支付时间”和“实付金额”，但很快发现几个麻烦：

一笔合并支付订单下面有 3 个子订单，每行都显示同一个支付金额。直接汇总会把销售额算成 3 倍。

退款单有的在订单表里表现为“已退款”，有的只在退款明细表里出现。订单表里的退款金额还不一定是最终金额。

测试单没有统一标记，有些账号叫“测试买家 01”，有些是公司内部同事下的单，有些用的是门店备用账号。

商品数量为空的行，其实是套装拆分行；支付时间为空的行，有些是未付款，有些是历史导入异常。

如果这时直接问 AI：“帮我分析销售情况”，它很可能会在错误数据上写出一份看起来很完整的周报。问题不是 AI 不聪明，而是你还没有给它一张能分析的底表。正确做法是先让 AI 帮你把清洗口径写清楚，再由人抽样确认，然后按规则生成分析底表。

这篇文章适合电商运营、数据助理、店铺负责人，也适合临时接手周报的人。只要你的输入材料是订单导出 CSV、退款明细、测试账号名单、字段说明截图，就可以照着做。

材料准备

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

先准备四类材料。材料不需要完美，但要尽量放在同一个文件夹里，文件名清楚，方便你复制给 AI 或交给同事复核。

第一类是订单导出 CSV。至少包含订单号、子订单号、订单状态、商品 ID、SKU、商品数量、商品金额、优惠金额、实付金额、支付时间、下单时间、买家账号或买家 ID。不要只截几行图片给 AI，最好给字段名和 20 到 50 行脱敏样例。

第二类是退款明细。至少包含订单号、子订单号、退款单号、退款状态、申请退款金额、实际退款金额、退款完成时间。如果后台只有退款汇总，也要注明它是按订单号还是按子订单号汇总。

第三类是测试账号名单。它可以是一张很简单的表：账号 ID、账号昵称、是否内部测试、备注。注意不要给真实手机号和真实邮箱。可以用买家 ID、脱敏昵称或内部编号替代。

第四类是字段说明。很多后台字段名称相似，例如“商品总价”“应付金额”“实付金额”“结算金额”“退款金额”。如果有后台字段说明截图，把文字摘出来给 AI；如果没有，就让 AI 先根据样例推断，再把不确定项标出来，交给人工确认。

在开始清洗前，你还要先定 4 个口径问题：

1. 销售额按什么算：通常周报销售额建议使用“支付成功订单的实付金额”，但如果实付金额在子订单行重复，需要先去重或按子订单口径拆分。
2. 退款率按什么算：可以按“退款金额 / 支付销售额”，也可以按“退款订单数 / 支付订单数”。两者含义不同，本文只帮你把底表字段准备好，不替你决定业务口径。
3. 合并单怎么处理：如果一笔父订单包含多个子订单，要明确订单级金额只能保留一次，商品级金额可以按子订单或 SKU 行统计。
4. 测试单怎么排除：AI 可以帮你识别疑似测试单，但最终名单必须由人确认，不能只凭“昵称像测试”就删除。

实操流程

按这套步骤把工作跑起来

【第一步：先让 AI 读字段，不要急着让它做分析】

把订单表字段名、退款表字段名、测试账号字段名和少量样例行贴给 AI，让它先输出“字段理解表”。你要的不是结论，而是让它把每个字段可能代表什么、是否可用于统计、需要人工确认什么说清楚。

这一步特别重要。很多错误都出在字段名字看起来相近。例如“订单实付金额”可能是父订单金额，在每个子订单行重复；“商品实付金额”才是 SKU 行金额；“退款金额”可能是申请金额，不是实际到账退款。AI 如果没有先识别字段，就容易把重复列当成可加总列。

你可以要求 AI 把字段分成五类：主键字段、时间字段、金额字段、状态字段、辅助识别字段。主键字段用于去重和关联，时间字段用于周度筛选，金额字段用于销售额和退款率，状态字段用于排除未付款或取消单，辅助识别字段用于识别测试单、赠品单和异常行。

【第二步：定义底表粒度】

订单底表最容易混乱的地方是粒度。你必须先决定一行代表什么。

如果你的周报只看每日销售额、订单数和退款率，可以使用“订单级底表”：一行代表一个支付订单。它适合统计订单数、销售额、退款金额、退款率、件单价，但不适合直接分析 SKU 销量。

如果你的周报要看商品销量、SKU 销售额和类目表现，可以使用“子订单或 SKU 行级底表”：一行代表一个子订单商品行。它适合看商品维度，但订单级金额不能重复汇总。

本文建议先做一张“订单分析底表”，粒度是一行一个子订单商品行，同时保留订单级去重标记。这样后续既能按 SKU 透视，也能通过 `is_first_row_in_order` 避免订单级金额重复计算。

底表至少需要这些字段：

| 字段名 | 含义 | 统计用途 | 人工确认点 | | --- | --- | --- | --- | | order_id | 父订单号 | 订单去重、关联退款 | 是否存在合并支付 | | sub_order_id | 子订单号 | 商品行识别、关联退款 | 是否唯一 | | order_row_key | 行唯一键 | 防重复 | 可由订单号、子订单号、SKU 拼接 | | paid_at | 支付时间 | 周度筛选 | 空值是否代表未支付 | | order_status_clean | 清洗后订单状态 | 过滤有效订单 | 状态映射是否准确 | | sku_id | SKU 编号 | SKU 分析 | 空值是否为赠品或异常 | | product_name_clean | 清洗后商品名 | 商品透视 | 是否需要统一别名 | | quantity | 商品数量 | 件数、件单价 | 空值是否可填 1 | | item_paid_amount | 商品行实付金额 | SKU 销售额 | 是否含优惠分摊 | | order_paid_amount_once | 订单级实付金额 | 销售额 | 只在订单首行保留 | | refund_amount | 实际退款金额 | 退款率 | 以退款明细为准还是订单表为准 | | refund_completed_at | 退款完成时间 | 退款周期分析 | 统计周期是否按退款时间 | | is_test_order | 是否测试单 | 排除测试 | 名单由人工确认 | | is_valid_for_sales | 是否计入销售 | 销售统计过滤 | 规则需抽样核验 | | exclude_reason | 排除原因 | 留痕 | 不允许空泛写“异常” |

【第三步：让 AI 写清洗规则，而不是直接改原表】

你可以让 AI 基于字段理解和样例数据，输出规则清单。清洗规则要写得像操作说明，而不是一句“删除异常值”。每条规则至少包含：规则编号、适用字段、判断条件、处理动作、原因、是否需要人工确认。

例如：

| 规则编号 | 判断条件 | 处理动作 | 原因 | 人工确认 | | --- | --- | --- | --- | --- | | R01 | `paid_at` 为空且订单状态为“待付款” | `is_valid_for_sales=false`，排除销售统计 | 未完成支付 | 抽样确认状态含义 | | R02 | `buyer_id` 出现在测试账号名单 | 标记 `is_test_order=true`，排除销售和退款率统计 | 测试单不反映真实交易 | 测试账号名单需人工维护 | | R03 | 同一 `order_id` 多行重复出现同一订单级实付金额 | 只在订单第一行保留 `order_paid_amount_once` | 避免合并单销售额重复累加 | 抽样检查 10 个合并单 | | R04 | 退款表中同一子订单有“退款成功”记录 | 取实际退款金额写入 `refund_amount` | 退款口径以成功退款为准 | 检查部分退款和多次退款 | | R05 | 商品数量为空但订单已支付且 SKU 不为空 | 标记 `quantity_check_needed=true`，不自动填数 | 空值可能来自套装或导出异常 | 人工核验后再填 |

注意，AI 输出规则后不要马上执行。先让负责周报的人看一遍，尤其确认三件事：金额列是否选对、退款列是否选对、排除规则是否过度。确认之后再生成底表。

【第四步：生成清洗后的字段结构和异常清单】

在正式处理全量数据前，先让 AI 用样例数据跑一遍“预期输出”。你可以要求它输出两张表：一张是清洗后的底表样例，一张是异常待确认清单。

底表样例用于验证字段是否够用，异常清单用于提醒人工检查。比如测试账号、空支付时间、退款金额大于支付金额、同一子订单出现多笔成功退款、订单状态和退款状态冲突，都应该进入异常清单。

如果你使用电子表格，可以先在一个新 sheet 里建立底表字段；如果你使用数据库，可以先创建临时表；如果你只是做周报，也至少要保留“原始表”和“清洗后底表”两个版本，不要在原表上直接覆盖。

【第五步：人工抽样核验，再进入周报统计】

AI 的价值是加速识别规则和生成结构，不是替你承担数据口径责任。清洗规则完成后，至少做 5 类抽样：

只有抽样结果通过，才用这张底表去做销售额、件单价和退款率。抽样如果发现规则错了，回到规则清单修订，不要在周报里临时手改几个数字。手改数字最容易让下周复盘找不到原因。

1. 抽 10 个普通已支付订单，检查销售额是否只算一次。
2. 抽 10 个合并单，检查父订单金额是否没有重复累加。
3. 抽 10 个退款单，检查退款金额和退款完成时间是否来自正确表。
4. 抽 5 个测试账号订单，确认都被排除，且没有误伤真实买家。
5. 抽 5 个异常空值订单，确认是未付款、导出异常还是需要补字段。

输入示例

可以直接参考的输入材料

下面是一组脱敏样例。它不是完整数据，只是你可以粘给 AI 的材料格式。注意样例里没有真实手机号，也没有真实邮箱。

订单导出 CSV 样例：

退款明细样例：

测试账号名单样例：

字段说明摘录样例：

你还可以补充业务口径：

order_id,sub_order_id,buyer_id,buyer_name,order_status,created_at,paid_at,product_name,sku_id,quantity,item_list_price,item_discount_amount,order_paid_amount,item_paid_amount,receiver_masked,remark
O202606240001,SO202606240001-1,B10001,普通买家A,已支付,2026-06-24 09:10:22,2026-06-24 09:12:03,防晒喷雾 150ml,SKU-SPRAY-150,2,158.00,20.00,236.00,138.00,华东-***,常规订单
O202606240001,SO202606240001-2,B10001,普通买家A,已支付,2026-06-24 09:10:22,2026-06-24 09:12:03,晒后修护凝胶,SKU-GEL-80,1,118.00,20.00,236.00,98.00,华东-***,合并支付子订单
O202606250018,SO202606250018-1,T90001,测试账号01,已支付,2026-06-25 14:01:09,2026-06-25 14:02:11,洁面乳 100g,SKU-CLEAN-100,1,69.00,0.00,69.00,69.00,内部-***,测试流程
O202606260033,SO202606260033-1,B10027,普通买家B,已退款,2026-06-26 20:33:41,2026-06-26 20:35:02,精华液 30ml,SKU-SERUM-30,1,199.00,30.00,169.00,169.00,华南-***,申请退款
O202606270041,SO202606270041-1,B10039,普通买家C,待付款,2026-06-27 11:20:00,,面膜 5片装,SKU-MASK-5,1,59.00,0.00,0.00,0.00,华北-***,未支付
O202606280052,SO202606280052-1,B10052,普通买家D,已支付,2026-06-28 16:18:17,2026-06-28 16:19:09,旅行套装,SKU-SET-TRAVEL,,129.00,10.00,119.00,119.00,西南-***,数量为空需确认

refund_id,order_id,sub_order_id,refund_status,refund_apply_amount,refund_actual_amount,refund_completed_at,refund_reason
R20260626003301,O202606260033,SO202606260033-1,退款成功,169.00,169.00,2026-06-27 10:12:45,买家不想要
R20260624000101,O202606240001,SO202606240001-2,退款中,98.00,0.00,,买家申请部分退款
R20260625001801,O202606250018,SO202606250018-1,退款成功,69.00,69.00,2026-06-25 14:20:03,测试退款

buyer_id,buyer_name_masked,test_type,owner,valid_until,note
T90001,测试账号01,内部流程测试,运营组,2026-12-31,用于下单退款链路演练
T90002,门店备用测试号,门店测试,门店组,2026-12-31,不计入销售

order_paid_amount：订单实付金额，父订单维度。同一父订单下多子订单时，该金额可能在每个子订单行重复展示。
item_paid_amount：商品行实付金额，已分摊优惠，可用于 SKU 行销售额统计。
order_status：订单当前状态，包含待付款、已支付、已发货、已完成、已关闭、已退款。
refund_actual_amount：实际退款金额，只有退款成功后才有最终金额。
paid_at：支付完成时间，未付款订单为空。

本次周报统计 2026-06-24 至 2026-06-30 支付成功的订单。
销售额优先使用 order_paid_amount，但父订单金额只能计一次。
商品销售额使用 item_paid_amount。
退款金额以退款明细表中“退款成功”的 refund_actual_amount 为准。
测试账号名单中的订单不进入销售额、订单数、退款率统计。
数量为空的已支付订单不能自动填 1，需要进入异常清单。

提示词

可复制使用的提示词

你可以把下面这段提示词复制给 AI，再把自己的字段和样例数据贴进去。

如果你希望 AI 顺便给出电子表格公式，可以追加：

如果你希望 AI 给出 SQL 思路，可以追加：

你是电商数据清洗助手。请帮我把后台导出的订单明细整理成一张可用于周报统计的订单分析底表。

目标：
1. 不写周报，不做渠道归因，只做订单明细清洗规则和底表字段结构。
2. 底表要支持统计销售额、订单数、件单价、退款金额、退款率。
3. 请先识别字段含义，再输出清洗规则，不要直接给经营结论。
4. 所有涉及金额口径、退款口径、测试单排除的地方，都要标注“需要人工确认”。

输入材料：
【订单导出字段和样例】
粘贴订单 CSV 字段名和 20-50 行脱敏样例。

【退款明细字段和样例】
粘贴退款 CSV 字段名和脱敏样例。

【测试账号名单】
粘贴 buyer_id 或账号编号，不要包含真实手机号或真实邮箱。

【字段说明】
粘贴后台字段说明或人工整理的说明。

【业务口径】
本次统计周期：
销售额口径：
退款口径：
合并单处理方式：
测试单处理方式：

请按以下结构输出：

一、字段理解表
- 字段名
- 推断含义
- 字段类别：主键 / 时间 / 金额 / 状态 / 商品 / 辅助识别
- 是否可直接用于统计
- 风险说明
- 需要人工确认的问题

二、推荐底表粒度
- 建议一行代表什么
- 为什么适合本次周报统计
- 哪些指标可以直接统计
- 哪些指标不能直接统计

三、清洗规则清单
每条规则包含：规则编号、判断条件、处理动作、影响字段、原因、人工检查点。
请至少覆盖：合并单金额去重、退款明细关联、测试单排除、未付款订单排除、空白字段处理、重复子订单检查、退款金额异常检查。

四、清洗后底表字段结构
输出字段名、字段类型、来源字段、生成逻辑、用途、是否需要人工确认。

五、基于样例数据的 AI 输出样例
请用我给的样例数据生成 5-8 行清洗后底表，并单独列出异常待确认清单。

六、人工抽样核验清单
请列出运营或数据助理在正式使用前必须抽查的项目。强调 AI 的清洗建议不能替代人工核验。

如果适合用电子表格处理，请补充辅助列建议和公式思路。但不要假设我的表格软件支持特殊插件，也不要输出需要真实密钥或外部 API 的方案。

如果适合用 SQL 处理，请补充临时表设计和伪 SQL。请保持字段名通用，不要连接真实数据库，不要要求我提供密钥。

输出样例

AI 应该输出到什么程度

下面是一段使用上方提示词后，AI 可能输出的结果。它是“初稿”，不是最终规则。你仍然要人工抽样核验。

【一、字段理解表节选】

| 字段名 | 推断含义 | 字段类别 | 是否可直接统计 | 风险说明 | 需要人工确认的问题 | | --- | --- | --- | --- | --- | --- | | order_id | 父订单号 | 主键 | 可用于订单去重 | 多个子订单共享同一父订单号 | 是否所有合并支付都用该字段表示 | | sub_order_id | 子订单号 | 主键 | 可用于商品行识别 | 可能与 SKU 不是一一对应 | 是否存在一个子订单多 SKU | | paid_at | 支付时间 | 时间 | 可用于筛选支付周期 | 空值代表未支付或异常导出 | 空值订单是否全部排除 | | order_paid_amount | 父订单实付金额 | 金额 | 不可直接逐行加总 | 合并单下会重复 | 订单销售额是否以该字段为准 | | item_paid_amount | 商品行实付金额 | 金额 | 可用于 SKU 行销售额 | 需确认是否已分摊优惠 | 是否存在赠品行金额为 0 | | refund_actual_amount | 实际退款金额 | 金额 | 可用于退款金额 | 只应取退款成功记录 | 多次退款是否累加 | | buyer_id | 买家编号 | 辅助识别 | 不直接统计 | 可用于测试单排除 | 测试账号名单是否完整 |

【二、推荐底表粒度】

建议底表采用“子订单商品行级”：一行代表一个子订单商品行，并增加订单级金额去重字段 `order_paid_amount_once`。这样可以同时支持两类统计：

| 指标 | 统计方式 | | --- | --- | | 销售额 | 对 `is_valid_for_sales=true` 的行汇总 `order_paid_amount_once` | | 订单数 | 对 `is_valid_for_sales=true` 的行去重统计 `order_id` | | 商品销售额 | 汇总 `item_paid_amount` | | 件数 | 汇总 `quantity`，但排除 `quantity_check_needed=true` 的异常行 | | 件单价 | 商品销售额 / 件数，或销售额 / 订单数，需先确认定义 | | 退款金额 | 汇总退款成功记录中的 `refund_amount` | | 退款率 | 退款金额 / 销售额，或退款订单数 / 支付订单数，需人工确认 |

不建议直接使用原订单导出表逐行汇总 `order_paid_amount`，因为合并单 `O202606240001` 在两行都显示 236.00，直接求和会得到 472.00，实际父订单支付金额应只计 236.00。

【三、清洗规则清单】

| 规则编号 | 判断条件 | 处理动作 | 影响字段 | 原因 | 人工检查点 | | --- | --- | --- | --- | --- | --- | | R01 | `paid_at` 为空，且 `order_status` 为“待付款” | `is_valid_for_sales=false`，`exclude_reason=未支付` | `is_valid_for_sales`, `exclude_reason` | 未完成支付不进入销售统计 | 抽样确认空支付时间没有已支付异常单 | | R02 | `buyer_id` 出现在测试账号名单 | `is_test_order=true`，`is_valid_for_sales=false`，`exclude_reason=测试单` | `is_test_order`, `is_valid_for_sales` | 测试订单不反映真实销售 | 名单必须由人工确认，不要只靠昵称判断 | | R03 | 同一 `order_id` 出现多行，且 `order_paid_amount` 相同 | 每个 `order_id` 仅第一行写入 `order_paid_amount_once`，其他行写 0 | `order_paid_amount_once` | 防止父订单金额重复累加 | 抽查合并单，确认第一行规则稳定 | | R04 | 退款表存在同一 `sub_order_id` 且 `refund_status=退款成功` | 将 `refund_actual_amount` 写入 `refund_amount`，多笔成功退款按子订单累加 | `refund_amount`, `refund_completed_at` | 退款金额以成功退款为准 | 抽查部分退款、多次退款 | | R05 | `order_status` 为“已关闭”或“已取消” | 排除销售统计 | `is_valid_for_sales`, `exclude_reason` | 未形成有效交易 | 确认后台是否有“已关闭但已支付后退款”的特殊状态 | | R06 | `quantity` 为空但订单已支付 | 标记 `quantity_check_needed=true`，不自动补 1 | `quantity_check_needed` | 空数量可能来自套装或导出异常 | 人工确认后再修复数量 | | R07 | `refund_amount` 大于 `order_paid_amount_once` 或对应商品行实付金额 | 加入异常清单，不自动修改金额 | `exception_flag` | 可能存在多次退款、运费退款或字段口径不同 | 需要查后台原单 | | R08 | `sub_order_id` 重复且 SKU 不同 | 加入异常清单 | `exception_flag` | 可能是一子订单多商品或导出重复 | 确认唯一键应否加入 SKU |

【四、清洗后底表字段结构节选】

| 字段名 | 类型 | 来源字段 | 生成逻辑 | 用途 | 是否需人工确认 | | --- | --- | --- | --- | --- | --- | | order_row_key | 文本 | order_id, sub_order_id, sku_id | 拼接生成唯一行键 | 防重复、追踪 | 是 | | paid_date | 日期 | paid_at | 取支付时间日期部分 | 周度筛选 | 否 | | order_status_clean | 文本 | order_status | 映射为 paid / unpaid / closed / refunded | 统一状态 | 是 | | order_paid_amount_once | 数值 | order_paid_amount | 每个 order_id 仅首行保留金额 | 销售额 | 是 | | refund_amount | 数值 | refund_actual_amount | 仅关联退款成功记录 | 退款金额 | 是 | | is_test_order | 布尔 | buyer_id, 测试名单 | 命中测试名单为 true | 排除测试 | 是 | | is_valid_for_sales | 布尔 | 多字段 | 已支付、非测试、非取消 | 销售统计过滤 | 是 | | exclude_reason | 文本 | 规则生成 | 记录排除原因 | 审计留痕 | 是 |

【五、基于样例数据的清洗后底表】

| order_row_key | order_id | sub_order_id | paid_date | sku_id | quantity | item_paid_amount | order_paid_amount_once | refund_amount | is_test_order | is_valid_for_sales | exclude_reason | exception_flag | | --- | --- | --- | --- | --- | ---: | ---: | ---: | ---: | --- | --- | --- | --- | | O202606240001-SO202606240001-1-SKU-SPRAY-150 | O202606240001 | SO202606240001-1 | 2026-06-24 | SKU-SPRAY-150 | 2 | 138.00 | 236.00 | 0.00 | false | true | | | | O202606240001-SO202606240001-2-SKU-GEL-80 | O202606240001 | SO202606240001-2 | 2026-06-24 | SKU-GEL-80 | 1 | 98.00 | 0.00 | 0.00 | false | true | | 退款中未计入成功退款 | | O202606250018-SO202606250018-1-SKU-CLEAN-100 | O202606250018 | SO202606250018-1 | 2026-06-25 | SKU-CLEAN-100 | 1 | 69.00 | 0.00 | 69.00 | true | false | 测试单 | 测试单退款不进退款率 | | O202606260033-SO202606260033-1-SKU-SERUM-30 | O202606260033 | SO202606260033-1 | 2026-06-26 | SKU-SERUM-30 | 1 | 169.00 | 169.00 | 169.00 | false | true | | 已退款订单，销售和退款口径需确认 | | O202606270041-SO202606270041-1-SKU-MASK-5 | O202606270041 | SO202606270041-1 | | SKU-MASK-5 | 1 | 0.00 | 0.00 | 0.00 | false | false | 未支付 | paid_at 为空 | | O202606280052-SO202606280052-1-SKU-SET-TRAVEL | O202606280052 | SO202606280052-1 | 2026-06-28 | SKU-SET-TRAVEL | | 119.00 | 119.00 | 0.00 | false | true | | quantity 为空，需人工确认 |

【六、异常待确认清单】

| 异常类型 | 涉及订单 | 原因 | 建议人工动作 | | --- | --- | --- | --- | | 合并单金额去重 | O202606240001 | 父订单金额在两行重复展示 | 查后台原单，确认 236.00 为整单实付 | | 退款中未计入 | O202606240001 / SO202606240001-2 | 退款明细状态为退款中，实际退款金额为 0 | 下次刷新数据时更新，不计入当前成功退款 | | 测试单排除 | O202606250018 | buyer_id 命中测试名单 | 确认测试名单有效期和归属 | | 已退款订单口径 | O202606260033 | 订单已退款，但支付和退款都发生在统计周期附近 | 确认周报销售额是否仍按支付订单计入 | | 数量为空 | O202606280052 | 已支付订单商品数量为空 | 查商品后台或原订单，不能自动填 1 |

这个输出样例已经能帮助你发现关键风险，但还不能直接成为最终底表。正式处理全量数据前，必须由人抽样检查原订单页面、退款页面和测试账号名单。AI 可能不知道后台字段是否改版，也可能把“退款中”误解成“已退款”，更不可能知道你们公司内部临时测试账号有没有漏登。

人工验收

人要怎么检查和改到可用

AI 给出的清洗建议要经过人工检查，尤其是以下几类。

【1. 检查金额列是不是选对了】

打开 3 到 5 个合并支付订单，对照后台订单详情，确认 `order_paid_amount` 是否为父订单金额，`item_paid_amount` 是否为商品行金额。如果父订单金额在每个子订单行重复展示，底表里必须使用 `order_paid_amount_once` 这种去重字段，不能直接汇总原列。

还要确认优惠是否已经分摊。比如一个父订单付了 236.00，两件商品行分别是 138.00 和 98.00，两者相加正好等于 236.00，说明商品行金额可用于 SKU 销售额。如果商品行金额相加不等于父订单金额，需要检查是否有运费、优惠券、积分、赠品或四舍五入差异。

【2. 检查退款口径是不是可复现】

退款最容易出错。订单表里的“已退款”状态只是状态，不等于最终退款金额。退款表里的申请金额也不一定等于实际退款金额。建议把退款相关字段拆开：申请退款金额、实际退款金额、退款状态、退款完成时间。

如果做“本周支付销售额对应的退款率”，你可能要把本周支付订单后续发生的退款也追踪起来。如果做“本周发生退款金额占本周销售额”，则需要按退款完成时间筛选。本文不替你决定采用哪一种，但底表必须保留支付时间和退款完成时间，避免以后无法切换口径。

【3. 检查测试单排除有没有误伤】

AI 可以根据账号名单标记测试单，但不要让它凭买家昵称自由发挥。昵称里包含“测试”不一定就是测试单，真实买家也可能写了类似备注；内部账号也可能没有明显名字。正确做法是维护一张测试账号名单，以 `buyer_id` 或内部账号编号为准。

如果发现临时测试账号没有进入名单，应先补充名单，再重新跑规则。不要只在结果表里删除某几行，否则下周同一账号又会混进来。

【4. 检查空值处理是否保守】

空白字段不应该被 AI 自动“脑补”。`paid_at` 为空通常意味着未付款，但也可能是历史数据导入异常；`quantity` 为空可能是套装拆分，也可能是后台导出问题；`sku_id` 为空可能是赠品，也可能是手工订单。

保守做法是：影响金额和件数的空值先进入异常清单，经过人工确认后再补。能用规则补的，也要在 `fix_reason` 或 `exclude_reason` 里留下原因。

【5. 检查底表是否保留追溯字段】

清洗后的底表不要只留下“干净指标”。至少保留原始订单号、子订单号、SKU、支付时间、退款单号、测试标记、排除原因。后续如果周报数字被质疑，你可以追溯到原始订单，而不是只说“AI 清洗过”。

【6. 检查规则是否可以下周复用】

如果本周规则里出现大量“手动删除这一行”“把这个数字改成 0”，说明规则还不够稳定。尽量把人工判断沉淀成可复用字段，例如新增测试账号名单、新增状态映射表、新增异常类型，而不是散落在结果表里。

失败反例

这些失败反例要提前避开

下面这些反例都很常见。它们看起来省时间，但会让周报数字变得不可解释。

【反例 1：直接汇总订单表里的实付金额】

错误做法：把原订单导出表按支付时间筛选后，直接对 `order_paid_amount` 求和。

为什么错：合并单下同一个父订单金额可能在多行重复展示。样例中的 `O202606240001` 有两个子订单，每行都显示 236.00。如果逐行求和，销售额会多算 236.00。

正确做法：先判断 `order_paid_amount` 是父订单金额还是行级金额。若是父订单金额，则生成 `order_paid_amount_once`，每个 `order_id` 只计一次。

【反例 2：把“退款中”当成“已退款”】

错误做法：只要退款表里出现退款记录，就把申请金额计入退款金额。

为什么错：退款中可能失败，也可能金额变更。样例中 `SO202606240001-2` 申请退款 98.00，但实际退款金额为 0，完成时间为空。把它计入本周退款，会提前夸大退款率。

正确做法：只把 `refund_status=退款成功` 且实际退款金额有值的记录计入 `refund_amount`。退款中进入异常或跟踪清单。

【反例 3：让 AI 根据昵称删除测试单】

错误做法：提示 AI “帮我删除看起来像测试的订单”，然后它把买家名包含“测试”“demo”“内部”的行都删掉。

为什么错：昵称不是可靠依据。真实买家可能使用类似名称，内部账号也可能没有明显特征。AI 不知道你们最新测试账号名单。

正确做法：用测试账号名单关联 `buyer_id`。疑似测试单可以进入待确认清单，但不能自动删除。

【反例 4：空数量自动填 1】

错误做法：看到 `quantity` 为空，就让 AI 全部填成 1。

为什么错：数量为空可能是套装行、赠品行、导出异常或拆单异常。自动填 1 会影响件数、件单价和 SKU 销量。

正确做法：已支付且金额不为 0 的空数量行先标记 `quantity_check_needed=true`，抽样查原订单后再决定补值规则。

【反例 5：清洗后不保留排除原因】

错误做法：清洗结果只保留有效订单，把未付款、测试单、取消单直接删掉。

为什么错：周报复盘时无法解释为什么订单数变少，也无法检查是否误删。下周更换同事接手时，只能重新猜规则。

正确做法：保留 `is_valid_for_sales`、`is_test_order`、`exclude_reason`、`exception_flag`。统计时过滤，追溯时可查。

【反例 6：销售额和退款率使用不同排除口径】

错误做法：销售额排除了测试单，但退款金额没有排除测试单退款；或者订单数排除了未付款，退款订单数却把取消单也算进去。

为什么错：分子分母口径不一致，退款率会失真。样例中的测试单 `O202606250018` 有成功退款，如果销售额排除测试单但退款额保留这 69.00，退款率会被抬高。

正确做法：给底表增加统一过滤字段。用于销售额、订单数、退款率的过滤条件要写在规则清单里，并抽样验证。

【反例 7：用清洗后的底表覆盖原始文件】

错误做法：在原始 CSV 上直接删除行、改金额、填空值，然后保存。

为什么错：一旦发现清洗规则有误，你无法回到原始状态，也无法解释某个数字从哪里来。

正确做法：保留原始文件只读，另存清洗底表。底表里保留原始主键和清洗标记。规则调整时重新生成底表。

【反例 8：让 AI 顺手写周报结论】

错误做法：在数据还没抽样核验前，让 AI 根据样例输出“本周销售增长明显、退款率可控”。

为什么错：样例数据不代表全量数据，清洗规则也没验证。此时写经营结论会把错误口径包装成正式判断。

正确做法：本步骤只输出清洗规则、底表结构、异常清单和人工核验清单。周报表达和经营判断放到下一步。

主题边界

它和相邻主题的区别

这篇文章只处理“原始订单表清洗”。它的边界很清楚：输入是订单导出 CSV、退款明细、测试账号名单和字段说明；输出是清洗规则清单、异常检查清单和可透视分析的订单底表字段结构。

它不是“写销售周报”的文章。销售周报会关心本周销售变化、爆品、退款原因、下周动作，而本文只保证周报所依赖的底表口径清楚。

它也不是“渠道归因分析”的文章。渠道归因会处理来源渠道、广告计划、达人 ID、优惠券归属和成交路径，而本文不讨论订单来自哪里，只处理订单本身能不能被正确统计。

它也不是“退款原因复盘”的文章。退款复盘会看退款原因、客服备注、商品质量、物流时效和售后话术；本文只把退款金额、退款状态和退款完成时间整理到底表里，保证退款率统计有字段基础。

它也不是“自动化报表搭建”的文章。自动化报表要考虑定时任务、数据库同步、权限、仪表盘刷新和告警；本文停在本地或表格层面的清洗规则与底表结构，不要求读者接入系统。

最后再强调一次：AI 可以帮助你更快写出清洗建议，发现合并单、退款单、测试单和空白字段的风险；但 AI 输出不是数据口径的最终裁判。正式用于周报前，一定要由人工抽样核验原订单、退款明细和测试账号名单。核验通过后，这张订单底表才算真正“能分析”。