FDE的定位思考:是护城河,还是新一轮人力外包?
文章结合头部 AI 大厂实践解读新兴角色 FDE。区分优质 FDE 与高端驻场外包,提出判断价值的三次转化标准,给出企业从单个智能体样板沉淀内部落地标准的实操路径。

最近和一家头部 AI 大厂的智能体团队开了一场交流会,会上有个词被他们反复提及:FDE。
这是我第一次从一线的 AI 厂商口中听到这个词,也就是说,不光OpenAI、Salesforce、EY 这些公司在公开强化FDE这类角色,国内大厂在做企业 AI 方案时,也开始把 FDE 融进整体交付方法里。
这个信号进一步证实了,FDE的工作正在逐步走上企业 AI 落地的舞台,也说明企业 AI 落地进入到了一个新阶段。
前两年,大家更关心模型能力、工具选型、知识库搭建和智能体 Demo。现在很多企业已经走过了第一步,采购了平台,也零星用了一些工具,甚至搭了好多智能体,但这时候新的问题又出现了:
智能体上线后,到底谁来管理?运行效果谁来判断?出了问题怎么复盘?调优经验怎么沉淀?以及内部有没有人能把这套能力快速复制到更多场景?
尽管AI 能力的进化速度足够快,但企业采用 AI 的能力,还远不及预期。
一、FDE的定位:让智能体顺利落地的中间层
从企业 AI 落地角度看,FDE已经不只是一个工程师岗位。它更像是一个复合角色:既要理解业务场景,也要理解产品和技术约束;既要能和客户沟通需求,也要能推动项目往前走;既要解决当下的问题,也要把现场经验沉淀成后续可复用的方法。
因此我会把FDE定义成:企业 AI 从“能用”走向“真用”的中间层。
传统软件交付里,客户买系统,供应商交付项目,IT 负责部署,之后业务使用,后续则由运维团队持续维护。虽然过程也复杂,但产品、售前、实施、运维的边界相对清晰。
到了 AI 智能体时代,边界就开始变得模糊。
一个智能体要进入真实业务流程,不只是搭个机器人这么简单。它会涉及知识库、业务规则、系统权限、接口调用、人工复核、运营指标、版本迭代等各个环节,背后会牵动一整套业务协同方式。
业务部门觉得 AI 不好用,但说不清楚到底哪里不好用。数字化部门觉得业务需求太散,没法判断优先级。平台方觉得客户没有运营机制,智能体上线后没人维护。而领导层最后则只能看到 Demo 和试点,看不到稳定的业务结果。
这时候,FDE 就被推到台前了。
这个岗位的存在价值,在于让智能体真正进入企业的工作系统。
二、客户缺的,是上线后的运营机制
在AI工具已经广泛普及的今天,很多客户已经在用 Dify、智谱的AICO试着搭建内部智能体,甚至开发了自己的智能体平台。但真正的问题是,平台提供了数据观测能力,也能收集智能体的运行数据,客户却不知道怎么围绕这些数据做分析、运营统计和流程优化。
再有就是运营机制的缺失,业务部门提出智能体需求时,到底该提交哪些信息?申请算力资源时,应该遵循什么规范?模型调用、工作流搭建、上线发布分别由谁负责?上线前要不要做测试?上线后谁来看运行数据?出了问题是业务方改规则,还是平台方改配置,还是产品团队改能力?
这些很琐碎的问题,决定了智能体能不能真正跑起来。
我的判断是:企业 AI 落地,正在从“建设问题”进入“运营问题”。
过去大家关心智能体能不能搭出来。现在的考验,则是搭出来后,企业有没有能力让它持续有效。
这就是 FDE 重新被重视的原因。
它面对的,是企业采用 AI 过程中的一整套现实约束。
三、FDE可能成为护城河:前提是能沉淀
首先,我非常认可 FDE 的价值,因为我自己就在做类似的事。
毕竟在企业 AI 落地里,标准产品很难直接看到客户水面下的问题。客户在选型时,经常问的是功能、价格、模型效果、私有化部署和系统兼容性。但到了真正上线,真正的问题就会浮出水面:事情该怎么干、谁来干、按什么顺序干?
企业需要明确这个智能体到底服务哪个岗位?哪些问题可以回答,哪些不能回答?知识来源谁来维护?业务规则变化后谁更新?如果智能体影响了原有审批流程,原来的制度要不要调整?如果一个岗位的工作被智能体改变了,新的责任边界怎么定义?
AI 产品落地,表面上是交付一个工具,实质上会改写客户做事的底层逻辑。
而真正有价值的 FDE,不是站在客户现场救火(是的,我上篇文章提到的故事:一个救火FDE的一周,其实是个反面案例,而是通过真实项目发现这些隐藏问题,并进一步沉淀成可复用的场景评估方法、问题复盘机制和责任分工模板。
这也是我认为未来FDE能产生岗位溢价的地方:
FDE 的价值不体现在驻场,而是在“沉淀”。
如果只是人到现场,帮客户多干一些活,那本质上还是人力服务。
但如果它能把现场问题转化为产品能力、流程模板和客户内部能力,它就有可能成为护城河。
四、FDE也可能沦为新一轮人力外包
站在另一个视角看,如果没有给这个岗位一个清晰的边界,它就很容易被包装成万能解法。
FDE 当然能解决问题,但也会有一个很大的风险:变成更贵、更懂 AI 的驻场外包。
客户需求说不清,FDE 去聊。客户流程不清楚,FDE 去梳理。客户不会搭智能体,FDE 去搭。客户不会测试,FDE 去测。客户不会运营,FDE 去看数据。客户内部推不动,FDE 去协调。
短期看,项目确实推进了。汇报材料更完整,试点效果也更容易做出来。但从长期看,客户组织并没有变得更会用 AI。外部团队一撤,很多机制又会停摆。
还有一种情况也很危险:每个项目都从零开始。
如果一个 FDE 团队每次进客户现场,都要重新访谈、重新梳理、重新设计模板、重新写交付物,说明它没有形成一套可复用的方法论。这样的 FDE 再高级,也很难变成护城河。
最理想的状态,是项目做完后,客户内部开始知道怎么提 AI 需求、怎么判断场景价值、怎么验收智能体、怎么运营知识库、怎么复盘问题做下一轮迭代。
否则,最后会形成一种虚假繁荣:供应商忙得不行,客户看起来也在推进,会上汇报也很漂亮,但一旦外部顾问撤走,智能体立马就会闲置。
这就是新一轮人力外包的典型特征。
五、我的判断:FDE的价值,在三次转化
我判断一个 FDE 是不是护城河,主要看它有没有完成三次转化。
第一次转化,是从混乱需求到可评估场景。
客户说想做 AI,不等于有场景,也不一定适合用智能体解决。比如想提高效率、想减少人工、想做一个助手、想让员工随时提问。
FDE 第一件事,就是把这些模糊的想法,拆成一个可以判断的业务场景。给谁解决什么问题,输入什么资料,输出什么结果,依赖什么系统和知识,风险边界在哪里,上线后谁维护,怎么判断它真的有效。
在我参与过的项目里,前期真正有价值的部分,就是需求调研和场景取舍。选错场景,后面越努力越浪费。
第二次转化,是从单点交付到标准流程。
一个智能体能上线,不代表企业有智能体运营能力。
FDE 要把一次项目经验变成一套流程SOP。比如需求怎么提、场景怎么评估、资源怎么申请、方案怎么设计、上线怎么审核、运行数据怎么看、问题怎么归因、版本怎么迭代。
企业真正需要的,是一套可续复制的工作方法。
而这套萃取出的算力运营或智能体运营的典型 SOP,是要以方法论的形式,交给企业的数字化部门的,后续再由数字化部门向业务单元推广。
外部团队负责从 0 到 1 打样,内部团队负责从 1 到 N 复制。
这才是企业真正能承受的 FDE 落地方式。
第三次转化,是从外部专家到内部能力。
成熟的 FDE 项目,不应该让客户越来越依赖外部团队。而是先由外部团队带着客户跑一遍,再让客户内部团队接着跑,最后形成企业自己的 AI 落地工作法。
它应该帮助客户内部长出几类能力:业务侧能提出更清晰的 AI 需求,数字化部能评估智能体建设优先级,平台运营方能看懂运行数据,专家复核人能持续维护知识和规则,管理层也能判断项目价值和风险边界。
如果 FDE 做完以后,客户内部没有出现新的工作标准、新的角色分工、新的运营机制,那项目价值会大打折扣。
六、企业最优先要做的,是形成自己的FDE标准
看到这,也许你会想,我们公司要不要也招个FDE?
从现实约束看,很多企业就算想招,也很难招到这样的人:既懂业务、懂 AI、懂系统、懂项目推进、还能写方案和做交付的人,本来就很稀缺。
更现实的路径是:先建立一套内部 FDE 工作标准。
这里有一个思路供大家参考:
先从一个典型智能体开始,跑通最小闭环。
这个闭环要把几个关键问题想清楚:业务部门怎么提需求,数字化部门怎么判断优先级,平台团队怎么确认知识、数据、权限和系统条件,上线前怎么测试,运行后看哪些指标,出了问题怎么复盘,下一版怎么迭代。
把这些都理清楚,就已经足够有价值了。
企业不用一上来就谈 AI 原生组织,也不用一开始就搞很大的 FDE 团队。先选一个高价值、边界清晰、责任人明确的智能体,把它从需求、建设、上线、运营到复盘完整跑一遍。
一个样板跑通,会比十场 AI 认知培训更能说明问题。
因为它会逼着企业把场景、知识、数据、系统、流程、权限、责任人和验收标准一次性想清楚。
七、对AI厂商来说,FDE的挑战是不要把自己做成高级驻场外包
从 AI 厂商角度看,FDE 能提高客户采用率,能推动更大的合同,也能深入客户现场发现真实需求。
公开报道也提到,AI 创业公司正在重新采用 FDE 这种被 Palantir 推广过的打法,用嵌入客户现场的方式帮助企业定制和采用生成式 AI。
但这种模式也会带来成本和毛利压力,投资人会关注它的长期规模化能力。
客户越复杂,越需要人。越需要人,越难规模化。越难规模化,越容易变成项目制交付。
所以 AI 厂商真正要做的,是让 FDE 现场发现的问题不断产品化、模板化、方法论化。
客户反复卡在需求表达上,就该沉淀场景评估方法。客户反复不会验收,就该沉淀测试和评测模板。客户反复不知道谁负责,就该沉淀责任矩阵和运营机制。
这才是 FDE 对厂商的价值。
如果 FDE 每次都靠人脑解决问题,它就是成本中心。
如果 FDE 能持续产出可复用组件、行业方案、运营模板和伙伴交付标准,它才可能成为护城河。
八、FDE落地不要从组织转型开始,而要从一个智能体样板开始
现在很多企业提到AI落地,都或多或少会和组织转型、流程重构绑在一起。
这件事本身是有道理的,也一定要做,但过于强调组织升级,会容易把项目带虚。
企业真正需要的,是先找到一个能跑通的样板间,从一个智能体开始,建立一套 FDE 工作法。
这个样板要有明确的业务痛点,有相对完整的知识材料,有稳定的使用人群,也有一个愿意负责的业务接口人。
项目推进时,先跑通从需求到上线的流程。上线后,再看它是否真的能稳定完成任务。
接下来,要建立问题复盘机制。最后,把这次样板里的经验沉淀成各种 SOP 和模板。
这条路径我觉得更适合大多数企业:
先跑通一个最小闭环,再复制到第二个、第三个业务场景。
先建立一套可执行标准,再讨论组织层面的岗位和职责调整。
这是我认为企业 AI 落地最稳的推进方式。
九、结尾:FDE是不是护城河,取决于有没有沉淀
所以,FDE 是护城河,还是新一轮人力外包?
我的答案是:取决于有没有沉淀。
如果 FDE 只是派人到客户现场,帮客户补流程、补系统、补执行,很容易变成更贵的人力外包。
如果 FDE 能把现场问题变成产品能力,把一次试点变成标准 SOP,把外部顾问经验变成客户内部能力,它才是企业 AI 落地真正的护城河。
本文由人人都是产品经理作者【申悦】,微信公众号:【互联网悦读笔记】,原创/授权 发布于人人都是产品经理,未经许可,禁止转载。
题图来自Unsplash,基于 CC0 协议。
- 目前还没评论,等你发挥!

起点课堂会员权益




