大模型的能力持续走强，企业对 AI 落地的关注点已经从模型能力本身转向 ROI，投入一块钱能不能产出两块钱的收益。

但越深入会发现，B 端 AI 落地最难的不是模型不够强，而是 AI 理解不了企业的业务语言。同一句话，在不同企业、不同时点、不同部门都有不同含义，AI 只有把这些含义搞清楚，才能真正跑通业务。

本文围绕这一核心问题展开，介绍了落地过程中遇到的三大鸿沟、五步实施路径，并通过消费电子、文旅、新能源车企、B2B 四个行业的真实案例，最后落到业务语言的三门一表方法论，给出一套可落地的治理与责任框架。

分享嘉宾：迈富时 Marketingforce 产研高级总监，张小龙

内容已做精简，如需获取专家完整课件，请扫码领取。

01 

怎么去落地 AI，从全景图到五步路径

迈富时最早是做营销出身，所以针对每一个业务领域或每个行业，都会建立自己的全链路、全场景的产品和服务体系对应的全景图。这个全景图跟我们做 AI 落地的整套方法论是直接相关的。具体做法上，主要是结合咨询，加产品、加实施，三位一体的 AI 整体服务。

AI 时代来了之后，我们基于原先的企业全链路服务打造了 AI 原生的内核及底座，对外提供各种不同的智能体相关赋能的服务。通过两年多的实际落地会发现，现在的 TO B 市场并不是大模型不够强，最明显的变化是，企业对 ROI 的关注度越来越高，越来越务实，越来越关注 AI 带来的业务价值。

在前期 AI 落地过程中，我们看到三个比较突出的问题，称为三大鸿沟。

第一，最开始大模型出来后做的一些应用比较浅，可能就是做个调研报告、写篇文章、做个 PPT，那时候主要还是大家来体验 AI 带来的一些能力，或者更多体现爽点。

第二，缺少底座。这个底座并不是缺少一个单纯的工具，而是在企业内部真正缺少一个共同的可以承载业务的底座或平台。

第三，缺少工程化。之前很多企业做了一些样板间的工程，可能是因为 AI 的焦虑想去体验，或者一些政绩工程，但在这些样板间里很难去做复制或批量推广。

基于三大鸿沟，我们形成三个判断。

第一，AI 来了之后组织的关系变了，原来是人跟岗位的工作关系，现在变成了人加 Agent 跟任务的关系。

第二，AI 知道世界，却不知道你的企业。AI 能力很强，但 AI 怎么来理解企业的业务，成为一个关键要素，这也是业务语言的核心问题，所以很多企业会更多关注 AI 落地过程中语义层的建设。

第三，很多企业还是用老的思维在用 AI，也就是俗称的穿新鞋走老路。

我们怎么做 AI 落地，或者怎么做 AI 实施的交付，核心是把 FDE 理解为一套方法论，而不是单纯的岗位名称。FDE 或者 AI 落地过程中有五个步骤，基本上是找场景、建 Agent、跑业务、验价值、持续优化。

找场景跟全景图关系紧密，会针对每个客户、每个行业以及客户想做的场景，在全景图里找到能体现或与之匹配的高价值业务场景，每个场景里都有对应的 Agent 方案给到客户。在五步过程中，我们认为最大的体现不同公司功力差异的，是第三步，跑业务是分水岭。

FDE 现在比较共识的两个明面变化。

第一是一人多角色，一个人可能既兼了 BA（业务分析师），又要做 Coding，还要做其他治理性的工作，因为 AI 来了之后能力变得很复合。

第二是要多代码，而且要在现场快速迭代，很快给客户看到不同产品迭代的样子。但我们觉得最大的差异是，对于 FDE 不只是要强调把现场经验带回来变成产品的能力，而是更多要把能力留在客户组织里面，让 AI 在客户侧真正体现出价值，这就是客户真正关注的点。

02 

客户说不清需求，从三个动作开始

AI 落地的过程中会看到一个共性问题，就是大部分客户讲不清自己到底要什么。这也是我们做全景图的重要原因。

要做咨询，就得知道客户行业或业务场景里有哪些 AI 可以落地的机会或可切入的场景，每个场景里的业务价值如何、其他客户怎么做，这些都要帮客户去澄清，帮客户找到可落地的点。但即使找到了场景，客户也很难描述出具体需求是什么，他可能只是描述症状。

