RPA+Python实现1688商品自动化采集清洗上架全流程

1. 先把这个闭环讲清楚：它到底解决了什么

干电商选品的朋友应该都有过这种体验：在 1688 上看到一个潜力款，想把商品完整搬到自己的店铺里，光是复制标题、抠参数、下载主图、处理详情页、对着后台一项一项填属性，一个 SKU 就得折腾十几分钟。一天铺个几十个品，大半天时间就交代出去了，而且复制粘贴最容易出错——属性填串行、价格小数点漏掉、图片漏下载一张，后台一提交就报错，又得回头重新检查。

我最初也是纯手动操作，后来被逼得不行，才开始研究自动化。当时主要纠结两个方向：一是用 Python 写爬虫直接去抓 1688 的接口，二是用 RPA 模拟人工操作浏览器。试了一圈下来，我发现纯爬虫方案在 1688 这类平台面前很吃力——登录态不稳定、接口加密、页面异步加载严重、反爬策略频繁变化，抓下来数据还要单独维护一套代理池；而纯 RPA 虽然规避了这些技术问题，但数据处理能力弱，几十种字段的清洗、格式转换、价格计算用 RPA 脚本来写，维护成本又极高。

于是我把思路改成了 RPA 负责采集和上架、Python 负责清洗和计算 的组合方案。RPA 在跟真实网页打交道这件事上天然有优势，它不破解任何接口，就是模拟人的操作，只要登录一次、保持会话，稳定性和合规性都更容易把握；而 Python 作为数据处理的核心，用 pandas 做一些复杂的清洗、去重、批量计算，再合适不过。这个方案用一句话概括就是：RPA 做手和脚，Python 做大脑。整个闭环跑起来之后，平均采集一个 1688 商品只需要几十秒，清洗和上架全自动执行，我每天到点看一下任务日志，确认没有异常告警就行，选品效率比手动操作提升了大概 5 到 8 倍。

这篇文章适合谁看？如果你在做电商铺货、无货源选品、供应链选品，或者只是对 RPA 和 Python 的组合玩法感兴趣，都可以参考。下面我会把整个闭环的架构设计、核心代码、踩坑记录全部摊开来讲。

2. 方案选型：为什么是 RPA + Python，而不是其他组合

2.1 RPA 工具的选型思路

市面上的 RPA 工具不少，影刀、UiBot、按键精灵、微软 Power Automate 我都接触过。因为我的应用场景是电商数据采集，需要同时满足三个条件：能稳定模拟浏览器操作、能方便地把数据导出给外部程序处理、脚本维护成本可控。

综合下来我选择了影刀 RPA，理由很直白：

• 界面操作上手快，选择器、图像识别、OCR 这些能力都是图形化配置，采集流程改起来比纯代码快得多；
• 支持 Python 扩展，可以直接执行 Python 代码块或调用外部 Python 脚本，数据在 RPA 和 Python 之间可以通过 JSON、Excel、数据库中转，这正好符合我“RPA 只管交互、Python 管处理”的设计；
• 免费版对个人开发者够用，跑常规采集任务没什么压力。

当然，如果你更熟悉 UiBot 或者自研基于 Playwright/Selenium 的自动化框架，逻辑也是完全一样的。RPA 工具本身不是关键，关键是搞清楚它的边界——RPA 擅长的是跟网页、系统界面打交道，数据分析、计算、规则处理这种活不该丢给它。

注意：RPA 采集的核心是模拟真人操作，不是说完全绕开风控。后面第五部分我会专门讲节流设置，这里先留个印象，采集频率千万别设得太激进。

2.2 技术栈全景

整套系统的技术栈不复杂，我用到的组件如下：

这个组合的本质，是把两个工具的优势区隔开：RPA 管“不能通过接口做”的部分，Python 管“复杂计算与批量处理”的部分。两者通过文件或数据库解耦，哪怕那天 RPA 工具升级导致脚本要重写，Python 处理部分完全不受影响。

2.3 数据流设计：采集、清洗、上架三步怎么衔接

整个流程的数据流向是这样的：

