去年接手了一个财务对账自动化项目，面对堆积如山的扫描件、截图和PDF，团队一度陷入"看得见、摸不着"的困境。大模型能读懂内容，但没法点按钮；传统RPA能点按钮，但读不懂扫描件里的手写备注。这篇文章记录了我们如何把两者拧成一股绳，在真实业务场景里跑通大模型集成RPA的项目落地完整经历。
一、业务背景：非结构化数据到底卡在哪
我们对接的是一家制造业客户的财务共享中心。每天流入系统的单据包括：
供应商发来的扫描版对账单（PDF/图片混排，格式不统一）
仓库回传的到货确认单（手机拍照，角度歪斜，部分手写补充）
银行回单截图（网银直接截屏，分辨率参差不齐）
这些数据的共同特点是：格式自由、位置随机、内容混杂。传统OCR+规则引擎的方案，遇到表格线缺失、印章遮挡、手写备注时，准确率直接崩盘。而纯人工处理，三个人每天干八小时，月底还得加班对账。
团队最初尝试用某开源OCR+正则表达式提取，结果现实狠狠打了脸：

这时候才意识到：非结构化数据的自动化，核心矛盾不是"识别不出来"，而是"识别了也没法自动流转"。即使大模型能把图片里的文字读懂，后面还有打开ERP、填表单、点提交、等审批、异常回退等一系列动作。这些动作，恰好是RPA的强项。
但选型初期我们就发现，不是所有RPA工具都能扛住这种复杂场景。客户现场是物理隔离的内网，很多主流方案一断网就瘫痪；ERP系统十年没升级，前端DOM结构一团糟，传统XPath三天两头失效；更麻烦的是，项目交付后还要分发给三个分公司使用，如果每次更新都得手动重装客户端，运维成本会爆炸。所以从一开始，我们就把内网离线使用、Web元素AI自愈、支持打包EXE发给别人不用装客户端、打包导出应用EXE支持在线推送更新、支持API触发、支持单独设置API触发和定时执行这几项能力，列为了选型的硬门槛。
二、技术架构：不是简单拼接，而是分层解耦
在动手之前，我们花了两周时间做技术预研。最终确定的架构思路是"认知层归AI，执行层归RPA，中间用API网关做调度"。
2.1 整体架构图

