多平台电商运营中，商品上架是最标准、最重复的体力活。本文复盘一套已稳定运行半年以上的多店铺自动化上架方案，覆盖商品数据建模、分平台流程实现、元素失效自愈、内网离线部署与应用分发等关键环节，并附上真实踩坑记录。方案不绑定特定店铺规模，个人开发者到中小团队均可参考落地。
一、问题拆解：重复劳动到底卡在哪
在动手之前，先把"上架"这个动作拆开看。以淘宝为例，单个商品从准备到提交审核，标准动作不少于 20 步：
读取商品资料 → 登录商家后台 → 进入发布页 → 选择类目
→ 填写标题 → 填写品牌/属性 → 上传主图（5张）→ 填写SKU矩阵
→ 录入库存 → 录入价格 → 填写详情页 → 物流模板选择 → 提交审核
三个平台的差异点：
人工操作的瓶颈不在单步耗时，而在规模：5 家店 × 每天 30 个新品 × 3 个平台，就是 450 次重复流程。且规则固定、输入结构化，这正是流程自动化工具的标准适用场景。
二、总体架构设计
最终落地的架构分四层，核心原则是数据本地、流程外置、状态可回写：
┌─────────────────────────────────────────┐
│ 调度层：定时任务 / API触发 / IM机器人指令 │
├─────────────────────────────────────────┤
│ 执行层：RPA流程引擎（按店铺拆分为独立流程） │
├─────────────────────────────────────────┤
│ 数据层：本地商品表（Excel/CSV/本地SQLite） │
├─────────────────────────────────────────┤
│ 回写层：执行状态、驳回原因、截图存档 │
└─────────────────────────────────────────┘
选型阶段我们定了五条硬指标，后文所有技术决策都围绕它们展开：
支持全离线内网部署，流程数据不出本地——商品成本价、货源渠道属于核心经营数据；
Web 元素失效时能自动修复定位，而不是流程中断等人来改；
AI 生成的脚本能一键转为可运行的正式流程，而非一次性玩具代码；
流程可打包成独立可执行文件分发，并带授权管控；
费用透明可控，不绑定平台订阅制，长期使用成本可测算。
三、数据层：一张表驱动所有平台
商品资料统一放在本地，字段对齐三个平台发布页的交集，平台特有字段单独留列：
两个工程细节：数据量小走 Excel，单店 SKU 超千的商品表建议迁到本地 SQLite，避免单元格 32767 字符上限问题；图片路径在流程入口处统一转为绝对路径，防止定时任务的工作目录漂移。
流程侧配套的能力是变量批量管理和 JSON 字段自动提取：表格读入的 sku_json 无需手写解析代码，一条指令自动展开成列表变量，供后续填表节点逐行消费；变量支持批量创建、删除、修改，调试时逻辑一目了然。
设计要点：流程不写死任何商品数据。换品、改价、改库存只动表格，流程代码零修改。这也是后续"商品搬家"（把A店已有商品批量同步到B店）能复用同一套流程的原因——这也覆盖了商品采集上架的完整链路：搬家的本质就是先采集导出成表，再走一遍上架流程；库存同步同理，只需把回写方向反过来。
四、分平台流程实现
4.1 淘宝：优先走网页端，避开客户端弹窗
千牛客户端弹窗多、窗口结构随版本漂移，我们统一走网页端商家中心。流程节点如下（伪代码）：
for row in 商品表 where platform='taobao' and status='pending':
open "https://sell.taobao.com/.../publish.htm"
select_category(row.cat_id)
fill(title=row.title, attrs=row.attrs)
upload_images(row.main_images) # 逐张上传，校验返回URL
fill_sku_matrix(row.sku_json) # 动态行，按表格列数展开
submit()
if 页面出现"提交成功":
write_back(row, status='success')
else:
capture_screenshot() # 驳回留档
write_back(row, status='rejected', error_msg=获取驳回文案)
4.2 天猫：品牌校验是最大坑
天猫比淘宝多了品牌、资质、发票字段，且品牌ID与类目的对应关系由平台后台校验。我们踩过的典型坑：
流程提交后页面返回"品牌信息校验未通过"，人工排查发现是类目录入时使用了历史缓存的类目ID，平台侧已调整映射关系。而流程里没有对这个报错分支做处理，导致后续 40 个商品全部卡在同一个弹窗上。
修复方式有两个层面：一是数据层建立 cat_id 与 brand_id 的校验清单，每周核对；二是在流程里为每个提交动作增加异常分支——出现弹窗即截图、获取文案、写回 error_msg、关闭弹窗继续下一行。流程的健壮性不取决于主路径多长，而取决于异常分支覆盖多全。这也是 AI 直写脚本最常见的短板：主流程逻辑完整，但异常分支漏判率高，遇到问题就要回头改代码，维护成本随运行时长线性累积。
4.3 拼多多：跑量优先，做成无人值守流水线
拼多多店铺上新频率最高、铺货需求最密集，我们把它配置成纯定时任务：每天凌晨 2 点自动执行，新品表内的商品按序上架，执行结果早上回写完毕，运营上班只看异常行。
临时任务（改价、补库存、紧急下架）通过 API 触发——我们自己的运营中台推一条 JSON 指令，流程立即启动：
{
"flow": "pdd_update_price",
"shop": "shop_c",
"params": {"goods_id": "G20261008002", "price": 49.9}
}
钉钉群里也接了一个机器人入口：@机器人发送指令即可远程触发指定流程，执行完成后结果自动回调到群里。值班同学不在电脑前也能处理紧急改价和商品上下架管理。
五、稳定性工程：元素失效自愈
这是整套方案能长期运行的核心，单独一节展开。
RPA 操作网页最脆弱的环节是元素定位。平台前端一改版，原本录好的选择器就失效，流程批量报错。传统解法只有停机改脚本，旺季根本耗不起。我们对这套方案的关键要求就是：Web 元素失效时，由 AI 自动分析页面结构、重新定位元素并修复，流程不中断。
实际运行中，这套机制按三层兜底：
本地智能元素生成：录制时工具基于页面结构在本地生成多条候选元素路径，我们人工挑最稳的一条落库，不依赖云端；
自然语言生成路径：不会写 xpath 也能维护流程——直接用"点击右上角的发布按钮"这样的描述生成定位表达式，AI 自动封装成可复用的指令，每条指令带注释，逻辑一目了然；
AI 自愈修复：运行期元素匹配失败时，自动重分析 DOM 结构找到新路径并替换，同时记录修复日志供人工抽检。
另外针对千牛、企业微信、微信这类拿不到标准 DOM 节点的客户端软件，使用视觉颜色定位兜底：不依赖元素节点，基于图像识别完成点击、内容读取等操作。消息类客户端的自动化（比如读取售后消息）就靠这一层实现。
调试阶段还有一个高频痛点是报错看不懂。我们的做法是截图 + 报错堆栈直接发给 AI 做错误诊断：自动分析错误原因、给出修复建议，能自动修复的当场修复并重跑验证到通过。排查一个元素失效问题从平均半小时降到几分钟。
六、AI 与 RPA 的分工：一个思考，一个落地
这半年最大的经验是：不要让 AI 全程操作后台，也不要让 RPA 流程从零手写。
结论是分工制：AI 负责思考——生成流程脚本、诊断报错、优化元素路径；RPA 负责稳定落地——7×24 执行、异常自愈、离线可用。运行期需要动态决策的环节（如 OCR 识别图片内容、按页面内容分支处理），流程中按需实时调用大模型 API 接口，其余时间零 AI 消耗。AI 部分走各平台 API 自行对接，用多少花多少，成本完全透明可控，长期跑下来比纯 AI 方案便宜一个量级。
实操中还有两个提效细节：对着页面截图加一句话描述需求（"把这个列表里的价格列全部提取出来"），AI 就能生成对应流程，省去逐条文字描述逻辑的麻烦；遇到多分支业务，AI 会自动拆分逻辑、封装成可复用的子流程，而不是摊出一屏平铺的指令，后续店铺复制时直接复用。
在工具链层面，这类流程引擎还支持 MCP 服务协议，可以被 Codex、Claude 等 AI 编程工具反向调度，让 AI 在生成代码的同时直接驱动流程搭建与回归测试，自动化生产的自动化程度可以再上一层。
七、工程化分发：从脚本到可交付应用
流程稳定后，我们把整套方案打包成可执行文件交付给运营团队，这一步解决的是"别人怎么用"的问题：
一键打包导出 EXE：接收方无需安装任何客户端，双击即用；
授权管理：每个分发的应用绑定授权，控制使用方和使用期限，防止流程被无限外传；应用本身加密分享，源码不可见；
在线推送更新：流程改了一版，对方打开应用自动检测并升级，不用再手动发文件；
独立配置触发方式：每个应用可单独设置 API 触发或定时执行；
自定义界面：用可视化方式给 EXE 套一层界面——商品表导入、进度展示、参数填写全部图形化，复杂界面也可以直接用 HTML 组件实现，对非技术运营零门槛。
对成本敏感的团队还有两个实用点：这类工具对个人开发者和小工作室通常提供免费档位，无运行时长、无流程数量限制，多设备部署也不叠加会员费，适合先小规模验证再铺开。
八、安全与部署：数据不出本地
全流程数据（商品表、执行日志、截图存档、授权信息）只保存在本地设备，不同步任何服务端。有客户现场只能访问内网的场景，我们把流程引擎和商品数据整体部署在离线环境，AI 相关的增强能力在内网环境下自动降级关闭，核心上架流程不受影响。这也是选型时把"全离线可用"列为第一优先级的原因——离线环境用不了云的 AI，但店还是要照常开。
九、踩坑实录汇总
多店铺商品自动化上架的技术门槛不高，成败在三件事：
数据工程化——商品信息全部外置成表，流程只认表，不认商品；
稳定性工程化——把元素自愈、异常分支、状态回写当成一等公民设计，而不是上线后补；
分工工程化——AI 生成与诊断，RPA 执行与兜底，让贵的用在思考上，让稳的用在运行上。
从一张商品表、一条上架流程开始，先跑通单店单流程，再复制到全平台，再叠加定时调度、API 触发和远程指令——步子不用大，关键是跑得久。
