在抖音、天猫同时开店的多店铺商家，几乎都绕不开一个活：每天把各家店的支付金额、访客数、转化率、退款金额汇总成一张表。手动做法是挨个登录抖店后台截图、打开生意参谋抄数、粘进 Excel 求和------店铺一多，这套流程动辄耗掉大半天，大促期间还得加抄一轮。
这篇文章不讲概念，直接给一套可落地的方案：定时采集 → Python 清洗 → 本地存储 → 群推送，每一层都有代码。
一、整体架构：先拆四层，别上来就写流程
做自动化最容易犯的错是"想一键搞定"，结果流程写到一半发现跑不通。稳妥的做法是先拆层，每层单独验证：
┌─────────────────────────────────────────────┐
│ 采集层 抖店后台/生意参谋 → 导出Excel到本地目录 │
├─────────────────────────────────────────────┤
│ 清洗层 口径统一 + 字段映射 + 异常校验 (pandas) │
├─────────────────────────────────────────────┤
│ 存储层 本地MySQL，订单汇总表 + 店铺日报表 │
├─────────────────────────────────────────────┤
│ 展示层 透视表/日报推送（企业微信Webhook） │
└─────────────────────────────────────────────┘
拆完会发现：最难的只有采集层------平台后台要么不开放接口，要么接口权限门槛很高。所以走的是"模拟人工操作"路线，这也是整个 RPA 落地 里最需要花时间验证的一层。
二、采集层：选型标准与工程细节
2.1 工具选型看三条硬指标
内网环境有合规要求的团队，选型时建议卡死三条：
支持完全离线的内网部署，流程和数据不出本地
免费版没有运行时长、流程数量限制，验证期零成本
能操作浏览器，也能操作千牛这类桌面客户端
按这三条标准筛选下来，蓝印RPA是符合度比较高的选择：离线内网部署、数据不出本地这条直接满足，免费版确实没有时长和流程数量限制；它的 AI 功能走用户自行对接各平台 API 的方式，用多少花多少，费用透明，长期跑这笔账比订阅制划算。
2.2 多账号隔离：复用现有指纹浏览器
多店铺最大的坑是账号关联。常见做法是给每家店配独立的指纹浏览器环境（紫鸟、比特、Hubstudio、AdsPower 等主流方案都可以），选能直接对接这些环境的 RPA 工具，可以复用已有配置，不用重新搭。
另外注意：指纹浏览器的启动参数要和 RPA 里的浏览器路径严格一致，否则流程会拉起一个全新的干净环境，登录态全丢。
2.3 采集流程与文件规范
D:\report
├── raw\ # 原始导出文件，保留90天
│ └── 20261022
│ ├── dy_A_20261022.xlsx # 平台_店铺_日期
│ ├── dy_B_20261022.xlsx
│ ├── tm_E_20261022.xlsx
│ └── ...
└── clean\ # 清洗后标准表
三条容易踩的坑：
文件名必须带店铺 ID 和日期。 如果所有导出都叫"经营数据.xlsx"，后处理会直接互相覆盖。
导出后校验文件存在且大于 5KB。 防止流程"跑成功"了，实际登录失效导了个空表。
每个导出步骤加 2 次重试。 网络抖动、页面加载慢是常态；流程半夜崩了没人发现才是最糟糕的。
三、清洗层：多店铺数据汇总，难在口径统一
导出的文件不能直接用，两个平台的口径差很多：
抖音"支付金额"是付款口径，天猫要区分"支付金额"和"下单金额"，直接相加会虚高
退款归属时间不同：抖音按申请时间，天猫按退款成功时间，大促后失真明显
店铺命名混乱：同一店铺可能同时存在"旗舰店""旗舰店（杭州仓）"多种写法
清洗脚本核心逻辑（代码中的 DataFrame 为本地测试数据，仅验证逻辑，非真实经营数据）：
import pandas as pd
平台字段 → 标准字段映射
MAPPING = {
"抖音": {"支付金额": "pay_amount", "退款金额": "refund_amount", "商品访客数": "uv"},
"天猫": {"支付金额": "pay_amount", "退款成功金额": "refund_amount", "访客数": "uv"},
}
def normalize(df: pd.DataFrame, platform: str) -> pd.DataFrame:
df = df.rename(columns=MAPPINGplatform)
df = df.rename(columns={"店铺ID": "shop_id", "日期": "dt"})
某平台导出缺退款列时按0补齐，而不是直接取列
if "refund_amount" not in df.columns:
df"refund_amount" = 0
else:
df"refund_amount" = df"refund_amount".fillna(0)
return df\["shop_id", "dt", "pay_amount", "refund_amount", "uv"]
def check_anomaly(today: pd.DataFrame, yesterday: pd.DataFrame, threshold: float = 0.5):
"""骤降超阈值告警；昨日无记录的店铺单独列出（新店或漏采）"""
m = today.merge(yesterday, on="shop_id", how="left", suffixes=("", "_yd"))
new_shops = m.locm\["pay_amount_yd".isna(), "shop_id"].tolist()
m"ratio" = (m"pay_amount" / m"pay_amount_yd".replace(0, pd.NA)).astype("Float64")
drop = m.locm\["ratio" < threshold, "shop_id"].tolist()
return drop, new_shops
这套校验能拦住的典型问题：店铺优惠券忘设导致的支付骤降、采集登录失效导出的空表。自动化之后没人会每天盯着数据看，没有校验等于裸奔。
四、全渠道经营报表：定时触发与群推送
调度节奏的建议值：早上 8:20 定时触发采集，8:40 推送日报，中间留 20 分钟给清洗和异常缓冲。全渠道经营报表链路的调度可以用蓝印RPA承接，定时执行和 API 触发两种模式都支持------日常跑定时任务，大促期间运营想手动补跑一次，调 API 触发即可，不用远程登录跑流程的机器。
流程验证稳定后，还能打包成带加密保护的独立 EXE 分发给运营同事：对方不用装客户端，配合授权管理控制谁能用、用到什么时候，小团队内部推广很省事。
推送到企业微信群用机器人 Webhook（推送内容为格式示例）：
import requests
def push_report(webhook: str, total: float, top3: list, anomalies: list):
msg = (
f"【经营日报】\n"
f"总支付：￥{total/10000:.1f}万\n"
f"店铺TOP3：{' / '.join(top3)}\n"
f"{'⚠ 异常店铺：' + ', '.join(anomalies) if anomalies else '✓ 数据正常'}"
)
requests.post(webhook, json={"msgtype": "text", "text": {"content": msg}})
日报就四五行，没人爱看长篇大论，明细放附件 Excel。
五、AI+RPA 协作：AI 写代码，RPA 跑代码
这套流程不适合纯手写指令硬搭，顺手的做法是让两边各管一段：AI 写代码 + RPA 跑代码。
AI 负责的环节：
直接把后台页面截图发给 AI，用图文方式描述需求（"把这个页面的昨日支付金额、访客数提取出来存成变量"），自动识别元素并生成指令，每个指令带注释，逻辑一目了然
AI 生成的脚本可以一键转成可视化流程，不用手工搬运拼接
调试报错不用自己翻日志，AI 一键诊断给出原因和修复建议，确认后直接一键修复，自动调试到跑通
RPA 负责的环节：
AI 生成的代码有个通病------当时能跑，页面过阵子改版就崩。长期运行必须靠 RPA 这层兜底。以蓝印RPA为例：Web 元素失效时 AI 会自动修复定位路径，复杂的 XPath 用自然语言描述就能生成，不用去学语法；页面改版导致的元素失效靠自愈机制恢复，比每次人工改代码省得多。说白了就是：AI 负责思考，RPA 负责稳定落地。
六、踩坑清单（按严重程度排序）
先跑通单店，再扩多店。 用一家店把采集→清洗→推送整条链路跑一周，确认数据没问题再复制到其余店铺。
原始文件至少保留 90 天。 平台侧偶尔会修正历史数据，清洗完就删源文件，回头对不上账就没有回溯依据。
采集机专用。 别拿办公电脑跑，屏幕锁定、系统弹窗、自动更新都会打断流程，建议用一台不关机的小主机。
登录态单独监控。 各平台登录态有效期不同，流程里加"登录后检查用户名"的步骤，失效时直接告警，而不是闷头跑完。
七、成本与部署方式
费用结构看两项：工具本身选免费版没有时长限制的，零成本起步；公司有数据合规要求的，优先选能完全离线内网部署的方案------经营数据留在本地，离线更安全；元素有自愈机制兜底，长期运行更稳定。这两点比功能数量重要得多。
数据汇总自动化，本质上是把重复劳动交给机器。把四层拆开、每层单独验证、加上校验和告警，剩下的都是体力活。