Q1：作为FDE，你应用AI的具体场景是什么？在这个场景下遇到的具体问题长什么样？
我这个案例的客户，是一家省属国企一级子公司，业务覆盖服装、美妆、3C等十多个电商业务线，已经完成了比较扎实的数字化建设，有OA、ERP、数据中台，也有自己的信息化部门。
管理层在GPT等大模型出现之后提出了一个很模糊的要求：既然公司的数字化建设在国企中已经领先，能不能再往AI走一步？
如果只听这句话，你可能会觉得这不过是一次常见的“企业上AI”项目。但我们真正进入现场以后，发现这其实不是一个技术问题。
业务在增长，但国企有编制限制，人员并不能跟着业务无限增加。真正懂电商、懂业务的人才也不一定愿意进入国企来从事这方面的工作。所以第一个真实问题其实是：业务要扩张，团队能力却很难同步扩张，怎么办？
第二个问题来自内部管理。国企的合规要求严格，业务越多，法务、财务、纪检等内控岗位的压力就越大。比如法务团队只有两个人，却要面对不同业务线、不同合作伙伴的大量合同。很多事情不能简单靠增加人手解决，因为真正懂业务的外部律师也不好找。
所以我们后来复盘的时候发现，客户说的“AI化”，背后至少有几个真实需求：业务增长之后如何提效，专业岗位如何承接更多工作，以及企业里大量依赖个人经验的工作，能不能变成一种可复用的能力。
这里面最重要的一步，是把表层需求和真实需求区分开。
高层不会直接告诉你：“我希望法务少招一个人”，“我希望员工的重复劳动减少”。他只会说：“我们要拥抱AI。”FDE真正要做的，是进入业务现场以后继续往下问：做什么？为什么现在要做？哪个环节最痛？这个痛点究竟是人不够、流程不清、数据没有沉淀，还是组织机制的问题？
我后来逐渐明确的一点是：先把客户真正的问题找出来，再决定做什么。
Q2：在你参与之前，这个问题过去是怎么解决的？
传统企业的软件交付是这么做的：企业有一套相对成熟的软件和流程，技术团队根据客户的实际情况做配置、开发和定制。简单的就配置一下，复杂一点就开发模块。再复杂一点的就要先做咨询，把企业的业务流程梳理清楚以后再交付系统。
这套方式过去完全能跑通，但它的前提是软件行业几十年的最佳实践，能被信息化覆盖的业务部分，是能被讲清楚、流程相对固定。而企业落地AI的真正难点，恰恰藏在“几十年的最佳实践”这里。
很多企业知识根本没有被沉淀，被结构化。比如法务以前审核过很多合同，但最终只留下了一份修改后的合同，中间为什么修改、哪些条款是关键、哪些地方不能省，可能都在法务脑子里。客服也是一样，员工可能已经在脑子里形成了一套知识体系，但这些知识并没有真正沉淀到AI可以使用的数据系统中。
流程也是同样的问题。一个人把一件事情做了几年之后，会觉得很多步骤“理所当然”，甚至意识不到自己其实是在执行一套复杂流程。可对于AI来说，这些步骤如果不被明确梳理出来，大模型就只能自己“生成”。
所以传统方式的真正问题，到业务规模变大、流程越来越复杂以后才暴露出来：靠人、靠经验、靠传统软件定制的方式，开始越来越难继续扩张。
Q3：后来你使用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是帮自己分担重复工作的助手。
Q4：相比传统方式，使用AI后的实际效果如何？
这个项目让我比较深的一个感受是，AI落地的效果，不一定都应该用“节省了多少人”来衡量。
当然，有些场景可以量化。比如在法务场景里，我们帮助企业根据历史合同和业务信息去识别关键条款、发现风险，再交给法务最终确认。
原来法务需要从头到尾自己看，现在AI可以先帮他做一轮筛查，把需要重点关注的内容挑出来。
客户原本至少还还要招一个法务，因为有了AI法务助手，这个招聘的编制就节省下来了。并且目前两个法务工作状态也比较正常。如果一定要用人数去折算，那就是一人年的综合成本。
但我觉得更有价值的，其实是另一种变化。
我们做过一个很小的行政场景。企业里有办公用品自助柜，员工可以刷工牌领取电池、笔、本子等办公用品。自助柜方便了员工，却给行政人员增加了补货管理的工作。
员工到了柜子前发现电池没了，只能发消息给行政人员。行政人员什么时候看到、什么时候补货，也不确定。
这个事情当然可以用传统软件解决。我们完全可以在OA里做一个页面或者弹窗。但真正有意思的事情是，这个小工具是负责行政物品的同事自己通过AI提示词做的。
在我们全员培训以后，他发现了自己工作中的这个需求，然后通过AI平台，基于数据中台的MCP能力，用提示词做一个简单的Agent。员工可以在IM上直接问机器人：“我今天要领两节电池，还有没有？”系统去查库存；库存不足时，就提醒行政人员补货。补货完成后发送信息给需要电池的员工。
这个工具本身的业务价值并不大，但它让我们觉得特别重要，有一种特别的含义。
以前这位同事遇到这个问题，需要要找IT部门提需求、排期、开发、内部结算工时。现在，他自己已经可以想“这个问题我能不能用AI解决？”
这时候，FDE交付的就多了一层意义：它在企业内部培养出了新的AI使用者，新的FDE。
这可能比我们这些外部团队替他做一个Agent更重要。
Q5：在部署AI过程中，是否遇到了新问题或挑战？你是怎么解决的？
我们踩过最大的坑，其实不在技术。
如果让我给企业AI落地的难度排个序，我现在的排序是：人最难，其次是组织，再是数据，最后才是技术。以前总说万事俱备差个技术。现在技术反而是现在没有那么难的部分。
第一个挑战，是业务人员不一定愿意把自己的知识变成组织资产。
尤其当员工觉得组织使用AI最终是为了替代自己时，他自然不会主动把自己的经验、流程和知识全部告诉你。
所以我们必须从“替代”切换到“助手”，同时让企业的人事制度、激励机制跟上。
正因如此，我们后来一定要让人事部门参与进来。AI本身就是一个组织工程，需要企业去思考：员工为什么愿意参与？AI帮员工完成重复工作之后，他接下来做什么？有没有业务增长？有没有晋升路径？有没有新的激励？
第二个挑战，是技术部门牵头并不一定是最好的组织方式。
我们第一年就是IT部门牵头，技术底座也做出来了，但后来遇到了瓶颈。
因为AI真正深入业务以后，问题的重心从“系统怎么做”，转到了“员工怎么用”“流程怎么改”“组织怎么配合”。
所以今年我们让人事部门牵头，从培训开始重新推进。
这个转变看起来有点反直觉，但恰恰是我们服务两年以后踩坑踩出来的经验。
第三个挑战，是数据并没有我们想象中那么完整。
这家企业是数字化基础很不错的代表，但仍然有大量业务没有结构化沉淀。很多新业务、内控业务和人工操作环节，数据可能根本不存在；即使存在，也未必按照AI需要的方式总结归纳。
所以不能因为客户有ERP、有数据中台，就默认它已经做好了AI的准备。
我们后来甚至开始尝试建立自己的企业AI成熟度模型，从流程能不能被萃取、数字化程度怎么样、AI到底能实现到什么程度等维度，去判断一个场景适不适合做AI。
所以如今再去看一个AI项目，我会特别警惕两种极端：一种是客户觉得“AI什么都不能干”；另一种是客户觉得“既然AI什么都能干”。
实际上，很多时候问题出在企业自己的流程没有梳理清楚、数据没有沉淀、组织机制也没有准备好，AI能力本身反而是次要的。
Q6：根据你的经验，我们怎么才能更好地把AI部署到实际业务中？
如果让我把这两年的经验压缩成几句话，我现在最看重的，其实是怎么把下面这几件事做好，Agent本身反而排在后面。
第一，先判断问题，再选择AI。
不要为了AI而找场景。一个问题值不值得做，要同时看价值和可行性。技术做不到的不要硬做，做出来没有价值的也不要做。
第二，先把业务流程讲清楚，再谈Agent。
很多人一上来就问：“这个场景能不能做个Agent？”我的答案通常是：先别急。
先问这个岗位到底是怎么工作的。把隐性的经验、判断和流程拆出来。因为企业里的很多流程，业务人员自己已经习惯到感觉不到它存在了，但AI必须知道这些东西。
第三，不要把FDE简单理解成一个“产品经理+全栈工程师”。
现在回头看，FDE真正的价值，是打通业务和技术之间的鸿沟。FDE可以是业务人员往技术方向发展了一点，也可以是技术人员往业务方向走了一点。但这个岗位对于人的要求其实很高。
以目前的现实来看，当前一个成熟的FDE交付团队，仍然需要分工。有人负责业务咨询，有人负责知识萃取，有人负责培训，有人负责技术开发，各司其职。
第四，中大型企业的AI落地一定是一号位工程。
如果老板只是说一句“我们要AI化”，然后把事情扔给IT部门，最后很容易变成一个技术项目，最后大概率面临失败。
但真正进入业务以后，人事、业务负责人、团队负责人甚至一号位都需要参与进来。因为AI最终改变的，是组织的协作和工作方式。
第五，最终目标是让企业自己长出AI能力。
这是我现在觉得最有意思的变化。
我们做那个行政小工具的时候，真正产生价值的，是那个原本不懂技术的行政人员开始意识到，我工作里遇到的问题，也可以自己用AI解决。
当企业员工开始主动发现问题、主动拆流程、主动用AI解决问题的时候，FDE才真正完成了从“交付工具”到“改变组织能力”的转变。
所以如果让我重新定义FDE，我可能不会把它理解成“去客户现场帮他做AI的人”。
我更愿意把它理解成：进入业务现场，把企业真正的问题找出来，把AI嵌进真实工作流，同时帮助客户逐渐获得自己解决问题的能力。
因为AI的技术门槛一定会越来越低。今天我们会写提示词、会搭Agent，可能是一种能力优势；但过几年，AI会更成熟，企业员工自己都会用AI工具。
到那个时候，FDE真正留下来的竞争力，就是我比别人更懂你的业务，积累了更多真实场景、流程、知识和交付经验，知道什么值得做、什么不值得做，以及怎么让一个AI能力真正进入组织。
这也是我现在做企业AI落地时越来越看重的事情：技术会越来越普及，但对业务的理解、长期的客户积累，以及把AI真正落到组织里的能力，反而会越来越重要。