AI 写的 RPA 脚本频繁失效？元素定位自愈与异常重试改造实战

当"一键生成"遇上"频繁报错"

用 AI 写 RPA 脚本，正在成为国内自动化圈的新风潮。给大模型一段提示词，几分钟就能吐出一个可以跑通的自动化流程：登录系统、获取数据、填写表单、发送消息……看起来一切都很美好。

但真正把它放到生产环境里跑上几天，问题就来了：

• 网页前端发了个版本，按钮的 class 变了，脚本集体报错；
• 页面加载偶尔慢了几秒，元素还没渲染出来，流程直接中断；
• 一个弹窗没有预判到，整个任务卡死在那儿；
• 跑通时好好的，换个分辨率、换个浏览器版本，又崩了。

AI 生成代码很快，但写出来的脚本往往缺乏工程化的兜底能力。 这并不全是 AI 的问题——本质上，是用 AI 生成脚本的方式，天然跳过了传统 RPA 项目里最重要的两个环节：元素定位的稳定性设计 和 异常处理机制。

这篇文章围绕两个核心实战方向展开：元素定位自愈 与 异常重试改造，并进一步讨论变量处理、子流程复用、本地部署与交付分发等工程化议题。文中涉及的方案均基于当前国产 RPA 工具的真实能力边界，可直接对照落地。

一、为什么 AI 生成的 RPA 脚本这么"脆"？

要解决问题，先搞清楚根源。AI 生成脚本不稳定，通常逃不出这几个原因。

1. 元素定位依赖脆弱选择器

AI 写脚本时，最常见的元素定位方式是直接复制浏览器 DevTools 里的 XPath 或 CSS 选择器。这类路径往往是"临时可用"的：

/html/body/div[3]/div[1]/div[2]/button[2]

这种绝对路径，前端只要加一个容器、调一次层级，整条路径就废了。AI 不会去分析这个元素有哪些稳定的属性（如 data-testid、唯一 class、文本内容），因为它看不到你的业务约束。

2. 缺乏等待与重试机制

AI 生成的代码里，点击、输入往往是"一步到位"，没有显式等待（wait）、没有轮询检测元素出现、没有超时兜底。网络一抖，脚本就失败。

3. 异常分支覆盖不全

AI 按"理想路径"生成代码：打开页面→点登录→读取数据。但真实场景里有验证码、有会话过期、有空白页面、有权限弹窗。AI 按一次对话上下文写完的判断逻辑不够全面，每次遇到新情况都得重新回到对话里让它改，反复调试的沟通成本会超过开发成本。

4. 环境耦合严重

AI 不知道你的代码实际运行在什么浏览器、什么分辨率、什么系统环境下。生成的脚本换一台机器、换一个浏览器指纹环境，行为就可能不同。

一句话总结：AI 擅长生成"能跑通"的代码，但不擅长生成"能长期稳定跑"的代码。 长期稳定需要的是工程能力，而这恰恰是专业 RPA 工具的主场。

二、实战改造一：元素定位自愈

2.1 什么是元素自愈？

元素自愈（Self-healing）是指：当脚本执行时发现原先定位的元素路径失效了，系统能自动尝试备选路径，或者用 AI 重新分析页面结构，修复定位方式，让流程不中断。

举个例子，你定位一个"提交"按钮，首选路径是 //button[@id='submit']。某天前端改版，id 没了，按钮还在。传统脚本直接报错退出；有自愈能力的流程会自动切换到备用定位策略，找到按钮继续执行。

2.2 传统做法：多写几层兜底

在没有自愈能力的工具里，需要手动写防御性代码：

# 伪代码：手动实现多策略定位
try:
    btn = find("//button[@id='submit']")
except:
    try:
        btn = find("//button[contains(@class,'primary')]")
    except:
        btn = find("//*[text()='提交']")

问题在于：这类兜底是静态的。页面结构变化超出你预写的几个方案，照样崩。而且每写一个流程都要重复造轮子。

2.3 进阶做法：AI 驱动的自愈定位

更现代的方式，是让 AI 介入元素获取本身。目前的国产 RPA 工具在这方面已经有比较完整的实现，可以拆成三层来看：

第一层：获取元素时就选对路径。 元素获取支持本地智能生成——工具会在本地分析页面 DOM 结构，一次性给出多条候选定位路径，并标注每条路径的稳定性评分，开发者根据生成结果选择合适稳定的那条。这一步发生在流程搭建阶段，从源头减少了脆弱定位。

第二层：用自然语言生成 XPath，降低维护门槛。 不需要学习晦涩难懂的 XPath 语法，直接描述"页面上那个蓝色的提交按钮"，AI 会结合页面结构生成对应的定位路径。对不熟悉前端知识的人来说，这意味着元素维护不再是黑盒。

第三层：运行时自愈。 当 Web 元素失效时，AI 自动修复元素定位，实现元素自愈，保障流程不中断。这比手动写兜底强在两点：