1. RPA 从 1688 采集原始商品数据，输出为 JSON 文件（为什么用 JSON 而不是 Excel？因为 JSON 天然支持嵌套结构，比如 SKU 列表、图片列表这种多层级数据，Excel 反而要分多张表去维护关系）；
2. Python 脚本读取 JSON，通过 pandas 将数据标准化，清洗出标题、价格、库存、属性等字段，计算加价、运费模板、最低 SKU 价，最后生成“可直接上架”的标准数据文件；
3. RPA 再读取标准数据文件，打开电商后台，把每条数据自动填到发布表单中，提交审核。

这里有一个非常重要的设计原则：采集和上架之间必须有清洗环节，清洗之后必须有人工抽样审核的入口。很多新手图省事，RPA 采集完直接让 RPA 上架，结果标题里面全是“厂家直销”“现货批发”这类 1688 风格词，属性表里面还有很多无效值，一发布就被平台拦截，返工反而更浪费时间。正确做法是在清洗环节把字段完全标准化，并且生成一份清洗报告，让你扫一眼就知道这次采集了多少条、清洗后剩多少条、每条是否包含完整的必填字段。

3. 采集端落地：从 1688 页面到结构化数据

3.1 采集流程的步骤拆解

先用影刀 RPA 搭一个最基础的采集流程。我习惯把流程拆成几个独立的子流程，这样的话任何一个环节出问题，都可以单独重跑，不会整条线断掉。

子流程一：登录状态维护。1688 网页版登录态有效期有限，我的做法是：首次在 RPA 浏览器里手动扫码登录一次，顺便把 cookie 存下来；之后每天第一次跑任务之前，先检查登录态，如果失效就唤起浏览器让运营人员重新扫码。这个过程只需要一次人工介入，比频繁处理验证码舒服得多。

子流程二：关键词搜索与列表页采集。输入关键词（比如“保温杯 货源”），进入搜索结果页，RPA 通过元素选择器抓取每个商品卡片的链接。这一步的核心技巧是：不要试图从列表页抓全部字段，列表页有价格、标题、销量这些基础信息就够了，真正完整的商品参数必须进详情页。

子流程三：详情页数据采集。在详情页里，RPA 需要抓取的内容包括：主图链接列表、SKU 规格与价格、起批量、库存、详情页图片链接列表、类目路径、关键属性（品牌、材质、容量、风格等）。抓取策略要注意处理页面异步加载——有些属性数据要先滚动到某个位置才渲染出来，所以我在 RPA 里加了“滚动页面—等待元素出现—再抓取”的动作，避免拿到的字段为空。

子流程四：数据落盘。每条商品数据组装成 JSON 对象，追加写入采集结果文件。同时维护一个 collected_links 表，记录本次已采集的链接，避免重复采集。

3.2 字段设计：哪些必须采集，哪些可以在清洗阶段补全

先列一下我实际在用的采集字段表：

为什么建议 SKU 列表一定要采集？因为后续上架时，不同平台（淘宝、拼多多、抖店）对 SKU 的格式要求不一样，如果在采集阶段就把 SKU 明细保存成结构化数据，清洗阶段就可以自由转换；如果只采一个区间价，后面做 SKU 映射就得重新回源头找，那自动化就失去意义了。

3.3 写一个简单的 RPA 示例片段（以影刀为例）

影刀里不需要写完整代码，但它的“执行 Python 代码”组件非常适合做数据格式化。举个例子，我在采集详情页时，会把页面上的价格文本提取出来传给 Python 函数处理：

python复制import json
import re
from typing import List, Dict

def parse_price_text(raw_text: str) -> Dict[str, float]:
    """
    处理从页面提取的价格文本，支持 '¥12.00-¥25.00'、'12到25元'、'起批量≥10件' 等格式
    """
    raw_text = raw_text.replace("¥", "").replace("￥", "").strip()
    numbers = re.findall(r"\d+\.?\d*", raw_text)
    if len(numbers) == 0:
        return {"price_min": 0, "price_max": 0}
    if len(numbers) == 1:
        price = float(numbers[0])
        return {"price_min": price, "price_max": price}
    return {"price_min": float(numbers[0]), "price_max": float(numbers[1])}

