泛二次元和潮玩零售这几年增长很快，但真正做过这类业务的人都知道，增长并不只是“订单变多”这么简单。它背后会带来一整套更复杂的运营问题：SKU 数量快速增加，预售和现货混在一起，多平台商品要同步上架，库存和发货状态要及时更新，财务流水来自几十个渠道，客服还要处理大量协商发货、延期履约、自提订单。

这些工作单看都不复杂，但一旦规模上来，靠人工复制、录入、核对、同步，就会很快成为业务瓶颈。

模玩熊使用影刀 RPA + AI 的案例，本质上不是简单地“让机器人代替人点击鼠标”，而是把业务里的重复动作、跨系统流转和部分语义判断拆开处理：

RPA 负责稳定执行，AI 负责理解和生成，人负责规则边界和异常判断。

这篇文章尝试从实操角度，把模玩熊的四个落地场景拆成一套可以复刻的技术方案。文章不追求讲概念，而是尽量写清楚：如果我们要自己用影刀复刻，应该准备什么数据表，怎么设计流程，哪些地方用 RPA，哪些地方接 AI Power，哪些地方必须留人工复核。

---

一、整体技术架构：不要一上来就“全 AI”

很多人在看 RPA + AI 案例时，容易产生一个误解：既然接了大模型，是不是所有流程都可以直接交给 AI？

实际落地时恰恰相反。越是业务现场，越要先区分两类任务。

一类是确定性执行任务，比如打开网页、读取 Excel、下载图片、填写表单、录入金蝶、发送消息、修改订单发货时间。这类任务规则明确、动作重复，最适合交给影刀 RPA。

另一类是理解和判断任务，比如识别商品属于哪个 IP、判断某个角色名是否是别名、从多周期搜索指数里发现异常上涨、把数据整理成运营报告。这类任务需要一定语义理解和文本生成能力，适合交给 AI Power 工作流。

所以，比较稳妥的整体架构是：

业务数据源
  ↓
影刀 RPA 采集 / 接收 / 读取
  ↓
中间数据表（Excel / 飞书多维表格 / 数据库）
  ↓
AI Power 工作流识别、判断、生成
  ↓
影刀 RPA 回填、录入、发送、同步
  ↓
人工复核异常数据

这套架构的好处是，每一层都很清楚：

• RPA 不负责“猜”，只负责把动作做稳；
• AI 不直接控制关键系统，而是输出结构化结果；
• 人不再做重复录入，而是维护规则、审核异常和做最终决策。

模玩熊案例中的商品自动上架、IP 流量趋势监测、财务流水清洗录入、客服履约管控，基本都可以放进这套框架里。

---

二、场景一：商品自动上架

商品自动上架看似只是把商品传到平台后台，但二次元和潮玩商品的难点并不在“上传”这个动作，而在“识别”。

比如一款徽章，它可能关联某个 IP、某个角色、某个系列、某个发售批次。供应商给到的标题和图片可能并不标准，如果只打上“动漫周边”“二次元徽章”这种泛标签，商品虽然上架了，但平台和用户都很难准确找到它。

所以这个场景要解决的是：

RPA 把供应商素材采回来，AI 识别 IP、角色、系列和标签，RPA 再把结果回填到商品表和平台后台。

1. 准备商品采集表

不要一开始就直接操作平台后台，建议先准备一张中间表。可以用 Excel，也可以用飞书多维表格。

字段可以这样设计：

字段	说明
商品ID	自定义唯一编号
供应商链接	商品详情页 URL
原始标题	从供应商页面抓取
原始描述	商品详情文本
原始图片链接	商品主图或详情图
图片本地路径	RPA 下载后的图片路径
AI识别IP	AI 输出
AI识别角色	AI 输出
AI识别系列	AI 输出
商品类型	手办、徽章、盲盒、模型等
平台标题	AI 生成或规则拼接
商品标签	AI 输出
平台类目	规则匹配
置信度	AI 输出
是否需要人工复核	true / false
上架状态	待采集、待识别、待复核、待上架、已上架、异常

这张表的作用非常重要。它不是简单的数据容器，而是整个流程的“缓冲层”。即使 AI 识别不准，也不会直接污染平台后台；即使平台上架失败，也可以在表格里看到失败状态和原因。

