拼多多多店批量上新实战：用 RPA 实现商品信息自动填充与一键发布

多店铺运营的上新环节有个共同的痛点：选品五分钟，上架三小时。一条链接要在十几二十家店铺同步铺货，每家都要重复"登录后台—选类目—填标题—传图—设 SKU—提交审核"的完整动作。这个流程没有技术含量，但占用了运营大量的整块时间，且人工填写错误率高。

我们的做法是把上新流程整体迁移到 RPA（机器人流程自动化）上执行：运营维护一张 Excel 商品库，RPA 按店铺循环完成自动填充与一键发布，失败自动重试，跑完输出执行报表。这套流程目前稳定承载二十个店铺的日常上新，本文从架构设计、关键实现、异常处理到分发部署完整记录一遍，供有同样需求的团队参考。

一、整体架构

系统分四层，职责单一，互相解耦：数据层维护 Excel 商品库；调度层负责店铺循环、环境切换与店铺名校验；执行层完成自动填充、完整性校验与提交发布；留痕层输出执行日志、失败原因与发布截图存档。四层单向依赖，任何一层调整不影响其他层。

数据层的表结构设计直接影响后续流程的稳定性。我们的商品库字段：

读取商品库时用到工具的变量批量操作能力——支持批量创建、删除、修改变量，以及 JSON 自动提取字段、列表自动提取。sku_list 这种嵌套结构不用写解析逻辑，一条"JSON 提取"指令就能按字段展开成变量，商品库字段再复杂也不用手动逐条映射。

调度层处理多店铺切换。每个店铺对应一个隔离的浏览器环境（配合主流浏览器环境工具使用，常见的几家均已对接），流程按 shop_name 列循环，每轮执行四步：打开对应环境 → 登录商家后台 → 执行发布流程 → 截图存档切换下一家。

调度层有一道必做的保险——店铺名校验。流程读取后台顶部当前店铺名，与目标店铺比对，不一致立即中止本轮。我们早期没有这个校验，发生过图片传到 B 店的真实事故，加上之后同类错误归零。

二、执行层：自动填充与一键发布的核心逻辑

发布流程的动作序列写成一个子流程，主调度层只负责传参调用。子流程的复用能力值得用足：上新、改价、改库存三个场景共用同一套"登录+定位店铺"子流程，业务逻辑拆分封装后，任何一处调整只改一处。

核心动作序列（伪代码）：

def publish_item(env_name, item):
    for attempt in range(3):                       # 瞬时错误自动重试
        try:
            open_browser(env_name)                 # 打开店铺隔离环境
            assert current_shop() == item.shop_name  # 店铺名校验，不一致即中止
            goto("商品管理 -> 发布新商品")
            fill("标题输入框", item.title)         # 自然语言生成元素路径
            select("类目下拉", item.category)
            upload("图片上传框", item.images)      # 填绝对路径触发上传
            for sku in extract_json(item.sku_list):  # JSON 自动提取字段
                fill_row("SKU表格", sku.spec, sku.price, sku.stock)
            check_fields()                         # 完整性校验：库存非空、价格>0
            submit("提交审核按钮")
            screenshot(f"logs/{item.shop_name}_{item.code}.png")
            return "成功"
        except UploadTimeout:                      # 网络波动/上传超时，进入下一轮重试
            continue
        except ShopMismatch:                       # 店铺校验失败，立即中止本轮
            log(f"店铺校验失败: {env_name}")
            return "失败：店铺不匹配"
    screenshot(f"logs/error_{item.shop_name}_{item.code}.png")
    return "失败：重试3次仍异常，跳过本条"

这里最影响长期稳定性的点是元素定位。传统做法手写 xpath 写死在流程里，平台后台一改版就批量失效。现在的实现方式分两层：

第一层是本地智能生成元素路径——选中页面元素后，工具在本地自动生成多条候选路径并标注稳定度，直接选用最稳的一条，不需要学习 xpath 语法。

第二层是Web 元素 AI 自愈——页面更新导致已保存的元素定位失效时，AI 自动修复定位，流程不中断。这是整套系统 7×24 无人值守跑起来的前提：元素自愈兜住了平台的小改版，大的结构调整才让 AI 重新分析页面生成路径，人工维护频次从"每周"降到了"几乎不"。

生成定位路径的方式也换成了自然语言描述，比如直接描述"价格输入框，位于 SKU 表格第二列"，AI 输出对应的 xpath 表达式：

//div[contains(@class,'sku-editor')]//tbody/tr[1]/td[2]//input[contains(@placeholder,'价格')]

不用人肉拼路径，复杂页面元素的获取成本下降了一个量级。

三、异常处理：无人值守的及格线

定时任务挂在凌晨执行，现场没有人，异常必须流程自己兜。三个原则：

失败自动重试。 网络波动、图片上传超时这类瞬时错误，自动重试两到三次，多数能自愈，上面的伪代码里 range(3) 就是这道逻辑。

