單一 RPA 機械人自動彙總淘寶、天貓、拼多多及抖店 8 家店舖報表的實踐

2026-11-03 11

版权

版权声明：

本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《 阿里云开发者社区用户服务协议》和 《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写 侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。

简介： 本文介绍团队如何用单个RPA机器人自动化8家跨平台店铺（淘宝/天猫/拼多多/抖店）的日报汇总与跨店对账。涵盖配置驱动六层架构、AI自愈定位、视觉兜底、全离线内网部署、EXE加密授权及AI+RPA协同开发等实践，兼顾效率、稳定与数据安全。

一个团队同时维护淘宝、天猫、拼多多、抖店共 8 家店铺时，每日报表汇总和跨店对账是最消耗人力的环节。本文记录我们用单个 RPA 机器人把这件事自动化落地的完整过程，包括任务队列设计、平台字段映射、Web 元素 AI 自愈、视觉颜色操作兜底、全离线内网部署、EXE 加密打包与授权管理等内容。流程只处理企业已授权账号和本地导出文件，遵守各平台规则。
一、背景：难的不是数据量，是口径
团队运营的 8 家店铺分布在淘宝、天猫、拼多多、抖店四个平台。每天上午运营要汇总前一日的订单量、退款量、推广消耗和结算金额，每周还要做一次跨店对账，核对平台结算单和实际到账的差异。
人工做这件事的痛苦很具体：
每家后台的导出入口、筛选项、报表命名都不一样，来回切换容易导错店、导错日期；
同一份"成交金额"，在订单表、结算表、推广报表里口径不同；
退款跨天、优惠分摊、运费险、赠品成本，靠人脑算一遍错一遍；
平台页面不定期改版，写死的按钮路径一失效，脚本全停；
经营数据里有毛利和投放信息，谁都不想把它传上第三方云端。
目标定得比较务实：单机器人并行 8 店铺，按队列逐个处理，每家店跑完留下原始文件、运行日志和状态标记，任何一步出错都能定位到具体店铺、时间段和字段。 不追求无人值守，追求可追溯。
二、架构：配置驱动的六层流水线
先把"店铺"从流程代码里抽出来，抽象成配置，再谈自动化。整体链路用一张图说明：

┌──────────┐ ┌──────────┐ ┌──────────────┐ ┌──────────────┐ ┌──────────┐ ┌──────────────┐
│ 店铺配置表 │ → │ 任务队列 │ → │ 浏览器环境隔离 │ → │ 导出与原始留痕 │ → │ 字段映射层 │ → │ 汇总宽表与日报 │
└──────────┘ └──────────┘ └──────────────┘ └──────────────┘ └──────────┘ └──────────────┘
店铺配置表是地基，每店一行：平台、店铺名、登录环境标识、报表类型、日期口径、保存目录、命名规则、负责人、最大重试次数、启用状态。
任务队列由机器人循环消费：取出店铺任务 → 校验登录态 → 确认当前店铺身份 → 执行导出 → 本地校验 → 写回状态 → 取下一个。同平台店铺共用一套页面模板，差异项用配置参数覆盖。新增第 9 家店，多数情况下只需在配置表加一行。
环境隔离是容易被低估的一环。8 家店如果共用一个浏览器环境，轻则下载文件互相覆盖，重则会话串店——导出来的数据是 A 店的，文件名却是 B 店的，对账时根本发现不了。我们的做法是每个店铺绑定独立指纹环境和独立下载目录。市面主流指纹浏览器比如紫鸟、比特浏览器、Hubstudio、AdsPower 都支持这种方式接入，机器人只管"启动指定环境、执行动作、关闭环境"，不关心环境内部实现。
三、原始留痕与字段映射
对账流程铁律：原始导出件永远不覆盖、不修改。 命名规范：
平台店铺报表类型日期批次号.xlsx
汇总宽表只记录原始文件路径、导入时间和校验结果。出现金额争议时回到原始文件逐行核对，而不是在二手数据里找问题。
四个平台字段名各不相同，直接拿原始字段汇总必错。中间加一层映射，统一成宽表：

