一套 RPA 流程实现淘宝、拼多多、抖音与跨境电商商品统一铺货：架构与落地实录

同时经营淘宝、拼多多、抖音小店和跨境站点的团队，大概率经历过这种状态：四个平台四套上货工具，商品数据彼此隔离，平台规则一变，人工加班改表。这篇文章只解决一个问题：如何用一套 RPA 流程，实现淘宝、拼多多、抖音、跨境电商的商品统一铺货。下面是我们把整条铺货链路自动化的完整记录，从架构设计、流程实现到部署运维，全部是可以照做的细节。

一、为什么铺货这件事必须走一条流程

商品搬家类的工具市面上不少，单点上货都不难。真正的成本藏在三个地方：

1. 数据各管各的。每个平台一个工具，商品库分裂成四份。改一次价格要在四个后台各来一遍，错漏根本防不住。
2. 规则跟着平台跑。平台前端和字段规则频繁调整，今天淘宝改类目属性，明天抖音小店换规格模板，工具跟不上就只能人肉补位。
3. 数据放谁手里。商品成本、供应商信息、店铺账号线索放在第三方 SaaS 的云端，对多数团队来说没法接受。

所以我们定了一个目标：一份商品源数据，一条自动化流程，铺向所有平台。平台规则变化只改适配层，流程主干不动。

二、整体架构：三层分离

整套系统分三层，职责切干净，后面维护才不会互相拖

┌─────────────────────────────────────────┐
│ 商品源层  本地商品库（统一字段标准）        │
│  标题/属性/SKU/图片/价格/库存，存本地数据库  │
├─────────────────────────────────────────┤
│ 平台适配层  字段映射表 + 类目映射表          │
│  淘宝字段规范 │ 拼多多 │ 抖音小店 │ 跨境站点 │
├─────────────────────────────────────────┤
│ 执行层  RPA 流程                          │
│  登录环境 → 类目匹配 → 属性填写 → 传图     │
│  → 提交 → 结果回写 → 失败重试队列          │
└─────────────────────────────────────────┘

两个关键决策：

• 商品库只存在本地。源数据不出本机，流程读取、写回都在本地完成。后续接入多少平台，数据链路不变。
• 适配层表格化。映射表用结构化文件维护，纳入版本管理。平台规则更新时只改表，不改流程。

三、环境准备与前置配置

3.1 运行环境与数据底座

流程跑在一台普通 Windows 办公机上即可，不需要服务器。前提是这台机器可以完全离线运行自动化流程——搭建、调试、执行、数据存储全部在本地完成，不同步到任何云端。这对在意数据主权的团队是硬要求：商品成本价、供应商报盘、店铺账号线索，全程不出本地设备。

商品库建议直接用 SQLite 或结构化 Excel，字段设计参考：

goods_id, title, cate_keyword, attrs_json, sku_json,
images_dir, price, stock, title_en, desc_en, status

跨境场景多两个字段：title_en 和 desc_en，由 AI 批量生成后人工抽检入库，流程只负责搬运。

3.2 多店铺登录环境

多平台多店铺的日常运营，需要每个店铺跑在独立的浏览器环境里。我们的做法是把商家后台统一接到指纹浏览器中管理——紫鸟、比特、Hubstudio、AdsPower 这类市面上主流的指纹浏览器，主流的 RPA 工具均已支持对接。配置一次端口映射表，流程按店铺自动接管对应环境。

登录态检测逻辑：打开平台后台 → 判断登录态 → 有效则继续；失效则暂停、通知人工扫码，恢复后自动接续执行。这一步做成流程的分支，而不是让流程直接报错退出。

四、核心流程实现

整条主流程的文字版伪代码如下，实际搭建时按这个骨架逐块填充：