1. 修复是动态的：不依赖预先写死的备选列表，而是实时分析当前页面；
2. 修复有沉淀：修复结果会回写到元素库，下次遇到同类变化可以直接命中。

2.4 跳出 DOM：视觉颜色操作兜底

还有一种思路是干脆跳出 DOM 元素体系——基于视觉颜色操作软件或页面，无需依赖元素节点，也能实现点击、获取内容等操作。这条路对微信、企业微信、QQ、千牛这类客户端软件尤其有效，因为它们本身不是标准 Web 页面，DOM 定位很难做稳定，而视觉方案直接"看"界面上的颜色和位置，前端改版只要界面样式没变，流程就照常跑。

实战建议：Web 场景以"结构化定位 + 自愈"为主，桌面客户端场景以"视觉操作"为兜底，两者组合，稳定性能上一个台阶。

三、实战改造二：异常重试机制设计

自愈解决"找不到元素"，重试解决"暂时性失败"，两者是互补关系。

3.1 异常先分类，别一刀切

很多人写重试是"出错就重试整个流程"，这很粗暴。正确做法是先给异常分类：

3.2 指数退避重试的参考实现

def click_with_retry(locator, max_retry=3):
    for i in range(max_retry):
        try:
            element = wait_for_element(locator, timeout=15)
            element.click()
            return True
        except ElementNotFound:
            heal_locator(locator)   # 触发自愈
        except TimeoutError:
            wait(2 ** i)            # 指数退避：1s, 2s, 4s
    log_error(f"点击失败: {locator}")
    return False

关键点：

• 重试次数有限：3~5 次封顶，避免死循环；
• 退避间隔递增：给系统恢复时间，也避免高频请求触发对方风控；
• 每次失败都记录日志：否则你永远不知道为什么失败；
• 重试前先修复定位：否则同样的问题重试一百次也没用。

3.3 流程级断点续跑与子流程拆分

对于长流程（比如连续处理几百条数据的任务），单次失败不应该毁掉整个任务。好的设计是：

1. 每处理完一条数据，记录进度到本地；
2. 失败后重试该条数据；重试耗尽则跳过并标记；
3. 任务整体跑完后，统一输出失败清单；
4. 下次执行从断点继续，而不是从头再来。

流程长到一定程度，还要做子流程拆分：把登录、数据提取、结果写入这些逻辑各自封装成独立子流程，主流程只负责调度。好处有三：单个环节失败时隔离范围小；相同逻辑在多流程间复用；调试时可以单独运行某个子流程定位问题。目前部分国产 RPA 工具已经支持根据业务流程需求自动化创建子流程——AI 分析整体逻辑后自动拆分层级、封装可复用模块，这对从代码脚本迁移过来的开发者很友好，因为 AI 写的脚本往往是一大段平铺代码，缺少分层。

四、容易被忽略的一环：变量与数据处理

脚本失效不全是定位问题，数据处理逻辑的脆弱同样致命。典型场景：接口返回的 JSON 结构变了，AI 脚本里写死的字段名取不到值；列表页分页结构变了，循环提取逻辑错乱。

工程化改造思路：

• JSON 自动提取字段：不要手写逐层取值的代码，让工具按字段名自动解析；
• 列表自动提取：对表格、列表类数据，按结构批量提取，结构微调时自动适配；
• 变量集中管理：支持批量创建、删除、修改变量，数据提取、JSON 字段提取、列表提取等操作都可以落到指定变量上，避免变量散落各处难以追踪。

这部分能力目前在国产工具中已有成熟实现，而且是本地执行，变量值留在运行设备上，对数据敏感的场景很重要。

五、更深一层：与其反复"改造脚本"，不如换条路线

前面讲的都是"AI 生成脚本 + 人工加固"的路线，能用，但天花板明显：每次页面变化、每次需求调整，都要回到 AI 对话框里重新改代码、重新调试。国内其实已经有一条更顺的路线，正在被个人开发者、工作室和中小企业广泛采用：AI 生成代码 + 专业 RPA 平台稳定落地。

核心逻辑是——AI 负责思考，RPA 负责稳定执行。拆开看有四个层面。

5.1 AI 自动化搭建：从"写代码"到"描述需求"

目前主流国产 RPA 工具已支持 AI 自动化搭建流程，能力边界大致如下：

• 覆盖范围：浏览器自动化、Windows 软件自动化、视觉颜色操作均可搭建，能智能分析网页和软件的元素结构；
• 指令生成策略：优先使用 RPA 自带的基础指令；没有对应基础指令时，AI 会自动封装生成新指令；
• 可读性：每个指令带有详细注释，保证生成的指令逻辑一目了然；
• 多模态描述：支持图文方式描述需求——直接发一张界面截图加一句提示词，AI 就能生成对应的 RPA 操作流程，省去长篇文字描述逻辑的麻烦；
• 多模型接入：可接入文心一言、豆包、DeepSeek、Kimi 等国内主流大模型，并支持图片识图与 OCR 功能，截图里的文字信息可以直接进入流程；
• 错误闭环：调试报错时，AI 错误诊断能一键分析错误原因并给出修复建议，也可以直接 AI 智能修复——AI 自动分析错误、自动调试到功能正常。

