高校财务智能审核系统

项目简介

面向高校财务审核场景,把财务门户里的待审批单据、签章与附件证据、规则审核和人工处理集中到一个工作台。系统通过浏览器自动化读取单据,用视觉语言模型直接从附件图片里提取财务事实,再结合版本化的规则生成审核建议,交给审核人员检查。

智能建议、财务人员的结论、学校平台的状态是分开记录的。智能建议只作参考,不会自动触发学校的审批。

审核工作台:当前批次、智能审核进度、待处理单据和智能建议

截图中的学校标识、单据号、部门、金额等信息已做模糊处理。

财务审核的重复劳动很重:一张单据要翻主附件、核对金额和项目编号、看签章是否齐全,再对照一堆规则。真正耗时的不是判断,而是找证据。所以这个系统想做的事是:

待审批单据采集:读取财务门户的待审批流水号,分页采集并去重,支持每日定时建批和手动建批。
主附件与签章解析:按文件名和正文识别主发放表,优先从主附件里提取金额、项目编号、部门和人员明细,再按审批节点截取签名区做签章验真。整个过程由视觉语言模型直接读图,没有单独的 OCR 步骤。
初审与反向复核:按项目编号前缀选取对应的规则章节,结合财务事实给出“通过 / 驳回 / 需复核”。初审通过之后,再独立做一次反向复核,两次都通过才会给出“通过”。
审核工作台:集中展示当前批次、智能审核进度、待处理单据、智能建议、财务结论和平台状态。点开单据能看到审核说明、签章验真、提取字段和附件影像。
审核规则:规则按章节分开维护,每次保存都会生成新的正式版本。
审核学习:从人工纠正的样本里总结经验提示词,新批次冻结使用。
批次历史:按状态和时间筛选,点开可看批次明细。

点开一张单据,可以看到智能审核建议、初审说明、引用的规则和经验,以及初审到复核的过程:

单据详情:智能审核建议

审核规则按章节分开维护,每次保存都会生成新的正式版本:

审核规则

批次历史可以按状态和时间筛选,点开查看批次明细:

批次历史

审核学习由人工纠正的样本总结出经验提示词,新批次冻结使用:

审核学习:经验提示词

让模型直接读图,不先做 OCR。 附件里有表格、印章和手写签名,先 OCR 再理解会在每一步丢信息。直接把图片交给视觉语言模型,链路更短,也更容易定位“它到底看到了什么”。代价是图片很占上下文,所以发送前会离线统计 token,图片宽度也设了上限。

规则和经验按批次冻结。 每个批次开始时就固定一份规则正文和经验快照,审核途中改规则不会影响正在跑的批次。好处是同一批单据的口径一致,出了问题也能准确回到“当时用的是哪一版”。

只发送用得上的规则。 规则分成多个章节,按项目编号前缀只带对应章节和通用规则进模型,既省上下文,也减少无关规则干扰判断。

宁可多问一次人,也不放过。 附件不全时,模型给出的“通过”会被改成“需复核”;初审通过后还要过一遍反向复核。这套设计偏保守,是有意的:对审核场景来说,漏掉一个问题的代价高于多一次人工确认。

浏览器是稀缺资源,要排队。 同一个学校账号同一时刻只能有一条浏览器会话在操作,所以采集和后续的单张通过 / 驳回进入同一个持久队列:当前这张单据收尾完,再依次执行已受理的通过或驳回,最后才开始下一张。模型审核不占用浏览器,可以独立继续。排队本身不会暂停批次,也不消耗重试次数。

真正点下“确定”,由开关控制。 通过 / 驳回的最后一步需要点学校弹窗里的确定。这一步做好了,但默认关闭,按部署需要才打开。代码能力和目标环境的验收是分开核对的,本地跑通不等于学校审批已经完成。

审核效果不靠感觉调,而是一个闭环:

规则里没写明、导致和财务意见对不上的情况,会整理成选择题请财务处确认,答复之后再改规则,而不是靠猜。

目前验证过的优化有两类:一是把专家咨询费这类有明确算法的口径交给程序先算出上限,再作为事实交给模型;二是超出上下文时按步骤压缩图片,仍然放不下就转人工,没有超出的请求保持原样。这些改动都先在独立分支上验证,通过之后才会合入。

主流程已经能完整跑通:采集、读图提取、初审与复核、人工确认、单张通过 / 驳回、规则与经验的版本管理。真实财务门户依赖校园网络、有效的学校账号和模型服务;审核效果优化仍在分支上验证。

React、TypeScript 做前端工作台,FastAPI 加 SQLAlchemy 做业务后端,Playwright 做浏览器自动化,视觉语言模型做附件理解,PostgreSQL 存储,Celery 加 Redis 负责定时与异步任务,Docker Compose 与 Nginx 部署。