事情的起因很简单，我们公司财务同事有一段时间每天都在手动录入发票数据。

说实话，我第一次看到她的工作状态时有点震惊——桌上摞着一叠发票，她对着屏幕一张一张地敲：发票代码、发票号码、开票日期、购买方、销售方、金额……每一张都要核对好几遍，生怕录错一个数字。一个月下来，光是这个环节就要花掉她将近两天的时间。更麻烦的是，发票类型还不统一，增值税专票、普票、电子发票混在一起，格式各有差异，手动处理出错率不低，后续对账又要再花时间纠错。

我当时就想，这件事应该可以用 AI 来做。OCR 识别发票信息不是什么新鲜技术，难点在于怎么把识别结果结构化，再自动同步到财务用的表格里，形成一个完整的闭环流程，而不是让人在中间再做一次搬运工。

于是我开始研究怎么搭这个东西。

最开始的思路是自己写脚本，调 OCR 接口，解析返回结果，再写入飞书多维表格。逻辑上不复杂，但真正动手之后发现细节很多：不同发票的字段位置不一样，解析规则要分类处理；飞书的 API 鉴权和写入逻辑也要单独维护；后续如果财务同事想调整字段映射，还得找我改代码重新部署。这条路走下去，维护成本会越来越高，而且整个流程对非技术同事来说完全是黑盒。

后来顺着 AI Agent 的热点，我去研究了一圈可视化编排平台，Dify 和 Coze 都试了一下。体验确实比纯写代码省力不少，节点拖拽、流程可视化，改逻辑也方便。但我们团队对数据安全有要求，发票里涉及公司的采购信息、供应商信息，不太适合走公有云服务，必须本地化部署。这两个平台在私有化部署这块对我们的场景支持得不够顺畅，所以暂时搁置了。

再后来，我在一个开源社区的讨论帖里看到有人提到一个 RAG 框架项目，评论区讨论度挺高，说它开源、支持私有化部署、有可视化工作流，还有模板市场可以直接复用。我点进去看了一下，项目叫 FastGPT，Apache 2.0 协议，底层基于向量检索做知识库召回，工作流是节点化编排的方式，支持接入 ChatGPT、Claude、DeepSeek 等主流模型，也有标准 API 可以对接飞书、企微这类协作工具。

我当时的第一反应是：这个东西正好能解决我的问题。

部署起来没花太多时间，本地跑起来之后我直接去模板市场找了发票识别相关的模板，稍微改了一下字段映射和飞书表格的写入配置，一个基础版本就跑通了。整个流程大概是这样的：财务同事上传发票图片或 PDF，系统通过 OCR 识别出发票代码、号码、日期、购买方、销售方、商品名称、金额等关键字段，识别结果自动整理后写入飞书多维表格，不需要人工中转。

搭积木的感觉确实比我预期的要好。每个节点的输入输出很清晰，条件分支改起来也方便，比如针对不同发票类型走不同的解析逻辑，在画布上拉一条线就能实现，不用改底层代码。财务同事第一次看到这个流程图的时候说"我能看懂"，这句话对我来说比什么都重要——她能看懂，就意味着她以后提需求的时候能说清楚哪个环节要改，而不是只能说"感觉哪里不对"。

当然也有不顺的地方，说出来给大家参考。节点一多，画布上的连线就开始乱，尤其是有循环逻辑的时候，线条交叉叠在一起，看着有点头疼。复杂的条件嵌套也有一定学习门槛，我自己摸索了一两天才搞清楚某些节点的参数传递方式。这些不算致命问题，但如果你第一次上手，最好预留一些时间踩坑。

说回这个工作流真正解决了什么。最直接的变化是迭代速度快了很多。以前改一个逻辑要动代码、重新部署、测试，现在在画布上调一下节点配置，保存就生效，财务同事反馈"这个字段不对"，我五分钟内就能改完。另一个变化是团队协作顺畅了——非开发同事能看懂流程图，提需求的时候会说"第二个节点的输出能不能加一列备注"，而不是"你帮我改一下那个功能"。私有化部署这点也让整个项目推进顺利很多，数据不出内网，合规层面没有阻力。

后来我想了想，可视化工作流这类工具的价值，其实不在于取代手写代码，而在于它适合快速迭代、业务逻辑多变的场景。如果你的流程相对固定、性能要求极高，手写代码可能更合适；但如果你需要频繁调整逻辑、需要让非技术同事也能参与进来，可视化编排的优势就很明显。我觉得未来这个方向会往更轻量的自动化和领域专用模板走，比如财务、HR、客服这些场景，都有很强的标准化空间。

任何工具都有它的边界，选型的时候还是要先想清楚自己的场景。

最后想问问大家，你们在搭 RAG 或者 Agent 的时候遇到过哪些比较棘手的问题？比如知识库召回率不稳定、多轮对话上下文丢失、模型幻觉怎么压制……这些我自己也还在摸索，欢迎评论区聊聊，互相参考一下。