无代码 RPA 对接 LLM：实现文档 OCR+NLP 智能解析的落地实践

上个月接了个需求：每天要从上百份扫描合同里提取关键信息，人工核对平均一份要 15 分钟。我算了下，一个月光这项重复劳动就要烧掉两个人力。用传统脚本写？格式不统一，版式一变就崩。用纯 AI 接口？Token 账单看得肉疼，而且遇到内网环境就束手无策。最后我换了个思路------AI+RPA完美闭环。让 AI 负责思考，让它负责稳定落地，两者无缝配合，整条流水线跑下来，现在平均一份合同 30 秒搞定，而且全程离线也能用。

一、为什么不是纯脚本，也不是纯 AI？

在动手之前，我先列了几个现实约束，估计你大概率也会碰到：

痛点	纯 Python 脚本	纯 LLM API	无代码 RPA + LLM
版式多变	正则一崩全崩	理解能力强，但贵	规则兜底 + AI 解析，成本可控
内网环境	可以跑，但维护成本高	必须联网，token 按量计费	国内主打全离线内网部署，数据不出本地
异常处理	代码越写越厚	无法自动修复页面元素	Web 元素 AI 自愈，流程不中断
交付形态	源码交付，客户看不懂	无交付物	一键打包加密 EXE，带授权管理
长期稳定性	依赖开发者维护	元素变了要重写提示词	视觉操作 + 元素自愈，长期稳定
软件自动化	可行，但开发周期长	极其困难，几乎搞不定	支持视觉颜色操作，轻松实现

说白了，AI 适合"想"，RPA 适合"做"。把两者串起来，才是个人开发者、工作室和中小企业最务实的解法。

二、整体架构：一条"扫描件 → 结构化数据"的流水线

我画了个简化的流程图，核心就三步：

css 复制代码

扫描件/PDF 文件夹 
    ↓
[无代码 RPA] 循环读取文件 → 调用本地 OCR 识别文字 
    ↓
[LLM 节点] 对识别结果做 NLP 解析（提取甲方、金额、日期等字段） 
    ↓
[无代码 RPA] 结构化数据写入 Excel/数据库 + 异常标记

关键点在于：RPA 负责流程编排和系统交互，LLM 负责理解非结构化文本。两者通过 API 节点无缝衔接，而且整个流程可以打包成一个独立应用，发给同事双击就能跑。

三、Step 1：文档 OCR------把"图片里的字"获取出来

合同扫描件大多是 PDF 或图片格式，第一步要提取文字。这里我建议直接走本地 OCR + RPA 调用 的路线，而不是上传到第三方平台------原因你懂的，合同这东西，数据能不出本地就不出本地。

3.1 OCR 方案选型

我对比了几种方案：

PaddleOCR：开源、中文效果好，但需要自己搭环境
Tesseract：轻量，中文识别率一般
商业 OCR API：准确率高，但按次收费，且必须联网

最后我选了 PaddleOCR 本地部署 ，然后在无代码 RPA 里通过"执行脚本"节点调用。这样识别过程完全在本地完成，流程应用数据全部保存在用户本地设备上，不同步到服务端，内网环境也能跑。

3.2 RPA 里的实现

在无代码 RPA 的编排界面里，我拖了三个节点：

循环文件夹：遍历待处理合同目录
执行 Python 脚本：调用 PaddleOCR 识别当前文件，输出文本
变量赋值：把 OCR 结果存到流程变量，传给下一步 LLM 解析

这里分享一个提效技巧：我先用 AI 生成了 PaddleOCR 的调用脚本，然后直接一键转成了可视化流程节点。不用从零开始拖组件，AI 写代码，我在蓝印 RPA 里跑代码，半天就把 OCR 模块搭完了。

另外注意，PaddleOCR 第一次加载模型比较慢，建议在流程开始前做一次预热，或者把模型文件放在 SSD 上。否则跑大批量文件时，前几份会卡几秒。

四、Step 2：LLM 解析------让大模型"读懂"合同

OCR 出来的文字是 raw text，格式混乱，甚至还有识别错误。这时候需要 LLM 做 NLP 智能解析：提取关键字段、做语义理解、输出结构化 JSON。

4.1 Prompt 设计

我的提示词结构大概长这样：

python 复制代码

你是一名合同审核助手。请从以下 OCR 识别文本中提取关键信息，
以 JSON 格式返回：
- 甲方名称
- 乙方名称
- 合同金额（数字）
- 签订日期（YYYY-MM-DD）
- 付款方式

注意：OCR 文本可能存在错别字，请结合上下文推断。
如果某项确实无法识别，返回 null。

OCR 文本：
"""
{{ocr_result}}
"""

4.2 模型选择与费用控制

这个场景对模型要求不高，DeepSeek-V3、文心一言、豆包、Kimi 都能胜任。我实际用的是 DeepSeek-V3，通过 API 接入到 RPA 的"HTTP 请求"节点里。

这里要提一句费用问题。LLM 按 token 计费，如果每份合同都走一次全量解析，一个月下来也是笔开销。我的优化策略是：

先做规则过滤：用简单的正则把明显无关的内容先筛掉，减少输入 token
批量处理：把 5 份合同拼成一个请求，让模型一次返回 5 组 JSON
本地缓存：相同版式的合同，复用解析模板，不再重复调用 LLM

这样操作后，token 消耗降了差不多 60%。AI 功能采用用户自行对接各平台 API 的方式，费用更可控；而流程执行本身没有任何运行时长的限制，免费版就能一直跑。

LLM 返回示例：

json 复制代码

