从技术交付到业务自驱：FDE用AI推动国企工作流程真正落地

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

原案例封面

为什么这个案例值得看？

一家省属国企一级子公司已有 OA、ERP 和数据中台，但业务增长后，法务、财务、内控等岗位难以继续依赖人工经验扩张。项目用两年时间共同梳理业务、数据、流程与组织，把 AI 从技术项目变成嵌入工作流的助手，并沉淀知识库、模型调度和多个 Agent。

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

一、企业与业务场景

FDE这个案例的客户，是一家省属国企一级子公司，业务覆盖服装、美妆、3C等十多个电商业务线，已经完成了比较扎实的数字化建设，有OA、ERP、数据中台，也有自己的信息化部门。

管理层在GPT等大模型出现之后提出了一个很模糊的要求：既然公司的数字化建设在国企中已经领先，能不能再往AI走一步？

如果只听这句话，项目团队可能会觉得这不过是一次常见的“企业上AI”项目。

但项目团队真正进入现场以后，发现这其实不是一个技术问题。

业务在增长，但国企有编制限制，人员并不能跟着业务无限增加。

真正懂电商、懂业务的人才也不一定愿意进入国企来从事这方面的工作。

所以第一个真实问题其实是：业务要扩张，团队能力却很难同步扩张，怎么办？

第二个问题来自内部管理。

国企的合规要求严格，业务越多，法务、财务、纪检等内控岗位的压力就越大。

比如法务团队只有两个人，却要面对不同业务线、不同合作伙伴的大量合同。

很多事情不能简单靠增加人手解决，因为真正懂业务的外部律师也不好找。

所以项目团队后来复盘的时候发现，客户说的“AI化”，背后至少有几个真实需求：业务增长之后如何提效，专业岗位如何承接更多工作，以及企业里大量依赖个人经验的工作，能不能变成一种可复用的能力。

这里面最重要的一步，是把表层需求和真实需求区分开。

高层不会直接说明：“业务人员希望法务少招一个人”，“业务人员希望员工的重复劳动减少”。

他只会说：“企业要拥抱AI。”FDE真正要做的，是进入业务现场以后继续往下问：做什么？

为什么现在要做？

哪个环节最痛？

这个痛点究竟是人不够、流程不清、数据没有沉淀，还是组织机制的问题？

随后，FDE逐渐明确的一点是：先把客户真正的问题找出来，再决定做什么。

二、原有流程与核心问题

传统企业的软件交付是这么做的：企业有一套相对成熟的软件和流程，技术团队根据客户的实际情况做配置、开发和定制。

简单的就配置一下，复杂一点就开发模块。

再复杂一点的就要先做咨询，把企业的业务流程梳理清楚以后再交付系统。

这套方式过去完全能跑通，但它的前提是软件行业几十年的最佳实践，能被信息化覆盖的业务部分，是能被讲清楚、流程相对固定。

而企业落地AI的真正难点，恰恰藏在“几十年的最佳实践”这里。

很多企业知识根本没有被沉淀，被结构化。

比如法务以前审核过很多合同，但最终只留下了一份修改后的合同，中间为什么修改、哪些条款是关键、哪些地方不能省，可能都在法务脑子里。

客服也是一样，员工可能已经在脑子里形成了一套知识体系，但这些知识并没有真正沉淀到AI可以使用的数据系统中。

流程也是同样的问题。

一个人把一件事情做了几年之后，会觉得很多步骤“理所当然”，甚至意识不到自己其实是在执行一套复杂流程。

可对于AI来说，这些步骤如果不被明确梳理出来，大模型就只能自己“生成”。

所以传统方式的真正问题，到业务规模变大、流程越来越复杂以后才暴露出来：靠人、靠经验、靠传统软件定制的方式，开始越来越难继续扩张。

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

项目团队其实是边做边调整的。

最开始进入这家企业，项目团队也先按传统思路来：以技术人员为主，把技术底座搭起来。

当时项目团队认为，只要把知识库、模型能力、Agent这些东西搭起来，再接到客户已有的信息化系统里，AI就能够逐渐进入业务。

技术上确实能做出东西，但做到一定程度以后，项目团队发现不对。

系统有了，客户的员工没有用起来，业务并没有真的发生变化。

真正难的其实是业务知识、数据、流程和人的问题，技术只是其中一部分。

所以项目团队的做法后来逐渐变成了几个层次。

第一步，先判断这个场景到底值不值得做。

项目团队不会再看到一个问题就马上做Agent。

而是逐渐形成了一个基本判断：一个场景首先要看价值和可行性。

有些事情技术上目前做不好，就不要硬做；还有一些事情虽然技术上能做，但实际价值太低，也没有必要做。

这个判断帮项目团队避免了很多“做出来没人用”的玩具。

随着这套框架逐渐形成，团队现在会先判断场景有没有真正的价值，再决定是不是投入。

第二步，把业务知识真正“挖”出来。

项目团队发现，单靠技术人员不够。

因为项目团队虽然懂AI，但不一定懂客户的美妆批发业务，也不一定知道这个企业具体怎么做合同、怎么审批、怎么管理业务的。

