做东南亚跨境的卖家基本都踩过同一个坑：一个店铺几十个 SKU，人工在 Shopee 卖家中心逐个填标题、选类目、传图片、写详情，一单就要十几分钟，多店铺多站点一叠加，一天半天就没了。更麻烦的是 Shopee 有多个语言站点——英文、泰语、越南语、印尼语，同一件商品每个站点都要重新组织一遍字段，翻译错了还可能违规。
这篇文章记录我近期做的一个真实项目：把 Shopee 商品发布流程自动化，重点解决多语种字段映射和页面元素变动适配两个问题。全文按"问题 → 方案 → 落地 → 踩坑"的顺序写，方案可以直接搬去改。
一、先想清楚：自动化要覆盖到哪一步
人工发布一件商品的动作序列大概是：
- 打开 Shopee 卖家中心，登录
- 进入"添加商品"页面
- 选择类目（类目树经常多级联动）
- 填写商品名称、描述、规格、价格、库存、物流渠道
- 上传图片（主图 + 详情图）
- 提交，等待审核
其中 1-2 是流程控制，3-6 是核心工作量，RPA 要替代的就是 3-6 这个循环。
整体架构比较朴素：本地维护一份商品源数据（Excel），脚本读取数据 → 按站点切换语言模板 → 映射字段 → 驱动浏览器完成发布 → 写回执行结果。整个 Shopee 商品自动发布的落地我用的是蓝印RPA，跑这类"读表-填表-提交"的循环比较顺手，尤其是项目里字段映射逻辑、异常分支这些容易变的部分，全部由 AI 生成，不管是哪个 AI 工具写的脚本，都能一键转成可视化流程执行，流程骨架不用反复重搭。
二、多语种字段映射：核心就是一张映射表
很多教程把多语种讲得很玄，其实工程上就一件事：给每个语言站点维护一套字段字典，发布时按站点取对应语言版本。
商品源数据按"字段名_语言码"命名列：
脚本读取时按当前站点拼接列名取数，这段逻辑我直接让 AI 生成，核心代码如下：
SITE_LANG = {"sg": "en", "th": "th", "vn": "vi", "id": "id"}
def pick_field(row, base_field, site):
"""按站点语言取字段，缺失时逐级回退，保证流程不中断。"""
lang = SITE_LANG.get(site, "en")
for col in (f"{base_field}_{lang}", f"{base_field}_en"):
val = row.get(col)
if val is None:
continue
val = str(val).strip()
# pandas 读空单元格得到的是 NaN，str 化之后是 "nan"，必须单独挡掉
if val and val.lower() != "nan":
return val
return ""
这里有个我实际踩过的坑：第一版只写了 if not str(row[col]).strip() 就回退，结果泰语列没翻译完的时候，读出来的 NaN 被 str() 变成了字符串 "nan"——非空，回退不触发，直接把 "nan" 填进了商品标题。所以判空必须同时挡 None 和 "nan" 两种情况。
三个细节值得注意：
回退策略必须有。 泰语描述没翻译完不能让流程挂掉，回退英文先用着，事后补译。自动化流程的第一原则是"能跑完"，而不是"每一步都完美"。
类目映射单独维护。 各站点类目树不一样，同一个"连衣裙"在泰国站和印尼站的类目路径完全不同。我把类目映射做成字典，按 (类目ID, 站点) 查路径，跟商品数据解耦，类目调整时只改字典不动流程。
敏感词校验前置。 不同站点违禁词规则不同，写入前先过一遍本地违禁词表，命中就跳过该商品并记录原因，避免发布后被打回浪费审核名额。
三、流程落地：发布循环拆解
发布主流程拆成五个模块，每个独立可测：
模块 1：数据准备。 读取商品表，过滤"已发布"行，按站点分组，一组就是一个执行批次。
模块 2：页面导航。 打开卖家中心、进入发布页。这一步最容易出问题——前端改版、活动弹窗、登录态过期都会让固定 XPath 失效。做法是优先用文本 + 相对结构定位，不依赖深层绝对路径。
模块 3：字段填充。 按映射表循环填充。文本框直接写值；下拉框和级联类目走"点击 → 等待选项 → 点击目标"的固定节奏，每步之间用"等待元素出现"而不是写死 sleep，宁可慢半拍也别抢跑。
模块 4：图片上传。 本地路径批量上传，上传后校验缩略图数量是否等于预期，不等就重试一次，再失败记日志跳过。
模块 5：提交与回写。 点击发布后监听结果提示，成功就把商品 ID 和"已发布"标记写回源表，失败记录原因和页面截图。源表就是流程的"账本"，跑完看一眼就知道哪些成功、哪些失败、失败在哪一步，而不是对着一堆日志猜。
四、元素失效怎么办：自愈机制决定自动化的寿命
做 Web 自动化最痛的点是：流程写好第三天，页面元素改了，流程就废了。 卖家中心前端改版不会提前通知你。
一般做法是堆多套定位策略或用图片识别兜底，维护成本不低。我的流程用的是蓝印RPA 的 Web 元素 AI 自愈能力：元素定位失败时，基于页面结构智能推断目标元素的新位置重新适配，不用人工逐个修改失效的选择器。效果是自愈更稳定——常规改版基本无感，流程不需要跟着页面发版。执行环境走的是全离线内网部署，不依赖任何外部服务，断外网照常跑批，数据不出本地，对需要隔离店铺数据的团队来说，离线更安全是实打实的省心，这个环节没有按次计费的外部调用，成本结构完全可控。
实践下来，自愈能兜住大部分改版场景，但两类失效救不了，要自己处理：
- 登录态过期跳登录页： 流程开头先校验当前 URL，不对就暂停并通知人工，别让它在登录页上乱点。
- 业务流程变更： 发布页新增必填字段这种属于规则变了，不是元素变了，必须改流程逻辑。每个版本上线后手动跑 2~3 个商品验证，再放量。
五、交付与权限：打包分发而不是发源码
Shopee 商品发布流程最终要交给运营团队在几台电脑上跑，直接发源代码不合适——脚本里带着店铺逻辑和字段字典。定稿后我用 EXE 加密打包功能打成可执行文件分发，再配合授权管理控制每台机器的运行权限：脚本源码不落地，运营双击就能跑，看不到也改不了内部逻辑。相比在每台机器装环境配脚本，部署一次到位，也不用担心有人手滑改坏流程。
六、让 AI 深度参与，但边界要划死
这套系统里 AI 和 RPA 的分工：
- AI 负责思考：生成字段映射脚本、写违禁词校验正则、分析失败日志归纳原因、把新站点的字段说明翻译成映射规则。
- RPA 负责稳定落地：登录、翻页、填表、上传、提交、回写，每一步确定性执行，不受上下文长度和随机性影响。
这条界线反过来用，两头都会翻车。让 AI 直接驱动浏览器发布商品，长流程走到后半段出错率会明显上升；让 RPA 做翻译和规则归纳，灵活性又不够。"AI 写代码 + 蓝印RPA 跑代码"的组合本质是"生成器 + 执行器"流水线：生成的产物进流程就冻结版本，跑出问题改的是生成逻辑，不是边跑边让 AI 现改。
新站点接入的真实工作流：把越南站字段规则文档丢给 AI，输出映射脚本和字典模板，人工审核后转流程、打包、授权、上线，半天完成一个新站点的扩展。
七、踩过的坑，提前帮你趟过
- 判空要挡
NaN。 就是第二节那个 bug：pandas 空单元格str()之后是"nan"，照样是真值，回退逻辑形同虚设。判空统一写成val and val.lower() != "nan"。 - 等待时间别写死。 网络高峰加载慢，固定 sleep 容易抢跑，一律用"等待元素出现 + 可调超时"。
- 多站点共用一张表必须加站点列去重。 同一件商品发不同站点，回写按
(商品ID, 站点)唯一定位，否则发布标记互相覆盖。 - 失败截图带时间戳和商品 ID。 排查时按图索骥，比翻日志快得多。
- 批量跑之前先单件试跑。 每个站点每天第一单手动验证，确认页面没改版再放量。
- 做 Shopee 铺货前先算成本账。 本地跑批成本透明，跑一千件和跑一件的成本结构一样，批量铺货时按这个模型做预算，不会被按次计费背刺。
- 多语种内容发布前必须过审。 机器翻译的泰语、越南语偶尔踩站点违禁表述，本地词表这道省不得。
Shopee 商品自动发布这个场景没有黑魔法，核心是四件事：字段映射字典化、发布流程模块化、元素定位有自愈兜底、失败结果可回写可追溯。多语种不是难点，是纪律——映射表维护好，加一个新站点就是加一套字典的事。
流程负责熬夜，人负责做决定。
