共享财务智能审核

过去两年，我们在一些化工、制造业行业链主的客户现场做 FDE 交付。这些企业并不缺数字化基础，也不是没有系统、没有数据。恰恰相反，它们往往有复杂的业务流程、多个存量系统、大量历史记录、层层审批链路，以及一批真正懂业务但很难把经验写成规则的专家。

第一次进场时，客户问我们的问题通常很具体：

「我们能不能做 RAG？」
「Text-to-SQL 能不能上？」
「合同审查能不能用 AI 做？」
「是不是把文档喂进去就行？」
「RAG 是不是就是训练 AI？」
「模型以后足够强了，是不是就不用继续投入了？」
「这个准确率能做到多少？」
「AI 的 ROI 怎么和领导证明？」

这些问题都很真实。但真正进入现场后，我们发现：客户一开始问的往往是技术问题，项目真正卡住的却是业务问题。

AI 部门说的是技术场景：问答、问数、RAG、Agent、工作流。
业务领导说的是业务场景：合同审查、财务分析、智能审核。
一线员工关心的则是更具体的任务：这张单据能不能过？这份材料有没有风险？这个结论能不能直接拿去处理？

如果这些语义层没有对齐，AI 项目很容易从一开始就跑偏。

所以我们在现场形成了一套工作方式：先像咨询一样，和客户一起梳理战略重点、业务流程和场景优先级；再像实施团队一样，从数据、规则、入口、权限、反馈和验收往下落。

不是一上来就搭 Agent，也不是一上来就做工作流。先要弄清楚：到底要解决什么业务问题？现在的数据能支撑到哪一步？AI 应该嵌入原流程，还是通过 API 接入现有系统，或者重新做一个 AI 原生的小产品？

这两年下来，我越来越觉得，FDE 做的不是把 AI 技术搬进企业，而是把企业的业务问题翻译成 AI 可以参与、可以交付、可以持续变好的闭环。

## 一个现场案例：共享财务智能审核

有一个共享财务职能审核项目，很典型。

客户最初的需求可以概括成一句话：我们想要一个 AI 自学习的智能审核，最好能把人工都替代。

听起来很明确，但拆开以后，每个词都需要重新定义。

审核什么？怎么叫自学习？人工到底能不能被替代？哪些单据可以自动判断？哪些必须人工复核？AI 判错以后怎么办？验收时看准确率，还是看风险有没有漏过去？

这个项目主要审核费用类单据，比如差旅费、住宿费、餐费等。餐费里就有很典型的场景：如果一顿肯德基人均 300 元，单看它是一张餐费单据可能没问题，但结合常识、制度、金额区间和业务场景，它显然需要被拦出来。

问题是，客户现场的数据并没有想象中那么完整。

系统里主要保存的是最终通过后的单据。没有退单记录，没有人工审核意见，没有修改痕迹，也没有完整附件。也就是说，我们看到的多是「最后被允许通过的结果」，而不是「为什么有些单据不该通过」的过程。

这时候，如果简单说「让 AI 从历史数据里学习审核规则」，其实是不严谨的。因为只有正样本，没有负样本，没有退单原因，也没有关键附件，AI 不可能凭空倒推出完整的不通过规则。

所以我们没有硬和技术较劲，而是调整了落地路径：制度规则先打底，通过单据做合规画像，附件抽样补齐变量，人工经验补充典型负样本，AI 负责结构化整理和候选规则生成，人工确认后进入规则库。上线以后，再通过人工复核、bad case 和反馈机制持续迭代。

这件事的本质，不是让 AI「神奇地学会审核」，而是设计一个能持续长出审核能力的业务闭环。

### 1. 企业是不是 AI-ready？

AI-ready 不是有没有模型 API，也不是有没有一个知识库平台。

更关键的是：业务流程有没有被定义清楚，关键数据有没有留痕，系统能不能接入，业务专家能不能参与确认，结果有没有人负责，错误能不能被反馈回来。

在财务审核项目里，客户不是不能做 AI，而是不适合直接跳到「全自动自学习审核」。更合理的起点，是先建立规则库、审核助手和反馈闭环。

### 2. 到底应该做什么场景？