所以项目团队引入了“知识萃取师”这个角色。

知识萃取师和传统咨询不太一样。

传统咨询往往有行业案例和成熟模板，可以拿一套方法去判断客户应该在哪个环节提效。

但项目团队需要的是把客户自己脑子里的知识和经验真正萃取出来。

因为企业最了解自己的业务。

外部的人即使懂这个行业，也未必知道这家公司为什么这么做。

所以项目团队开始要求业务人员把原来的工作过程讲出来，到底怎么做、为什么这么做、哪些情况例外、什么情况下必须人工判断。

这个过程本质上是在给AI准备“业务世界”。

第三步，把隐性的知识和流程变成AI能够理解的东西。

有了知识以后，才谈得上知识库、RAG、Agent和工作流。

项目团队会去做知识加工、知识库管理，把原本散落在文档和人员经验里的内容沉淀下来；同时把一个岗位原来依赖经验完成的工作拆成明确流程。

因为通用LLM模型的本质是概率生成（这也是幻觉的来源），它对A公司的电商流程理解正确，并不意味着对B公司的流程也正确。

所以真正进入企业以后，项目团队不能简单地告诉模型：“业务人员自己理解一下这个业务然后去做。”流程必须来自企业自己。

后来项目团队会特别强调“先梳理流程，再做Agent”。

第四步，让员工真正学会用AI。

这是项目团队最大的一个转变。

最开始项目团队以为，董事长要求业务骨干来配合项目，找几个人就可以开始做。

结果员工来了以后，项目团队发现他们可能连提示词是什么都不知道。

项目团队让他配合知识萃取，他甚至不知道应该提供什么。

所以项目团队又增加了培训。

与其项目组每个人一点点教，不如直接给相关部门做AI通识培训，让业务人员具备基本的AI认知，具备组织向AI协同转型的认知。

正是这个原因，项目团队一方面是“IT部门牵头的技术项目”，另一方面是“人事部门牵头的组织转型项目”。

第五步，让AI成为员工的助手。

这是进入大企业以后非常重要的一件事。

项目团队在员工面前从来不强调“AI替代人”。

一方面，有些业务涉及法务、财务等责任问题，AI最终不能承担责任，所以真正进入工作流的Agent，大部分最终都需要人确认。

另一方面，这也是一个组织问题。

如果员工觉得：“要求员工交出个人知识，再由AI替代岗位，员工为什么要配合？”那整个项目从一开始就会产生阻力。

所以项目团队设计的时候，会让AI负责大量重复工作，但最终仍然由人确认、签字和承担责任。

这样既保证了业务安全，也让员工清楚地知道，AI是帮自己分担重复工作的助手。

四、项目结果与业务价值

这个项目的一项重要结论是，AI落地的效果，不一定都应该用“节省了多少人”来衡量。

当然，有些场景可以量化。

比如在法务场景里，项目团队帮助企业根据历史合同和业务信息去识别关键条款、发现风险，再交给法务最终确认。

原来法务需要从头到尾自己看，现在AI可以先帮他做一轮筛查，把需要重点关注的内容挑出来。

客户原本至少还要招一个法务，因为有了AI法务助手，这个招聘的编制就节省下来了。

并且目前两个法务工作状态也比较正常。

如果一定要用人数去折算，那就是一人年的综合成本。

但项目实践表明更有价值的，其实是另一种变化。

项目团队做过一个很小的行政场景。

企业里有办公用品自助柜，员工可以刷工牌领取电池、笔、本子等办公用品。

自助柜方便了员工，却给行政人员增加了补货管理的工作。

员工到了柜子前发现电池没了，只能发消息给行政人员。

行政人员什么时候看到、什么时候补货，也不确定。

这个事情当然可以用传统软件解决。

项目团队完全可以在OA里做一个页面或者弹窗。

但真正有意思的事情是，这个小工具是负责行政物品的同事自己通过AI提示词做的。

在项目团队全员培训以后，他发现了自己工作中的这个需求，然后通过AI平台，基于数据中台的MCP能力，用提示词做一个简单的Agent。

员工可以在IM上直接问机器人：“业务人员今天要领两节电池，还有没有？”系统去查库存；库存不足时，就提醒行政人员补货。

补货完成后发送信息给需要电池的员工。

这个工具本身的业务价值并不大，但它让项目团队觉得特别重要，有一种特别的含义。

以前这位同事遇到这个问题，需要要找IT部门提需求、排期、开发、内部结算工时。

现在，他自己已经可以想“这个问题业务人员能不能用AI解决？”这时候，FDE交付的就多了一层意义：它在企业内部培养出了新的AI使用者，新的FDE。

这可能比项目团队这些外部团队替他做一个Agent更重要。

五、关键落地难点

项目团队踩过最大的坑，其实不在技术。

如果让FDE给企业AI落地的难度排个序，FDE现在的排序是：人最难，其次是组织，再是数据，最后才是技术。

以前总说万事俱备差个技术。

现在技术反而是现在没有那么难的部分。

第一个挑战，是业务人员不一定愿意把自己的知识变成组织资产。