def build_product_json(link: str, title: str, price_text: str,
                       skus: List[Dict], images: List[str]) -> str:
    """
    组装单条商品 JSON，方便落盘
    """
    price_info = parse_price_text(price_text)
    product_data = {
        "product_url": link,
        "title": title,
        "price_min": price_info["price_min"],
        "price_max": price_info["price_max"],
        "skus": skus,
        "main_images": images[:5],
        "detail_images": images[5:]
    }
    return json.dumps(product_data, ensure_ascii=False)

# 在影刀的“执行Python代码”组件中，直接调用上述函数即可

这个片段解决了两个常见麻烦：一是价格文本格式千奇百怪，用正则统一提取数字；二是数据结构化，组装成 JSON 后落盘、传输都方便。

4. 用 pandas 把“脏数据”变成“上架就过”的干净数据

采集只是第一步，真正的核心在清洗，这也是整个闭环里最值得花时间的部分。平台对商品发布的审核越来越严格，如果你直接把 1688 的标题、属性、图片原封不动搬过去，大概率被判定为重复铺货或者劣质商品，轻则下架，重则扣分。所以清洗的目标不只是去掉换行符，而是要从标题、价格、图片、属性四个维度全面标准化。

4.1 标题清洗：去营销词 + 重写标题

1688 的标题通常带着一堆 B 端味道的词，比如“厂家直销”“现货批发”“一件代发”“爆款”“网红同款”等。这些词对 C 端消费者没有吸引力，有的平台还会因为有夸大宣传嫌疑直接拦截。

我的标题清洗逻辑分三步：

1. 建立营销词库，用正则或简单替换把这类词全部剔除；
2. 提取核心词和规格词（材质、容量、颜色、尺寸等），如果没有明显问题就直接用清洗后的标题，但会过滤掉所有特殊符号（如【】、[]、| 等）；
3. 如果清洗后标题字数低于 10 个字或者明显缺失卖点，就标记为“需要人工优化”，在上架前人工聚合并批处理。

python复制import pandas as pd

def clean_title(title: str) -> str:
    """
    标题清洗：去除营销词、特殊符号、多余空格
    """
    marketing_words = ["厂家直销", "现货批发", "一件代发", "爆款", "网红同款",
                       "支持混批", "秒杀", "清仓", "尾货"]
    for w in marketing_words:
        title = title.replace(w, "")
    # 替换特殊符号
    title = re.sub(r"[【】\[\]|｜{}]", " ", title)
    title = re.sub(r"\s+", " ", title).strip()
    return title

def process_titles(df: pd.DataFrame) -> pd.DataFrame:
    df["clean_title"] = df["title"].apply(clean_title)
    # 过滤明显不合格的标题
    df["title_valid"] = df["clean_title"].apply(lambda x: len(x) >= 10)
    return df

提示：如果标题清洗后出现词序错乱，建议不要盲目重写，模型重写标题是另一套复杂度了，先用“删词保序”策略，至少语义是通顺的。真要重写，可以后续接大模型接口，但那是另一个话题。

4.2 价格与库存计算：平台差异巨大

1688 的价格体系是“阶梯价”，比如 10 件以内 15 元、10 件以上 13 元，还可能有“混批价”。但淘宝、拼多多、抖店的 SKU 定价模型各不相同，有些要求每个 SKU 单独价格，有些支持区间价展示。

我的做法是：取 1688 最低阶梯价作为成本价，然后按预设的利润率计算售价。这里会用到以下公式：

售价 = 成本价 / (1 - 利润率)
到手价 = 售价 + 运费 + 包装成本

这里要注意的是利润率的计算基数。我最初犯过一个错误，直接用 成本价 × (1+利润率) 来定价，结果平台抽佣、运费、优惠券层层叠加之后，实际利润直接从 15% 降到了 5%。后来改成除以 (1-利润率) 的方式，才把利润留出来。

清洗环节里我会批量生成一个 target_price 字段，同时根据平台规则计算运费模板。下面是一段示例：

python复制def calc_sale_price(cost: float, profit_rate: float = 0.3,
                    shipping_cost: float = 3.0, pack_cost: float = 1.0) -> float:
    """
    根据成本、利润率、运费、包装费计算建议售价
    """
    if cost <= 0:
        return 0
    price = cost / (1 - profit_rate) + shipping_cost + pack_cost
    return round(price, 2)