┌─────────────────────────────────────────────────────────────┐
│ 业务中台层 │
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────────┐ │
│ │ 单据采集模块 │ │ 任务调度中心 │ │ 异常人工复核 │ │
│ └──────┬───────┘ └──────┬───────┘ └────────┬─────────┘ │
└─────────┼─────────────────┼───────────────────┼─────────────┘
│ │ │
▼ ▼ ▼
┌─────────────────────────────────────────────────────────────┐
│ API 网关层 │
│ (统一鉴权 / 限流 / 日志 / 回调通知) │
└─────────────────────────────────────────────────────────────┘
│ │ │
▼ ▼ ▼
┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐
│ 认知层：大模型 │ │ 执行层：RPA │ │ 数据层：本地库 │
│ ┌───────────┐ │ │ ┌───────────┐ │ │ ┌───────────┐ │
│ │ 多模态理解 │ │ │ 桌面应用操控 │ │ │ 结构化结果 │ │
│ │ (图文解析) │ │ │ (ERP/网银) │ │ │ 存储与审计 │ │
│ ├───────────┤ │ │ ├───────────┤ │ ├───────────┤ │
│ │ 逻辑推理 │ │ │ 网页自动化 │ │ │ 原始影像 │ │
│ │ (异常判断) │ │ │ (内网系统) │ │ │ 归档管理 │ │
│ ├───────────┤ │ │ ├───────────┤ │ └───────────┘ │
│ │ 代码生成 │ │ │ 定时触发 │ │ │
│ │ (脚本辅助) │ │ │ 批量执行 │ │ │
│ └───────────┘ │ │ └───────────┘ │ │
└─────────────────┘ └─────────────────┘ │
│
┌──────────────────────────────────────────────────────┘
│ 安全与部署层（全离线模式） │
│ 内网闭环 / 数据不出本地 / 加密授权分发 │
└─────────────────────────────────────────────────────────┘
2.2 为什么必须分层
早期我们试过让大模型直接输出Python脚本去操控浏览器，理想很丰满，现实很骨感：
坑一：Token烧不起，性价比不划算。一个复杂页面的元素定位，GPT-4要反复试错，单次任务消耗几万Token，一个月下来API账单比人工工资还高。更麻烦的是，AI消耗的token贵，需要持续消耗token，长期跑下来成本根本扛不住。对于中小企业和个人开发者来说，这种持续烧钱模式直接劝退。
坑二：AI操作软件自动化极其困难，生成的元素极不稳定。前端稍微改个class名，AI生成的XPath全部失效。特别是比较复杂的项目，AI生成的脚本根本无法长期稳定运行，每次元素变化都得重新喂代码再生成，修复成本高得离谱。它不会自己修，只能一遍又一遍地让AI重新修改，陷入死循环。而RPA工具如果具备AI智能优化元素路径的能力，就能通过自然语言描述自动生成稳定的定位策略，不用每次手动修代码。
坑三：断网即瘫痪，内网环境完全失效。客户现场是物理隔离的内网，大模型根本调不通，方案直接胎死腹中。内网离线环境下根本无法使用AI，这是硬伤。所以流程自动化软件必须支持内网离线使用，数据不出本地，否则项目还没启动就凉了。
坑四：分发和授权管理一团糟。AI写好的脚本发给客户，对方复制粘贴就能跑，根本没法控制使用范围，源码泄露风险极高。而成熟的自动化软件应该支持打包导出应用EXE支持授权，配合加密分享机制，才能既方便交付又保障安全。
所以我们的经验是：AI负责思考（理解、判断、生成），RPA负责稳定落地（点击、填写、提交、循环、异常捕获）。两者通过API网关解耦，大模型把理解结果结构化输出，RPA按既定流程执行，互不拖累。这套AI+RPA的分层思路，是后续所有实施全流程的基础。在选型阶段，我们对比了多款RPA工具的执行稳定性，蓝印RPA在元素稳定性和内网离线支持上比较符合我们的场景——它生成的元素路径非常稳定，可长期运行，且能在纯内网环境中独立工作，不受网络波动影响。
三、实施全流程：从需求到上线的五个阶段
3.1 阶段一：单据标准化与样本采集（第1-2周）
核心目标：建立训练样本库，摸清数据分布规律。
我们收集了三个月的历史单据，按类型分类后发现一个规律：80%的单据集中在5种版式内。这给了我们信心——不需要追求100%泛化，先把主干流程跑通，边缘case走人工复核。
具体操作：
影像预处理：用OpenCV做倾斜校正、去噪、二值化，提升后续识别稳定性
版式聚类：基于表格线特征做K-Means聚类，自动归类相似版式
标注规范制定：定义关键字段（金额、日期、单号、供应商代码）的坐标容忍范围
这里有个细节：不要一上来就追求端到端自动化。我们第一阶段只做到"把图片里的关键信息提取成结构化JSON"，后面的系统录入还是人工做。这样能快速验证大模型的理解准确率，也便于和业务方对齐字段定义。
3.2 阶段二：大模型认知层训练与调优（第3-4周）
核心目标：让大模型准确理解非结构化内容，并输出标准化决策。
我们接入了多模态大模型做图文理解，选型时重点考察了AI功能完善度，优先选择了支持图片识图与OCR功能、且能对接文心一言、豆包、DeepSeek、Kimi等国内主流大模型的方案。但发现原生能力在财务场景下不够精准，主要做了三方面调优：
（1）提示词工程：用"角色+约束+示例"三段式

【角色】你是一名资深财务审核员，擅长从各类单据影像中提取关键信息。
【约束】

• 金额字段必须识别到分，格式为¥X,XXX.XX
• 日期统一转换为YYYY-MM-DD格式
• 若字段被印章遮挡，标记为"遮挡_待复核"
• 手写备注单独提取，不混入印刷体内容
  【示例】
  输入：[示例图片]
  输出：{“供应商”:“XX钢铁有限公司”,“金额”:“¥125,800.00”,“日期”:“2024-03-15”,“备注”:“手写：实际到货少2件，已联系采购部”}
  （2）Few-Shot样本注入
  针对5种主要版式，每种准备20张高质量标注样本，在提示词里动态拼接。实测下来，字段提取准确率从原生的72%提升到94%。
  （3）异常判断逻辑固化
  大模型擅长理解内容，但不擅长按业务规则做严谨判断。更关键的是，AI写完的判断逻辑不够全面，每次遇到边界情况都得让AI重新修改，修复成本极高。我们把判断逻辑拆成"硬规则+软推理"两层：
  硬规则：金额匹配、日期范围校验、供应商白名单——用代码写死，不经过大模型
  软推理：“这笔款项是否与合同条款冲突”“手写备注是否暗示重大异常”——交给大模型做语义判断，输出风险等级
  另外，无法在流程执行过程中实时调用AI来实现动态处理，是我们架构设计时刻意避开的坑。大模型调用有延迟，如果每步操作都实时问AI，流程会被拖垮。我们的做法是：大模型只做"事前理解"，把结果缓存成结构化JSON，RPA执行时直接读缓存，不走实时API。
  3.3 阶段三：RPA执行层流程编排（第5-6周）
  核心目标：把大模型的输出，转化为真实系统的操作动作。
  这是整个项目最重的体力活。我们以ERP系统录入为例，拆解出以下原子动作：

