从“表哥表姐”到智能执行：FDE用AI重构央国企财务流程效率

访谈资料整理：依据 Datawhale《FDE案例100》所收录访谈。案例叙述与成果均归属于原访谈，本站未进行独立项目审计。

原案例封面

为什么这个案例值得看？

央国企科研型组织的财务工作需要处理出差记录、部门和项目归属、会计科目、审批意见与系统录入。项目让 AI 承担判断和归类、RPA 承担页面操作，并设置监督和风险机制，在一家央企科研机构落地 10 个 AI 相关场景，将部分原需半个月至一个月的工作压缩到约 1—2 天。

这个案例的价值不只在于采用了某种模型，而在于把数据、规则、系统和人工责任连接成可执行的业务链路。落地过程围绕问题识别、方案选择、交付路径、业务结果和关键难点展开。

一、企业与业务场景

FDE做的是一个央企科研机构的财务流程AI应用。

这个场景其实特别典型。

央国企的财务工作有大量规则和流程，很多业务都超过了“把一张发票录进去就结束”的范围。

比如一个员工出差回来要报销一张发票。

过去，他可能要先提交报销，然后财务人员去判断这笔费用到底属于什么性质，是差旅费、招待费还是其他费用；如果涉及项目，还要判断它应该记在哪个项目下面；同时还要去找这个人的出差申请、审批记录、所属部门等信息。

这些信息其实分散在不同的业务流程里。

真正耗时间的，是填表之前那段判断过程。

而且央国企的财务科目本身就比较复杂，规则多、层级深。

再加上付款对象除了员工，也可能是供应商，或者涉及保证金等各种对外的财务流转。

所以当业务量越来越大以后，财务人员大量时间都花在重复判断和录入上。

对科研型央企来说，这个问题又多了一层。

项目团队服务的很多企业里有大量科研人员，甚至是博士，他们真正应该投入的是科研工作，但大量时间被消耗在一个报销流程里。

所以当时，FDE看这个问题，看到的是一个很明显的价值错配：让高价值的人去做低价值、重复性的流程工作，本身就是一种浪费。

这也是FDE作为FDE比较关注的地方。

需要先去看：这个业务到底哪里最痛？

哪些环节是真正值得被改变的？

想清楚之后，再回头匹配对应的能力去解决它。

二、原有流程与核心问题

过去这套方式其实完全可以运行。

财务人员有自己的专业经验，也有成熟的业务规则。

他们知道什么费用应该记在哪个科目，知道什么业务需要关联哪些审批信息，也知道集团系统应该怎么填写。

在业务规模和复杂度还没有那么高的时候，它是一套可靠的办法。

问题在于，很多事情必须依赖人工。

前面要有人判断。

比如一张发票过来，财务人员需要结合员工的出差申请、部门、项目等信息，判断这笔钱到底应该怎么记。

后面还要有人执行。

判断完成之后，财务人员还需要打开集团网站，创建单据，一行一行地填写信息，再提交。

所以整个过程实际上有两个明显的时间消耗：一个是判断时间，一个是执行时间。

过去靠专业人员来完成没有问题，但随着业务量增长，这种方式很难继续线性扩张。

业务量增加一倍，就增加一倍的财务人员，这条路很难走得通。

所以项目团队真正要解决的，是把财务人员从大量重复性的判断和操作里解放出来，让机器去承担那些更加适合机器完成的事情。

三、AI 解决方案与交付路径

FDE做这类项目，有一个很重要的习惯：直接进业务现场陪跑。

因为不能期待业务人员把自己的整个业务逻辑完整地说明。

很多时候，他自己做了十几年，很多判断已经成为了下意识动作。

所以项目团队会跟着业务人员一起做，去看他每天到底怎么处理一笔业务，再把整个流程一点一点拆开。

这个项目也是这么做的。

第一步，先把业务逻辑真正梳理出来。

以员工报销为例，员工不需要再关心后面的复杂流程，他只需要在钉钉里告诉机器人“业务人员要报销”，然后把发票发过去。

从这里开始，后面的流程就交给AI。

AI首先识别发票，然后去关联员工原有的业务信息，比如这个人之前有没有出差申请、审批意见是什么、属于哪个部门、对应哪个项目。

这些信息被拉取出来之后，AI再结合财务规则进行判断：这笔费用到底应该归到什么科目、哪个项目、按照什么规则进行处理。

这里其实发生了一个很重要的变化：以前是人自己去系统里找信息、判断信息，现在变成AI主动把信息组织起来，再辅助完成判断。

第二步，让AI负责“判断”，监督机制负责兜底。

财务属于严肃业务，AI判断得再好，也不能简单理解成“AI说什么就是什么”。

所以项目团队在里面设计了监督机制，可以把它理解成几个AI角色一起工作：一个负责执行判断，一个负责监督，一个负责发现风险。

对于已经比较确定的业务，就直接往后走；如果几个模型判断之后仍然存在不确定性，就进入风险监控，由相关人员重点关注。

这样一来，人的角色也发生了变化。

