非结构化数据处理：OCR + 大模型 + RPA，搞定文档、票据自动解析流转

上个月去朋友公司喝茶，财务主管老王拉着我吐槽：每天两千多张发票，四个人轮流转录，眼睛都看花了，出错还得返工。我瞄了一眼他的屏幕，ERP 系统里密密麻麻的表格，旁边堆着半人高的纸质单据非结构化数据处理：OCR + 大模型 + RPA，搞定文档、票据自动解析流程。说实话，这种场景在制造业、零售业、物流行业太常见了——非结构化数据处理，一直是企业数字化转型的「最后一公里」。

一、为什么传统方案搞不定

在聊技术之前，先说几个血泪教训。

规则引擎死得很快。我们早期用正则表达式抽发票字段，增值税发票还好，遇到电子普票、火车票、机票行程单，规则写得像 spaghetti code，维护成本极高。更惨的是，供应商换了个发票模板，整个规则链直接崩盘。

纯 OCR 不够聪明。OCR 能识别出「北京某某科技有限公司」，但它不知道这是「销售方名称」还是「购买方名称」。没有语义理解，识别出来的只是一堆零散文字。

纯 AI 落不了地。大模型能看懂合同条款，但它不会登录你的 ERP 系统，不会点提交按钮，不会处理审批流。AI 负责思考，但落地执行还得靠 RPA。

所以正确的姿势是三层分工：OCR 负责看见，大模型负责理解，RPA 负责执行。AI 写代码，RPA 跑代码，各干各的擅长的事。

整体架构如下：

[输入层]  扫描件 / 拍照 / PDF / 截图 / 邮件附件
    ↓
[识别层]  OCR 提取文字 + 版面分析 + 图片质量预处理
    ↓
[理解层]  大模型抽取关键字段 + 逻辑校验 + 异常标记
    ↓
[执行层]  RPA 自动录入系统 + 触发审批流 + 归档 + 回调通知

二、OCR 识别：让图片里的文字「显形」

OCR 这层，我的建议是能用云端的用云端，敏感场景走本地。

2.1 云端 OCR：腾讯云智能结构化识别

对于版式相对固定的票据（增值税发票、火车票、身份证），直接调用腾讯云智能结构化 OCR 是最省事的。它基于多模态大模型技术，不需要提前训练模板，自动建立键值对关系。比如上传一张发票，返回的直接是结构化 JSON：

{
  "发票代码": "011001900211",
  "发票号码": "12345678",
  "开票日期": "2026-08-01",
  "销售方名称": "北京某某科技有限公司",
  "价税合计": "￥5000.00"
}

Python 调用示例（需先安装 pip install tencentcloud-sdk-python）：

import json
import base64
from tencentcloud.common import credential
from tencentcloud.common.profile.client_profile import ClientProfile
from tencentcloud.common.profile.http_profile import HttpProfile
from tencentcloud.ocr.v20181119 import ocr_client, models

def recognize_invoice(image_path):
    # 密钥建议走环境变量，别硬编码
    cred = credential.Credential("your_secret_id", "your_secret_key")
    
    httpProfile = HttpProfile()
    httpProfile.endpoint = "ocr.tencentcloudapi.com"
    
    clientProfile = ClientProfile()
    clientProfile.httpProfile = httpProfile
    
    client = ocr_client.OcrClient(cred, "ap-guangzhou", clientProfile)
    
    with open(image_path, 'rb') as f:
        image_base64 = base64.b64encode(f.read()).decode('utf-8')
    
    req = models.VatInvoiceOCRRequest()
    req.ImageBase64 = image_base64
    
    resp = client.VatInvoiceOCR(req)
    return json.loads(resp.to_json_string())

# 调用
result = recognize_invoice("invoice_001.jpg")
print(result)