def enrich_price(df: pd.DataFrame) -> pd.DataFrame:
    df["target_price"] = df["price_min"].apply(calc_sale_price)
    df["profit_per_item"] = df["target_price"] - df["price_min"] - 3.0 - 1.0
    return df

价格计算看似简单，但实际上要小心的地方很多：平台佣金率不一样、类目不同佣金不同、是否有运费险、活动报名价要求等。所以我建议把利润计算逻辑集中到一个配置文件中，每次调整只改配置文件，不用动主流程代码。

4.3 图片处理：统一尺寸、压缩体积、检查合规

1688 的主图尺寸通常是 800x800 或 1000x1000，但不同平台对主图的要求不一样，比如淘宝要求 800x800 以上、拼多多建议 480x480 以上、抖店要求 600x600 以上。再加上商品图片体积往往超过 2MB，上传慢而且容易被压缩，所以清洗阶段我会批量处理所有图片。

python复制import os
from PIL import Image

def process_image(src_path: str, dest_path: str, target_size=(800, 800),
                  quality: int = 85) -> str:
    """
    统一尺寸、压缩体积。返回目标路径
    """
    img = Image.open(src_path)
    img = img.convert("RGB")
    img = img.resize(target_size, Image.LANCZOS)
    img.save(dest_path, "JPEG", quality=quality, optimize=True)
    return dest_path

图片这块有两点特别提醒：

1. 版权风险：1688 的商品图大多是供应商拍摄的，直接拿来商用有版权隐患。比较稳妥的做法是：跟供应商确认是否有授权发货和图片使用权限，如果对方平台明确禁止图片搬运，就联系供应商提供原始素材或者自行拍摄。不建议用去水印工具硬来，这是给自己埋雷。
2. 图片批量重命名：上架时图片名最好跟商品 ID 关联，比如 SKU1024_01.jpg，在 RPA 上架时按文件名顺序填充，避免图片对应错位。这个细节看着不起眼，出问题后排查极其痛苦。

4.4 用“规则引擎”管理清洗逻辑

清洗越来越复杂之后，我发现最好的做法是把清洗规则做成“可配置”，而不是写死在代码里。比如标题营销词列表、价格计算利润率、属性映射表，全部放到一个 config.yaml 或者 JSON 配置文件里。这样运营想调整利润率，直接改配置重新跑一遍就行了，不用每次找开发改代码重发版本。

json复制{
  "title_rules": {
    "remove_words": ["厂家直销", "现货批发", "一件代发"],
    "min_length": 10
  },
  "price_rules": {
    "profit_rate": 0.3,
    "shipping_cost": 3.0,
    "pack_cost": 1.0
  },
  "image_rules": {
    "size": [800, 800],
    "quality": 85
  }
}

这个配置文件天然成了“运营规则库”，不同类目可以配置不同规则，之后切换类目只换一个配置就行，这是一个很实用的工程习惯。

5. 上架环节：RPA 如何把数据安全地填进后台

5.1 上架前的二次校验

清洗完的数据还不能直接上架。我的流程里面，清洗阶段生成的“标准数据文件”会先经过一道二次校验，校验规则包括：

• 必填字段完整性：标题、主图、价格、库存、类目必须非空；
• 数值合理性：售价必须大于成本价，库存不小于 0，售价不能低于平台最低限价；
• 图片文件存在性：图片路径必须真实存在，不能是死链；
• 标题合规性：不能包含违禁词（平台有公开的违禁词表，我会导入进来做匹配）。

校验通过的数据生成一个 publish_ready.csv，校验失败的数据写入 rejected.csv 并标记原因。这一步必须保留，因为自动化流程里最怕的就是“坏数据悄悄溜过去”，如果校验不通过也硬上架，平台处罚是很大的成本。

5.2 RPA 自动化发布流程

上架环节我用 RPA 模拟后台操作，流程是：