场景不能只从技术热词里选。

RAG、Text-to-SQL、Agent 都不是场景，它们只是技术形态。真正的场景应该落到业务任务里：谁在什么流程节点，因为缺少什么信息或判断，导致效率、质量、风险或体验出了问题。

共享财务审核之所以适合做，是因为它高频、规则密集、风险可控，而且有明确的业务闭环。

### 3. 数据怎么来？没有现成数据怎么办？

现场经常不是「没有数据」，而是「数据不能直接用来解决这个问题」。

这个项目里，历史通过单据可以用来分析正常报销画像，但不能直接训练通过/不通过模型。制度文件、通用审核规则、通过单据画像、附件抽样识别、人工补充案例，合在一起才构成可用的数据输入。

所以数据不是客户扔过来一张表就结束了。FDE 要做的是把业务痕迹转成可用资产。

### 4. 业务专家的经验怎么被 AI 学会？

很多企业最有价值的知识，不在文档里，而在审核人员的判断里。

比如哪些餐费看起来异常，哪些住宿水单需要特别关注，哪些发票字段组合不合理，哪些情况属于例外。

这些经验不能只靠访谈一次性抽取。更好的方式是让专家参与候选规则确认、典型案例标注、例外情况补充和 bad case 复盘。专家经验会逐渐沉淀成规则、样例、记忆和运营动作。

### 5. 人在流程里到底是什么角色？

很多客户一开始会说「最好把人工替代」。

但现场交付里，更重要的问题是：人到底应该是审批者、协作者，还是兜底者？

在财务审核早期，人不应该被直接拿掉。AI 可以做初审、风险提示、规则命中、附件缺失提醒和处理建议；人负责确认、复核、例外判断和最终责任。随着规则库、样例库和反馈数据成熟，再逐步扩大自动化范围。

### 6. AI 怎么进入现有工作流？

AI 如果变成一个额外打开的新入口，很容易没人用。

这个项目最后选择嵌入原报销系统。AI 在原有审核流程中输出审核结论、风险点、命中规则、所需字段、附件缺失项、处理建议和解释依据。

用户不需要跳到另一个系统里「问 AI」，而是在原本处理单据的位置，直接看到 AI 给出的审核辅助。这一点很重要：AI 不是多一个工具，而是进入原来的工作现场。

### 7. 智能体怎么验收？

审核类 AI 不能只看一个准确率。

因为不同错误的代价不一样。AI 把本来能通过的单据拦下来，是误拦，影响效率和体验；但 AI 把本来不该通过的单据放过去，是漏拦，影响风险控制。

所以我们引入了类似混淆矩阵的验收方式：区分 AI 判不通过且人工确认不通过、AI 判通过且人工确认通过、AI 误拦、AI 漏拦。

对这类场景来说，验收不是问「总体上准不准」，而是先问清楚：哪一种错最不能接受。早期宁可让 AI 稍微谨慎，也不能让高风险单据轻易漏过去。

### 8. 上线以后，bad case 怎么闭环？

AI 上线不是结束，而是开始。

每一次 AI 判错、人工改判、规则冲突、字段缺失、附件识别失败，都应该进入运营闭环。它们不是零散反馈，而是规则库、样例库、记忆和数据采集机制的迭代资产。

真正有价值的产品能力，不只是 RAG 或 Agent 本身，而是能把散乱知识变成可运营知识，把 bad case 变成持续迭代资产，把专家经验沉淀成系统能力。

## 最后的感受

做 AI 项目，最容易走偏的是和技术较劲。

模型还不够聪明，RAG 还不够准，Agent 还不够自动，工作流还不够复杂。

但在客户现场，真正要先回答的是：这个 AI 有没有解决一个真实业务问题？它有没有形成业务闭环？这个闭环嵌入现有流程以后，是提升了原流程，还是制造了新的负担？

很多时候，AI 落地不是先追求一个最强模型，而是先把业务问题定义清楚，把数据来源补齐，把专家经验沉淀下来，把人机分工设计好，把验收标准说清楚，把 bad case 运营起来。

AI 不是做个 Demo。
AI 落地，是把一个模糊的业务现场，变成一个可验证、可迭代、可托付的系统。