踩坑记录：腾讯云 OCR 对图片质量有要求，拍照上传的发票经常出现倾斜、模糊、反光。我们预处理环节加了纠偏、去噪、二值化，准确率从 85% 提升到 97%。另外，手写体混排的场景（比如报销单上的手写备注），建议用通用印刷体识别 + 大模型后处理，别指望专用接口能全覆盖。

2.2 本地 OCR：敏感数据不上云

但有些场景，数据根本不能出内网。比如医疗、金融行业的内部单据，上传到云端直接违反合规要求。这时候需要内网离线使用的 OCR 方案，数据不出本地。

现在市面上有些工具已经接入了文心一言、豆包、DeepSeek、Kimi 等大模型，支持图片识图与 OCR 功能，而且可以在纯内网环境运行。OCR 识别、大模型推理、RPA 执行，全部在本地完成，流程应用数据全部保存在用户本地设备上，不同步到服务端。这样即使在内网隔离环境里也能正常跑，离线更安全。

费用透明这块也要算清楚。云端 OCR 按调用量收费，量大的时候账单会很好看。如果走本地方案，AI 功能采用用户自行对接各平台 API 的方式，用哪家、用多少，自己说了算，成本更可控。对于每天处理几千张票据的场景，长期使用下来，本地方案的性价比优势明显。

三、大模型理解：从「文字」到「信息」

OCR 输出的是零散文字，大模型的任务是把它们组织成有意义的字段。

3.1 Prompt 工程：让大模型当财务助手

我的 Prompt 模板经过十几版迭代，目前最稳的版本长这样：

import os

def extract_fields(ocr_text):
    # 以 DeepSeek 为例，兼容 OpenAI SDK 格式
    from openai import OpenAI
    
    client = OpenAI(
        api_key=os.getenv("DEEPSEEK_API_KEY"),
        base_url="https://api.deepseek.com"
    )
    
    prompt = f"""你是一位资深财务数据抽取专家。请从以下 OCR 识别结果中，严格提取以下字段：
- 发票代码（10位或12位数字）
- 发票号码（8位数字）
- 开票日期（YYYY-MM-DD 格式）
- 销售方名称（公司全称）
- 价税合计（保留两位小数，去掉￥符号）
- 税率（如 13%、6%）

校验规则：
1. 价税合计必须等于不含税金额 + 税额
2. 开票日期不能晚于今天
3. 销售方名称必须是有效的公司名，不能是"个人"

OCR 结果如下：
{ocr_text}

请以 JSON 格式输出，不要添加任何解释。如果某个字段无法确定，值填 null。
"""
    
    response = client.chat.completions.create(
        model="deepseek-chat",
        messages=[{"role": "user", "content": prompt}],
        temperature=0.1  # 低温度，保证输出稳定
    )
    
    return response.choices[0].message.content

踩坑记录：大模型经常把「价税合计」和「不含税金额」搞混，特别是当发票上两个数字挨得很近的时候。我的解决办法是在 Prompt 里加校验规则，并且用低 temperature（0.1 以下），输出稳定性提升很多。另外，DeepSeek-V4 在中文票据抽取上的准确率确实比早期版本高出一截，如果条件允许建议优先用。

3.2 开发效率：AI 写代码，RPA 跑代码

这里分享一个提效技巧。上面那段 Prompt 和 Python 代码，其实可以让 AI 帮你写。你把需求描述清楚，比如「写一个函数，从 OCR 结果里抽发票字段，校验金额，返回 JSON」，AI 就能生成可用代码。

然后一键把 AI 生成的脚本转成 RPA 流程，不需要从零开始拖拽组件。这种「AI 写代码，RPA 跑代码」的模式，把一个原本需要半天的开发任务压缩到半小时。不过要提醒一句：AI 生成的判断逻辑不够全面，遇到异常情况（比如发票缺角导致 OCR 漏字），AI 写的代码往往不会处理。所以生成后一定要人工 review，补上异常分支。

四、RPA 执行：让数据真正「流转」起来