过去是人处理所有事情，机器没有参与；现在变成AI处理大部分确定性工作，人只处理真正需要关注的风险和异常。

第三步，让RPA负责真正的“手”。

AI解决了“应该怎么做”，但还有一个问题：谁去把这个动作真正做完？

所以项目团队又把RPA引进来了。

AI判断完成以后，RPA机器人就开始执行。

它可以自动打开浏览器，进入集团对应的网站，创建单据，然后把相关信息填写进去并提交。

所以这个方案实际上是把整个流程拆成了几个部分：业务信息获取 → AI判断 → AI监督→ 风险识别 → RPA执行。

这也是FDE与单纯技术方案的最大区别：项目团队想的是怎么把AI真正嵌进原来的业务流程里面。

第四步，先做一个“破冰项目”，再逐步扩大范围。

这也是FDE在项目落地过程中非常看重的一点。

FDE一般会把第一个项目叫做“破冰项目”。

为什么？

因为企业第一次接触AI的时候，往往需要先看到真实价值，才愿意投入大量资源，尤其是央国企，后面还涉及数据安全、基础设施、预算等问题。

所以需要先找离业务最近、最痛、最容易产生ROI的那个场景。

就像摘桃子一样：先摘离自己最近、最甜的那个桃子。

让业务人员真正用一次，发现原来AI真的可以帮FDE节省大量时间。

当业务团队自己尝到红利以后，他们才会愿意和项目团队站在一起，继续做更大的事情。

四、项目结果与业务价值

最直观的变化，就是时间。

过去处理这些财务场景，工作人员可能需要半个月，甚至一个月。

现在通过AI加RPA，把一个完整流程跑下来，大概一天、两天就可以完成。

而且这覆盖了不止一个报销场景。

在这个项目里，项目团队最终落地了10个AI相关应用场景，把财务不同环节都逐步覆盖了进去。

但项目实践表明，这个项目真正有价值的地方，在于它改变了人的工作方式。

过去科研人员可能需要参与很多与科研本身无关的流程。

现在，他只需要在钉钉里把发票给机器人，后面的信息关联、规则判断、系统录入等工作都被隐藏到了后台。

人的操作被压缩到了非常短的一步。

而对于企业来说，AI带来的价值也远超节省几个人工。

它实际上是在把一套依赖大量人工经验和重复操作的流程，逐步变成一个可以持续运行的业务能力。

五、关键落地难点

这个项目的一项重要结论是：AI项目最难的地方，很多时候在技术之外。

在AI时代，项目经验表明，一个项目如果单纯从技术上已经能够落地，其实已经成功了80%。

真正容易让项目“死掉”的，是业务、人和组织。

第一个挑战，是业务部门的接受度和推进节奏。

AI程序本身不会产生价值，真正产生价值的是业务部门。

比如AI帮他们节省了时间，但最后真正享受到这个效率提升的，是业务人员，所以项目团队必须想办法让业务部门和项目团队站在一起。

FDE特别反对一种方式：让AI项目组自己坐在那里设计一个东西，然后让业务部门过来使用。

业务人员本来每天已经很忙了，项目团队突然给他增加一个新系统、新流程，他第一反应很可能是“业务人员为什么又给业务人员增加了一个负担？”所以项目团队的方式是业务陪跑：FDE可以跟着业务人员一起做几天，看他真实的工作流程，把业务逻辑主动梳理出来，让业务人员不必自己整理一份特别完整的需求文档交给项目团队。

同样，第一次合作也不能大刀阔斧地改流程。

如果FDE跟业务部门说“业务人员们原来的流程全部不要了，企业重新设计一套AI流程”，这个项目大概率会遇到阻力，因为业务人员已经有自己的工作习惯，原来的流程之所以存在，也有它自己的原因。

所以更适合从一个很小、很痛的场景开始，先把一个点做好，让业务人员看到真实ROI。

当他发现这个东西真的能帮自己省时间，他就会开始主动跟项目团队讨论“这个地方是不是也可以做”。

这时候，AI项目就从“项目团队要求业务人员使用”变成了“业务人员希望业务人员帮业务人员继续做”。

第二个挑战，是数据安全和基础设施。

央国企尤其是科研机构，对数据安全要求非常高。

财务数据很多都属于敏感数据，不可能简单地丢到公共模型里处理，所以项目团队必须从底层基础设施开始解决问题，包括算力、模型部署、数据环境等。

FDE之前就帮企业采购过大型AI算力一体机，投入达到两百多万元的量级，让企业具备运行大模型的基础环境。

对于敏感财务数据，还需要采用数据不出域的私有化部署方式。

但这里又出现了一个很现实的问题：如果项目团队一开始就告诉甲方“企业先花两三百万元买一台机器”，对方很可能会问“为什么？

业务人员还没看到AI能给业务人员带来什么价值”。

所以这又回到了前面的逻辑：先用小场景证明价值，再推动基础设施建设，不能反过来。

第三个挑战，是不同场景不能强行使用同一个模型。