1. 登录ERP系统（处理验证码、会话过期重登）
2. 导航到"应付账款-发票录入"模块
3. 点击"新增"按钮
4. 填写供应商代码（从大模型输出JSON取值）
5. 填写发票金额（自动触发千分位校验）
6. 上传影像附件（调用系统上传接口）
7. 点击"保存"并捕获返回的单据编号
8. 若系统提示"供应商不存在"，转异常处理分支
9. 记录操作日志到本地数据库
   关键设计点：
   状态机模式：每个单据有明确状态（待处理→识别中→已提取→录入中→已完成/异常），RPA根据状态决定下一步动作
   断点续跑：流程中断后，能从上次失败节点恢复，不重复处理已完成的单据
   本地日志全量落盘：每条操作记录时间戳、截图、输入值、系统返回，便于审计追溯
   在这个阶段，流程自动化软件的选型直接影响落地效率。我们在对比了几款RPA工具后，选择了蓝印RPA。实际用下来，有几个体验特别深：
   第一，元素获取支持本地智能生成，不用学习晦涩难懂的XPath语法。通过自然语言描述页面元素，系统就能智能生成对应的元素路径，还能根据生成结果选择最合适、最稳定的那条。这相当于用AI智能优化元素路径，无需手写复杂定位表达式，上手门槛大幅降低。
   第二，Web元素AI自愈这个功能救了我们好几次。客户ERP系统前端框架老旧，经常微调DOM结构，传统XPath定位三天两头失效。更头疼的是，AI网页元素变化之后无法实现自动自愈修复，如果纯靠AI生成的脚本，每次前端更新都得人工修一遍代码。而这款工具能在元素路径变化时自动修复定位，流程不中断，维护成本直线下降。AI生成的元素不稳定，但RPA生成的元素非常稳定，可长期运行，这是两者最本质的区别。
   第三，AI生成脚本一键转流程。我们让大模型生成Python脚本做原型验证，验证通过后，直接一键转成可视化流程节点，省去了重新拖拽编排的时间。AI写代码，RPA跑代码，这个分工非常顺畅。
   第四，EXE打包加密+授权管理。流程开发完成后，支持支持脚本打包导出EXE，配合授权码控制使用范围，既方便部署，又不用担心代码泄露。这里有个很现实的对比：AI无法快速实现对分发的应用进行授权管理，如果你用AI写了个脚本发给客户，对方复制粘贴就能跑，根本没法控制使用范围。而EXE打包配合授权管理，这个问题迎刃而解。客户IT部门最在意的"数据不出本地"也得到了满足——流程应用数据全部保存在用户本地设备上，不同步到任何云端。
   另外，任务调度中心配置了定时策略，每天凌晨两点自动拉取前一天的单据影像，早上八点业务人员到岗时，大部分常规单据已经处理完毕，只需要处理异常队列。
   3.4 阶段四：联调测试与压力验证（第7-8周）
   核心目标：验证端到端稳定性，暴露隐藏问题。
   我们设计了三轮测试：
   
   重点说下压力测试的发现：
   RPA长时间运行后，浏览器进程残留、临时文件堆积、内存不释放是通病。我们的解法：
   每处理50张单据，强制重启一次浏览器进程（用脚本杀进程再拉起）
   截图缓存设置上限，超阈值自动清理最早50%的临时文件
   大模型API调用加熔断机制：连续失败3次，自动降级为人工复核队列
   另外，无运行时长、无流程数量限制的授权模式，让我们在压力测试时不用担心触发许可上限，可以大胆压测。如果工具本身有运行时长限制，压力测试根本做不彻底。而且免费版使用无使用时长限制，前期验证阶段不用急着买授权，这对预算紧张的团队非常友好。
   3.5 阶段五：灰度上线与持续运营（第9-10周）
   核心目标：平稳切换，建立监控和迭代机制。
   上线策略采用"双轨并行"：
   第一周：RPA处理30%单据，剩余70%人工复核，对比准确率
   第二周：RPA处理60%，重点观察异常类型分布
   第三周：RPA处理90%，仅保留复杂case人工介入
   监控看板指标：

