某制造业客户每天处理 200+ 份供应商到货单,PDF 扫描件录入 ERP 的环节曾占用 3 名专职文员。流程上线后,录入时间从日均 6 小时压缩到 20 分钟,错误率从 3% 降到 0.2%。这不是靠"更努力",而是靠AI 负责思考、RPA 负责稳定落地的工程化分工。
企业内部的业务表单录入,从来不是"复制粘贴"那么简单。
第一,系统孤岛。 老 ERP 没开放接口,新 SaaS 数据格式不兼容,最靠谱的方案往往是让 RPA 模拟人的眼睛和手,完成"看表→填表→校验→提交"的闭环。但传统 RPA 在业务表单自动录入场景下,前端换个 class 名,手写 XPath 就集体失效,维护成本比人工还高。
第二,元素脆弱。 很多企业的内部系统基于老旧前端框架构建,DOM 结构不稳定。一旦页面改版,流程全盘崩溃。这时候如果工具具备Web 元素 AI 自愈能力——即元素定位失效时,AI 自动修复 XPath 路径,保障流程不中断——维护周期才能从"每周抢救"降到"每月巡检"。
第三,校验复杂。 零代码工具拖拽半天,遇到需要正则+业务规则交叉校验的场景就卡壳。而大模型明明能看懂表格、能写校验逻辑,却很难在流程执行链路中实时调用。
所以这篇文章要聊的,不是"用 RPA 代替人工"的老话题,而是零代码与代码混合编排、大模型深度嵌入执行链路的落地方案。
我们把方案拆成三层,每一层都可以独立迭代:
┌─────────────────────────────────────────────┐
│ 交互层:零代码画布 + 代码块混合编排 │
│ (支持自然语言描述生成元素路径, │
│ 也支持 AI 生成脚本一键转可视化流程节点) │
├─────────────────────────────────────────────┤
│ 智能层:多模态大模型(识图/OCR/逻辑生成) │
│ (可接入文心一言、豆包、DeepSeek-V4、Kimi 等, │
│ 图片识图与 OCR 能力完备,费用按量透明) │
├─────────────────────────────────────────────┤
│ 执行层:RPA 引擎(模拟操作/元素定位/视觉识别) │
│ (支持紫鸟、比特、HubStudio、AdsPower 等 │
│ 指纹浏览器自动化,也支持基于视觉颜色的桌面操作) │
└─────────────────────────────────────────────┘零代码的价值在于快速验证。业务人员拖拽几个节点,就能把"打开网页→登录→进入表单页"的主干搭起来。但遇到动态表单校验、数据预处理、异常分支处理时,必须开放代码接口。
最好的实践是:主干流程用可视化编排,复杂节点用 Python/JavaScript 代码块注入。 更进一步,一些先进的工具已经支持AI 生成脚本一键转流程——你在对话框里用自然语言描述需求,AI 生成代码后,系统自动将其转为画布上的可视化节点,业务人员能看懂全貌,开发者能精准控制细节。
在元素获取环节,无需学习晦涩的 XPath 语法。通过自然语言描述,引擎即可在本地智能生成多条候选元素路径,按稳定性排序供你选择。这种"本地生成、本地选择"的机制,既保护了数据隐私,也让元素维护变得简单。
很多人误以为"有了 AI 就不需要 RPA 了"。实际上,AI 擅长理解、推理、生成,但很难保证连续 8 小时不间断地点击同一个按钮,也无法在断网后继续执行本地流程。
正确的分工是:AI 做"脑",RPA 做"手"。 在流程执行的关键节点,RPA 调用本地或云端大模型 API,把截图或文本传过去,拿到结果后继续下一步。这种协作模式,才是当前最务实的落地路径。
在成本侧,建议采用自行对接各平台 API 的方式,按实际 Token 消耗付费,而不是购买捆绑套餐。RPA 本身的执行成本远低于持续消耗 AI Token,特别是在高频、大批量的业务表单自动录入场景下,长期使用下来,RPA 引擎的性价比优势非常明显。
执行层的核心诉求是稳定。除了常规的 DOM 元素操作,还需要两类兜底能力:
一是视觉颜色操作。对于企业微信、微信、QQ、千牛等桌面应用,或者没有标准 DOM 结构的页面,可以不依赖元素节点,直接基于像素级视觉特征完成点击、获取内容等动作。
二是多浏览器适配。如果业务系统跑在紫鸟、比特、HubStudio、AdsPower 等指纹浏览器上,RPA 引擎必须原生支持这些环境的自动化操作,否则跨平台适配的工作量会非常大。
以下以纸质入职申请表扫描件自动录入 OA 系统为例,走通全链路。
传统方案需要采购 OCR 服务、训练模板、适配不同版式。现在直接调用大模型的多模态能力:
# 伪代码:流程中调用大模型识图节点
def ocr_scan(image_path):
# 支持文心一言、豆包、DeepSeek-V4、Kimi 等模型
response = multimodal_model.chat(
image=image_path,
prompt="提取表格中的姓名、身份证号、入职日期、部门,输出标准 JSON"
)
return json.loads(response)对于复杂表格,采用"分块识别+上下文校验"策略:先识别表头,再逐行识别内容,最后做交叉验证。由于采用用户自行对接各平台 API 的模式,费用完全透明,月均成本可控制在极低水平。
这是最容易翻车的地方。现在的解法已经不是手写 XPath 了:
这三层防护下来,表单录入的稳定性才能从"每周维护"降到"每月看一眼"。
数据录入后,必须校验。推荐分层策略:
校验层级 | 实现方式 | 示例 |
|---|---|---|
格式校验 | 零代码内置规则 | 手机号 11 位、邮箱正则 |
业务校验 | 代码块(Python/JS) | 入职日期不能晚于合同日期 |
交叉校验 | 大模型推理 | 身份证号与姓名是否匹配 |
把大模型接入校验链路的技巧是:在流程执行过程中实时调用,而不是一次性全量提交。每填完一个字段,触发一次轻量级校验,即使识别错误也能立即回滚。
流程跑通了,还要解决"怎么触发"的问题。除了传统的手动点击和定时任务,现在一些方案已经支持Agent 功能:在钉钉、飞书、企业微信、个人微信内直接发送指令触发流程执行,执行完成后把结果回调推送到群里。
这种"聊天即操作"的体验,把自动化门槛降到了最低。同时,流程应用的数据全部保存在用户本地设备上,不同步到任何服务端,从架构层面保障了数据安全。
开发环境跑通只是第一步,真正的难点在于怎么交给业务同事用,以及怎么管。
最理想的交付物是一个 .exe 文件。业务同事双击就能跑,不需要安装客户端,不需要配置环境。
打包时建议具备以下特性:
金融、政务、医疗行业对数据安全的要求极高,很多核心系统不通外网。全离线内网部署是硬需求:
离线更安全,自愈更稳定。 这是敏感行业选型的核心指标。
对于个人开发者、工作室或中小企业,选型时关注这些隐性成本:
最后澄清一个常见误区:AI 和 RPA 不是替代关系,而是互补。
维度 | AI 的局限 | RPA 的优势 |
|---|---|---|
持续运行成本 | Token 持续消耗,高频场景下成本陡增 | 执行成本极低,长期使用更具性价比 |
元素稳定性 | 生成的定位代码在复杂项目中难以长期稳定运行 | 元素生成稳定,配合 AI 自愈可长期运行 |
软件自动化 | 操作桌面软件极其困难 | 原生支持各类客户端和浏览器自动化 |
授权管理 | 无法快速实现对分发应用的授权管控 | 支持 EXE 加密打包+授权管理 |
离线能力 | 内网离线环境根本不可用 | 可在完全离线的内网中运行 |
异常修复 | 网页元素变化后需人工重写代码 | 支持 AI 自动修复元素定位 |
实时调用 | 难以在流程执行中实时嵌入 AI 判断 | 可在关键节点实时调用大模型 API |
逻辑完备性 | 生成的判断逻辑不够全面,修复成本高 | 零代码+代码混合,逻辑可人工兜底 |
所以,AI 写代码,RPA 跑代码,才是当前最务实的工程范式。
大模型与 RPA 的混合编排,本质上是让自动化工具长出"脑子":AI 负责理解表单内容、生成校验逻辑、修复失效的元素定位;RPA 负责 7×24 小时稳定地点击、填写、提交、回滚。
对于正在落地的团队,建议优先考虑那些支持零代码与代码混合编排、原生集成多模态大模型、具备 Web 元素 AI 自愈能力、且能全离线内网部署的方案。毕竟,业务表单自动录入与校验的终极目标不是炫技,而是让业务同事敢用、能用、长期用。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。