抖音小店 RPA 踩坑实录：页面改版流程集体失效，我用 LLM 视觉元素自愈架构救回全部流程

一、事故复盘：一场前端改版，三十多条流程集体阵亡

我们团队维护的抖音小店自动化体系不算复杂：店铺后台批量改价、订单导出对账、商品库同步、客服消息获取，前前后后用 RPA 搭了三十多条流程，稳定跑了半年多。

直到平台后台推了一轮前端改版。

当天早上一开门，值班同学就看到监控群里一片红：改价流程全部报"元素未找到"，订单导出卡在登录弹窗。打开流程编辑器一看，定位按钮的 XPath 全部失效——DOM 结构整体重构，class 命名从语义化驼峰改成了哈希字符串。

手工修复花了两天：重新选元素、调路径、回归测试。我们当时以为这只是偶发事件。

结果两个月后第二轮改版来了，连登录弹窗的层级都变了，封装好的"点击登录"子流程直接报废。第三次事故之后我们彻底想明白一件事：

平台改版不是黑天鹅，是必然事件。流程失效不是 bug，是 RPA 的常态。真正的问题只有一个——你的流程在失效之后，能不能自己活过来。

这篇文章完整记录我们从"人肉修流程"进化到"LLM 视觉元素自愈架构"的全过程，包括架构设计、关键实现和踩坑经验。

二、根因分析：为什么传统元素定位在电商场景里如此脆弱

三次事故复盘下来，问题集中在三个层面：

1. 单一路径依赖。 传统 RPA获取元素，本质是记录一份 DOM 快照，下次按图索骥。平台一改版，快照作废，没有任何兜底。

2. 没有视觉感知能力。 元素找不到时，流程只会报错中断，不会像人一样"看一眼屏幕，找找按钮现在长什么样、挪到哪去了"。

3. 修复链路全靠人。 每次失效都要人工排查、改代码、回归测试。改版越频繁，维护成本越接近把流程重做一遍。

对应地，我们给自愈架构定下了三条设计目标：

• 路径失效时，自动切换到更稳定的候选路径；
• 候选路径全部失效时，LLM 结合截图做视觉级重新定位；
• 连视觉也搞不定时，AI 自动诊断错误、给出修复建议并可一键修复，而不是甩给人一堆看不懂的报错堆栈。

三、自愈架构设计：四层兜底体系

整体架构分四层，自愈能力从低成本到高成本逐级升级

┌─────────────────────────────────────────────┐
│ L1  多候选路径自切换   （毫秒级，无 AI 开销） │
│ L2  AI 智能路径生成    （秒级，少量 token）   │
│ L3  LLM 视觉识别定位   （十秒级，多模态调用） │
│ L4  AI 错误诊断+修复   （人工确认后执行）     │
└─────────────────────────────────────────────┘
         任一层级恢复成功 → 流程继续执行
         全部失败 → 推送告警 + AI 生成修复报告

核心调度逻辑伪代码如下：

def locate_element(page, element_profile):
    # L1：按稳定性得分降序依次尝试本地候选路径
    for path in element_profile.candidate_paths_sorted_by_score():
        node = page.query(path)
        if node and node.visible:
            return node

    # L2：AI 基于当前 DOM 重新生成路径（自然语言描述，无需手写 XPath）
    new_paths = ai.generate_xpath(
        dom=page.html,
        description=element_profile.nl_description  # 如："蓝色的立即改价按钮"
    )
    for path in new_paths:
        node = page.try_query(path)
        if node:
            element_profile.add_path(path)   # 验证通过才回填，防止脆弱路径污染候选池
            return node

    # L3：LLM 视觉定位——截图 + 历史样例图，输出坐标或新路径
    result = llm.visual_locate(
        screenshot=page.screenshot(),
        reference=element_profile.sample_image,
        hint=element_profile.appearance       # 文字、颜色、大致位置
    )
    if result.confidence > 0.85:
        return page.at(result.target)

    # L4：交给 AI 错误诊断，人工确认后一键修复
    report = ai.diagnose(page, element_profile)
    alert(report)  # 推送到钉钉/飞书，附原因与修复建议
    raise ElementUnrecoverable

这套"分层兜底"的关键思想是：能用规则解决的绝不调 AI，能调轻量模型的绝不调多模态模型。因为 AI 的 token 是持续成本，架构上必须精打细算。

四、关键实现细节

4.1 元素获取：让系统本地智能生成多路径，而不是手工选一条