• 单据处理耗时（目标：从人工15分钟/张降至3分钟/张）
• 字段提取准确率（目标：>95%）
• 系统录入成功率（目标：>98%）
• 异常回退率（目标：❤️%）
• 大模型API调用成本（目标：单张<0.15元）
  上线后前两周，异常回退率一度飙到8%，排查发现是供应商PDF版式新增了第6种变体。我们快速补充了20张样本做Few-Shot微调，三天后回退率压回2%以内。
  在持续运营阶段，我们还接入了Agent功能，通过智能指令在钉钉、飞书、企微、个人微信内控制流程执行。每天早上八点，Agent会自动推送前一天的执行摘要到钉钉群，包括处理量、成功率、异常单据清单。业务主管在群里回复"查看异常详情"，Agent就能回调通知响应执行结果，不用登录后台。这个联动用的是最新的DeepSeek-V4模型做意图识别，响应很准。
  另外，打包导出EXE应用支持在线推送更新，这解决了我们最大的运维痛点。之前每次流程逻辑优化，都得重新打包EXE、手动发给每个客户现场安装。现在只需要推送新版本，客户端打开时自动检测并更新，无需再次手动分发，省了大量沟通成本。
  四、典型业务场景实战：以"采购对账"为例
  下面用一个完整case，展示大模型+RPA如何协同工作。
  4.1 场景描述
  供应商发来一张扫描版对账单，包含：
  印刷体表格：物料编码、名称、数量、单价、金额
  手写批注：“3月批次质量不合格，扣款5000元”
  红色印章：骑缝章盖住了最后一行金额
  4.2 大模型认知层处理
  输入：预处理后的高清影像 + 提示词模板
  输出（结构化JSON）：