2. 用影刀 RPA 采集供应商素材

在影刀中新建一个网页自动化流程，主要步骤如下：

打开供应商后台或商品页面
→ 登录账号
→ 进入商品列表页
→ 获取商品列表元素
→ 循环每个商品
   → 点击进入商品详情页
   → 提取商品标题
   → 提取商品描述
   → 提取图片链接
   → 下载图片到本地
   → 写入商品采集表
→ 翻页
→ 继续采集

这里有几个实践细节。

第一，图片建议同时保存“图片链接”和“本地路径”。有些 AI 工作流可以直接识别链接，有些场景更适合传本地文件。保留两个字段后，后面调试会更灵活。

第二，采集流程里要加异常处理。比如某个商品图片加载失败、详情页打不开、字段为空，都不要让整个流程中断，而是把该商品标记为“异常”，并记录失败原因。

第三，不建议一开始采集全部商品。第一次测试可以只跑 20 条到 50 条，先验证字段是否完整、图片是否能下载、表格是否能正常写入。

3. 搭建 AI Power 商品识别工作流

商品识别工作流的输入建议包括：

{
  "title": "商品原始标题",
  "description": "商品原始描述",
  "image": "商品图片链接或本地路径"
}

如果企业内部已经积累了 IP 资料，建议先做一个知识库。知识库里可以放：

• IP 名称表；
• 角色名表；
• 角色别名表；
• 系列名称表；
• 发售批次表；
• 商品类型词库；
• 平台类目规则；
• 禁售词和敏感词规则。

工作流结构可以设计为：

输入商品标题、描述、图片
→ 检索 IP 知识库
→ 大模型识别 IP、角色、系列、类型
→ 输出结构化 JSON
→ 根据置信度判断是否需要人工复核

提示词不要写得太泛。比如不要只写“帮我识别这个商品”，而是写清楚输出格式和判断规则：

你是二次元潮玩商品运营助手。

请根据商品标题、商品描述、商品图片信息，并结合知识库中的 IP、角色、系列资料，识别该商品的结构化信息。

需要识别：
1. IP 名称；
2. 角色名称；
3. 系列名称；
4. 商品类型，例如手办、徽章、盲盒、模型、亚克力立牌等；
5. 适合电商平台使用的商品标题；
6. 商品标签；
7. 平台类目；
8. 识别置信度；
9. 是否需要人工复核。

要求：
- 如果无法确认 IP 或角色，不要编造；
- 如果知识库中没有明确匹配项，请将 need_manual_review 设置为 true；
- 输出必须是 JSON，不要输出解释性文字。

输出格式建议固定为：

{
  "ip_name": "示例IP",
  "character_name": "示例角色",
  "series_name": "示例系列",
  "product_type": "徽章",
  "platform_title": "示例IP 示例角色 正版徽章 动漫周边",
  "tags": ["示例IP", "示例角色", "徽章", "动漫周边"],
  "category": "动漫周边/徽章",
  "confidence": 0.91,
  "need_manual_review": false,
  "reason": "标题和图片均匹配知识库中的角色与系列信息"
}

这里一定要让 AI 输出 JSON。因为 RPA 后续要解析结果，如果输出自然语言，流程稳定性会差很多。

4. RPA 调用 AI 工作流并回写结果

RPA 读取商品采集表中状态为“待识别”的商品，循环调用 AI Power 工作流。

流程如下：

读取商品采集表
→ 筛选状态 = 待识别
→ 循环每一行
   → 读取标题、描述、图片路径
   → 调用 AI Power 商品识别工作流
   → 获取 JSON 输出
   → 解析 ip_name、character_name、series_name 等字段
   → 写回商品采集表
   → 如果 confidence < 0.8，标记为待复核
   → 如果 confidence ≥ 0.8，标记为待上架

置信度阈值可以根据业务调整。刚开始建议设得严格一些，比如 0.85。等知识库和提示词稳定后，再逐步放宽。

5. RPA 自动上架到平台后台

当商品状态变成“待上架”后，RPA 可以继续执行平台上架动作：