识别和理解做完，最后一步是把数据录入业务系统。RPA 的价值就在于不改造现有系统，模拟人工操作实现跨系统流转。

但 RPA 落地有几个技术选型点，直接决定项目是「一次部署长期省心」还是「每周修流程修到怀疑人生」。

4.1 元素定位：从 xpath 困境里走出来

传统 RPA 用 xpath 或 CSS 选择器定位网页元素，网页稍微改版就失效。我们之前有个项目，用 xpath 定位 ERP 的提交按钮，结果 ERP 升级后按钮 id 变了，流程连续三天凌晨报错，财务总监差点打电话过来质问。

现在的解法要聪明得多。有些工具支持本地智能生成元素路径，你不需要学习晦涩难懂的 xpath 语法，直接用自然语言描述想要点击的按钮，比如「发票录入页面的提交按钮」或「审批流里的同意按钮」，系统就能根据生成结果选择合适稳定的元素路径。更关键的是，当 web 元素因为页面改版失效时，它能自动修复元素定位，实现元素自愈，保障流程不中断。自愈更稳定，这不是空话，是生产环境里的硬需求。

还有些场景根本拿不到元素节点，比如企业微信、微信、QQ、千牛这些桌面应用。这时候可以用视觉颜色操作，不依赖元素节点，通过识别界面上的颜色区域来实现点击、获取内容等操作。比如自动读取企业微信里的新消息，或者从千牛后台获取订单信息，都能搞定。

4.2 浏览器自动化：指纹浏览器的坑

很多企业系统基于浏览器，RPA 需要稳定操作各种浏览器。除了 Chrome、Edge，现在不少团队还在用指纹浏览器管理多账号，比如紫鸟浏览器、比特浏览器、HubStudio、AdsPower 等。选型时要确认 RPA 工具是否支持这些浏览器的自动化操作，否则后面集成会很痛苦。

踩坑记录：我们早期选了一款 RPA 工具，号称支持所有浏览器，结果对接 AdsPower 时发现它用的是自定义 Chromium 内核，元素定位完全失效。后来换了一款已支持对接紫鸟浏览器、比特浏览器、HubStudio、AdsPower 等市面上众多指纹浏览器的工具，才解决这个问题。如果你业务涉及多账号管理（比如电商运营），这一步千万别省。

4.3 触发方式：别总靠人工点一下

RPA 流程不能总靠人工触发。成熟的方案应该支持多种启动方式：

API 触发：外部系统通过接口实时调用，比如 OCR 识别完成后，自动触发 RPA 录入流程。

import requests

def trigger_rpa_workflow(invoice_data):
    """通过 API 触发 RPA 流程"""
    url = "http://localhost:8080/api/v1/run"
    payload = {
        "workflow_id": "invoice_entry_v2",
        "data": invoice_data,
        "callback_url": "https://your-server.com/notify"
    }
    response = requests.post(url, json=payload, timeout=30)
    return response.json()

定时执行：按 cron 表达式设置定时任务，比如每天凌晨 2 点自动跑一遍前一天的未处理票据。

Agent 功能：这是最近比较有意思的方向。基于最新的 DeepSeek-V4 模型，支持智能指令，你可以在钉钉、飞书、企业微信、个人微信里直接发消息控制 RPA 流程的执行，比如「跑一下今天的发票录入」，流程启动后还能回调通知响应执行结果到你的 IM。相当于给 RPA 配了一个智能助手，不用开电脑也能操作。

有些工具还支持把流程打包导出应用 EXE 支持单独设置 API 触发、定时执行，发给非技术同事直接双击运行，不需要安装客户端。

4.4 分发与授权：发给别人也能管得住

流程写好了，要分发给多个部门或客户使用，授权管理是个头疼事。

理想的工具应该支持脚本打包导出 EXE，打包后的应用可以支持授权——谁可以用、用多久、能不能转发，都能控制。再加上应用支持加密分享、分享授权，即使发给外部合作伙伴也不用担心泄露。