FDE在做方案的时候，也不会执着于某一家模型。

财务场景需要严谨，科研场景可能需要专业计算能力，有些内容生成场景又更需要开放性。

所以FDE的原则是根据场景选能力：有些场景可能使用阿里云的模型，有些使用其他厂商的模型，还有一些央国企场景则采用本地私有化部署。

FDE把这种方式理解成“因材施教”：先确定业务需要什么，再去组合背后的能力。

六、FDE 交付方法与企业启示

做了这些项目以后，项目实践表明，FDE真正的价值，在于能不能把技术、业务和组织真正连起来，这比“懂多少AI技术”更重要。

项目经验可以归纳为：需要特别强调几个方面。

第一，先进入业务，再进入技术。

FDE最重要的动作之一，就是业务陪跑。

别坐在会议室里等业务人员说明需求，真正需要做的是跟着他工作，看他到底怎么做。

很多业务规则，业务人员甚至自己都很难一次性讲清楚，但项目团队跟着他做一遍，就能发现大量隐藏在流程里的判断和经验。

第二，先找“最近、最甜”的桃子。

别一开始就做一个宏大的AI转型项目，先找一个小场景。

这个场景最好同时满足三个条件：业务真的痛、实现相对可控、ROI能够快速被看见。

先把第一个项目做成“破冰项目”，让业务部门拿到结果、得到表扬，甚至成为集团内部的标杆。

有了这个标杆，后面的资源、预算和组织支持都会更容易获得。

第三，要把业务方真正绑到结果上。

AI项目要跳出“技术团队自己的项目”这个定位。

如果最后只是AI团队说“企业把系统做出来了”，其实没有意义。

真正应该关注的是：业务有没有节省时间？

人效有没有提高？

业务结果有没有变化？

所以FDE要想办法让业务团队和项目团队共同承担结果，甚至在条件允许的时候，把AI改造和业务部门的KPI、OKR结合起来，让业务部门自己也有动力把项目推下去。

第四，FDE需要从“技术实现”跳到“业务结果”。

FDE以前也是架构师出身，但后来越来越觉得，AI时代不能一直停留在“这个技术怎么实现”。

底层很多实现工作，未来很可能本身就会被AI完成。

真正需要人来做的是：FDE为什么做这件事？

这个问题到底怎么定义？

它对企业有什么价值？

怎么设计一个能够支撑企业未来3到5年的架构？

怎么把项目真正推动落地？

所以项目经验表明，一个成熟的FDE至少要同时具备沟通能力、架构思维和项目管理思维。

第五，要主动“破圈”和“摸高”。

FDE团队很看重两个词：破圈、摸高。

破圈，是走出去跟企业一把手、业务负责人、不同产业的人沟通，他们真正关心的是：营收能不能提高？

成本能不能降低？

组织管理能不能更透明？

业务控制力能不能提升？

摸高，是主动去接触比自己认知更高一点的人，理解他们怎么看问题。

企业的认知发生变化以后，项目团队解决问题的方式也会发生变化。

最后，需要说明的是，FDE本身是一个“中间态”。

FDE角色可以看作一个“中间态”：一开始，一个人可能什么都做，先靠解决不同客户的问题活下来；慢慢地，可以看到自己在哪个行业、哪个场景真正有优势，于是开始聚焦；当项目团队能够独立理解业务、设计架构、推动项目落地，项目团队就成为了这个领域的FDE。

但如果一直停留在“业务人员亲自交付每一个项目”，个人带宽是有限的。

下一步就应该把过去积累的交付经验、业务方法和SOP沉淀下来，让更多人可以按照这套方法交付；再往后，把反复出现的共性问题提炼成标准产品。

从个人能力，到团队能力，再到可复制的产品能力，这才是FDE能力真正放大的过程。

所以如果让FDE重新定义这次财务案例，它其实超过了一个“AI+财务”项目的范畴，更像是一次完整的FDE实践：先进入业务现场，找到真实痛点；再拆解业务流程，把AI放到真正需要判断的位置；让RPA去执行重复动作；用监督机制控制风险；最后通过一个小场景证明价值，再逐步扩大AI在企业里的应用范围。

这也是这一案例中的FDE角色：真正对一个业务问题负责，直到技术变成业务结果。

七、可复用的交付资产

同类项目若要复制这条路径，可以优先沉淀以下交付物：

• 场景访谈记录与 As-Is／To-Be 流程图
• 业务对象、关键字段、角色责任和异常分支清单
• 知识地图、文档清洗规则、切片规范和高频问题测试集
• Agent 工作流定义、工具调用清单、提示词版本和任务评测集
• 系统集成图、字段映射、权限配置、失败重试与回写日志
• 覆盖普通、复杂和异常任务的验收样本与业务指标口径
• 人工审核、失败回退、上线巡检和持续迭代清单

来源与作者

Datawhale《FDE案例100》，受访者：毛卫俊（杭州舳舻科技有限公司CEO）；PDF 第 88-96 页，书内页码 87-95。本文为访谈资料的第三人称整理，不是本站新采访。