1. 读取 publish_ready.csv 的每一行；
2. 在 RPA 中打开店铺后台的“发布商品”页面；
3. 选择类目（通过类目映射表，把 1688 类目映射到平台类目，这个映射表需要人工维护，我后面会细讲）；
4. 填充标题、价格、库存、SKU 规格，上传主图和详情图；
5. 设置运费模板、库存预警、上架时间；
6. 点击提交，检测是否弹出错误提示；如果出现错误，截图并记录日志，然后继续下一件商品。

这里想强调一个很容易被忽略的点：RPA 上架不是把数据填进去就完事了，一定要做“提交结果检测”。怎么检测？在影刀里，提交后可以等待页面跳转到“发布成功”页面，或者查找页面上的“商品审核中”“提交成功”这类提示文案；如果页面还停留在表单页，那大概率是校验失败了，需要截屏留证。这一步我最初没做，结果一批商品其实没发出去，我却以为全成功了，白白等了几天。

5.3 类目映射与属性映射的维护

每个平台的商品类目跟 1688 的类目并不完全相同，比如 1688 里“日用餐具”下的某个子类，在淘宝可能要映射到“居家日用品>>餐具”下面的另一个子类。这个映射关系天然无法完全自动完成，最好的办法是维护一张类目映射表：

csv复制source_category,target_platform,target_category
日用餐具,淘宝,居家日用品>>餐具
日用餐具,拼多多,餐厨具>>餐具

属性映射类似，1688 的属性键值对（比如“材质: 304不锈钢”）到平台属性（比如“材质: 不锈钢/钢”），很多平台的属性值是枚举值，不是自由文本，需要提前配置好。

提示：这个类目和属性映射表，建议每个月花半天时间维护一次，拿平台后台的发布类目页面做参考，把最近新增的类目补上。映射表不维护，自动化就跑不长久。

6. 调度、告警与稳定性：从“能跑”到“一直跑”

6.1 定时任务与任务编排

整个闭环里，采集和上架是两个独立的定时任务。采集任务我设置了每天凌晨 2 点跑，因为凌晨平台访问量小、页面加载快，而且第二天早上醒来就能看到采集结果；上架任务通常设定在早上 9 点到 11 点之间，尽量避开平台高峰时段，减少被风控的几率。

如果你采集的商品量特别大（比如一天几千条），建议把采集任务拆成“分批跑”：按关键词或类目分成多个子任务，每个子任务中间留出 10 到 15 秒的间隔。这样做既是为了稳定，也是为了给网络和页面加载留出缓冲。

6.2 失败告警：让流程出问题时第一时间通知你

自动化流程跑在无人值守的环境里，最怕的就是跑挂了你都不知道。所以我给整个流程加了两层告警：

1. 影刀自带的失败通知：设置任务执行失败后发送短信或邮件；
2. 在 Python 清洗脚本里加了一个“钉钉机器人”推送：清洗完成后，把成功条数、失败条数、异常类型摘要推送到群消息里，这样每天早上一睁眼就知道昨晚跑了些什么。

示例代码：

python复制import requests

def send_dingtalk_alert(msg: str, webhook_url: str) -> None:
    """推送告警消息到钉钉群"""
    payload = {
        "msgtype": "text",
        "text": {"content": f"[选品自动化] {msg}"}
    }
    requests.post(webhook_url, json=payload, timeout=10)

类似的告警也可以接入企业微信、飞书或者邮件，看团队用哪个方便。重点不是钉钉，而是“异常一定要主动暴露”，不能等运营发现“怎么今天没上新”才意识到出了问题。

6.3 节流与风控：保护你的账号

1688 对频繁请求是有一定风控策略的，RPA 采集时如果页面切换太快、请求频率太高，很容易触发滑块验证或账号限制。这里我总结了几条实操建议：

• 单个商品详情页采集间隔设为 3 到 5 秒，不要设 1 秒；
• 每个搜索词最多采集前 5 页，避免异常流量特征；
• 每次采集任务的总量控制在 300 到 500 条以内，超出部分等下一轮；
• 如果出现滑块验证码，让 RPA 自动截图并暂停任务，等人工处理完再继续跑；
• 尽量避免同时开多个 RPA 实例去采集同一个账号。