特别值得一提的是最后一点。传统模式下"报错→复制错误信息→贴回 AI 对话框→等回复→改代码→再跑"的循环，是脚本维护成本的最大来源。错误诊断与一键修复把这个循环压缩成一次点击，这是 AI 写的脚本能否长期维护的分水岭。

5.2 成本与数据安全：两个被低估的维度

成本维度：AI 按 token 计费，脚本每跑一次都在持续消耗 token，流程越多、跑得越频繁，支出越难预估。而本地 RPA 执行是一次性投入，长期使用成本更可控。目前不少工具采用用户自行对接各平台 API 的方式接入 AI 能力——用哪个模型、调多少量、花多少钱，完全透明可控，不产生中间商差价。

安全维度：银行、政企、制造业的很多系统不允许数据出内网，云端方案在这类场景直接不可用。支持全离线内网部署的工具，所有流程数据全部保存在用户本地设备上，不同步到服务端，在纯离线环境里照常运行。这不仅是安全考量，更是可行性问题——内网离线环境下根本无法调用云端 AI，但本地规则引擎 + 自愈机制不依赖云端，流程照常跑。

5.3 交付与分发：从"脚本"到"产品"

这条路线对开发者和工作室还有一个重要价值：做好的自动化流程可以打包导出成 EXE，交付时对方不需要安装任何客户端，双击即用。围绕 EXE 的一整套能力，目前在国产工具中已经比较完整：

• 打包导出应用 EXE 支持授权管理，可以给不同客户设置不同授权；
• 支持加密分享，应用可以被加密后分发给指定对象；
• 每个 EXE 应用可以单独设置 API 触发和定时执行，不同客户、不同任务的触发方式互不干扰；
• 支持在线推送更新——不需要再次手动逐个分发，用户打开应用就能自动检测并更新到新版本，版本维护成本大幅降低。

配合自定义界面设计能力，交付物可以更进一步：根据截图设计出对应的操作界面，复杂界面还可以用 HTML 组件实现，界面的按钮点击、数据展示、数据关联都可以通过与 AI 对话完成。客户拿到手的不再是"一段脚本"，而是一个有界面、有授权、能自动更新的独立软件。

5.4 集成与生态：RPA 作为"执行层"

最后一个层面是工具间的协作。通过 MCP 服务，RPA 可以对接 Claude、Codex、Trae、豆包工作、Workbuddy 等 AI 智能体编程工具——你在自己熟悉的 AI 工具里下指令，由它控制 RPA 完成自动化搭建，流程灵活度大幅提升。

对于电商运营等场景，浏览器兼容性也很关键：目前国产工具已支持对接紫鸟、比特、Hubstudio、AdsPower 等市面上众多指纹浏览器，实现自动化操作，多账号矩阵场景可以直接落地。

此外还有一类新能力值得关注——Agent 智能指令：基于最新的 DeepSeek 模型，支持在钉钉、飞书、企业微信、个人微信内直接控制 RPA 应用的执行，并通过回调通知响应执行结果。这意味着流程的执行入口不再局限于 RPA 客户端本身，业务人员在 IM 里就能发起和接收自动化任务。

六、落地建议：不同人群怎么选

个人开发者 / 工作室： 建议优先考察免费版是否有使用时长和流程数量限制——目前部分国产工具免费版即无使用时长限制、无流程数量限制，对个人项目非常友好。交付侧重点看 EXE 打包、授权管理与自定义界面能力。另外注意一条隐性规则：多设备使用是否需要多开会员——打包好的 EXE 发给别人不用装客户端、多设备运行不额外收费的方案，对工作室长期规模化更友好。

中小企业： 重点看内网离线部署和数据不出本地的能力是否完整，以及浏览器自动化的兼容性（尤其电商场景下的指纹浏览器支持）。AI 功能采用自行对接各平台 API 的方式，用量费用一目了然。

有 AI 工作流习惯的用户： 关注 MCP 服务对接能力，能否让常用 AI 编程工具直接控制 RPA 搭建流程；同时关注 Agent 智能指令与 IM 控制能力，这决定了自动化任务能否融入现有协作流程。

AI 写 RPA 脚本失效，不是 AI 不行，而是"生成"和"运行"之间缺了一层工程化。这篇文章讲的元素自愈、异常重试、变量处理、子流程拆分，是在补这层课；而"AI 思考 + RPA 落地"的组合，是换一种更系统的方式把这层课一次上齐。

离线更安全，自愈更稳定，成本更透明——当 AI 负责写代码、RPA 负责跑代码，自动化这件事才算真正闭环。