打开电商平台后台
→ 登录
→ 点击新增商品
→ 上传商品主图
→ 填写商品标题
→ 选择商品类目
→ 填写规格、价格、库存
→ 填写商品标签
→ 填写商品详情
→ 保存或提交审核
→ 回写商品状态为已上架

这里最容易出问题的是平台后台的元素定位。很多平台后台会不定期改版，如果只靠坐标点击，流程很容易失效。更稳妥的做法是优先使用元素属性定位，比如输入框名称、按钮文本、页面 DOM 元素特征等。

同时，自动上架最好不要一步到位“直接发布”。更安全的方式是先自动保存为草稿，再由运营抽检后批量发布。等流程稳定后，再考虑更高程度自动化。

---

三、场景二：IP 流量趋势监测

二次元零售里，IP 热度本身就是选品和营销信号。某个角色突然出圈，某个经典 IP 周期性回温，某个头部作品热度下滑，都会影响补货、上新和内容投放。

人工监测的问题在于：数据源多、关键词多、周期多，运营很难长期稳定地盯住每一个变化。模玩熊的做法是让 RPA 定时抓取搜索指数，再由 AI 生成异动洞察报告。

1. 准备 IP 监控表

建议先建立一张 IP 监控表：

字段	说明
IP名称	例如某动漫、游戏、角色系列
关键词	实际搜索词
平台	百度指数、巨量算数、小红书、淘宝等
7日指数	RPA 抓取
15日指数	RPA 抓取
30日指数	RPA 抓取
60日指数	RPA 抓取
90日指数	RPA 抓取
周环比	表格公式或 RPA 计算
月环比	表格公式或 RPA 计算
异动类型	AI 输出
动作建议	AI 输出
更新时间	RPA 写入

如果关键词很多，可以再加一张“关键词池表”，用于维护 IP 和关键词的映射关系。

2. RPA 定时抓取指数数据

在影刀中配置定时任务。例如每天上午 9 点运行一次，或者每周一上午生成周报。

流程可以这样设计：

定时触发流程
→ 打开搜索指数平台
→ 登录账号
→ 读取 IP 监控表中的关键词
→ 循环每个关键词
   → 输入关键词
   → 切换 7日维度
   → 抓取指数
   → 切换 15日维度
   → 抓取指数
   → 切换 30日维度
   → 抓取指数
   → 切换 60日维度
   → 抓取指数
   → 切换 90日维度
   → 抓取指数
   → 写回 IP 监控表
→ 计算环比变化
→ 标记数据更新时间

这里也有几个实操注意点。

第一，很多指数平台会有反爬或登录校验，所以流程里要预留登录检测。如果检测到账号掉线，就暂停流程并通知人工处理。

第二，抓取数据时要注意页面加载时间。不要刚切换周期就立即取数，最好等待目标元素出现，或者设置合理的延时。

第三，尽量保留历史快照。不要每次只覆盖最新数据。可以把每次抓取结果写入“历史明细表”，再由汇总表计算趋势。否则后续很难追溯某个 IP 是何时开始上涨的。

3. AI 生成 IP 异动报告

当数据抓取完成后，RPA 可以把最新数据传给 AI Power 工作流，由 AI 生成报告。

提示词可以这样写：

你是二次元潮玩零售行业的数据分析助手。

请根据输入的 IP 搜索指数数据，生成一份《IP 搜索大盘异动洞察报告》。

分析规则：
1. 如果某 IP 的周环比涨幅超过 30%，标记为“短期爆发”；
2. 如果某 IP 连续多个周期上涨，标记为“持续升温”；
3. 如果某 IP 90日均值较高，但近 7 日明显下降，标记为“头部回落”；
4. 如果某长尾 IP 基数不高但增速明显，标记为“潜力观察”；
5. 如果某 IP 连续下降，标记为“热度走弱”。

请输出：
- 本周核心结论；
- 短期爆发 IP；
- 持续高热 IP；
- 热度走弱 IP；
- 长尾机会；
- 选品建议；
- 补货建议；
- 内容营销建议；
- 需人工复核的数据异常。

输出格式为 Markdown。

AI 输出报告可以长这样：

# IP 搜索大盘异动洞察报告

## 一、本周核心结论