比如说 " 帮我做一个销售助手 "、" 帮我做一个智能客服 "、" 帮我做个知识库 "，或者 " 我反正有数据库，或者之前买过 BI 系统，现在要上 AI 能力，能智能地帮我想要什么数据就回答什么数据 "。这些都是我们碰到的大多数客户普遍存在的现象。

真正到 FDE 去落地的过程中，我们做法是：第一周进去之后会做三件事，就是把业务跑一遍、把数据摸一遍、把关键人物聊一遍。这并不是先期做调研，跟调研还是有区别，必须边了解边干，因为客户的需求有时候不是问出来的，而是靠一次次验证逼近的。

最体现这一点的是，每天都要帮客户做一个 demo。客户心中 Agent 理想的样子是什么，他只描绘了理想，这个过程中其实有很多东西，要靠不同的部门或不同的人去聊、挖出来，把关键的因素找出来，靠 AI coding 快速建立 demo，让客户再去确认。

这个快速每天迭代的过程就会快速逼近客户心目中真正想要的东西，这也是我们在 FDE 落地中相对其他公司会有差异的做法。

03 

四个行业的真实落地

四个案例中，我会展示客户最初说的、实际现场看到的，以及在业务语言层面卡在了哪个点，最后交付的是什么。

第一个是全球化消费电子制造龙头，要做一个销售聊天记录的助手或应用。从 AI 角度来说，最初的需求看起来很容易，把聊天记录拿下来帮他整理、清洗、归档就行了。

但实际进去后会看到，聊天记录虽然在 WhatsApp 里面，但报价规则大部分是在销售的脑子里面，什么样的客户应该怎么报价，并没有形成标准的知识库，或者落到文档里去。审批在 OA 里面，订单跟库存又在 ERP 里面。表面上缺的是一个工具，实际的深层问题是，海外业务这条链路根本没有被公司真正掌握，也就没有人落到系统、不落到数据层面。

在真正去落地时，我们第一步是跟着销售去跑一遍整个流程，从线索询盘到报价审批，再到订单库存，把整个链路梳理出来，从链路里找出真正关键的一些点。比如客户意向的标准是什么、怎么判定，报价规则怎么来提审批申请，哪些历史的订单跟客户分层之间的关系是什么、分层的标准是什么。

通过这些东西的梳理，把客户原来散乱的、不掌握的东西变成客户的资产。所以最终交付的并不是单纯一个销售 Agent，而是真正把客户以前不掌握的东西变成了知识资产，沉淀下来。

第二个是文旅集团，想做一个销售 Agent，目的是辅助销售，能提升转化、增加销售额。这个场景跟客服有点类似，但实际现场中，大部分情况都是出现一个问题，就是真正销售的核心东西都在销售的脑子里面，而且往往好的销售对这事还看得比较重要。

做文旅来说最常见的一些情况，就是每个销售对处理不同客户有不同的策略跟技巧。比如客户带着孩子怎么推荐、客户带着老人怎么推荐、客户刚结婚的怎么推荐，什么样的客户应该推荐高客单价，什么样的客户应该给他发优惠券。

这些其实都有不同的策略，虽然大家的工具都一样，但每个人处理起来会不一样。所以客户真正希望的是，把一些优秀的销售经验挖掘出来做成助手，给到一般的销售或者新人，能很快地提升销售能力。

进去之后要真实地去找这些好的销售进行沟通，一遍一遍地把他们的话术记录下来，然后进行清洗、分类、标签，找出里面高转化的一些关键点。然后再把话术转成 prompt，把相关知识转成知识库，把推荐判断转成决策链路，最终的一些结果还要进行评测集的评估，这样才能做到最终的有效交付。

所以最终交付的不是智能体，其实还有一套能复制专家能力的机制。这是现在很多大公司里面对研发在做的事情，有一个更好的名词叫蒸馏。把一些优秀人的能力蒸馏成 skill，能沉淀到 Agent 里面去，让 Agent 能力更强。当然这个里面也会带来一些变化，很多裁员很多人觉得是因为这个引起的，但这其实也不是，只是 AI 落地带来的能力，让大家可以更往深层次去。

