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

我做的是一个央企科研机构的财务流程AI应用。 这个场景其实特别典型。央国企的财务工作有大量规则和流程，很多业务都超过了“把 一张发票录进去就结束”的范围。 比如一个员工出差回来要报销一张发票。过去，他可能要先提交报销，然后财务人员去 判断这笔费用到底属于什么性质，是差旅费、招待费还是其他费用；如果涉及项目，还 要判断它应该记在哪个项目下面；同时还要去找这个人的出差申请、审批记录、所属部 门等信息。 这些信息其实分散在不同的业务流程里。真正耗时间的，是填表之前那段判断过程。 而且央国企的财务科目本身就比较复杂，规则多、层级深。再加上付款对象除了员工， 也可能是供应商，或者涉及保证金等各种对外的财务流转。所以当业务量越来越大以 后，财务人员大量时间都花在重复判断和录入上。 对科研型央企来说，这个问题又多了一层。我们服务的很多企业里有大量科研人员，甚 至是博士，他们真正应该投入的是科研工作，但大量时间被消耗在一个报销流程里。 让高价值的人去做低价值、 所以我当时看这个问题，看到的是一个很明显的价值错配： 重复性的流程工作，本身就是一种浪费。 这个业务到底哪里最痛？哪些环节是 这也是我作为FDE比较关注的地方。我会先去看： 真正值得被改变的？ 想清楚之后，再回头匹配对应的能力去解决它。

过去这套方式其实完全可以运行。 财务人员有自己的专业经验，也有成熟的业务规则。他们知道什么费用应该记在哪个科 目，知道什么业务需要关联哪些审批信息，也知道集团系统应该怎么填写。在业务规模 和复杂度还没有那么高的时候，它是一套可靠的办法。 问题在于，很多事情必须依赖人工。 前面要有人判断。比如一张发票过来，财务人员需要结合员工的出差申请、部门、项目 等信息，判断这笔钱到底应该怎么记。 后面还要有人执行。判断完成之后，财务人员还需要打开集团网站，创建单据，一行一 行地填写信息，再提交。 一个是判断时间，一个是执行时间。 所以整个过程实际上有两个明显的时间消耗： 过去靠专业人员来完成没有问题，但随着业务量增长，这种方式很难继续线性扩张。业 务量增加一倍，就增加一倍的财务人员，这条路很难走得通。 所以我们真正要解决的，是把财务人员从大量重复性的判断和操作里解放出来，让机器 去承担那些更加适合机器完成的事情。

直接进业务现场陪跑。 我做这类项目，有一个很重要的习惯： 因为你不能期待业务人员把自己的整个业务逻辑完整地告诉你。很多时候，他自己做了 十几年，很多判断已经成为了下意识动作。所以我们会跟着业务人员一起做，去看他每 天到底怎么处理一笔业务，再把整个流程一点一点拆开。这个项目也是这么做的。 第一步，先把业务逻辑真正梳理出来。 以员工报销为例，员工不需要再关心后面的复杂流程，他只需要在钉钉里告诉机器人“ 我要报销”，然后把发票发过去。从这里开始，后面的流程就交给AI。 AI首先识别发票，然后去关联员工原有的业务信息，比如这个人之前有没有出差申请、 审批意见是什么、属于哪个部门、对应哪个项目。这些信息被拉取出来之后，AI再结合 财务规则进行判断：这笔费用到底应该归到什么科目、哪个项目、按照什么规则进行处 理。 这里其实发生了一个很重要的变化：以前是人自己去系统里找信息、判断信息，现在变 成AI主动把信息组织起来，再辅助完成判断。 第二步，让AI负责“判断”，监督机制负责兜底。 财务属于严肃业务，AI判断得再好，也不能简单理解成“AI说什么就是什么”。所以我们 在里面设计了监督机制，可以把它理解成几个AI角色一起工作：一个负责执行判断，一 个负责监督，一个负责发现风险。 对于已经比较确定的业务，就直接往后走；如果几个模型判断之后仍然存在不确定性， 就进入风险监控，由相关人员重点关注。 这样一来，人的角色也发生了变化。过去是人处理所有事情，机器没有参与；现在变成 AI处理大部分确定性工作，人只处理真正需要关注的风险和异常。 第三步，让RPA负责真正的“手”。 AI解决了“应该怎么做”，但还有一个问题：谁去把这个动作真正做完？ 所以我们又把 RPA引进来了。 AI判断完成以后，RPA机器人就开始执行。它可以自动打开浏览器，进入集团对应的网 站，创建单据，然后把相关信息填写进去并提交。 业务信息获取 → AI判断 → AI监督 所以这个方案实际上是把整个流程拆成了几个部分： → 风险识别 → RPA执行。 这也是我理解的FDE和单纯做技术方案最大的区别：我们想的是怎么把AI真正嵌进原来 的业务流程里面。 第四步，先做一个“破冰项目”，再逐步扩大范围。 这也是我在项目落地过程中非常看重的一点。我一般会把第一个项目叫做“破冰项 目”。 为什么？因为企业第一次接触AI的时候，往往需要先看到真实价值，才愿意投入大量资 源，尤其是央国企，后面还涉及数据安全、基础设施、预算等问题。 所以我会先找离业务最近、最痛、最容易产生ROI的那个场景。就像摘桃子一样：先摘 离自己最近、最甜的那个桃子。 让业务人员真正用一次，发现原来AI真的可以帮我节省大量时间。当业务团队自己尝到 红利以后，他们才会愿意和你站在一起，继续做更大的事情。