本周大盘整体搜索热度较上周上涨 12%。其中，A IP 出现短期爆发，7 日搜索指数环比提升 36%；B IP 虽然仍处于头部位置，但近 7 日指数连续下滑，需要关注后续热度回落风险。

## 二、短期爆发 IP

| IP | 7日指数 | 周环比 | 异动判断 |
|---|---:|---:|---|
| A IP | 120000 | +36% | 短期爆发 |

## 三、运营建议

1. A IP 可优先检查现货库存，适当增加徽章、亚克力立牌等低客单价周边曝光；
2. 对 B IP 暂缓大批量补货，优先观察下周趋势；
3. 长尾 IP C 虽然基数不高，但增速明显，可尝试小批量测试上新。

4. 自动推送给运营团队

最后由 RPA 把报告发送到飞书、企业微信、钉钉或邮箱。

流程如下：

获取 AI 生成报告
→ 读取接收人或群机器人地址
→ 发送 Markdown 报告
→ 附带原始数据表链接
→ 更新本次任务状态

这个流程做完后，运营不需要每周手动查几十个关键词。RPA 把数据拿回来，AI 先做初步洞察，人再决定是否补货、投流、联名或上新。

---

四、场景三：财务流水清洗及录入

财务场景和前两个场景不同，它不适合大量使用 AI。原因很简单：财务数据不能“差不多”，也不能让模型自由发挥。

因此，财务流水清洗和录入应该以 RPA 规则执行为主，AI 最多用于辅助解释异常，不建议直接参与核心记账判断。

1. 准备渠道字段映射表

模玩熊每月要处理 50 多家银行和支付平台流水，不同渠道的表头、字段顺序、时间格式都不一样。要自动化，第一步不是写流程，而是做映射表。

示例：

渠道	原字段名	标准字段名	转换规则
支付宝	交易创建时间	交易时间	转为 yyyy-MM-dd
支付宝	交易金额	金额	保留两位小数
微信支付	支付时间	交易时间	转为 yyyy-MM-dd
微信支付	商户订单号	订单号	原样保留
某银行	借方金额	支出金额	空值转 0
某银行	贷方金额	收入金额	空值转 0

2. 准备科目匹配表

再准备一张科目规则表：

关键词	方向	借方科目	贷方科目	摘要模板
商品销售	收入	银行存款	主营业务收入	商品销售收款
退款	支出	主营业务收入	银行存款	用户退款
平台服务费	支出	销售费用-平台服务费	银行存款	支付平台服务费
运费	支出	销售费用-物流费	银行存款	支付物流费用

这个表要由财务人员确认，不建议技术人员自己拍脑袋定义。

3. RPA 批量读取流水文件

把各渠道流水文件统一放到指定文件夹，影刀流程从文件夹开始读取。

流程如下：

读取流水文件夹
→ 获取所有 Excel / CSV 文件
→ 循环每个文件
   → 判断渠道来源
   → 读取表头
   → 根据字段映射表识别字段
   → 清洗时间格式
   → 清洗金额格式
   → 清洗摘要和对方账户
   → 写入标准流水表

标准流水表可以设计为：

字段	说明
渠道	支付宝/微信/银行等
交易时间	标准日期格式
订单号	如有
摘要	清洗后摘要
收入金额	标准金额
支出金额	标准金额
对方账户	如有
匹配状态	已匹配/待复核
借方科目	规则输出
贷方科目	规则输出
凭证状态	待录入/已录入/异常

4. RPA 自动匹配科目

接下来，RPA 读取标准流水表，按规则匹配科目：

读取标准流水表
→ 循环每一行
   → 判断收入或支出
   → 根据摘要、渠道、交易方匹配关键词
   → 写入借方科目和贷方科目
   → 如果匹配不到，标记为待复核

这里不要为了追求 100% 自动化而强行匹配。实际项目里，最重要的是把 80% 到 90% 的标准流水自动处理掉，剩下异常交给财务复核。这样既能提升效率，也能降低风险。

5. RPA 批量录入金蝶

如果金蝶开放 API，优先使用 API 写入；如果没有接口，就用影刀模拟人工操作金蝶页面或客户端。

流程如下：