第三个是新能源车企，想建一个知识库。因为对车企来说，新能源车每年发布很多车型，会带来很多资料不断地更新跟变化。对这些车企来说，希望有一个统一的知识平台来做这个部分，这涉及原来一个老大难的问题，就是知识治理跟知识管理的问题。

这里面并不是单纯原来治理工作的脏活跟累活的问题，关键在于版本管理、发布审批跟权限管控的问题。这一套才是我们觉得整个体系里面的关键部分，所以交付的不是仅仅只是一个产品，还有它整套对知识体系治理跟管理的一套整个的流程或一套标准。

最后一个是民生数据龙头，做的是问数。这个跟智能问数相关，是很多企业比较美好的理想：AI 来了之后，原来要去自己查报表、自己去翻档案，能不能有个 Agent 把所有数据接上去，不管把 BI 接上去也好，或者把原来的数据库直接接上去也好，是不是就能自动地想要什么数据就拿什么数据。这里面非常关键的就是敏感数据的管控问题，会涉及合规、业务跟技术三者之间的关系。

在这个逻辑过程中，我们做了一个关键但非常笨重的事情，就是把合规、业务跟技术这三条线，在流程图上做了非常清晰的定义。不是单纯去做梳理，而是数据未来的维护跟运转要有章可循、有迹可溯，所以一定有流程节点。

因为做数据的过程中，开始梳理之后帮他建立 Agent，但所有的数据在后面应用的过程中，一定涉及到定义的或者口径的变化，而且不同部门对变化的规则还不一样。

比如对一个活动业绩口径的定义，经营部门跟财务部门一定是不一样的，因为经营部门有业绩的标准，财务更多核算的是毛利或者净利润的规则。不同部门对这东西不一样，Agent 的处理逻辑就会完全不一样。业务部门要改口径、财务部门的权限或管理是怎样的，在这个整个链条里面，每个部门怎么协同和统一，其实这套机制是蛮复杂的。

四个案例总结时去看，虽然每个案例里体现的问题点不一样，但关键回到其实都是一个问题：AI 要采纳的业务语言，来自于谁。谁有最终或最准的出口，谁能有权做变更，最终出了问题应该找谁。这些问题都回归到人的因素上面。

04 

业务语言的三门一表

业务语言的三门一表，这是我们在做 AI 落地里面非常重视的部分。涉及三个权利：定义权、变更权、责任权。不管是哪个权利，其实都跟人相关，这就回归到 AI 治理的两条腿。

第一个大家讲得最多的就是技术这条线，技术要做到可追溯、可审计、可评估。但在 AI 里面，在 TO B 市场里，不可能绕过的一道关就是一定要可问责。你做的东西出问题了要找谁，肯定不能找 AI，因为 AI 现在不承担这个责任，所以一定是回归到背后那个人是谁，这就是今天主题的关键内容。

第一个是定义权，也就是谁掌握企业知识的解释权。每个知识点、每个口径定义，可能来自不同的部门跟不同的人。比如关于活动业绩口径或指标的定义问题，定义权的归属决定了知识跟人之间的绑定关系。

在落地过程中，针对定义权，我们会先做一份口径责任人清单。在梳理或调研的过程中，会把所有关键的知识点、数据项，针对具体哪个部门、哪个人，全部整理出来。这是做这个事情最重要的一个基础。

第二个是变更权。在做交付的时候，传统的交付不一定特别关注，因为更多涉及到系统上线之后用户使用相关的一些问题。但在 Agent 上线之后，如果定义变了，怎么在系统里进行调整，而且能达成全量的一致，这需要特别关注。

传统软件里可能比较好做，因为定一个规则它会自动做一些连锁的更新。但 Agent 里很多东西是异步的，因为它涉及语义，所以会涉及到历史的回答、Agent 的 prompt、Agent 的知识以及这些产生的一些决策。历史规则怎么再回溯，或历史知识怎么更新，其实是一连串带出来的新问题。

这套机制，我们在落地过程中会做两项。

第一，针对口径的变更，一定有一个清晰的流程。每个口径的变更一定有个路径，每个口径重要的部分会做影响面的分析：这个东西变了会影响哪些部分，一定要梳理清楚输出。变化之后是不是要对历史的一些回溯、历史数据进行同步更新，也必须在客户侧明确。这一步在传统交付里往往不会去做，但要让 AI 在客户产生价值、让客户能用起来，这是不能缺少的一个关键环节。