最直观的变化，就是时间。 过去处理这些财务场景，工作人员可能需要半个月，甚至一个月。现在通过AI加RPA， 把一个完整流程跑下来，大概一天、两天就可以完成。 而且这覆盖了不止一个报销场景。在这个项目里，我们最终落地了10个AI相关应用场 景，把财务不同环节都逐步覆盖了进去。 但我觉得，这个项目真正有价值的地方，在于它改变了人的工作方式。 过去科研人员可能需要参与很多与科研本身无关的流程。现在，他只需要在钉钉里把发 票给机器人，后面的信息关联、规则判断、系统录入等工作都被隐藏到了后台。人的操 作被压缩到了非常短的一步。 而对于企业来说，AI带来的价值也远超节省几个人工。它实际上是在把一套依赖大量人 工经验和重复操作的流程，逐步变成一个可以持续运行的业务能力。

AI项目最难的地方，很多时候在技术之外。 这个项目让我比较深的一点感受是： 在AI时代，我甚至认为，一个项目如果单纯从技术上已经能够落地，其实已经成功了 80%。真正容易让项目“死掉”的，是业务、人和组织。 第一个挑战，是业务部门的接受度和推进节奏。 AI程序本身不会产生价值，真正产生价值的是业务部门。比如AI帮他们节省了时间，但 最后真正享受到这个效率提升的，是业务人员，所以我们必须想办法让业务部门和我们 站在一起。 我特别反对一种方式：让AI项目组自己坐在那里设计一个东西，然后让业务部门过来使 用。业务人员本来每天已经很忙了，你突然给他增加一个新系统、新流程，他第一反应 很可能是“你为什么又给我增加了一个负担？”所以我们的方式是业务陪跑：我会跟着 业务人员一起做几天，看他真实的工作流程，把业务逻辑主动梳理出来，让业务人员不 必自己整理一份特别完整的需求文档交给我们。 同样，第一次合作也不能大刀阔斧地改流程。如果我跟业务部门说“你们原来的流程全 部不要了，我们重新设计一套AI流程”，这个项目大概率会遇到阻力，因为业务人员已 经有自己的工作习惯，原来的流程之所以存在，也有它自己的原因。 所以我更愿意从一个很小、很痛的场景开始，先把一个点做好，让业务人员看到真实 ROI。当他发现这个东西真的能帮自己省时间，他就会开始主动跟你讨论“这个地方是不 是也可以做”。这时候，AI项目就从“你要让我用”变成了“我希望你帮我继续做”。 第二个挑战，是数据安全和基础设施。 央国企尤其是科研机构，对数据安全要求非常高。财务数据很多都属于敏感数据，不可 能简单地丢到公共模型里处理，所以我们必须从底层基础设施开始解决问题，包括算 力、模型部署、数据环境等。 我之前就帮企业采购过大型AI算力一体机，投入达到两百多万元的量级，让企业具备运 行大模型的基础环境。对于敏感财务数据，还需要采用数据不出域的私有化部署方式。 但这里又出现了一个很现实的问题：如果你一开始就告诉甲方“我们先花两三百万元买 一台机器”，对方很可能会问“为什么？我还没看到AI能给我带来什么价值”。所以这又 回到了前面的逻辑：先用小场景证明价值，再推动基础设施建设，不能反过来。 第三个挑战，是不同场景不能强行使用同一个模型。 我在做方案的时候，也不会执着于某一家模型。财务场景需要严谨，科研场景可能需要 专业计算能力，有些内容生成场景又更需要开放性。所以我的原则是根据场景选能力： 有些场景可能使用阿里云的模型，有些使用其他厂商的模型，还有一些央国企场景则采 用本地私有化部署。 我把这种方式理解成“因材施教”：先确定业务需要什么，再去组合背后的能力。