这个“稳妥”原则同样适用于上架环节：发布商品本来就是一个低频操作，如果你一天上架几百个商品，且全部是同一 IP 快速操作，平台后台很容易提示异常。所以我的默认策略是：每次上架间隔 10 到 20 秒，每批次不超过 50 条，宁可跑得慢一点，也要保证账号安全。

6.4 日志体系：事后排查的唯一线索

还有一件事必须养成习惯：每个环节都要写日志。RPA 这边可以记录“采集到第 N 个商品”“进入详情页失败”“提交成功/失败”等状态；Python 这边用 logging 模块记录清洗前/后的数据量、异常记录。日志文件按日期切分，保留最近 30 天。

python复制import logging

logging.basicConfig(
    filename=f"logs/clean_{datetime.now():%Y%m%d}.log",
    level=logging.INFO,
    format="%(asctime)s %(levelname)s %(message)s",
)
logger = logging.getLogger(__name__)
logger.info("开始清洗，读取 %d 条原始数据", raw_count)

在没有日志的情况下排查一个“为什么昨天上架失败了”，基本上靠猜；有了日志，五分钟就能定位是采集异常、清洗异常还是上架异常。这个习惯能省下的时间，远比你写日志花的时间多。

7. 常见问题与排查技巧实录

7.1 页面改版导致选择器失效

这类问题出现的频率最高。1688 的页面每年都会改版几次，RPA 里的元素选择器一失效，整个采集流程就报错。我的应对方案是：

• 选择器不要写死成绝对路径，尽量用文本定位（比如“价格”文本附近的元素）、相对位置定位；
• 每个核心页面节点做“存在性检查”，如果页面加载后没找到目标节点，先等 2 秒再重试，重试 3 次仍失败就跳过；
• 定期跑一条冒烟测试任务，检查常用页面是否正常，如果冒烟失败，第一时间人工介入更新选择器。

7.2 登录态频繁失效

RPA 浏览器保存的 cookie 可能因为账号在别处登录、安全策略等原因失效。处理办法是：

• 尽量用独立的浏览器环境跑 RPA，不要和日常浏览器混用；
• 登录态失效时自动触发“扫码重新登录”流程，而不是直接报错退出；
• 如果频繁失效，检查账号是否被平台要求二次验证，那就需要人工介入一次。

7.3 清洗后的价格与平台最低价冲突

有些平台（尤其是拼多多）对部分类目有最低价限制，你的售价不能低于某个值。我的建议是在 config.yaml 里增加一个 platform_min_price 配置项，清洗阶段如果计算出的售价低于平台最低价，自动取平台最低价并标记一条日志，方便后续人工核对是否要放弃该商品。

7.4 图片下载失败或文件损坏

批量采集时，图片可能存在下载超时、文件损坏、格式不支持等问题。我的处理策略是：

• 图片下载设置超时时间，超过 10 秒即重试；
• 用 Pillow 打开图片验证完整性，打不开的标记为“图片异常”，不会让它进入上架队列；
• 异常图片单独记录，定期人工补图。

7.5 常见错误速查表

这些坑看着琐碎，但每一个都实实在在会耽误时间。自动化流程的好处是只要把问题修掉，后面就能稳定跑很久，但这些排查经验却是必须踩过坑才能积累下来的。

还有一个小技巧我想分享一下：在 RPA 采集和清洗的中间环节，我保留了一个 pending_review 目录，专门放“所有需要人工看一眼”的商品数据。比如标题清洗后长度低于阈值的、价格明显异常的、图片缺失的，都会被丢到这个目录。每天我只需要花十几分钟扫一遍这个目录，该改的改，该放弃的放弃，然后重新触发一次上架任务即可。这个“半自动”缓冲带让系统既有自动化的速度，又有可控的质量底线。

在实际操作中，我最大的体会是：这类自动化方案真正难的不是写代码，而是把异常处理想周全。页面会改版、登录会失效、平台规则会变、数据质量会波动，只要每一层都做好校验和日志，这个闭环就能长期稳定运行；如果你想着“搞定一次就能永远跑”，那大概率三天两头要去救火。建议第一次落地时不要贪多，先取一个类目 50 到 100 个商品跑通全流程，确认稳定了再逐步放量，这样对整体节奏和账号安全性都更友好。