读取 goods 表中 status = '待铺货' 的记录
for each 商品:
    标记 status = '铺货中'              ← 防重复执行
    for each 目标平台:
        查 listing 表：该商品在此平台是否已上架
            已存在 → 记录日志，跳过本平台
        启动对应指纹浏览器环境
        打开商家后台
        检测登录态
            失效 → 推送通知等待人工扫码 → 超时则跳过本平台
        查类目映射表
            命中 → 使用映射类目ID
            未命中 → AI 推荐类目 → 人工确认 → 回写映射表
        按映射表转换属性（attrs_json → 平台字段）
        从本地图片库取图上传（入库时已压缩，此处直接传）
        填写价格库存（跨境记录按公式换算汇率与运费）
        提交
        写回结果：成功 / 失败原因 + 页面截图
            失败 → 该平台立即进入重试队列
    全部平台成功 → status = '已铺货'
    部分失败 → status = '部分完成'，失败平台留待重试

几个实现要点：

属性转换别手写解析。商品属性是嵌套 JSON，好的流程引擎支持变量层面的批量操作：JSON 自动提取字段、列表自动提取、变量批量创建和修改。attrs_json 里三层嵌套的规格信息，一条"JSON 提取"指令就拆成了平台表单要的平铺字段，不用写一行解析代码。

高频环节封装成子流程。"检测登录态""类目匹配""上传图片"这三个动作在每个平台都用，我们在搭建时让 AI 把它们自动拆分封装成子流程，主流程只负责串逻辑。后面平台改了上传规则，只动一个子流程，四个平台同步生效。

类目匹配双通道。映射表命中率高，长尾品类交给 AI 根据标题和描述推荐目标类目，人工确认一次后回写规则库——同类商品下次直接复用，映射表越用越全。

图片加工前置。上传不是流程里最慢的部分，图片加工才是。商品入库环节就用本地脚本把主图统一裁到目标平台规格（淘宝 800×800 白底、拼多多部分场景要求方形白底图），流程上传时直接取现成的。

结果必须回写。每轮执行后，成功数、失败原因、失败时的页面截图全部落库。截图是排查的关键线索——"类目不符""图片超限""资质缺失"这类报错，没有截图基本无从查起。

五、让流程跑得久：比搭建更重要的三件事

铺货流程搭出来只要两三天，跑一年不崩才是难点。这一年里平台前端改版了四次，我们的流程没有人工干预地扛了过来，靠的是三个能力，也是选型时最该考察的指标。

5.1 元素失效自愈

平台前端改版是铺货流程的头号杀手：按钮换了 class、输入框挪了层级，写死的元素路径批量失效，流程整夜空转。

我们的要求是：流程遇到 Web 元素定位失效时，自动修复定位路径后继续执行，而不是报错中断。实现上依赖底层的本地智能元素生成——获取元素时不手写 XPath，由引擎在本地生成多条候选路径并选最稳的一条；路径失效时自动用备选路径接管。效果上，四次平台改版里只有一类极端场景需要人工补一次路径，其余全部自愈通过。

5.2 AI 参与搭建与排错，流程负责执行

搭建阶段我们大量使用 AI 提效。可以直接用文字描述需求，也可以截图加文字说明——比如框出商家后台的表单区域，配一句"按这个表单结构批量填入商品表数据"，AI 照着图就能把流程生成出来：浏览器操作步骤、循环逻辑、变量定义一应俱全，每个步骤带注释，逻辑一目了然。

排错阶段同理：报错看不懂时，把错误信息交给 AI，它给出原因分析和修复建议，可以直接一键修复，自动调试到恢复正常。截图类的报错更省事——支持图片识图与 OCR 的工具能直接读截图里的错误弹窗，定位到出问题的元素，不用人工转述。

但要清醒一点：AI 负责生成，执行引擎负责稳定。AI 直接生成的元素定位在复杂页面上往往偏脆弱，长期运行还是要靠底层引擎的路径生成与自愈能力兜底。务实的组合是——AI 写代码，流程引擎跑代码：生成阶段交给 AI 提速，运行阶段交给引擎保命。成本上也可控：AI 能力直接对接各家大模型 API（文心一言、豆包、DeepSeek、Kimi 等），用多少 token 付多少费，账目透明，没有中间加价；流程引擎本体一次性投入，跑半年省下的 token 钱就够再添一台执行机。