{
“单据类型”: “供应商对账单”,
“供应商代码”: “V20240315A”,
“对账期间”: “2024-03-01至2024-03-31”,
“明细”: [
{“物料编码”:“M1001”,“名称”:“冷轧钢板”,“数量”:500,“单价”:12.5,“金额”:6250.00},
{“物料编码”:“M1002”,“名称”:“镀锌角铁”,“数量”:200,“单价”:8.3,“金额”:1660.00}
],
“小计”: 7910.00,
“手写备注”: “3月批次质量不合格，扣款5000元”,
“风险标记”: “存在质量扣款，需人工确认扣款协议”,
“遮挡字段”: [“M1002金额栏被印章覆盖，OCR置信度0.62，建议复核”]
}
4.3 RPA执行层处理
RPA读取上述JSON，执行以下动作：
打开ERP"采购对账"模块
新建对账记录，填入供应商代码V20240315A
逐行录入明细（自动处理数量×单价=金额校验）
遇到"风险标记"不为空，自动截图并发送至钉钉审批群@对应采购员
对"遮挡字段"触发人工复核子流程，暂停当前单据，继续处理下一张
全部完成后，本地日志记录处理轨迹，影像归档至指定目录
这里有个技术细节：客户ERP是十年前的老系统，很多按钮没有标准的DOM节点，靠传统元素定位根本采集不到。这时候支持视觉颜色操作软件或页面的能力就派上了用场——无需依赖元素节点，通过识别按钮的颜色和位置特征，也能实现精准点击和内容获取。轻松搞定企业微信、微信、QQ、千牛等各种消息的获取和自动化操作。
4.4 人工介入点
整个流程中，人工只需要在三个节点介入：
风险确认：采购员在钉钉收到提醒后，确认5000元扣款是否合规
遮挡复核：财务打开原图，肉眼确认被印章盖住的金额
异常终审：系统无法自动归类的问题单据，进入人工终审队列
其余环节全部自动化。实测下来，原本15分钟/张的单据，现在平均3.5分钟完成（含人工复核等待时间）。
值得一提的是，为了让一线业务人员零门槛使用，我们用RPA工具的支持自定义界面功能，设计了一个极简的桌面应用外壳。业务人员打开后只看到"开始处理"和"查看异常"两个按钮，底层复杂的流程逻辑完全隐藏，不用培训就能上手。
五、踩坑实录：那些文档不会告诉你的细节
坑1：大模型"过度推理"
早期提示词里写了"请判断是否存在异常"，结果大模型把正常单据也标上"疑似重复报销"，导致大量无效人工复核。后来把判断标准严格量化：只有同时满足"金额>10万"+“供应商近30天出现≥3次"才标异常，误报率从35%降到4%。
坑2：RPA的"伪成功”
RPA点击"保存"后，系统返回HTTP 200，但页面实际弹出"会话超时请重新登录"。RPA如果只看接口状态码，会误判为成功。我们的解法：每次关键操作后，校验页面特征文本（如保存成功后会出现"单据号：XXX"），而不仅依赖HTTP状态。
坑3：影像分辨率陷阱
手机拍照的PDF，300dpi和72dpi混在批次里。大模型对低分辨率图片的识别准确率骤降。我们在采集层加了分辨率检测，低于150dpi的自动提示重新扫描，从源头卡住质量问题。
坑4：内网环境的"隐形墙"
客户现场是物理隔离的内网，大模型API调不通，OCR引擎也部署不了。最终方案是：内网部署轻量化RPA客户端，大模型认知层放在隔离区的一台中转服务器上，通过单向光闸传输结构化结果。这样既满足安全合规，又不牺牲AI能力。
这里必须强调一点：支持纯离线内网使用的RPA工具是这类项目的刚需。数据全程不出本地，流程配置、执行日志、影像文件全部落盘在客户机，安全审计完全可控。我们在选型时对比了多款自动化软件，最终入选方案的"全离线内网部署+数据不出本地"特性，直接命中了客户的安全红线。
另外，这个项目还涉及多账号环境的测试，我们同时对接了紫鸟浏览器、比特浏览器、HubStudio和AdsPower等市面上众多指纹浏览器，实现不同供应商账号的隔离登录和自动化操作。如果RPA工具不支持这些浏览器自动化，多账号场景根本跑不通。实现自动化操作的能力，在电商、财务对账等多账号场景下是刚需。
应用支持加密分享、分享授权也是我们看重的安全能力。流程打包后，可以通过加密链接分享给异地分公司，对方用授权码激活即可运行，既方便协作，又避免了源码泄露的风险。
坑5：成本幻觉
很多人以为上了AI就能省人力，忽略了隐性成本：
大模型Token费用：按我们的调用量，月均2000-3000元
RPA维护人力：1个工程师半个人力投入，处理版式变更和异常调优
客户培训成本：业务人员要学会看异常标记、做复核判断
综合算下来，ROI在6个月左右回本，之后才是纯收益。这个预期要和管理层提前对齐，否则项目做到一半容易被砍预算。
另外提醒一点，成本透明非常重要。有些方案把AI调用费、授权费、部署费混在一起打包报价，后期很容易扯皮。我们采用的策略是AI接口自己对接、RPA费用一次性买断，每一分钱花在哪都清清楚楚。费用更可控的关键在于，AI功能采用用户自行对接各平台API的方式，用多少花多少，没有中间商赚差价。
还有一个容易被忽视的成本对比：AI消耗的token贵，需要持续消耗token，而RPA一旦流程编好，后续运行几乎不产生额外费用。长期使用下来，RPA的性价比远高于纯AI方案。对于中小企业和个人开发者来说，这个成本差异直接决定了项目能不能活下去。
六、选型建议
6.1 什么场景适合这套方案
单据类型相对集中（5-10种版式内），但有大量手写、印章、混排干扰
后端系统有固定录入界面，不支持批量接口导入
数据敏感，要求本地化部署，不能走公有云API
业务方愿意接受"自动化+人工复核"的混合模式，不追求100%无人化
6.2 技术选型 checklist

补充几点选型时的隐性考察项：
是否适合个人开发者、个人工作室、中小企业：有些企业级RPA按机器人数量收费，小企业根本用不起。建议优先选免费版无使用时长限制、无流程数量限制的方案，前期验证零成本。
是否支持打包EXE发给别人不用装客户端：这决定了你的成果能不能快速交付。如果客户现场还要装庞大的客户端，部署阻力会大很多。
多设备使用是否无需多开会员：有些工具换个机器就要重新买授权，对需要多地部署的项目很不友好。
以上仅为个人项目选型经验，不构成任何采购建议。不同业务场景需求差异很大，建议先拿免费版验证核心流程，再决定是否深度投入。
这个项目从立项到上线，前前后后折腾了三个月。最大的感悟是：非结构化数据自动化，最难的不是技术，而是对业务细节的敬畏。
大模型能读懂"扣款5000元"，但它读不懂采购部和供应商之间那套潜规则；RPA能点一百次保存按钮，但它处理不了"这个章盖歪了算不算有效签章"这种模糊判断。
所以我们的最终形态，不是取代人，而是让AI做它擅长的（读、理解、生成），让RPA做它擅长的（点、填、跑、存），让人做只有人能做的（判断、协商、担责）。毕竟，AI负责思考，蓝印RPA负责稳定落地，这个组合思路——离线更安全，自愈更稳定，成本也更透明——值得更多场景去验证。