映射层由运营负责人维护，每列标注口径说明和最近确认日期。规则变了只改映射表，不动流程。这张表后来成了团队里被查阅次数最多的文档——"这笔钱到底怎么算的"，答案只在这里。
四、幂等、去重与失败隔离
跨天退款、重复导出、人工补跑是常态，流程里做三层防护：
文件层：同一店铺同一天同一批次不重复导入；
订单层：以"平台 + 店铺 + 子订单号"为唯一键去重；
金额层：汇总结果与平台结算单比对，差异超过阈值自动标记人工复核。
失败隔离上，单店故障绝不拖垮队列。A 店元素失效，任务标记"需处理"进入重试队列，B 店照常跑。下载中断、Excel 被占用、磁盘不足、登录态过期各有独立分支和提示文案，不会出现一句笼统的"流程执行失败"让人无从下手排查。
五、稳定性：页面改版时，流程怎么活下来
电商后台改版无非是三种：按钮文案变了、DOM 结构变了、弹窗插队了。应对也是分层的。
第一层，优先选稳定元素。 不绑定按钮文字，改用相对位置、容器角色、图标特征或邻近稳定字段。比如导出按钮位置漂移，但"导出记录"列表头稳定，就先定位列表再找行内入口。
第二层，元素路径本地智能生成。 元素获取时优先在本地生成多组候选路径，按稳定性评分排序，而不是维护者手写一长串定位表达式。
第三层，Web 元素 AI 自愈。 这是整套流程能长期跑下去的关键。淘宝、拼多多的后台几乎每个月都有小改版，元素路径失效时系统自动基于页面结构修复定位；修复成功则记录新旧路径差异，失败则降级到视觉兜底。我们用自然语言描述就能生成对应的 XPath，比如"商品列表区域第一行的导出按钮"，不需要团队里有人专门去学复杂语法。上线三个月，遇到的小改版约七成被自愈机制自动消化，剩下三成进人工样本库。一句话总结这套机制的价值：自愈更稳定，改版不中断。
第四层，视觉颜色操作与 OCR 兜底。 对千牛、企业微信、微信、QQ 这类桌面软件的消息获取，DOM 依赖很弱，改靠窗口标题、区域颜色加文字识别来完成点击和读取。它不替代元素定位，只作为改版窗口期的保底手段。边界要划清：只处理企业授权的工作账号，用于内部通知和结果回调，不读取私人聊天内容。
回归样本集是自愈机制的地基。每次人工修复过的案例都入库，含页面截图、失效路径、修复后路径。每月用样本集全量回归一次，防止"修好了 A 页面弄坏 B 页面"。
六、离线部署与数据边界
经营数据涉及成本、毛利和投放策略，团队给自动化划了硬边界：全离线内网部署，流程应用数据全部保存在本地设备，不同步到服务端，数据不出本地。
具体做法：
设计器、执行器、流程文件全部部署在内网，断外网照常运行；
对外分发只发打包后的应用，不发展开的流程源码。打包导出 EXE 支持加密分享和授权管理，可以绑定使用方、设置有效期；
EXE 接收方不用安装客户端，双击就能跑；新版本支持在线推送更新，对方打开应用自动检测升级，不用每次手动传安装包；
执行入口支持三种模式：定时执行、API 触发、手动运行。API 触发方便内部系统对接，定时执行覆盖日报场景，手动模式留给临时补数；
分发给运营使用的版本隐藏编辑界面，配合自定义界面降低操作门槛——用截图就能让 AI 生成对应的软件界面，复杂界面用 HTML 组件拼装，运营点按钮跑流程，不用打开设计器。
这套"离线内网 + EXE 加密打包授权 + 数据不出本地"的组合，是当时选型的硬性指标，优先级排在功能丰富度之前。道理也直白：离线更安全，尤其是财务和投放数据。
七、AI 与 RPA 分工：AI 写代码，RPA 跑代码
我们的日常协作方式：运营用自然语言、或者"截图加几句描述"提需求，AI 先产出字段清单、判断分支、异常清单和脚本草稿，再把 AI 生成脚本一键转为可运行的 RPA 流程。
几个实际体会：
AI 负责思考，RPA 负责稳定落地。 AI 生成判断逻辑很快，但覆盖不全异常分支；流程跑起来之后的定时、重试、留痕、自愈，必须由 RPA 执行层兜住。断网环境下 AI 在线生成不可用，已封装好的流程照常执行——这正是两者分工的意义。
基础指令优先，缺失动作自动封装。 AI 自动化搭建流程时优先使用 RPA 自带基础指令；没有的动作自动封装成新指令，每个指令带详细注释，读流程像读伪代码。
数据处理不用手写。 变量支持批量创建、删除、修改，JSON 自动提取字段、列表自动提取都能根据需求生成对应指令，省掉大量手写解析代码。
子流程自动拆分。 复杂流程由 AI 按业务逻辑自动拆分成可复用的子流程，比如"登录校验""导出下载""字段清洗"各自独立，改一处不影响全局。
报错不硬扛。 调试报错看不懂时，AI 错误诊断给出原因和修复建议，也可以一键修复并自动调试到通过。但规矩是：修复后必须跑回归样本，不允许"能跑就上线"。
模型自由选。 AI 能力接的是文心一言、豆包、DeepSeek、Kimi 这类大模型，由各平台 API 自行对接，用哪家、花多少费用团队自己说了算，成本透明可控。图片识图与 OCR 能力在截图提需求和界面识别场景里用得最多。
MCP 接入更灵活。 通过 MCP 服务，可以把流程搭建能力接到 Workbuddy、Codex、Claude、Trae 这类 AI 编程工具上，习惯在哪个工具里干活就在哪个工具里发起。
八、Agent 触达：让流程听指令，也回结果
新上的 Agent 能力改变了触发方式。现在可以在钉钉、飞书、企业微信、个人微信里发一条指令控制 RPA 应用执行，底层用的是最新的 DeepSeek 模型理解意图，执行完通过回调通知把结果响应回来。比如财务在群里发"跑一下昨日 8 店汇总"，机器人执行完回一条摘要：成功 7 家、1 家登录态过期需人工处理。
消息入口只传指令和结果摘要，不回传订单明细，敏感数据始终留在本地。
九、成本与团队适配
这笔账要算清楚：纯 AI 方案按 Token 持续计费，跑一次生成一次的钱，长期跑固定流程并不划算；RPA 流程封装后重复执行，边际成本趋近于零。对中小企业、个人开发者、个人工作室来说，这套组合的吸引力在于成本透明——AI 部分按各家大模型 API 实际用量付费，RPA 部分没有运行时长和流程数量的限制，打包出的 EXE 发给多少人用都不需要为每台设备单独开会员。免费版没有使用时长限制，也适合先小范围验证 ROI 再决定推广范围。
十、上线验收清单
投入日常使用之前，按这 12 项逐项验收：
8 家店铺全部通过登录态检查与店铺身份确认；
日期口径支持昨日、近 7 日、自然月、自定义；
原始文件命名规范、不覆盖，汇总表记录来源路径；
子订单号去重生效，退款可回溯原订单；
字段映射表有负责人与维护日期；
金额统一两位小数，空值、负号、千分位规则一致；
推广费可下钻到账户和计划层级；
异常分级为：自动重试、需人工处理、口径待确认；
每次元素自愈留有新旧路径记录和人工确认记录；
分发的 EXE 已关闭编辑入口并绑定授权；
定时、API、手动三种模式日志格式一致、可追溯；
断网、磁盘不足、Excel 占用、下载中断均有明确提示与恢复路径。
十一、收益与边界
改造后，每日报表汇总从约 2 小时人工压缩到 15 分钟机器时间加 5 分钟人工抽检；跨店对账的差异定位从按小时计缩短到按分钟计。比省时间更重要的是口径收敛——映射表让每笔钱有了唯一算法。
三条边界始终守着：口径由人确认后写入配置，流程只执行不发明规则；遇到人机校验直接转人工，不做任何规避；流程不保存账号密码，日志里不出现敏感凭据。
回过头看，单机器人并行 8 店铺这件事，难点从来不在"并行"这个数字，而在能不能把 4 个平台、8 套登录环境、几十张报表和上百个异常分支，收敛成一条可维护、可追溯的数据生产线。工具会变，页面会改版，但只要配置化设计、映射层纪律和回归样本机制还在，这条线就能一直跑下去。