第二项是回归测试。做软件的过程中有回归测试，但那时讲的是阶段性工作。在 Agent 里因为有 AI 的自主化运行，所以一定要做一个回归的问题集。所有东西变了之后，要针对相关联性的问题做回答跟验证，证明变化能让相关性的问题全量更新，或者全量知识同步。因为有些定义改变的是规则，所有规则改变都意味着所有的数据结果都能变，相应变得准确，这是非常关键的一点。

第三个是责任权。这道门虽然大家不太会讲，但在企业里面确实是一道红线。企业系统出问题了，他一定想知道这个问题是谁，谁来为这个问题的错误买单，一定不是 AI。出了问题之后能回溯、能溯源，能知道这个问题是出在模型、出在数据、出在口径、还是出在输出。

因为对 Agent 来说，每一个环节出问题都可能导致最终的结果出问题。所以必须把这个问题的出处、涉及的人、涉及的时间找出来。这样企业才能知道这个问题怎么纠正，下次不会出现同样的问题。

现在做 Agent 最普遍的一个失败情况是：Agent 做得非常好、验收也很好，但真正投入到业务场景里面，但凡业务人员用过两次之后觉得数据不准或回答不好，这个东西可能就不用了。如果回答错误或不准确用户就不用，对企业来说是一次巨大的浪费。

基于这三道门，我们有一张今天特别想分享的表。这张表在 FDE 落地过程中比较有价值。在真正的实施交付过程中，会把关键的知识点或者数据要素，它的定义权、变更权、责任权跟主要的部门（这里讲的是业务部门、数据部门、IT 部门、财务审计部门），通过 RACI 的方式来确定他们不同的权限。

RACI 里面：R 代表负责执行，A 代表拍板，I 代表事后知会，C 代表事前咨询。有了这张表，企业自己拿到这个 Agent 之后怎么去运营就有了对照。任何数据的变化，要知道哪个部门应该怎么去做，出了问题应该是谁负责，或者有些问题应该谁来变更、谁来发起、谁来处理。

这张表防止了原来只交个功能清单的传统方式，那种方式对企业来说可能用不起来或不长久。很多的智能体，包括 Gartner 的报告也说，很可能 60% 或接近 60% 的智能体就会被放弃。要保证整个智能体能有效、能持续运转，必须有运维的一些手段进行保障。

这张表怎么用，我们给了甲方和乙方两个建议。甲方如果说认同这张表，可以针对表里去找指定关键口径的责任人，建口径变更的流程跟步骤，收集所有问题的回归验证集。

作为乙方，要针对这个部分，像我们一样，所有指标口径在落表格设计、处理或整理时，把关键的人角色填上；对于变更时的相关流程跟处理，也有一张表来进行记录；还要做验证，说明每一次最终交付的东西，答案里的内容是不是能跟表上的事实或业务规则定义的部分匹配上。

在产品上面，我们针对这三个部分有自己的三类产品。关于定义权，我们已有统一本体推理平台，是我们 Data Agent 的内核。关于变更权，有知识平台进行承载，涉及具体的权限、版本发布管理审批、全链路的流痕。针对责任权，主要是智能体在运行过程中以及运行产生的问题怎么去厘清、怎么去溯源，由 Agentforce 智能体中台进行承接。

最终回归到前面的内容，我们在落地过程中就是咨询加平台加实施，而且不只是交付一个智能体，还要保证企业真的能把智能体用起来，能持续地运转下去，最终能达到客户期望的 ROI 的结果。这就是我们在 AI 落地过程中自己的经验与分享。

05 

Q&A 问答

爱分析：FDE 在咱们内部其实不只是一个团队，而是一套落地体系。当时承载这件事的组织，是怎么搭建起来的？

张小龙：这个问题非常好。但我要先说一个现实：现在不管甲方还是乙方，做 FDE 都不太依赖招聘，更多是通过内部培养和转岗。因为每个人的背景、原来的特长、扮演的角色都不一样，关键是他怎么转型来做 FDE。

