Q1：作为FDE，你应用AI的具体场景是什么？在这个场景下遇到的具体问题长什么样？
我做的是一个央企科研机构的财务流程AI应用。
这个场景其实特别典型。央国企的财务工作有大量规则和流程，很多业务都超过了“把一张发票录进去就结束”的范围。
比如一个员工出差回来要报销一张发票。过去，他可能要先提交报销，然后财务人员去判断这笔费用到底属于什么性质，是差旅费、招待费还是其他费用；如果涉及项目，还要判断它应该记在哪个项目下面；同时还要去找这个人的出差申请、审批记录、所属部门等信息。
这些信息其实分散在不同的业务流程里。真正耗时间的，是填表之前那段判断过程。
而且央国企的财务科目本身就比较复杂，规则多、层级深。再加上付款对象除了员工，也可能是供应商，或者涉及保证金等各种对外的财务流转。所以当业务量越来越大以后，财务人员大量时间都花在重复判断和录入上。
对科研型央企来说，这个问题又多了一层。我们服务的很多企业里有大量科研人员，甚至是博士，他们真正应该投入的是科研工作，但大量时间被消耗在一个报销流程里。
让高价值的人去做低价值、所以我当时看这个问题，看到的是一个很明显的价值错配：重复性的流程工作，本身就是一种浪费。
这个业务到底哪里最痛？哪些环节是这也是我作为FDE比较关注的地方。我会先去看：真正值得被改变的？想清楚之后，再回头匹配对应的能力去解决它。
Q2：在你参与之前，这个问题过去是怎么解决的？
过去这套方式其实完全可以运行。
财务人员有自己的专业经验，也有成熟的业务规则。他们知道什么费用应该记在哪个科目，知道什么业务需要关联哪些审批信息，也知道集团系统应该怎么填写。在业务规模和复杂度还没有那么高的时候，它是一套可靠的办法。
问题在于，很多事情必须依赖人工。
前面要有人判断。比如一张发票过来，财务人员需要结合员工的出差申请、部门、项目等信息，判断这笔钱到底应该怎么记。
后面还要有人执行。判断完成之后，财务人员还需要打开集团网站，创建单据，一行一行地填写信息，再提交。
一个是判断时间，一个是执行时间。所以整个过程实际上有两个明显的时间消耗：
过去靠专业人员来完成没有问题，但随着业务量增长，这种方式很难继续线性扩张。业务量增加一倍，就增加一倍的财务人员，这条路很难走得通。
所以我们真正要解决的，是把财务人员从大量重复性的判断和操作里解放出来，让机器去承担那些更加适合机器完成的事情。
Q3：后来你使用AI解决这个问题的整体思路和关键步骤是什么？
直接进业务现场陪跑。我做这类项目，有一个很重要的习惯：
因为你不能期待业务人员把自己的整个业务逻辑完整地告诉你。很多时候，他自己做了十几年，很多判断已经成为了下意识动作。所以我们会跟着业务人员一起做，去看他每天到底怎么处理一笔业务，再把整个流程一点一点拆开。这个项目也是这么做的。
第一步，先把业务逻辑真正梳理出来。
以员工报销为例，员工不需要再关心后面的复杂流程，他只需要在钉钉里告诉机器人“我要报销”，然后把发票发过去。从这里开始，后面的流程就交给AI。
AI首先识别发票，然后去关联员工原有的业务信息，比如这个人之前有没有出差申请、审批意见是什么、属于哪个部门、对应哪个项目。这些信息被拉取出来之后，AI再结合财务规则进行判断：这笔费用到底应该归到什么科目、哪个项目、按照什么规则进行处理。
这里其实发生了一个很重要的变化：以前是人自己去系统里找信息、判断信息，现在变成AI主动把信息组织起来，再辅助完成判断。
第二步，让AI负责“判断”，监督机制负责兜底。
财务属于严肃业务，AI判断得再好，也不能简单理解成“AI说什么就是什么”。所以我们在里面设计了监督机制，可以把它理解成几个AI角色一起工作：一个负责执行判断，一个负责监督，一个负责发现风险。
对于已经比较确定的业务，就直接往后走；如果几个模型判断之后仍然存在不确定性，就进入风险监控，由相关人员重点关注。
这样一来，人的角色也发生了变化。过去是人处理所有事情，机器没有参与；现在变成AI处理大部分确定性工作，人只处理真正需要关注的风险和异常。
第三步，让RPA负责真正的“手”。
AI解决了“应该怎么做”，但还有一个问题：谁去把这个动作真正做完？ 所以我们又把RPA引进来了。
AI判断完成以后，RPA机器人就开始执行。它可以自动打开浏览器，进入集团对应的网站，创建单据，然后把相关信息填写进去并提交。
业务信息获取 → AI判断 → AI监督所以这个方案实际上是把整个流程拆成了几个部分：→ 风险识别 → RPA执行。
这也是我理解的FDE和单纯做技术方案最大的区别：我们想的是怎么把AI真正嵌进原来的业务流程里面。
第四步，先做一个“破冰项目”，再逐步扩大范围。
这也是我在项目落地过程中非常看重的一点。我一般会把第一个项目叫做“破冰项目”。
为什么？因为企业第一次接触AI的时候，往往需要先看到真实价值，才愿意投入大量资源，尤其是央国企，后面还涉及数据安全、基础设施、预算等问题。
所以我会先找离业务最近、最痛、最容易产生ROI的那个场景。就像摘桃子一样：先摘离自己最近、最甜的那个桃子。
让业务人员真正用一次，发现原来AI真的可以帮我节省大量时间。当业务团队自己尝到红利以后，他们才会愿意和你站在一起，继续做更大的事情。
Q4：相比传统方式，使用AI后的实际效果如何？
最直观的变化，就是时间。
过去处理这些财务场景，工作人员可能需要半个月，甚至一个月。现在通过AI加RPA，把一个完整流程跑下来，大概一天、两天就可以完成。
而且这覆盖了不止一个报销场景。在这个项目里，我们最终落地了10个AI相关应用场景，把财务不同环节都逐步覆盖了进去。
但我觉得，这个项目真正有价值的地方，在于它改变了人的工作方式。
过去科研人员可能需要参与很多与科研本身无关的流程。现在，他只需要在钉钉里把发票给机器人，后面的信息关联、规则判断、系统录入等工作都被隐藏到了后台。人的操作被压缩到了非常短的一步。
而对于企业来说，AI带来的价值也远超节省几个人工。它实际上是在把一套依赖大量人工经验和重复操作的流程，逐步变成一个可以持续运行的业务能力。
Q5：在部署AI过程中，是否遇到了新问题或挑战？你是怎么解决的？
AI项目最难的地方，很多时候在技术之外。这个项目让我比较深的一点感受是：
在AI时代，我甚至认为，一个项目如果单纯从技术上已经能够落地，其实已经成功了80%。真正容易让项目“死掉”的，是业务、人和组织。
第一个挑战，是业务部门的接受度和推进节奏。
AI程序本身不会产生价值，真正产生价值的是业务部门。比如AI帮他们节省了时间，但最后真正享受到这个效率提升的，是业务人员，所以我们必须想办法让业务部门和我们站在一起。
我特别反对一种方式：让AI项目组自己坐在那里设计一个东西，然后让业务部门过来使用。业务人员本来每天已经很忙了，你突然给他增加一个新系统、新流程，他第一反应很可能是“你为什么又给我增加了一个负担？”所以我们的方式是业务陪跑：我会跟着业务人员一起做几天，看他真实的工作流程，把业务逻辑主动梳理出来，让业务人员不必自己整理一份特别完整的需求文档交给我们。
同样，第一次合作也不能大刀阔斧地改流程。如果我跟业务部门说“你们原来的流程全部不要了，我们重新设计一套AI流程”，这个项目大概率会遇到阻力，因为业务人员已经有自己的工作习惯，原来的流程之所以存在，也有它自己的原因。
所以我更愿意从一个很小、很痛的场景开始，先把一个点做好，让业务人员看到真实ROI。当他发现这个东西真的能帮自己省时间，他就会开始主动跟你讨论“这个地方是不是也可以做”。这时候，AI项目就从“你要让我用”变成了“我希望你帮我继续做”。
第二个挑战，是数据安全和基础设施。
央国企尤其是科研机构，对数据安全要求非常高。财务数据很多都属于敏感数据，不可能简单地丢到公共模型里处理，所以我们必须从底层基础设施开始解决问题，包括算力、模型部署、数据环境等。
我之前就帮企业采购过大型AI算力一体机，投入达到两百多万元的量级，让企业具备运行大模型的基础环境。对于敏感财务数据，还需要采用数据不出域的私有化部署方式。
但这里又出现了一个很现实的问题：如果你一开始就告诉甲方“我们先花两三百万元买一台机器”，对方很可能会问“为什么？我还没看到AI能给我带来什么价值”。所以这又回到了前面的逻辑：先用小场景证明价值，再推动基础设施建设，不能反过来。
第三个挑战，是不同场景不能强行使用同一个模型。
我在做方案的时候，也不会执着于某一家模型。财务场景需要严谨，科研场景可能需要专业计算能力，有些内容生成场景又更需要开放性。所以我的原则是根据场景选能力：有些场景可能使用阿里云的模型，有些使用其他厂商的模型，还有一些央国企场景则采用本地私有化部署。
我把这种方式理解成“因材施教”：先确定业务需要什么，再去组合背后的能力。
Q6：根据你的经验，我们怎么才能更好地把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：真正对一个业务问题负责，直到技术变成业务结果。