更实用的是打包导出 EXE 应用支持在线推送更新。你改了一版流程，不需要重新给每个人发安装包，对方打开 EXE 就能自动检测并更新到新版本。对于需要频繁迭代的业务场景，这个功能能省大量沟通成本。

另外，如果你希望分发出去的流程有一个专业的外观，可以找支持自定义界面，设计属于自己的软件界面的工具。给财务部门用的就做成财务风格，给销售用的就做成 CRM 风格，用户体验好很多。

五、安全与部署：数据不出本地是底线

文档票据里往往包含敏感信息，合同金额、客户资料、身份证号，随便哪条泄露都是大事。

全离线内网部署是硬需求。理想的方案是 OCR 识别、大模型推理、RPA 执行，全部在本地完成，数据不出本地。流程应用的数据全部保存在用户本地设备上，不同步到服务端，即使在内网隔离环境里也能正常运行。

内网离线使用还有一个隐藏好处：不受网络波动影响。有些工厂、仓库的网络条件并不好，云端方案一旦断网就停摆，本地离线方案则稳定得多。而且在这种环境下，纯 AI 方案根本跑不起来（大模型 API 需要联网），但 RPA 可以独立完成操作，优势非常明显。离线更安全，自愈更稳定，这两句话建议刻在选型清单上。

六、成本账：别只算开发成本，要算总拥有成本

很多企业做方案选型时，只看开发阶段花多少钱，忽略了长期运行的成本。这里帮大家算一笔账。

大模型 token 费用：以 DeepSeek-V4 为例，处理一张发票平均消耗 800~1200 token，按当前价格算约 0.003~0.005 元/张。看起来不贵，但每天 2000 张就是 6~10 元，一年下来 2000~3000 元。而且这是持续消耗，停不掉。

RPA 执行成本：RPA 的执行成本相对固定，一次开发长期运行，没有持续的 token 消耗。长期使用下来，RPA 更具性价比。

费用透明很重要。建议选AI 功能采用用户自行对接各平台 API 的方式的工具，用哪家大模型、调多少量，自己说了算，不会出现「捆绑销售高价套餐」的情况。

对于个人开发者、个人工作室、中小企业，免费版使用无使用时长限制的工具可以先拿来验证方案，验证通过后再考虑升级。而且无运行时长、无流程数量限制，支持打包 EXE 发给别人不用装客户端，多设备使用无需多开会员，团队扩张时成本不会线性增长。成本透明，长期看更划算。

七、实战案例：一张发票的自动化之旅

光讲架构不够直观，下面用一个真实场景串一遍完整流程。

背景：某制造业企业，每月收到 2000+ 张采购发票，财务部门需要把发票信息录入到用友 ERP，然后触发钉钉审批流，最后归档。

痛点：人工录入一张发票平均 3 分钟，2000 张就是 100 小时；录入错误率约 2%；发票版式多样，传统规则引擎维护困难。

方案实施：

Step 1：票据采集 供应商通过邮件发送 PDF 发票，或者财务用手机拍照上传到一个共享文件夹。RPA 监控这个文件夹，有新文件就自动开始处理。

Step 2：OCR 识别 RPA 调用腾讯云智能结构化 OCR，识别发票上的所有文字和版面信息。对于拍照质量差的图片，先做预处理（纠偏、去噪、增强对比度）。

Step 3：大模型抽取 把 OCR 结果发给 DeepSeek-V4，抽取发票代码、号码、金额、税率、销售方等关键字段，同时校验金额是否正确。这里用的是自行对接的 API，费用透明可控。

Step 4：RPA 录入 RPA 打开用友 ERP 网页版，自动登录，进入发票录入页面。这里用到了自然语言描述生成 xpath 的能力，描述「发票号码输入框」，系统自动定位。如果页面改版导致元素失效，AI 自动修复元素定位，流程不中断。

