《FDE案例100》方法论特辑 · No.16|FDE 到底是什么角色:三力模型与三套语言
先说一个我特别有印象的场景。
一家头部电商企业在海外做达人建联,老板最开始找到 FDE,问的是一句特别宽泛的话:“我们团队怎么用 AI 赋能?”
这话基本等于没说。你到底是要找人、要写内容、还是要筛商品?都不是。真正的问题得进了业务现场才看得出来。
你想想,如果你是那个 FDE,面对这句话,你脑子里得装多少东西才能接住它?你得听得出这不是需求,只是愿望;你得走进业务,闻出链路里哪一段最卡;你还得知道,哪些环节能用现成的模型,哪些得靠脚本,哪些必须留给人。
这大概就是 FDE 这个角色最真实的状态:一个人要同时踩在好几块地板上。
有人把 FDE 简单理解成“产品经理 + 全栈工程师”。一位做了两年企业 AI 落地的 FDE 直接否掉了这个说法。他说,FDE 真正的价值,是打通业务和技术之间的鸿沟。而且这道鸿沟,从哪边出发都行——可以是业务人员往技术方向走了一点,也可以是技术人员往业务方向走了一点。
在我看来,更准确的说法是:FDE 是业务与技术之间的翻译官和连接器,是最后一公里的那个人。
那“最后一公里”到底需要什么能力?我把它总结成一个三力模型。
第一力:懂业务——这是入场门票
不懂业务,你连门都进不去。
有个细节很值得琢磨。做央企财务 AI 的那位 FDE 说,业务人员做了十几年的判断,很多已经变成了下意识动作,你指望他一次性把整个业务逻辑讲清楚,不现实。所以他的做法是业务陪跑——跟着业务人员一起做几天,看他一笔业务到底怎么处理,再把流程一点一点拆开。
这里的关键不是“听懂需求”,而是把自己逼成半个行业专家。非标制造那位 FDE 为了做报价这个场景,进场之后先去了车间,看一个订单从图纸到交付经过哪些环节,翻了一批历史报价单,找业务人员和老师傅分别聊:谁看图纸、谁做需求拆解、谁定物料、谁判工艺、谁核成本、谁最后报价。只有把这条链路搞清楚,才知道 AI 该放在哪个位置。
不懂业务的人,会拿着锤子找钉子。懂业务的人,先看钉子长什么样。
第二力:懂 AI 的“宽度”,而不是深度
注意,是宽度,不是深度。
电信运营商那个案例的 FDE 打了个特别好的比方:如果你只知道自行车,那么你要去一个很远的地方,就只能想办法骑自行车过去。但如果你同时了解汽车、飞机,你才能判断什么场景该用什么工具。
这句话是冲着一种很常见的心态去的——“我最熟悉这个工具,那就拿这个工具去套问题”。可企业 AI 落地要的恰恰相反:你需要同时理解 AI、数据、云,以及基本的软件工程能力,然后判断哪里该用、哪里不该用。
央企财务那位 FDE 的做法就是典型的“宽度思维”:财务场景需要严谨,科研场景可能要专业计算能力,内容生成场景又更需要开放性。所以他不会执着于某一家模型——有些场景用这个厂商的,有些用那个,还有一些央国企场景直接本地私有化部署。他把这叫“因材施教”:先确定业务需要什么,再去组合背后的能力。
一个成熟 FDE 的技能盘子里,应该有模型、有数据、有云、有 RAG、有 Agent、有 RPA,也有传统的优化算法。不是每样都用,而是每样都知道“什么时候用得上”。
第三力:懂人与组织——算得清利益账
这一力最容易被技术出身的人忽略,却往往最要命。
一个项目刚进去的时候,你可能只跟一个部门、一个负责人打交道。但真正落地以后,会牵扯到不同部门、不同角色,甚至外部合作伙伴。信息化、数字化、智能化一旦真的改流程,就一定可能动到某些人的工作和利益。
所以那位车管所的 FDE 说了一句特别到位的话:FDE 除了做技术,还必须会沟通、协调、项目管理,甚至要会“算利益账”。 你要让不同角色看到——这个变化对他意味着什么?谁会获得收益?谁的工作会改变?出了冲突谁有最终决策权?
这些问题处理不好,再好的模型也进不了生产环境。
三套语言:对谁说什么话
三力是“内功”,落到具体场景,就变成一件更实操的事:你会不会说三种话。
那位有十年代码经历、后来转做 FDE 的人讲得很坦诚:以前他也会犯一个毛病,觉得只要把技术讲清楚,客户就应该能理解。后来发现完全不是。很多老板没有时间听懂模型、Agent、RAG 这些东西,他真正关心的是——“你能不能帮我把这个问题解决掉?”
所以,真正的 FDE 得切换语言:
对老板,讲 ROI 和战略。 他会问:营收能不能提高?成本能不能降低?组织管理能不能更透明?业务控制力能不能提升?
对中层,讲部门收益。 这件事帮你的部门省了多少人、多少时间,KPI 上能体现什么变化。
对一线,讲帮他减负。 别提“AI 转型”这种大词,就告诉他:以后写提示词这种长活儿、处理水印这种麻烦事,系统先帮你干了。
同一个人,同一套系统,得用三种语言讲三遍。讲不清楚,项目就卡在最后一公里。
分水岭:是不是对业务结果“持续”负责
那 FDE 和传统软件外包到底差在哪?
那位做达人建联的 FDE 给了一个我见过最干脆的答案:看是否对业务结果持续负责。
传统项目是一条直线:需求来了 → 做系统 → 验收 → 交付,结束了。
FDE 是一条螺旋:进入业务 → 理解问题 → 做第一版 → 让业务使用 → 根据反馈继续改 → 找到新的业务问题 → 再迭代。
注意最后那一下“再迭代”。传统项目验收即终点,FDE 的验收只是起点。一期做完以后,客户自然会冒出二期需求,因为第一个问题解决之后,企业会发现下一层问题。这也就解释了为什么 FDE 必须真的懂业务——他不是一个交完货就走的角色,而是那个要一直陪着企业把 AI 往业务里推进的人。
也正因为这样,一位 FDE 提到,成熟的交付团队其实还是需要分工的:有人负责业务咨询,有人负责知识萃取,有人负责培训,有人负责技术开发。一个人扛下所有,只存在于故事里;现实里,是把这三种力拆给一组人,再让一个 FDE 把它们串起来。
最后还想补一句清醒的话。电信案例里那位 FDE 提醒:别迷信 FDE 这个名词。 现在国内什么都能叫 FDE,从咨询到方案到部署。但无论叫什么,最终都要回到一件事:你有没有真正用过这些工具,有没有在自己的场景里解决过问题。FDE 的使命,说到底是把 AI 真正变成企业正在使用的工作方式。
这是《FDE案例100》方法论特辑的第 16 篇。聊完了角色,下一篇我们聊成长——一个 FDE 怎么从“什么都能干”的万金油,走到真正有壁垒的“行业聚焦”,这条路到底长什么样。
支持与分享
如果这篇文章对你有帮助,欢迎分享给更多人或赞助支持!