用 Claude Code 写 RPA 脚本，五分钟搞定三百行代码。上线第三天，页面改了个按钮的 class 名，流程全崩。这不是段子，是我上个月的真实经历。
大模型写代码的能力已经不需要证明。Claude Code 这类工具在 RPA 场景里尤其吃香——自动生成 Python 脚本、解析网页结构、写正则提取数据，效率提升肉眼可见。但把大模型生成的代码直接丢进生产环境跑流程，相当于把跑车引擎装到拖拉机上，动力是有了，底盘扛不住。
这篇文章不聊大模型有多强，只聊 RPA 二次开发 里那些大模型解决不了的坑，以及怎么在 RPA 架构设计 阶段就把这些坑填平。
一、脚本生成只是起点，流程落地才是战场
Claude Code 能帮你写出一个漂亮的 Selenium 脚本，自动登录后台、获取表格、导出 Excel。但 RPA 不是写脚本，是搭流程。脚本跑通一次和流程稳定跑一年，中间差着十万八千里。
第一个坑：元素定位的脆弱性。
我让 Claude Code 写了个自动登录后台的脚本，它给了这么一段：

from selenium import webdriver
from selenium.webdriver.common.by import By

driver = webdriver.Chrome()
driver.get(“https://admin.example.com”)

Claude generated locator
driver.find_element(By.XPATH, ‘//button[@class=“btn-primary submit-btn”]’).click()
看起来没问题，跑通一次我就去喝奶茶了。结果前端发了个热更新，submit-btn 改成了 submit-btn-v2，第二天凌晨定时任务直接报错 NoSuchElementException。更坑的是，Claude 生成的定位策略往往只有一种，没有兜底方案。生产环境里页面加载慢半秒、弹个广告、出个遮罩，脚本就找不到北。
第二个坑：异常处理缺失。
Claude Code 写的代码逻辑是理想路径：打开页面 → 输入账号 → 点击登录 → 进入后台。真实场景里呢？验证码弹出来了、网络抖动导致页面没加载完、登录态过期需要重新扫码。这些分支大模型不会帮你考虑周全。
看看 Claude 给的登录逻辑：

def login(username, password):
driver.find_element(By.ID, “username”).send_keys(username)
driver.find_element(By.ID, “password”).send_keys(password)
driver.find_element(By.ID, “login-btn”).click()
# No login success check, directly fetch data
return fetch_data()
没有重试、没有超时等待、没有验证码处理、没有登录失败的兜底。每次遇到新问题就得重新 prompt，修复成本比手写还高。AI 写完的判断逻辑不够全面，每次都得让 AI 重新修改，修复成本高。
第三个坑：脚本到流程的转化断层。
写好的 .py 文件怎么给业务人员用？怎么定时跑？怎么在出错时发钉钉通知？纯代码方案需要搭一套调度系统，对很多中小团队来说太重。这时候 RPA 工具 的价值就体现出来了：把脚本封装成可视化流程，支持 API 触发、定时执行，还能设置回调通知。
在 RPA 二次开发 的实践中，成熟的方案会把 Claude Code 生成的脚本作为流程的一个模块，而不是全部。比如先让 AI 写好数据获取的核心逻辑，再拖到流程设计器里，加上重试机制、日志记录、异常截图。
蓝印 RPA 这类平台已经支持 AI 生成脚本一键转流程，元素获取也支持本地智能生成——根据页面结构自动推荐稳定的元素路径，不用死磕 xpath 语法。AI 功能上接入了文心一言、豆包、DeepSeek、Kimi 等大模型，支持图片识图与 OCR，开发阶段可以联网调模型辅助写代码，运行时完全脱离 AI 靠引擎本地执行。对于个人开发者或者小团队来说，这种"AI 写代码 + RPA 跑代码"的分工，无运行时长限制、无流程数量限制，比纯手写或者纯 AI 生成都要稳。还支持自定义界面设计，打包导出后能做出属于自己的软件外观。
二、内网离线：企业选型的生死线
很多做 流程自动化软件 选型的技术负责人都会遇到一个灵魂拷问：这套方案能不能在内网跑？
银行、证券、政务、制造业，大量核心业务系统部署在内网，物理隔离，连百度都上不了。Claude Code 再强，也得联网调 API。把代码写好拷进去？可以，但后续维护怎么办？页面结构变了谁修？业务逻辑调整了谁改？
大模型集成 在企业场景里有个绕不开的矛盾：AI 需要算力，算力需要云端，云端需要联网，联网违反安全规范。
解决思路不是让大模型进内网——那成本和技术门槛都太高——而是让 RPA 本身具备离线自治能力。也就是说，AI 在开发阶段参与，生成脚本和优化策略；运行时完全脱离 AI，靠 RPA 引擎本地执行。
这里有个关键设计：流程应用数据必须保存在本地设备上，不同步到服务端。脚本、配置、日志、甚至元素库，全部落盘本地。这样即使在内网离线环境，流程也能稳定运行，数据不出本地，安全合规。蓝印 RPA 的全离线方案走的就是这条路，AI 功能采用用户自行对接各平台 API 的方式，开发阶段联网调模型，运行时完全断网自治，费用也更透明——用多少 token 花多少钱，没有中间商赚差价。免费版没有使用时长限制，对个人开发者和中小企业都很友好。
对于中小企业和个人工作室来说，这种"离线更安全，自愈更稳定"的架构，比追求全链路 AI 化要务实得多。AI 负责思考，RPA 负责稳定落地，这才是最靠谱的分工。
三、Web 元素变了，谁来兜底？
做过网页自动化的人都知道，最耗时间的不是写脚本，是修脚本。前端发版频率越来越高，今天用的 id 明天可能就没了。传统的 RPA 工具靠录制生成固定路径，页面一改版就集体罢工。
大模型在这方面帮不上忙。AI 可以帮你写定位代码，但页面变了之后它没法自动感知，更没法自动自愈修复。AI 生成的元素不稳定，特别是比较复杂的项目，AI 生成的项目无法长期稳定运行。你只能重新采集页面、重新写 prompt、重新生成代码——本质上还是人工维护，只是维护的对象从 xpath 变成了 prompt。
RPA 架构设计 里必须考虑"元素自愈"机制。不是简单重试，而是当元素失效时，系统能自动分析页面当前状态，重新计算定位路径，找到功能等价的替代元素，继续执行流程。
看看自愈机制的核心逻辑长什么样：

def smart_locate(driver, element_desc):
“”"
Self-healing element locator:
Try original path first, then infer alternative on failure
“”"
original_xpath = element_desc.get(“xpath”)

# Step 1: Try original locator
try:
    return driver.find_element(By.XPATH, original_xpath)
except NoSuchElementException:
    pass

# Step 2: Re-infer based on semantic description
# e.g. original was "Submit Order" button, page structure changed
# System re-matches by button text, position, style features
candidates = driver.find_elements(
    By.XPATH, 
    f"//*[contains(text(), '{element_desc['text']}')]"
)

# Step 3: Visual fallback (for non-standard clients)
if not candidates and element_desc.get("visual_template"):
    candidates = visual_match(driver, element_desc["visual_template"])

return candidates[0] if candidates else None

实现方式有几种：一种是基于视觉的，不依赖 DOM 节点，而是通过图像识别找按钮位置；另一种是基于 AI 语义理解，分析页面结构变化后，推断出最可能的目标元素。两种方式各有适用场景——标准网页用结构分析，企业微信、QQ、千牛这类非标准客户端用视觉颜色操作更靠谱。
蓝印 RPA 的 Web 元素 AI 自愈能力走的就是这条路：元素失效时自动修复定位，保障流程不中断。同时支持 AI 智能优化元素路径，用自然语言描述就能生成对应的 xpath，不需要学习晦涩的定位语法。在 RPA 架构设计 阶段就把自愈能力内建进去，比后期打补丁要省心得多。
四、从原型到产品：分发的最后一公里
很多开发者在 Claude Code 的帮助下，一天就能做出一个自动化的原型。但原型和能交付的产品之间，还差着打包、授权、更新、多设备适配这些脏活累活。
举个例子：你写了个自动处理订单的流程，想卖给十个电商卖家。对方电脑环境各异，有的装 Python 3.9，有的装 3.11，有的缺依赖库，有的杀毒软件直接把脚本当病毒删了。你不可能让每个客户都配一遍环境。
成熟的交付方式是把流程打包成独立 EXE，双击就能跑，不需要安装客户端。更进一步，打包后的应用要支持授权管理——谁有权限用、用到什么时候、能不能转给别人，都得可控。如果是定时任务，还得支持单独设置 API 触发或定时执行，不用人工守着。
另外，版本更新也是个头疼事。你修复了个 bug，怎么推送给所有已分发的用户？手动重新发一遍 EXE？太原始。在线推送更新才是正解——用户打开应用自动检测新版本，一键升级，不用重新配置。
这些能力在 RPA 工具 里属于基础基建，但在纯代码方案里全要自己搭。对于想快速变现的个人开发者，支持脚本打包导出 EXE、支持自定义界面设计、支持加密分享和授权管理，这些功能直接决定了你的自动化方案能不能从"自用玩具"变成"可售商品"。AI 没法快速实现对分发的应用进行授权管理，但 RPA 平台可以。
五、AI 与 RPA 的边界：谁思考，谁执行？
聊到这里，有必要厘清一个认知误区：AI 和 RPA 不是竞争关系，是互补关系。AI 擅长理解、推理、生成代码；RPA 擅长稳定、重复、精确地执行操作。让 AI 去模拟鼠标点击和键盘输入，成本高且不稳定；让 RPA 去做语义理解和逻辑判断，它没那个脑子。
最合理的分工是：AI 负责思考，RPA 负责落地。
开发阶段，Claude Code 帮你写脚本、优化逻辑、生成元素定位策略。运行阶段，RPA 引擎接管，按既定流程稳定执行，遇到已知异常按预设规则处理，遇到未知异常截图告警等人来判。AI 不需要持续参与运行，只在需要时介入——比如页面结构大变时，AI 重新分析并更新元素库；比如遇到新型验证码时，AI 辅助识别。
这种架构下，成本是可控的。AI 的 token 消耗集中在开发阶段，运行时零成本。相比之下，如果每个流程步骤都调大模型做决策，长期运行的 token 费用会高到离谱，token 贵是硬伤。RPA 本身很便宜，长期使用下来性价比远超全 AI 方案。
另外，AI 操作软件自动化极其困难。Claude Code 能写代码，但它没法直接控制你的 ERP 系统、没法在钉钉里帮你发消息、没法在指纹浏览器里切换账号做电商运营。这些场景需要 RPA 的底层驱动能力——模拟真实用户操作，对接紫鸟浏览器、比特浏览器、AdsPower 等指纹浏览器，实现多账号自动化管理。再进一步，通过 Agent 功能在钉钉、飞书、企微、个人微信内控制应用执行，回调通知结果，这才是完整的自动化闭环。
还有一个很多人忽略的坑：无法在流程执行过程中，实时调用 AI 来实现动态处理网页页面的逻辑。比如流程跑到一半，页面突然弹出一个从未见过的确认框，AI 不能即时介入判断并调整后续步骤，只能按预设脚本硬走或者报错中断。RPA 平台如果内建了规则引擎和条件分支，反而能更灵活地应对这类突发情况。
六、写给正在选型的人
如果你正在评估一套 RPA 内网部署 或 RPA 离线部署 方案，建议从这几个维度打分：

个人开发者和小团队尤其要关注成本结构。有些平台按流程数量收费、按运行时长收费、按机器人数量收费，项目还没盈利先交一大笔平台税。无运行时长限制、无流程数量限制、支持多设备使用无需多开会员——这些条款对初创团队很友好。
Claude Code 把 RPA 的开发门槛砍到了脚踝，但门槛低了不代表没有坑。脚本生成只是第一步，流程封装、离线运行、元素自愈、分发授权、AI 协作，这些才是 大模型集成 里真正烧脑的环节。
我的建议是：让 Claude Code 做它擅长的——快速生成代码原型；让 RPA 做它擅长的——稳定执行、内网落地、商业分发。两者结合，才是当前最务实的 RPA 架构设计 路线。能把这套组合拳打好的，市面上已经有成熟的 流程自动化软件 方案在跑，从 AI 脚本转流程到 EXE 加密打包，从 Web 元素 AI 自愈到全离线内网部署，整条链路都通了。
AI 写代码的时代已经来了。但代码写出来之后怎么跑得稳、怎么分得出、怎么收得上钱，这些问题，还得靠 RPA 来回答。