【AI 业务流架构师】09-实战案例：财务填报机器人——跨系统数据搬运的自动化改造

实战案例财务填报机器人——跨系统数据搬运的自动化改造一、背景痛点每月被报销和对账吃掉的那几天一家中型企业做信息化负责人财务部门每个月最头疼的事情不是算账而是搬数据。销售人员出差回来掏出一沓发票——住宿票、交通票、餐饮票拍照后要手动把金额、日期、税号、票据号一项项敲进报销系统财务月底对账要从网银导出流水、从 ERP 导出应收应付明细、再打开 Excel 做交叉核对三个系统来回切换稍有眼花就填错一格月度报表更是如此数据散落在四五个业务系统里手工搬运加核对往往要耗掉两个人两三天。公司每月报销票据大约 2000 张平均每张从拍照到落进报销表要花 4-5 分钟仅这一项就吃掉财务团队每月上百小时。这还没算填错重填、附件上传失败、跨系统口径不一致导致的返工。更麻烦的是报销系统是第三方 ERP有些操作根本没有 API只能靠人工在网页上点击填报。问题的核心不在识别——市面上随便一个 OCR 工具都能把发票字段抠出来。问题在于识别完之后这些数据怎么真正写进业务系统、附件怎么挂上去、写进去之后怎么确认没填错。能识别不叫完成能落地闭环才叫完成。这句话是我做这个项目时最深的体感。二、方案设计从搬数据到数据自动搬动手写代码之前我花了一个下午做架构推演。后来发现这个习惯帮了大忙——写代码前的那一个小时基本决定了项目的天花板。我把整个链路拆成了几个关键环节每个环节都要回答输入是什么、输出是什么、失败了怎么办。2.1 整体链路票据到记录的七步闭环我设计的核心链路是这样的票据输入 → 字段识别 → 字段校验 → 附件上传 → 写入目标表 → 回读确认 → 异常分流每一步都不是调一个函数那么简单。比如字段识别这一步输入是一张图片或 PDF输出是结构化的字段集合票据号、金额、开票日期、税号等失败的情况包括置信度过低、必填字段缺失、格式不符——这些都要有对应的兜底分支。2.2 能力拆分四个原子能力把整个机器人拆成四个独立可测试、独立可替换的能力单元能力职责替换条件识别把非结构化票据变成结构化字段OCR 引擎可换校验判断记录够不够格落表规则可独立修改写表把合格记录真实写入目标系统目标系统可换兜底处理不合格和写表失败的情况复核队列机制这样拆的好处是哪天我想把本地 OCR 换成云端多模态只动识别这一块就行哪天报销系统从飞书多维表格换到别的平台只动写表这一块。2.3 三种接口面向三种用户这是一个很重要的设计经验同一个能力要给三种不同的用户提供三种接口。给 Agent 看的一份自然语言契约SKILL.md声明这个能力做什么、什么时候触发、完成态是什么。大模型读这份文件来决定要不要调用你的能力。给程序看的一个函数签名上游代码直接调用参数明确。给业务人员看的一份可读的规则配置文件YAML 格式财务人员自己就能改额度上限、必填字段、复核策略不用动代码。第三条尤其重要。我设计的规则文件里报销额度上限、必填字段清单、什么情况进复核队列——全是业务决策不是技术决策。业务人员加一行就生效改个数字就调额度。这避免了改一条规则要提需求、排期、上线的痛苦循环。2.4 写表优先走 API而非浏览器自动化报销系统如果有官方 API我一定优先走 API。原因很直接API 依赖官方接口契约稳定性远高于模拟浏览器操作错误处理更清晰状态码、响应体、字段级错误都能追踪批量请求天然适合批处理。但现实中有些系统确实没有 API比如我们用的某个老旧 ERP 的填报模块。这种情况下浏览器自动化就成了攻坚武器——它是在没有 API 的场景下兜底用的而不是首选方案。这个定位要分清API 是日常武器浏览器自动化是攻坚武器。三、实施过程从识别到落表的每一步3.1 识别能力的三组设计抉择识别这一步看似简单不就是 OCR 嘛但做的时候我面临了三组抉择每个抉择的答案都不在哪个技术更先进里而在业务约束里。抉择一本地 OCR 还是云端多模态用 GPT 或其他云端多模态识别发票质量确实高。但每张票 0.05 到 0.2 元的成本每天上千张票就是几十到上百元更关键的是发票数据要上云税号、合作伙伴信息都是敏感数据。我选了开源本地 OCR 引擎RapidOCR零边际成本、数据不出网、输出结构稳定坐标加文本块。单字准确率确实略低于多模态但够用而且失败时能精确定位到哪个字段、哪条规则出了问题——这种白盒可追踪性比多个两三个百分点准确率重要得多。抉择二PDF 和图片走不同的路。图片JPG/PNG本质是像素“字就是图”没有别的选择必须走 OCR。PDF 则不同——电子发票的 PDF 文字层本来就在直接读字符流毫秒级、准确率接近 100%。只有扫描版 PDF图片包了个 PDF 皮才需要 OCR。我的策略是PDF 优先尝试原生文本抽取失败再降级到 OCR。这就是优雅降级——能用更快更准的方案就用用不了再退一步。抉择三字段提取用规则还是用大模型这里我踩过坑。最初我用大模型提取字段调用一次 LLM 让它理解发票结果每次输出格式都略有不同——今天叫金额明天叫总额下游解析经常断。后来改成规则提取关键词锚定加正则匹配加上下文位置判断毫秒级、零成本、输出 100% 稳定失败时能精确定位到哪条规则没匹配上。原则是强格式文档用规则弱格式文档才用大模型——别动不动就上 AI。3.2 校验与防填错机制识别完不等于能落表。我设计了一套校验层防止识别出来了但数据有问题的记录污染业务表字段完整性校验必填字段如交通报销表的乘车人、车次、出发站、到达站缺一个就拦截不进入写表阶段。额度上限校验住宿类上限 3000 元、交通类上限 2000 元——这些数字写在规则文件里财务自己改。重复检测同一张票上传两次自动标记 error。格式修正提取出来但格式不对比如金额多了个空格先走格式修正规则再试一次。一个重要原则识别失败不等于整张票作废。失败的是某个字段而不是整张票。某字段置信度过低就保留该字段但标记低置信度字段值与业务规则冲突就整张票进复核队列必填字段缺失就拦截不写表实在识别不了就不报错挂起等人工。这种渐进式失败机制保证了整体流程不停。3.3 附件上传与写入目标表这一步是最容易翻车的。发票原件要作为真附件挂到记录上而不只是把文件路径写在文本字段里。流程是先把附件上传到目标表的专属附件上传接口拿到一个附件 token再把这个 token 写到记录的附件字段里。写完之后再调一次读取接口把刚写入的记录读出来确认附件字段确实有值、记录确实存在。为什么非要回读确认因为我遇到过 API 返回 200 但实际没写入的情况。不回读就以为成功了这种假成功比报错更危险。3.4 对接无 API 系统的浏览器自动化对于那个没有 API 的老旧 ERP 填报模块我用浏览器自动化做了对接。思路是先把识别和校验后的结构化数据准备好然后驱动浏览器模拟人工操作——打开填报页面、定位字段、填入数据、上传附件、提交表单。这部分的关键不是技术难度而是容错设计页面加载超时怎么办字段定位失败怎么办提交后怎么确认成功我给每一步都加了状态检查和重试逻辑失败时记录到异常队列等人工处理。四、踩坑与解法4.1 OAuth 凭证三件套混淆报销系统走 API 需要 OAuth 授权这里有三层凭证混淆了就全盘报错凭证生命周期用途误用后果code授权码几分钟一次性只能换 token直接调接口必报错access_token约 2 小时调用接口写表、传附件过期了不能自己续refresh_token约 30 天access_token 过期后换新的不能直接调接口我第一次部署时把 code 当 access_token 用调接口一直报无效凭证。后来理清了拿 code → 换 access_token 加 refresh_token → 用 access_token 办事 → access_token 过期用 refresh_token 换新的。这种凭证分层不是哪个平台发明的是所有 OAuth 系统的标准设计——短期一次性凭证限制传播范围防中间人截获中期工作凭证限制泄漏代价长期续期凭证减少用户重新授权但需要严格保护。4.2 资源 ID 傍错了飞书多维表格的 URL 里有三段 ID我从地址栏一股脑复制就翻了车https://xxx.feishu.cn/base/APP_TOKEN?tableTABLE_IDviewVIEW_IDbase/后面那段是整个表格应用的身份APP_TOKENtable后面那段是某张表的身份TABLE_IDview后面那段是视图不是表 ID。我把table...view...一起复制进去脚本报parent node not exist。教训是URL 是资源地址不是字符串——路径段代表资源层级不同层级的 ID 不能互换查询参数是属性不是资源 ID。4.3 附件 token 不通用这个坑我踩了两天。附件上传成功了但附件字段里就是看不到文件。排查后发现我用的是云空间通用上传接口拿到的 Drive token但多维表格的附件字段需要的是它自己专属上传接口拿到的附件 token。token 是认门的不是认人的。附件必须上传到目标表的 attachment context拿到的 token 才能用。企业级 SaaS 不是一个大池子是一堆带围墙的小池子——token 是为特定 context 颁发的离开 context 就无效。4.4 Agent 虚报完成这是最隐蔽的一个坑。Agent 有时候会输出一份写表计划字段映射好了、目标表选好了然后报告说已完成。但实际表里并没有新记录。我在能力契约里加了硬约束完成态的定义是真实写入成功加回读确认加失败分项汇报而不是生成了计划。一份 plan 只是中间产物不是完成态。五、效果复盘上线运行三个月后我做了次 ROI 复盘。效率提升单张发票从拍照到落表的平均时间从 4-5 分钟压到 10 秒以内含识别、校验、附件上传、写表、回读全链路。财务团队每月报销处理时间从上百小时降到十几个小时——主要是处理异常队列和复核记录的人工时间。准确率OCR 印刷体准确率 95% 以上PDF 原生抽取接近 100%。填错率从人工时代的 3% 左右降到 0.5% 以下主要来自手写体发票和模糊扫描件这些进了复核队列由人工二次确认。异常处理约 5% 的票据会进入复核队列必填字段缺失、额度超限、重复上传、置信度过低这些不会被自动写入而是标记后等人工处理。这个比例是合理的——宁可不填也不能填错。成本本地 OCR 零边际成本云端 API 调用费用主要是写表和附件上传的接口调用每月不到 50 元。相比省下的人力成本ROI 非常清晰。六、可复用经验做完这个项目我总结了几条可以平移到任何跨系统数据搬运场景的经验先钉死三件事身份谁在调 APItoken 怎么拿怎么刷新、位置写到哪个表哪个字段ID 从哪来、完成态真实写入加回读确认不是 API 返回 200 就算完。能力拆分让系统可维护识别、校验、写表、兜底四个能力各自独立可测试可替换。换 OCR 引擎不用动校验逻辑换目标系统不用动识别逻辑。规则给业务人员改必填字段、额度上限、复核策略写成配置文件业务人员自己改不用动代码。这是技术决策和业务决策的分界线。渐进式失败优于全盘报错某字段识别失败不要废掉整张票标记后继续处理其他字段。整体流程不停失败部分进复核队列。强格式用规则、弱格式才用 AI发票是强格式文档规则提取比大模型稳定、快速、便宜、可追踪。别动不动就上大模型。优雅降级PDF 优先原生抽取失败再 OCRAPI 优先无 API 再用浏览器自动化。能用更快更准的方案就用用不了再退一步。回读确认堵死虚报API 返回成功不等于真正写入。强制回读确认是防止假成功的最后一道闸门。这些经验不绑定财务场景。报销自动化只是案例真正带走的是这套从非结构化输入到结构化系统记录的自动化方法论。换成合同归档、订单录入、简历入库——链路是一样的架构是可复用的。