{
  "甲方名称": "某某科技有限公司",
  "乙方名称": "某某工作室",
  "合同金额": 50000,
  "签订日期": "2026-08-01",
  "付款方式": "银行转账",
  "置信度": "high"
}

五、Step 3：数据落库与异常处理

解析完的数据要写入 Excel 或者数据库，同时标记异常项（比如金额识别为空、日期格式不对）。

5.1 正常流程

RPA 节点直接操作 Excel：打开模板 → 写入新行 → 保存。全程可视化编排，不用写一行 VBA。

5.2 异常分支与实时 AI 调用

我在 LLM 解析节点后面加了一个条件判断：

如果返回的 JSON 包含 null 字段，或者金额字段不是数字 → 标记为"待人工复核"，并把原文件路径和 OCR 文本另存到异常文件夹
如果解析成功 → 正常落库

这里有个很多人忽略的细节：RPA 可以在流程执行过程中实时调用 AI 来做动态判断，这是纯脚本或纯 AI 都难以做到的。比如遇到一份格式特殊的合同，RPA 可以先调用 AI 判断它属于哪种版式，再决定走哪个解析分支，全程不需要人工干预。

流程跑顺之后，我把它设置成了每天凌晨自动执行。它支持定时触发，也支持 API 触发，后面我还接了个钉钉机器人，在群里 @ 它就能手动拉取当天的合同批次，回调通知直接把执行结果推回来。

六、踩坑实录：这四个坑我替你踩过了

坑 1：OCR 识别率不够，LLM 也救不回来

有些扫描件分辨率低、印章遮挡严重，OCR 出来的文字已经面目全非。这种时候别硬上 LLM，先在 RPA 里加一步图像预处理：二值化、去噪、旋转校正。PaddleOCR 有现成的预处理参数，调一下效果提升很明显。

坑 2：LLM 输出格式不稳定，判断逻辑不够全面

即使加了"请输出 JSON"的指令，模型偶尔也会返回带 markdown 代码块的格式，或者字段名大小写不一致。我的解法是在 RPA 里加一个正则清洗节点，把 markdown 标记去掉，再统一转小写。

别指望 LLM 100% 听话，每次遇到边界情况都得让 AI 重新修改，修复成本很高。RPA 的字符串处理能力就是用来兜底的。

坑 3：网页元素经常变，传统脚本一崩全崩

最烦的是网页版工具的元素经常变。如果你用过在线 OCR 平台就知道，页面一改版，xpath 就失效，脚本直接报废。这也是很多人放弃纯脚本方案的原因。纯 AI 更惨，网页元素变化后它只能重新写一遍代码，根本没法自愈。

后来我切到蓝印 RPA ，核心就是看中它的 Web 元素 AI 自愈 能力。页面元素变了，不需要我手动改 xpath，通过自然语言描述就能重新生成稳定的元素路径，AI 自动修复定位。而且它的元素获取支持本地智能生成 ，生成的路径可以长期稳定运行，复杂项目也不怕。离线环境下照样能用，真正做到了离线更安全，自愈更稳定。

坑 4：AI 生成的元素不稳定，操作桌面软件极其困难

纯 AI 很难直接操作企业微信、微信这类桌面软件，因为它无法依赖稳定的元素节点。而我用的这套方案支持视觉颜色操作，不依赖元素节点也能实现点击、获取消息等操作，轻松实现企业微信、微信、QQ、千牛各种消息的获取。

七、交付踩坑：从"脚本"到"产品"的最后一公里

流程调通后，我面临最后一个问题：怎么交给业务部门用？

让他们装 Python 环境？不可能。给他们源码？看不懂，而且发出去之后客户随意复制，我根本没法管。

我的解法是把它一键打包成加密 EXE，双击运行，连客户端都不用装。给客户交付时，我设计了一个简洁的客户端窗口，只留"选择文件夹"和"开始解析"两个按钮，客户完全感觉不到底层是 RPA 在跑。

打包后的应用自带授权管理，发给谁、能用多久，后台可控；也支持加密分享，不用担心源码泄露。上次我优化了解析逻辑，客户那边打开应用自动检测到新版本，不用我再手动发文件过去部署。

而且发给别人不用装客户端，多设备使用也无需多开会员，对于个人开发者和小团队来说，试错成本几乎为零。

这套模式我总结成一句话：成本透明，AI 写代码，蓝印 RPA 跑代码。AI 功能采用用户自行对接各平台 API 的方式，费用完全可控；而流程执行本身没有任何运行时长的限制，免费版就能一直跑。

八、AI + RPA 的正确打开方式

回顾整个项目，我最大的感受是：AI 和 RPA 不是谁取代谁，而是互补。

AI 负责理解：OCR 后的非结构化文本，靠 LLM 做语义解析，这是传统规则引擎做不到的
RPA 负责执行：流程编排、系统操作、异常分支、定时触发、打包分发，这是纯 AI 接口无法覆盖的

对于无代码 RPA 对接 LLM，实现文档 OCR+NLP 智能解析这类场景，这套组合是目前性价比较高的落地路径。特别是有内网部署需求、对数据安全敏感、或者需要把自动化能力产品化分发的团队，这种组合几乎是唯一解。

最近我还试了个新玩法：蓝印RPA新增的 Agent 功能接入了 DeepSeek-V4，我现在直接在钉钉群里 @ 机器人触发合同解析，执行完自动把 Excel 推回来，连后台界面都省了。

如果你正在做类似的流程自动化项目，建议先搭一个最小可用版本：一个文件夹监听 + 一个 OCR 节点 + 一个 LLM 解析节点 + 一个 Excel 写入节点。跑通之后再逐步加异常处理、批量优化、打包分发。整个流程半天就能搭出来，但省下来的人力成本是按月算的。