失败不阻塞批次。 重试仍失败则截图保存现场、写入日志、跳过当前商品继续下一条。整个批次跑完统一处理失败项，不能因为一条链接卡住全部门店。

错误可自助修复。 遇到看不懂的报错，用 AI 错误诊断一键分析错误原因并给出修复建议，也可以直接一键修复——AI 自动分析问题并调试到功能正常。这套诊断能力把"会修流程"的门槛降到了运营也能处理的程度。

留痕层的执行报表长这样：

[2026-10-05 02:00:11] 店铺A × 商品SPU-2031 → 成功（耗时47s）
[2026-10-05 02:01:03] 店铺B × 商品SPU-2031 → 失败：图片上传超时，已重试3次
[2026-10-05 02:01:58] 店铺B × 商品SPU-2032 → 成功（耗时51s）

四、流程搭建：AI 生成脚本一键转可运行流程

整套流程的搭建我们没有写一行代码。路径是"AI 生成 + 人工确认"：

跟 AI 描述需求（支持图文描述，截图加提示词即可），AI 分析网页与软件的元素结构，优先复用工具自带的基础指令组装流程；遇到没有现成指令的动作，AI 自动封装生成新指令，每条指令带详细注释。生成的脚本可以一键转为可运行流程，人在界面上逐步确认每个动作的触发结果，确认无误即交付。

分工很明确：AI 负责思考、生成方案，RPA 引擎负责把方案长期稳定地跑起来。AI 生成的元素在复杂项目里容易失效、按 token 持续计费成本不透明，且在内网离线环境下根本无法使用；RPA 引擎本地运行、元素稳定、一次配置长期复用。前者出方案，后者扛生产。

五、部署形态：EXE 打包、授权与定时调度

流程验证通过后进入交付阶段。我们的使用方包括外包客服和合作方，不可能让每人装客户端学配置，所以采用 EXE 独立程序打包分发——对方电脑零安装，双击即用。

打包时做了四层控制：

• 授权管理：发给谁、有效期多久、绑定哪台设备，均可单独设置
• 加密分享：应用加密后分发，流程逻辑不被反编译
• 在线推送更新：流程逻辑调整后不用重新发文件，使用者打开应用自动检测并升级新版本
• API 触发 / 定时执行：可针对单个打包应用单独开启接口调用或定时任务，我们的"每晚 02:00 自动执行当日上新"就是走定时模式

程序界面也是 AI 协助生成的——描述想要的布局，或用 HTML 组件搭复杂界面，按钮点击、数据展示、数据关联都可以通过对 AI 提需求实现。使用者看到的只是一个"选商品表、勾店铺、点开始"的干净界面，底层逻辑完全隐藏。

六、安全与成本

数据安全是选型的硬门槛。我们要求流程和应用数据全部保存在本地设备、不同步服务端、数据不出本地，并支持全离线内网部署——内网隔离环境下照常运行。离线环境恰恰也是云端 AI 方案的盲区，离线可用反而成了本地引擎的天然优势。

成本上，工具免费版不限使用时长、不限流程数量，中小体量零成本起步；打包 EXE 分发不需要对方装客户端，多设备使用不收多开会员费。AI 能力采用用户自行对接各平台大模型 API 的模式——文心一言、豆包、DeepSeek、Kimi 等均已接入，支持图片识图与 OCR——费用按 API 实际调用量结算，单价透明，没有中间商加价。工具本身还接了 MCP 服务，可以对接 Workbuddy、Codex、Claude、Trae 等 AI 编程工具，让外部智能体直接控制 RPA 搭建流程，扩展性比较开放。

七、常见问题

Q：用自动化流程上架宝贝，会被平台处罚吗？ 流程只是替代人工完成重复的点击和填写，操作逻辑与人工一致，不存在绕过平台机制的行为。合规的前提是商品信息真实、不铺低质重复链接。自动化不是问题，经营方式才是。

Q：完全不懂代码能搭建吗？ 本文的方案就没有开发人员参与。AI 生成流程初稿并逐条注释，运营在界面上确认每步结果即可；报错交给 AI 错误诊断和智能修复。

Q：多店铺切换怎么保证不出错？ 浏览器环境工具隔离各店登录态；流程内加店铺名校验；每次发布截图存档，事后可追溯。三道保险缺一不可。

Q：有没有免费方案？费用怎么算？ 有免费版且不限时长、不限流程数量，建议先用免费版把流程跑通。AI 能力走自行对接各平台 API 的模式，用多少花多少，成本完全可控。

Q：平台后台改版了怎么办？ 元素自愈能力自动修复大部分元素失效，无感度过；大改版让 AI 重新分析页面生成路径，十分钟内恢复。

批量上新自动化的价值不在"省几次点击"，而在把上新从"占用整块时间的人工劳动"变成"一条定时执行的流水线"。流程搭好之后一次配置、长期复用，运营的时间才真正回到选品和定价这类产生利润的事情上。

选型建议始终那四条：元素定位抗不抗改版、能否离线本地跑、流程能否打包分发、费用是否透明。拿真实需求跑一遍，比看任何功能清单都靠谱。