做了这些项目以后，我越来越觉得，FDE真正的价值，在于能不能把技术、业务和组织 真正连起来，这比“懂多少AI技术”更重要。如果让我总结，我会特别强调几个方面。 第一，先进入业务，再进入技术。 FDE最重要的动作之一，就是业务陪跑。别坐在会议室里等业务人员告诉你需求，真正 需要做的是跟着他工作，看他到底怎么做。很多业务规则，业务人员甚至自己都很难一 次性讲清楚，但你跟着他做一遍，就能发现大量隐藏在流程里的判断和经验。 第二，先找“最近、最甜”的桃子。 别一开始就做一个宏大的AI转型项目，先找一个小场景。这个场景最好同时满足三个条 业务真的痛、实现相对可控、ROI能够快速被看见。 件： 先把第一个项目做成“破冰项目”，让业务部门拿到结果、得到表扬，甚至成为集团内 部的标杆。有了这个标杆，后面的资源、预算和组织支持都会更容易获得。 第三，要把业务方真正绑到结果上。 AI项目要跳出“技术团队自己的项目”这个定位。如果最后只是AI团队说“我们把系统做 出来了”，其实没有意义。真正应该关注的是：业务有没有节省时间？人效有没有提 高？业务结果有没有变化？ 所以我要想办法让业务团队和我们共同承担结果，甚至在条件允许的时候，把AI改造和 业务部门的KPI、OKR结合起来，让业务部门自己也有动力把项目推下去。 第四，FDE需要从“技术实现”跳到“业务结果”。 我以前也是架构师出身，但后来越来越觉得，AI时代不能一直停留在“这个技术怎么实 现”。底层很多实现工作，未来很可能本身就会被AI完成。 真正需要人来做的是：我为什么做这件事？这个问题到底怎么定义？它对企业有什么价 值？怎么设计一个能够支撑企业未来3到5年的架构？怎么把项目真正推动落地？ 所以我认为，一个成熟的FDE至少要同时具备沟通能力、架构思维和项目管理思维。 第五，要主动“破圈”和“摸高”。 破圈、摸高。 我自己很看重两个词： 破圈，是走出去跟企业一把手、业务负责人、不同产业的人沟通，他们真正关心的是： 营收能不能提高？成本能不能降低？组织管理能不能更透明？业务控制力能不能提升？ 摸高，是主动去接触比自己认知更高一点的人，理解他们怎么看问题。你的认知发生变 化以后，你解决问题的方式也会发生变化。 最后，我想说FDE本身是一个“中间态”。 我现在越来越把FDE理解成一个“中间态”：一开始，一个人可能什么都做，先靠解决不 同客户的问题活下来；慢慢地，你会发现自己在哪个行业、哪个场景真正有优势，于是 开始聚焦；当你能够独立理解业务、设计架构、推动项目落地，你就成为了这个领域的 FDE。 但如果一直停留在“我亲自交付每一个项目”，个人带宽是有限的。下一步就应该把过 去积累的交付经验、业务方法和SOP沉淀下来，让更多人可以按照这套方法交付；再往 后，把反复出现的共性问题提炼成标准产品。 从个人能力，到团队能力，再到可复制的产品能力，这才是FDE能力真正放大的过程。 所以如果让我重新定义这次财务案例，它其实超过了一个“AI\+财务”项目的范畴，更 像是一次完整的FDE实践：先进入业务现场，找到真实痛点；再拆解业务流程，把AI放 到真正需要判断的位置；让RPA去执行重复动作；用监督机制控制风险；最后通过一个 小场景证明价值，再逐步扩大AI在企业里的应用范围。 这也是我理解的FDE：真正对一个业务问题负责，直到技术变成业务结果。