尤其当员工觉得组织使用AI最终是为了替代自己时，他自然不会主动把自己的经验、流程和知识全部说明。

所以项目团队必须从“替代”切换到“助手”，同时让企业的人事制度、激励机制跟上。

正因如此，项目团队后来一定要让人事部门参与进来。

AI本身就是一个组织工程，需要企业去思考：员工为什么愿意参与？

AI帮员工完成重复工作之后，他接下来做什么？

有没有业务增长？

有没有晋升路径？

有没有新的激励？

第二个挑战，是技术部门牵头并不一定是最好的组织方式。

项目团队第一年就是IT部门牵头，技术底座也做出来了，但后来遇到了瓶颈。

因为AI真正深入业务以后，问题的重心从“系统怎么做”，转到了“员工怎么用”“流程怎么改”“组织怎么配合”。

所以今年项目团队让人事部门牵头，从培训开始重新推进。

这个转变看起来有点反直觉，但恰恰是项目团队服务两年以后踩坑踩出来的经验。

第三个挑战，是数据并没有项目团队想象中那么完整。

这家企业是数字化基础很不错的代表，但仍然有大量业务没有结构化沉淀。

很多新业务、内控业务和人工操作环节，数据可能根本不存在；即使存在，也未必按照AI需要的方式总结归纳。

所以不能因为客户有ERP、有数据中台，就默认它已经做好了AI的准备。

项目团队后来甚至开始尝试建立自己的企业AI成熟度模型，从流程能不能被萃取、数字化程度怎么样、AI到底能实现到什么程度等维度，去判断一个场景适不适合做AI。

所以如今再去看一个AI项目，FDE可以特别警惕两种极端：一种是客户觉得“AI什么都不能干”；另一种是客户觉得“既然AI什么都能干”。

实际上，很多时候问题出在企业自己的流程没有梳理清楚、数据没有沉淀、组织机制也没有准备好，AI能力本身反而是次要的。

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

将这两年的经验压缩成几句话，FDE现在最看重的，其实是怎么把下面这几件事做好，Agent本身反而排在后面。

第一，先判断问题，再选择AI。

不要为了AI而找场景。

一个问题值不值得做，要同时看价值和可行性。

技术做不到的不要硬做，做出来没有价值的也不要做。

第二，先把业务流程讲清楚，再谈Agent。

很多人一上来就问：“这个场景能不能做个Agent？”FDE的答案通常是：先别急。

先问这个岗位到底是怎么工作的。

把隐性的经验、判断和流程拆出来。

因为企业里的很多流程，业务人员自己已经习惯到感觉不到它存在了，但AI必须知道这些东西。

第三，不要把FDE简单理解成一个“产品经理+全栈工程师”。

从项目结果看，FDE真正的价值，是打通业务和技术之间的鸿沟。

FDE可以是业务人员往技术方向发展了一点，也可以是技术人员往业务方向走了一点。

但这个岗位对于人的要求其实很高。

以目前的现实来看，当前一个成熟的FDE交付团队，仍然需要分工。

有人负责业务咨询，有人负责知识萃取，有人负责培训，有人负责技术开发，各司其职。

第四，中大型企业的AI落地一定是一号位工程。

如果老板只是说一句“企业要AI化”，然后把事情扔给IT部门，最后很容易变成一个技术项目，最后大概率面临失败。

但真正进入业务以后，人事、业务负责人、团队负责人甚至一号位都需要参与进来。

因为AI最终改变的，是组织的协作和工作方式。

第五，最终目标是让企业自己长出AI能力。

这是项目实践表明最有意思的变化。

项目团队做那个行政小工具的时候，真正产生价值的，是那个原本不懂技术的行政人员开始意识到，FDE工作里遇到的问题，也可以自己用AI解决。

当企业员工开始主动发现问题、主动拆流程、主动用AI解决问题的时候，FDE才真正完成了从“交付工具”到“改变组织能力”的转变。

所以如果让FDE重新定义FDE，FDE可能不会把它理解成“去客户现场帮他做AI的人”。

可以把它理解成：进入业务现场，把企业真正的问题找出来，把AI嵌进真实工作流，同时帮助客户逐渐获得自己解决问题的能力。

因为AI的技术门槛一定会越来越低。

今天项目团队会写提示词、会搭Agent，可能是一种能力优势；但过几年，AI会更成熟，企业员工自己都会用AI工具。

到那个时候，FDE真正留下来的竞争力，就是FDE比别人更懂企业的业务，积累了更多真实场景、流程、知识和交付经验，知道什么值得做、什么不值得做，以及怎么让一个AI能力真正进入组织。

这也是FDE现在做企业AI落地时越来越看重的事情：技术会越来越普及，但对业务的理解、长期的客户积累，以及把AI真正落到组织里的能力，反而会越来越重要。

七、可复用的交付资产

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

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

来源与作者

Datawhale《FDE案例100》，受访者：沈凯（杭州恒璟科技有限公司创始人）；PDF 第 138-147 页，书内页码 137-146。本文为访谈资料的第三人称整理，不是本站新采访。