我们自己有一套学习路径，参照的是 Palantir。Palantir 的 FDE 有两个角色、两种职能，一个叫 Echo，一个叫 Delta，一个偏咨询，一个偏真正的开发。它把偏业务和偏技术的做了区分，这对企业内部来说比较好操作。原来技术背景强的人，可以先做 Delta，通过一两个、两三个项目的实践，逐渐转型成一个能 Hold 住整个项目的全能型 FDE。

而原来的产品经理、售前顾问，包括我们的 PM、BA，可以先去做 Echo，先去做交流沟通、先做方案，再在过程中强化自己的 AI coding 能力，用 AI coding 快速迭代出原型，把技术能力一点点补强。这两条路径，最终可以走到同一个角色里去。

我们自己现在也还在转型过程中。而在转型过程中，不同传统岗位的转型速度，差异其实还蛮大。

爱分析：这个转型速度的差异，主要来自技能，还是更底层的一些素质？

张小龙：我们会发现，不是所有人都适合做 FDE。

比如偏研究型的人。一些技术能力非常强的算法人才，他可能就是偏技术、不太偏业务。这种角色，你应该让他去解决关键性的技术问题，发挥他的长处，而不能强制让他转型去做 Echo 这类角色，那不一定适合，也不一定是他个人最好的发展方向。

当然，中间地带的很多岗位，大部分现在还处在一个灰度空间里，其实都有可能性。

爱分析：您刚才提到销售可能也不太适合做 FDE，这怎么理解？毕竟 Echo 那个角色，本身就要承担不少我们叫商务或者 BD 的工作。

张小龙：我觉得这跟销售文化和 FDE 文化之间存在差异有关。

销售如果自己创业，我觉得倒是个天然比较好的 FDE 角色。但他在企业内部，受绩效体系和长期形成的销售激励文化影响，跟 FDE 这套东西其实完全不一样。销售更多是拿前面的结果，FDE 更多是拿后期的结果。这个前后节奏的错位，是文化层面上的差异。

爱分析：现在大家聊企业 Agent 落地，聊得最多的还是从哪个场景切入、怎么找到高价值场景。但下一步更关键的是怎么推广，怎么把一个单点场景做成规模化、在企业内部铺开。关于规模化以及后续的推广，咱们有哪些思路？

张小龙：要回答规模化，还是要回到 FDE 这个岗位本身。如果把它当成一个岗位来看，有两个重要维度。一个是能把 AI 落地，把交付做好，让它真正产生价值；另一个是能把现场的经验沉淀回自己的产品里去。Palantir 讲的核心也是如何让 FDE 更好地打磨产品。我们认为，未来的规模化、复制化，一定是要回归到产品维度的。

但在国内，这不能完全照搬 Palantir。很多人认为 Palantir 的模式在中国不可行，因为它的平台非常复杂、非常重，整个项目标的也要非常高，才能承载它这种模式。

所以在我们内部，产品打磨是分两条路走的。针对真正的 KA 大客户，一个标品或者一个产品一定满足不了他的场景，必然涉及工具平台，再加上 FDE 帮他做实施和交付。所以我们一定要有自己的平台或者底座，在这个底座上承载复杂业务的交付，这是一类。

但对于中小客户，或者一些尝鲜型客户，他不可能一开始就搞那么复杂。所以我们还有一类产品，回归到端到端的、针对垂直业务场景的 AI 应用，也就是我们独立的 AI 产品。中小客户买回去可以直接用；尝鲜的客户不太敢一次性投入那么大，可以先买一个独立的 Agent、一个独立场景的 AI 应用，先试试效果。试好了，这类产品就可以作为快速复制的载体。这就是我们两条腿走路的方式。

以上就是本次分享的内容，如需获取完整课件和视频回放，请扫码领取。

⩓

长按二维码，领取完整版视频回放

现任迈富时（02556.HK）产研高级总监，历任多家科技企业技术 VP、CTO，复旦大学计算机系毕业，拥有二十余年 ToB/ToC 系统产品与技术架构经验。深耕企业数智化转型与 AI 落地，主导东方航空、招商银行、国网等大型客户智能体平台建设，擅长大模型、智能体技术体系搭建与行业场景规模化落地。

注：点击左下角" 阅读原文 "，领取专家完整版视频和课件。

近期厂商征集

AI 数据基础设施研究项目征集

点击申报

截至时间：10 月 31 日

本体市场研究项目征集

点击申报

截至时间：10 月 31 日