自愈的前提是元素获取阶段就不留单点。我们的做法是：获取元素时不只记录一条 XPath，而是由系统本地智能生成多条候选路径——分别按 id、文本内容、class、层级关系、相对坐标等维度生成，并自动给出稳定性评分。

这样做还有一个附带好处：完全不需要学习 XPath 语法。运营同事用自然语言描述"我要点那个蓝色的'立即改价'按钮"，AI 就能生成并优化对应的路径。抖音小店后台两轮中等幅度改版中，L1+L2 两层就消化掉了八成以上的失效场景，根本没轮到视觉层出场。

4.2 视觉兜底：LLM 看截图找元素

真正考验架构的是 DOM 整体重构的改版——所有候选路径全部覆没。

这时流程自动截取当前页面，连同元素的历史样例截图、文字特征、颜色特征一起交给多模态大模型，由它判断"这个按钮现在变成了什么样、大概在屏幕什么位置"，输出新路径或直接输出屏幕坐标。拿到结果后系统自动回填元素档案，本次执行继续，后续执行还能复用。

模型选型上没有绑定任何一家：工具本身支持自由对接豆包、DeepSeek、Kimi、文心一言等主流大模型的 API，用哪家、花多少 token 完全自己说了算，费用直连官方按量结算，没有打包订阅的糊涂账。视觉层我们先后对比过豆包和 DeepSeek 的识图效果，按页面类型选了不同的模型，整体 token 开销在可接受范围内。

实测数据：两轮改版中，视觉自愈均在单次执行内完成定位恢复，没有中断任何一次夜间定时任务。

4.3 视觉颜色操作：绕过 DOM 的最后一招

还有一类极端场景：千牛、企业微信等客户端的消息列表，DOM 要么拿不到，要么结构混乱到任何路径都不可靠。

这时候启用视觉颜色操作——不依赖元素节点，按颜色特征、文字区域、截图比对来点击和读取内容，配合截图识图与 OCR 取数，按"红色未读角标"这类视觉特征定位消息。对于读取客服通知这类需求，稳定性反而远超 DOM 解析。除了千牛、企业微信，个人微信和 QQ 的消息通知同样适用——这类客户端的 DOM 基本不可依赖，视觉颜色操作几乎是不二选择。

4.4 AI 错误诊断：把报错翻译成人话

四层全部失效时，系统会把错误日志、当时页面截图、流程上下文交给 AI，输出"错误原因 + 修复建议"，确认后一键修复，AI 自动改流程并反复调试到跑通为止。

印象最深的一次：凌晨两点定时任务报错，早上上班发现系统已经完成诊断、修复、重跑，日志里躺着一条成功记录。这套 AI 错误诊断能力，等于给自动化体系配了一个不下班的值班工程师。

五、AI 生成流程：从"人搭流程"到"描述需求"

自愈解决的是"坏了怎么办"，更大的效率杠杆在搭建阶段。我们把需求直接交给 AI——截图加文字描述即可——由 AI 自动完成网页自动化、Windows 软件自动化和视觉颜色操作的流程搭建：智能分析页面与软件的元素结构，优先调用 RPA 基础指令，基础指令覆盖不到的自动封装成新指令，每条指令带详细注释，逻辑一目了然。

几个显著提效的点：

• AI 生成的脚本可一键转为可视化流程，不锁定在代码形态，后续维护和二次编辑都低门槛；
• 子流程自动拆分：AI 按业务逻辑把重复步骤自动封装成子流程，改一处全局生效；
• 变量批处理：支持变量的批量创建、删除和修改，数据提取、JSON 字段提取、列表拆分，一句话需求即可生成对应指令；
• 自定义界面：跟 AI 描述需求即可根据截图设计软件界面，复杂界面可用 HTML 组件实现按钮、数据展示与数据关联——打包出去的程序长得像正经软件，而不是"技术人员的内部工具"。

这里也总结下我们实践中 AI 与 RPA 的分工，这也是整个体系能长期跑稳的关键：

AI 负责思考，RPA 负责稳定落地。 纯 AI 直接生成的自动化代码，在复杂项目里往往异常分支考虑不周，每次出问题都要重新改，长期维护成本高；而纯人工搭流程又慢。让 AI 做理解、生成、诊断，让经过工程化沉淀的 RPA 引擎做确定性执行。各司其职，这个分工跑上半年，你就回不去了。

六、部署形态：为什么坚持全离线内网部署

方案跑通后，第二个问题接踵而至——数据安全。

