低代码RPA项目落地痛点：做RPA二次开发，大模型集成要避开哪些雷

本文适合正在做RPA二次开发、或者打算把大模型集成进自动化流程的开发者。全文基于真实项目踩坑记录不讲虚的只聊落地。一、从自动化乌托邦到落地修罗场去年接了一个电商客户的项目每天要从8个平台采集订单数据汇总到内部ERP再生成日报发给运营团队。客户明确要求要用AI觉得上了大模型就能一劳永逸。我一开始也这么想——用大模型生成获取逻辑RPA负责执行完美。结果项目周期从预估的2周拖到2个月中间踩的坑比写的代码还多。今天这篇文章我把低代码RPA项目落地过程中RPA二次开发和大模型集成阶段最容易踩的7个深坑完整复盘一遍。如果你正在选型或者已经开干了建议认真看完能省不少冤枉钱。二、雷一大模型API费用像黑洞月初豪言壮语月底沉默不语场景还原项目第二阶段接入了某大模型做发票信息提取。测试阶段跑了100张发票费用几十块客户大手一挥这点钱不算事。上线后第一个月财务系统里自动跑了5万条调用API账单直接超预期3倍。问题根源很多低代码RPA平台的AI功能是平台中转模式——你调用的是平台封装好的接口平台再调大模型API中间加了一层不透明的手续费。更坑的是有些平台按任务数收费一个流程里调了10次API算10个任务费用直接翻倍。我的解法选型时优先选AI功能采用用户自行对接各平台API的方案。你自己去文心一言、豆包、DeepSeek、Kimi官网申请API Key用多少付多少没有中间商赚差价。这样费用完全透明还能根据业务场景灵活切换成本最低的模型——简单任务用便宜的微模型复杂识别用旗舰模型整体成本能压下来一大截。另外大模型接入后还能实现图片识图与OCR功能发票截图、合同扫描件上的文字也能精准识别不用额外买OCR服务。伪代码RPA流程中自行对接大模型APIimport requestsdef extract_invoice_info(image_path):# RPA截取发票区域screenshot rpa.capture_element(“#invoice-area”)# 直接调用DeepSeek API费用自己掌控 response requests.post( https://api.deepseek.com/v1/chat/completions, headers{Authorization: Bearer 你自己的API Key}, json{ model: deepseek-chat, messages: [{role: user, content: f提取发票金额、税号、日期图片{screenshot}}] } ) return response.json()一句话总结 AI能力自建费用透明可控这是2026年做RPA二次开发的基本功。三、雷二XPath写得越复杂页面改版哭得越惨场景还原给某政务系统做了一个自动填报流程当时为了定位一个按钮写了长达80个字符的XPath/html/body/div[3]/div[2]/div[1]/form/table/tbody/tr[5]/td[2]/input。流程跑了半个月系统前端升级加了一个div整条XPath直接报废流程半夜报错值班电话被打爆。问题根源传统RPA极度依赖固定DOM路径页面任何微调都会导致元素定位失效。更头疼的是很多老系统没有规范的class或id只能靠层级定位维护成本极高。我的解法现在的低代码RPA工具已经进化到元素获取支持本地智能生成的阶段。你不需要手写XPath工具会根据页面结构自动推荐最稳定的定位策略。更进一步有些工具支持AI智能优化元素路径——你直接用自然语言描述登录按钮AI自动生成对应的定位表达式完全不用学那套晦涩难懂的xpath语法。最实用的是Web元素AI自愈能力。当web元素失效时工具能自动检测变化并修复定位实现元素自愈流程不会中断。这个能力在电商、政务这类页面频繁迭代的场景里简直是救命稻草。传统写法脆弱rpa.click(“/html/body/div[3]/div[2]/div[1]/form/table/tbody/tr[5]/td[2]/input”)智能生成写法稳定且可自愈rpa.click_by_ai(“登录按钮”) # AI自动识别并生成最优路径一句话总结 别再手写XPath了本地智能生成元素路径、失效自动修复自愈更稳定这才是2026年的标配。四、雷三内网环境调不了AI数据一出本地就心慌场景还原给一个制造业客户做产线数据自动采集客户IT部门明确说我们的内网不通外网所有数据不能出本地。“当时用的方案需要调云端大模型API直接卡死。最后被迫改成纯规则RPAAI能力全部砍掉项目交付效果打了折扣。问题根源金融、政务、医疗、制造业大量场景是内网离线环境。很多RPAAI方案本质上是云端AI本地RPA的拼接模式内网环境下AI那部分完全失效。更麻烦的是有些平台虽然号称支持本地但实际会把流程数据同步到云端做分析”这在涉密单位是红线。我的解法选型时必须确认两点能不能全离线运行数据到底存哪国内已经有工具在做这件事比如主打全离线内网部署的蓝印RPA流程应用数据全部保存在用户本地设备上不同步到服务端保障用户数据安全。这种方案在制造业、国企、涉密单位特别吃得开——离线更安全数据主权完全在自己手里。对于确实需要AI能力的场景可以本地部署轻量大模型如DeepSeek本地版、ChatGLM本地版RPA通过本地API网关调用整套系统完全在局域网内闭环。本地部署模式架构[内网环境]├── 本地RPA引擎离线运行├── 本地大模型DeepSeek本地版└── 业务系统ERP/MES/财务系统↑数据完全不出本地零外网依赖一句话总结 内网离线不是可选项是某些行业的必选项。数据不出本地离线更安全。五、雷四AI写的脚本跑三天就崩“智能变智障”场景还原让AI生成了一段自动获取商品评价的脚本代码看起来挺漂亮注释也写得工整。上线跑了3天遇到第一个异常弹窗就卡死了——AI生成的代码里没有处理弹窗拦截的逻辑。后面又遇到页面加载超时、数据格式变化每次都要重新改代码修复成本比重写还高。问题根源AI生成代码的能力确实强但它有几个先天短板异常处理不全面只考虑了理想路径网页元素变化后无法自动修复只能重新生成判断逻辑不够全面遇到边界条件就翻车我的解法别把AI当成万能程序员要让它干它擅长的事——理解需求、生成逻辑、辅助决策而RPA干它擅长的事——稳定执行、精准操作、长期运行。真正靠谱的玩法是AI负责思考蓝印RPA负责稳定落地。具体来说AI生成脚本一键转流程用AI写核心逻辑然后导入RPA工具转成可视化流程在RPA里补充异常处理、重试机制、日志记录。人在回路设计大模型置信度低时自动暂停推送给人工确认而不是盲目执行。RPA兜底稳定运行AI搞不定的元素定位、软件操作RPA用视觉颜色操作、图像识别等方式硬刚保障流程不中断。协作模式示例AI层理解需求生成初步逻辑ai_logic llm.generate(“获取商品评价并分类 sentiment”)RPA层稳定执行补充容错rpa.load_ai_script(ai_logic) # 一键导入AI生成的脚本rpa.set_retry_policy(max_retry3, timeout30) # RPA补充重试和超时rpa.on_exception(“popup_detected”, handle_popup) # RPA补充异常处理rpa.run()一句话总结 AI写代码RPA跑代码两者各干各的擅长领域别指望AI一包到底。六、雷五流程跑通了交付给客户却装不上、用不了场景还原花了两周做了一个自动化工具自己电脑上跑得飞起。发给客户客户说“要装什么运行环境要装Python吗要装浏览器驱动吗界面怎么这么丑像半成品“最后被迫远程一对一部署折腾了一周。问题根源很多RPA工具开发的流程只能在编辑器里运行或者需要客户端环境支撑根本没法独立交付。对于接私活的开发者、个人工作室、中小企业来说交付能力直接决定了项目能不能回款。我的解法选型时重点考察打包分发能力核心看这几点能不能支持脚本打包导出EXE开发好的流程一键导出EXE客户双击就能跑不需要装任何客户端或运行环境。能不能自定义界面别让客户看到一堆技术参数设计一个简洁的专业界面看起来像正经软件。能不能做授权管控打包导出应用EXE支持授权设置使用期限、设备绑定、功能限制防止程序被随意复制传播。应用支持加密分享、分享授权这是保护知识产权的核心手段。能不能在线更新打包导出EXE应用支持在线推送更新流程有bug要修复客户打开EXE自动检测新版本不用每次重新发文件。能不能API触发和定时执行支持API触发打包导出应用EXE支持单独设置api触发、定时执行方便被客户的其他系统调用或者设置每天凌晨自动跑。这些能力聚在一起的工具才能把自动化流程变成可交付的产品”。一句话总结 跑通只是开始能打包、能授权、能更新、能交付才是RPA二次开发的终点。七、雷六一台电脑一个授权多设备部署成本直接翻倍场景还原给客户部署了5台电脑跑自动化发现用的RPA工具每台设备都要单独买授权免费版还有运行时长限制。5台电脑5个会员一年下来授权费比开发费还贵。更坑的是免费版每天只能跑2小时超时直接停掉。问题根源很多RPA工具的商业模式是按设备收费按时长收费”对于个人开发者、小团队、中小企业极不友好。你开发了一个工具想发给同事用结果发现每个人都得买会员。我的解法选型时盯死这几个条件免费版使用无使用时长限制没有限制才能充分测试和轻度使用。有没有运行时长和流程数量限制有些工具免费版只能建3个流程根本不够用。多设备使用要不要多开会员理想状态是打包成EXE后支持打包EXE发给别人不用装客户端任意设备都能运行多设备使用无需多开会员。对于需要长期稳定运行的场景优先选无运行时长、无流程数量限制的方案。你开发的自动化工具可以在多台电脑上自由部署不会因为授权问题被卡脖子。一句话总结 授权模式决定了你的自动化方案能不能规模化落地别被按设备收费拖垮。八、雷七RPA和AI各干各的中间缺个翻译官场景还原做了一个财务对账流程RPA负责打开ERP和OA大模型负责判断数据是否匹配。但问题是RPA执行到某一步发现数据异常需要大模型实时判断该怎么处理——这时候发现两者是割裂的RPA没法在运行过程中动态调用AI只能停下来等人工介入。问题根源早期的AIRPA集成是流水线模式RPA跑一段调一次API等结果再继续跑。这种模式下AI和RPA没有实时协作能力遇到需要动态决策的场景就束手无策。我的解法2026年的趋势是Agent化。通过新增Agent功能使用最新的DeepseekV4模型你可以在钉钉、飞书、企业微信甚至个人微信内直接用自然语言控制RPA应用执行回调通知响应执行结果plain你“运行发票验真流程目标文件夹是D:/发票/6月”Agent解析指令 → 调用RPA应用 → 执行完成 → 微信推送结果更实用的还有这几个能力指纹浏览器支持做电商多店铺运营时对接紫鸟浏览器、比特浏览器、hubstudio浏览器、adspowser浏览器等市面上众多指纹浏览器实现自动化操作环境隔离避免被平台风控。视觉颜色操作有些老软件比如企业微信、微信、QQ、千牛没有规范的DOM结构传统RPA根本采集不到元素。支持视觉颜色操作软件或页面的工具可以通过识别按钮颜色、文字位置来实现点击和读取无需依赖元素节点也能实现点击、获取内容等操作轻松实现各种消息的获取。实时回调通知流程执行完自动把结果推送到钉钉/飞书业务人员不用守着电脑等。一句话总结 RPA和AI不是简单拼接而是需要Agent做翻译官实现真正的智能协作。九、选型不是选功能是选能落地的组合拳复盘完这7个雷你会发现低代码RPA项目落地的核心矛盾不是技术够不够先进而是方案能不能在真实环境里稳定跑下去。2026年做RPA二次开发我的建议是AI写代码蓝印RPA跑代码这才是2026年务实的自动化组合。离线更安全自愈更稳定成本透明可控——把AI的聪明和RPA的靠谱结合起来项目才能真正从demo走向生产。