上个月月底财务同事又抱着厚厚一摞发票来找我表情很微妙我一看就知道什么意思——“哥帮忙录一下呗”。说实话那次我硬着头皮录了将近一个小时手指在键盘上敲发票号码、金额、税号敲到最后眼睛都花了中间还输错了好几个数字被同事核对出来又得改。当时我就想这活儿难道不能交给AI吗我平时在用Agent做一些内部的小工具对这玩意儿还算熟悉。它的工作流引擎后来更新了不少实用功能比如可以直接在工作流里接收用户上传的文件还能一次性处理多个文件不用一个一个点。正好拿来做发票识别。简单说一下我搭的这个工作流能干嘛。你把一堆发票图片或者PDF丢进去它能自动识别出每张发票上的关键信息——发票代码、发票号码、开票日期、买卖双方、商品名称、金额这些然后把这些数据整整齐齐地写到飞书的多维表格里。财务同事只要打开表格所有发票数据已经在那儿了按时间排好金额对得上直接拿去对账或者归档就行。这个工作流对财务效率的提升是肉眼可见的。以前手工录入一张发票从拿起发票看清楚每个格子到敲进Excel或者财务系统快一点也得两分钟。熟练的会计一个小时能录三十张左右而且中间不能分心一断档就容易串行。现在呢我试过一次性上传三十张发票从上传完成到最后表格里多出三十行数据总共不到三分钟。这还只是跑在我自己部署的FastGPT上网络条件一般。也就是说原来一个人干一下午的活儿现在喝杯咖啡的时间就干完了。更关键的是准确率。人是会疲劳会犯错的尤其是连续输入数字的时候把发票号码里的0打成O、金额少打一位这种事太常见了。但机器识别只要图片清晰基本不会错。我用飞书的增值税发票识别接口测了几十张电子发票和扫描件几乎百分百正确手机拍的照片只要光线正常、角度不太歪准确率也很高。偶尔有一两张拍糊了的工作流会把它挑出来单独标记手动补录一下就行比全量手工录入省了不知道多少力气。从技术上讲这个工作流有几个挺有意思的特点我觉得值得提一嘴。第一个是文件处理和批量能力。FastGPT的工作流现在可以直接接收用户上传的文件而且还支持批量处理——你一次性拖进去一堆发票它会自动遍历每一张逐个做识别和录入不用你一张一张地去点触发。这种批量处理对报销场景太友好了月底一堆发票甩过来一次性搞定。第二个是对外接能力的支持。工作流里有HTTP请求节点可以很方便地调用第三方API。像我这次就是用它去调飞书的发票识别接口——把文件传过去对方给我返回结构化的JSON数据。不需要自己写代码处理鉴权、签名什么的节点里填好URL、配好参数就行。同样最后写回飞书多维表格也是通过HTTP节点调用飞书的开放接口。整个过程相当于把FastGPT当成了一个编排引擎让它去指挥别的服务干活。第三个是AI节点的灵活运用。OCR返回的数据虽然是结构化的但字段名往往是英文的比如total_amount、seller_name而飞书表格里的列名是中文的“金额合计”“销售方”。我中间加了一个AI对话节点用一段很简单的提示词告诉它把字段映射好、日期格式统一成YYYY-MM-DD。这一步不用写正则也不用写映射表自然语言描述一下就行改起来也方便。这套方案还有一个隐形的好处就是数据安全。还可以私有化部署所有发票文件和你调用的OCR服务之间的传输是你自己控制的最终落地的飞书表格也是你们公司的内部空间。不像有些线上SaaS工具发票这种敏感数据要传到人家的服务器上心里总归有点不踏实。当然这个工作流也不是完美的。比如说它目前还不能自动做发票查重如果同一张发票被人上传两次表格里就会出现两条记录。另外飞书的OCR接口对图片质量有一定要求太糊或者光线太暗的可能会识别失败。不过这些问题都可以在后面慢慢优化比如在写表格之前加一个查重的条件判断或者对识别失败的文件单独建一个待处理列表。总的来说这件事给我的感受是像发票录入这种重复、枯燥、但又必须精确的活儿特别适合用类似的工作流来替代人工。你不用写复杂的代码也不用懂什么深度学习把现成的节点拖一拖、连一连再把几个外部API串起来一个实用的自动化工具就出来了。如果你也在被月底的发票报销折磨或者你们公司的财务同事经常抱着一摞纸来找你不妨试试用FastGPT里的Agent功能搭一个类似的工作流。模板市场里有现成的发票识别模板改改飞书的配置参数几分钟就能跑起来。省下来的时间干点啥不好。