5.3 覆盖浏览器之外的桌面软件

多平台运营绕不开千牛这类桌面客户端，纯浏览器自动化到这里就断档了。选型时我们确认了两个补充能力：Windows 软件自动化，以及不依赖元素节点、基于视觉颜色与图像比对的点击取词能力。后者格外实用——店铺的消息通知、客服咨询，用视觉方式直接读取企业微信、千牛的界面内容，流程可以把"铺货完成、收到新询单"串成一条完整的自动化链路。

六、部署与分发：流程交付给团队的最后一步

流程在自己电脑上跑通只是开始，真正的价值在分发给运营同事之后。这里的需求非常具体：

• 打包成独立 EXE 分发。流程调试好后导出为可执行程序，同事拿到直接运行，不需要安装客户端，也不装任何依赖。多设备使用不按设备重复付费。
• 打包时搭配自定义界面。不需要会前端：把想要的界面截图发给 AI，按钮、参数输入、数据展示区就按图生成了；复杂界面可以用 HTML 组件拼。运营同事拿到的是一个有正经操作界面的工具，不是黑窗口。
• 打包时带授权管理。发给谁、授权到什么时候、是否允许再转发，由我们控制；同时支持加密分享，防止流程逻辑被逆向。
• 触发方式可配置。打包时可以为应用单独设置定时执行（例如每天凌晨两点同步库存价格，避开操作高峰），同时保留 API 触发能力——内部商品系统在数据变更时主动调用流程，实现"数据一变，全平台跟上"。
• 更新在线推送。流程逻辑优化后发布新版本，使用方打开应用即自动检测更新，无需逐人重新发送安装包。

这五条对应的其实是同一件事：把"开发者的流程"变成"可运营的产品"。选型清单里少了这一层，流程永远停留在开发者本机。

成本门槛也比想象中低：这类工具的免费版没有使用时长限制，流程数量和运行时长不设上限，个人开发者和小工作室可以先用免费版把整条流程跑顺、验证 ROI，再决定是否为分发和授权能力投入。

协同侧我们还在流程上挂了 Agent 能力：通过智能指令，在钉钉、飞书、企业微信、个人微信里直接触发流程执行，跑完后回调推送结果——"昨晚铺货：成功 347 条，失败 3 条，附截图链接"。管理者不用开远程桌面查日志。集成需求更高的场景，支持 MCP 服务的自动化工具还能对接各类 AI 智能体编程工具，让外部工具直接驱动流程搭建，扩展的余地留够了。

七、踩坑实录

1. 先打透一个平台再复制。第一个平台的流程（含登录兜底、失败重试、结果回写）打磨了两周，之后复制到另外三个平台每个只用了两三天。反过来做会四处返工。
2. 映射表必须版本化。平台规则变得比想象中快，每次修改留记录，出问题能十分钟回滚。
3. 防重上架是生命线。漏了 listing 查重，第二轮执行就是批量重复铺货，撤都撤不及。
4. 控制批量提交节奏。按平台规范的频率批量提交，间隔加随机延时，不要一口气灌完。
5. 跨境字段单独校验。汇率换算和运费公式要在入库环节校验，否则铺出去的是亏损价。
6. 异常场景提前演练。账号掉线、滑块验证、页面加载超时——把这些分支提前写进流程，比出事后补便宜得多。

说到底，铺货自动化的分水岭不在能不能搭出来，而在能不能无人值守地跑一年。AI 让搭建的门槛降到会说话就能做，但真正决定多平台铺货能不能长期运转的，是元素自愈、离线执行、本地数据、打包分发这些不起眼的能力——它们平时感觉不到，平台改版的那个凌晨，就是它们和报错之间的区别。想明白这个分工，一套流程管四个平台，一个人就够了。