打开金蝶系统
→ 登录账号
→ 进入凭证录入页面
→ 读取标准凭证表
→ 筛选凭证状态 = 待录入 且 匹配状态 = 已匹配
→ 循环每一行
   → 填写凭证日期
   → 填写摘要
   → 填写借方科目
   → 填写贷方科目
   → 填写金额
   → 保存凭证
   → 回写凭证状态 = 已录入

为了保证稳定性，建议加三个机制：

第一，录入前校验。比如借贷是否平衡、金额是否为空、科目是否存在。

第二，录入后截图或日志。每条凭证录入完成后保存凭证号或截图，便于追溯。

第三，异常中断保护。如果某条凭证录入失败，只标记该条异常，不要影响后续流水处理。

---

五、场景四：客服履约管控

客服履约场景的核心不是 AI，而是及时性。预售、囤货、自提订单如果没有及时协商发货时间，就可能被平台判定延迟发货，产生罚金。

人工最大的问题是覆盖不了夜间和大促高峰。RPA 的价值在这里非常直接：7×24 小时监控订单，发现符合规则的订单后自动协商、自动修改发货时间。

1. 准备订单履约规则表

先把客服规则表整理出来：

订单类型	判断条件	协商话术	延期天数	是否自动处理
预售订单	商品标题含“预售”	亲亲，该商品为预售商品，预计发货时间为……	30	是
囤货订单	买家备注含“囤货”	亲亲，已为您登记囤货需求，将按约定时间发出……	15	是
门店自提	配送方式=门店自提	亲亲，您的订单为门店自提，请到店核销……	7	是
异常订单	缺少订单信息	转人工处理	0	否

话术要由客服主管确认，不能让 AI 随机生成。履约类沟通对合规和平台规则比较敏感，建议使用固定模板。

2. 用 Webhook 接收订单事件

如果订单系统支持事件推送，可以用 Webhook 触发影刀流程。

订单系统推送的数据大概长这样：

{
  "order_id": "202607280001",
  "platform": "淘宝",
  "buyer_id": "user123",
  "product_title": "某某IP 徽章 预售",
  "order_tag": "预售",
  "delivery_type": "快递",
  "deadline": "2026-07-30 23:59:59"
}

影刀流程接收到 Webhook 后，先解析 JSON，拿到订单号、商品标题、订单标签、发货截止时间等字段。

流程如下：

Webhook 接收订单事件
→ 解析 JSON
→ 获取订单号、商品标题、订单标签
→ 写入订单处理表
→ 判断是否需要协商发货

如果订单系统不支持 Webhook，也可以退一步，用 RPA 定时轮询订单后台，比如每 10 分钟抓取一次待处理订单。但从实时性角度看，Webhook 更适合这个场景。

3. 判断订单类型

RPA 根据订单规则表进行判断：

读取订单信息
→ 判断商品标题是否包含“预售”
→ 判断买家备注是否包含“囤货”
→ 判断配送方式是否为“门店自提”
→ 匹配对应话术和延期天数
→ 如果无法匹配，转人工

这里不一定需要 AI。因为预售、囤货、自提通常有明确标签或关键词，用规则判断更稳定。

只有在买家备注特别复杂、需要理解自然语言时，才可以接一个 AI 节点辅助判断，例如判断“我不急，等其他商品一起发”是否属于囤货诉求。但即使使用 AI，也建议输出“建议分类”，最终仍由规则控制是否自动执行。

4. 自动发送协商话术并修改发货时间

匹配成功后，RPA 打开客服工作台或订单后台：

打开客服工作台
→ 搜索订单号
→ 进入买家会话
→ 根据订单类型选择话术模板
→ 发送协商消息
→ 打开订单详情
→ 修改承诺发货时间
→ 保存
→ 回写处理状态

为了避免重复发送，可以在订单处理表里加一个字段：

字段	说明
是否已发送协商话术	是/否
是否已修改发货时间	是/否
最后处理时间	时间戳
处理结果	成功/失败/转人工

每次流程开始前先检查订单是否已经处理过，避免同一个订单重复发消息。

---

六、四个场景的实施顺序

如果是企业真实落地，不建议一开始就同时做四个场景。比较稳妥的顺序是：

第一阶段：财务流水清洗