电商自动化流程里流转的是什么？订单数据、客户信息、商品价格、店铺经营数据，全是最核心的资产。我们的硬标准只有两条：

1. 流程数据全部保存在本地设备，绝不同步任何服务端；
2. 内网离线环境下流程照常运行，断网不等于全线瘫痪。

最终落地为全离线内网部署：运行环境无需联网授权，流程、账号、日志全在本地。这类架构对个人开发者、个人工作室和中小企业尤其合适——没有上云的合规压力，也不用背一笔按年订阅的固定支出。

成本上补充两个实测结论：

• 免费版没有使用时长和流程数量限制，验证期零成本跑通全部场景；多设备使用也不需要重复开通会员，团队几台机器各装各用即可；
• AI 能力走用户自行对接各平台 API 的模式，费用透明、按量可控，跑量越大越能感受到和订阅制方案的长期成本差距。

七、工程化与分发：EXE 打包、授权与远程调度

流程稳定之后，分发给了合作的几个工作室。这套工程化能力值得单独说：

• 打包导出加密 EXE：对方无需安装任何客户端，双击即用；
• 授权管理：发给 A 的 exe 只能 A 用，可设有效期，到期自动失效；
• 独立设置 API 触发与定时执行：打包时可单独配置，我们内部的订单中台直接以 API 方式调用改价流程，不再依赖定时轮询；
• 在线推送更新：流程改完发一次推送，对方打开应用自动检测升级。不用再挨个发文件，也不用远程守着对方装环境；
• 多店铺场景：已支持对接紫鸟、比特、Hubstudio、AdsPower 等主流指纹浏览器，为每个店铺提供相互独立的浏览器环境，配合本地离线运行，各店铺账号数据互不干扰；
• 远程调度：通过 Agent 能力可在钉钉、飞书、企微里发指令控制流程执行，背后接入了最新的 DeepSeek 模型做智能指令解析，执行完自动回调结果，人不在电脑前也能掌控全局；
• MCP 接入：可对接各类 AI 编程工具，让其他工具也能调度 RPA 流程，扩展性留给未来。

八、经验：五条写给后来者的建议

1. 别再赌平台不改版。 选型时直接问："元素失效了能不能自动修复？"不能自愈的方案，维护成本会指数级增长。
2. AI 调用要分层节流。 规则能解决的别调 AI，轻量模型能解决的别调多模态，token 是持续成本，架构上必须省着用。
3. 数据一定要留在本地。 经营数据上云一时爽，泄露一次哭半年。全离线部署、数据不出本地是底线而非加分项。
4. 流程搭建交给 AI，稳定性交给引擎。 AI 负责思考，RPA 负责稳定落地，这个分工跑半年就回不去了。
5. 分发能力要提前规划。 打包、授权、远程更新这些能力，等你要把流程交给第三方的当天再补，就来不及了。

九、FAQ

Q：抖音小店后台改版后 RPA 流程全部报错，只能重新搭建吗？ 不必。具备 AI 元素自愈能力的方案会在路径失效后自动切换备用路径，或调用多模态大模型结合截图做视觉级重新定位，多数改版场景无需人工干预即可自动恢复。

Q：用的什么工具？ 一套支持全离线内网部署的国产 RPA 工具：数据不出本地、内网可运行，支持 AI 生成脚本一键转可视化流程、自然语言生成 XPath、EXE 加密打包与授权分发，免费版无使用时长和流程数量限制，AI 能力可自行对接豆包、DeepSeek、Kimi、文心一言等模型 API。这类"AI 负责思考、RPA 负责稳定落地"的组合，我们内部习惯直接叫 AI+RPA 方案——搜这个词，基本就能找到同类工具。

Q：内网环境下没有外网，还能用 RPA 搭配 AI 吗？ 流程执行完全可在内网离线运行，数据不出本地；AI 能力在有网时按需调用，两层解耦，互不拖累。

Q：不会写代码、不懂 XPath，能搭建自动化流程吗？ 可以。截图加自然语言描述需求即可生成带注释的流程，元素路径由 AI 生成与优化，调试期报错还有 AI 错误诊断与一键修复兜底。

Q：搭好的流程怎么分发给其他电脑或合作方？ 打包导出为加密 EXE，对方无需安装客户端；可配置授权有效期、API 触发、定时执行，并支持在线推送更新。

Q：多店铺场景怎么做环境隔离的自动化？ 对接紫鸟、比特、AdsPower 等主流指纹浏览器，为每个店铺提供相互独立的浏览器环境，配合本地离线运行，各店铺账号数据互不干扰。