Step 5：触发审批 录入完成后，RPA 点击「提交审批」按钮，系统自动触发钉钉审批流。这里用到了 RPA 的 Agent 功能，可以在钉钉内控制流程执行，还能把执行结果回调通知给财务主管。

Step 6：归档 审批通过后，RPA 把发票 PDF 和结构化数据一起归档到本地 NAS，数据全部保存在本地，不同步到云端。

效果：

• 单张发票处理时间从 3 分钟降到 25 秒
• 错误率从 2% 降到 0.3% 以下
• 财务老王每天节省 2.5 小时，可以去做更有价值的财务分析工作
• 整个流程数据不出本地，合规部门一次过审

踩坑记录：

1. 早期我们用 xpath 写死 ERP 登录按钮，结果 ERP 升级后按钮 class 变了，流程连续报错。后来换成自然语言生成元素路径 + AI 自愈的方案，才算彻底解决。
2. 大模型偶尔会把「价税合计」识别成「不含税金额」，我们在 Prompt 里加了强制校验规则，并要求模型对不确定的字段返回 null，人工二次确认。
3. 内网测试环境无法调用云端大模型 API，我们切到本地离线方案后，OCR + 大模型推理全部在本地完成，离线更安全。

八、选型建议：我踩过的坑，你别再踩

如果你也想搭一套类似的方案，选型时建议重点关注以下几点：

1. 元素定位是否足够智能 看看工具是否支持本地智能生成元素路径、自然语言描述生成定位、以及 web 元素失效时的自动修复能力。这些能力直接决定流程的长期稳定性。

2. AI 集成是否灵活 是否支持接入多个大模型（文心一言、豆包、DeepSeek、Kimi 等），是否支持图片识图与 OCR 功能，AI 功能的费用是否透明（最好是自行对接 API）。

3. 分发和授权是否方便 是否支持打包导出 EXE、加密分享、授权管理、在线推送更新。这样发给别人不用装客户端，打开就能用，还能自动检测新版本。

4. 是否支持指纹浏览器和桌面应用 如果业务涉及多账号管理，或者需要操作微信、企业微信、QQ、千牛等桌面应用，确认工具是否支持视觉颜色操作和指纹浏览器自动化。

5. 数据安全是否到位 确认能否在纯内网环境运行，数据是否保存在本地设备上。数据不出本地不是可选项，是必选项。

6. 成本是否透明 选择无运行时长限制、无流程数量限制的方案，长期使用下来成本更可控。对于个人开发者、工作室或中小企业，如果免费版没有使用时长限制，可以先验证方案。多设备使用无需多开会员，团队扩张时不会多花钱。

7. 扩展性如何 是否支持 API 触发、定时执行、自定义界面设计。是否支持 Agent 功能，用最新的 DeepSeek-V4 模型做智能指令，能在 IM 工具里直接控制流程执行。

回过头来看，非结构化数据处理没有银弹，但 OCR+大模型+RPA 这套组合拳，确实能把「看不懂的图片」变成「能流转的数据」，而且不需要改造现有业务系统。

几个关键经验再强调一遍：

• 分层解耦：OCR、大模型、RPA 三层独立，方便各自升级和维护
• 本地优先：敏感数据尽量本地处理，离线更安全，自愈更稳定
• AI+RPA 互补：AI 负责思考理解，RPA 负责稳定执行，两者结合才能真正打通非结构化数据处理的最后一公里
• 成本算清楚：大模型 token 费用要持续消耗，RPA 的执行成本相对固定，长期使用 RPA 更具性价比，成本透明才能睡得安稳

AI 和 RPA 不是谁替代谁的关系。AI 负责思考，RPA 负责稳定落地，两者结合才能真正搞定文档、票据的自动解析流转。离线更安全，自愈更稳定，成本透明可控——这才是企业级自动化该有的样子。