这个场景规则最明确，ROI 最容易计算。比如过去每月需要 2 人 2 天，现在压缩到几个小时，效果非常直观。而且它不太依赖 AI，流程稳定性更容易保证。

第二阶段：客服履约管控

这个场景的业务价值也很清楚：减少延迟发货罚金，覆盖夜间订单洪峰。只要订单规则和话术模板梳理清楚，就能比较快上线。

第三阶段：IP 趋势监测

这个场景开始引入 AI 生成报告，但风险相对可控。即使 AI 报告不完美，也不会直接影响交易系统，运营可以把它当作辅助分析。

第四阶段：商品自动上架

商品自动上架最复杂，因为它涉及图片识别、IP 知识库、平台字段、类目规则、库存价格、平台后台变动等问题。建议最后做，先从“AI 识别标签 + 人工复核”开始，不要一开始就全自动发布。

---

七、落地中最容易踩的坑

1. 没有中间表，直接让 RPA 操作后台

很多失败的 RPA 项目都有一个共同问题：流程直接从 A 系统操作到 B 系统，中间没有状态表。一旦失败，很难知道失败在哪一步。

正确做法是用 Excel、飞书多维表格或数据库做中间层，把每条数据的状态记录下来。

2. AI 输出自然语言，导致 RPA 无法稳定解析

AI 很擅长写解释，但 RPA 需要的是稳定字段。所以涉及流程衔接时，一定要让 AI 输出 JSON 或固定格式表格。

3. 追求 100% 自动化，忽略异常复核

真实业务里，异常永远存在。商品识别会有低置信度，财务流水会有无法匹配的科目，订单会有特殊备注。流程设计时应该预留“待人工复核”状态，而不是强行自动处理。

4. 只做流程，不维护规则

RPA + AI 不是一次性项目。IP 资料库要更新，科目规则要维护，客服话术要根据平台政策调整，商品类目也可能变化。如果没有人持续维护规则，流程上线后很快会失准。

5. 没有日志和回滚机制

每个自动化流程都应该记录：

• 处理时间；
• 输入数据；
• 输出结果；
• 是否成功；
• 失败原因；
• 操作截图或凭证号；
• 处理人或机器人账号。

尤其是财务和订单履约场景，日志非常重要。

---

八、一个最小可用版本怎么做

如果你想快速验证模玩熊这套方案，不建议一开始做全链路。可以先做一个最小可用版本：

供应商商品表
→ 影刀 RPA 读取标题和图片
→ AI Power 识别 IP、角色、商品类型
→ 结果写回商品表
→ 人工复核
→ RPA 辅助上架

这个版本的好处是：

• 技术链路完整；
• 风险可控；
• 能验证 AI 识别准确率；
• 能测试影刀调用 AI 工作流是否稳定；
• 不会因为识别错误直接影响平台商品。

等这个小流程跑顺后，再扩展到 IP 趋势监测、客服履约和财务录入。

---

九、总结

模玩熊的影刀 RPA + AI 落地方案，真正值得学习的不是某一个单点功能，而是一种业务自动化的拆解方法。

它不是简单地把人工操作搬给机器人，也不是盲目地把所有判断都交给大模型，而是把流程拆成三层：

• RPA 做确定性执行：采集、录入、回填、发送、同步；
• AI 做语义理解和内容生成：识别商品标签、分析趋势、生成报告；
• 人做规则和边界控制：维护知识库、审核异常、决定策略。

对于潮玩、二次元、电商零售这类 SKU 多、平台多、数据多、履约规则复杂的业务来说，这种架构非常适合复刻。

如果要真正落地，建议从最稳定的规则型场景开始，例如财务流水清洗、客服履约自动化；再逐步进入带 AI 判断的场景，例如 IP 趋势监测和商品自动上架。这样既能尽快看到效率提升，也能避免一开始就陷入复杂的 AI 准确率和平台后台适配问题。

最终，RPA + AI 的价值不是“替代所有人”，而是把人从复制、录入、核对、搬运中解放出来，让业务人员回到更重要的位置：制定规则、判断异常、做运营决策。

参考文献模玩熊：RPA+AI捕捉潮玩IP热点，让运营响应更快一步