腾讯《FDE模式行业观察与实践》报告快速：从实践经验总结FDE该怎么干

"AI时代FDE模式如何跑通？腾讯报告揭示：从80%到99%的关键跨越，在于双向蒸馏——将客户隐性知识转化为可复用平台能力，同时让AI降低定制化成本。核心是卖业务成果，而非软件本身。"

近日，腾讯研究院发布了《前线共创，双向赋能——FDE模式行业观察与实践》报告。报告主要以腾讯云的经验和方法论总结为基础，回答AI供应商如何更好的开展FDE。不同于很多报告大篇幅介绍供应商自身的解决方案和案例，报告相关内容很少，内容更多是一线实践落地经验和方法论总结。

报告内容质量很高，没有虚空的概念拔高，都是通俗易懂的实践总结，对于在探索FDE的AI技术供应商和关心FDE的从业者有比较强的参考和借鉴价值。
 

报告涉及的内容包括：

• 分析了FDE模式与传统现场交付模式的区别，以及为什么AI时代FDE模式得以成立
• 介绍了FDE模式对应的本体+Skill+连接器的技术架构，以及的适用客户行业特点
• 参考了Palantir等国外先进经验，也在各环节因地制宜的分析了国内的状况及对应的适应性策略
• 结合腾讯自身ADP平台和WorkBuddy团队的FDE经验，总结了FDE常见的挑战及应对策略
• 系统阐述了如何筛选和培养FDE人才团队，如何制定其业务目标和职业发展路径
• 用一个具体的虚拟案例，详细介绍了每个阶段、每个角色该做什么、产出什 么、怎么考核、利益怎么分配，全部落到操作层面
• 对未来的FDE发展做了判断，并给相关各方：用户企业、平台方、AI企业、个人从业者具体的建议。

报告中多次提到了Bob McGrew在YC的公开访谈，其具体内容见《Palantir早期高管解释如何正确的践行FDE》

AI在企业应用与之前的不同

AI Agent与SaaS的不同

SaaS核心逻辑是产品标准化和规模化扩张，用统一产品服务尽可能多的客户，边际成本趋近于零，适合CRM、HR、财务、协同办公等相对标准化的场景

AI Agent需要高度贴合客户业务，但 AI工具又降低了原型开发、流程编排和系统适配成本，原本"不划算"的定制化场景，在 AI 辅助下开始重新具备经济性。

一个Agent场景真正跑通后，会带来持续的模型调用、 工具调用和业务流程执行，平台收入也会从"卖席位"转向"持续使用"。

AI Agent与传统信息化项目的不同

传统信息化项目中，方案文档、原型图和参考案例往往足以帮助客户建立信心。但AI项目不同，模型效果、边界条件和业务收益都存在不确定性，AI项目天然要求更早进入可运行Demo阶段，用真实问题、真实数据或接近真实的业务流程验证可行性

企业级AI落地有一条"80/95/99"规律：覆盖80%用例的Agent可能很快搭出来，达到95%已经很难，达到 99%往往需要FDE、专用平台和上万级真实对话数据

FDE不是做从0到80%的活，而是做从80%到99%的活。客户愿意为FDE付费，不是因为他看不到 Demo，而是因为Demo到生产之间有一条很长的沟

企业引入AI的3个阶段

企业引入AI需要穿越三个阶段——个人提效、组织转型、业务重构——每个阶段动辄以年为单位，且每个阶段都需要FDE以不同方式介入。三个阶段依次递进，没有捷径

• 个人提效阶段，FDE的工作形态接近一线操作训练营，让业务团队真正上手用起来，而不是看完Demo就散了。
• 组织转型阶段，FDE需要向高层提供跨行业的组织变革经验——如何调整考核体系、如何打破"人肉 API"式的中间层——这类工作更像管理咨询和战略宣讲。
• 业务重构阶段才是常见的系统建设，把行业隐性知识沉淀为本体，让大模型进入业务核心。

FDE不是懂AI的实施工程师

FDE与传统实施工程师的区别

国内ToB团队传统软件项目的框架：售前讲方案，交付接系统，工程师按需求改流程，项目验收后转场。现场实施工程师工作更多围绕项目交付、资源协调和私有化部署展开

FDE确实要靠近客户，也确实要把东西部署到生产环境中。但FDE的前线是业务问题一线，部署不是安装系统，而是把模型、数据、流程、权限、组织责任和业务指标部署成可持续运行的结果

FDE的核心区别是项目结束后是否形成学习闭环，缺少第三步，FDE就会退化为高端外包

第一，重新定义客户问题——把客户说出来的需求，翻译成真正值得做的业务问题。

第二，交付为可验证结果——不只是功能可用，还要证明接听率、 转化率、处理时长或人效确实改善。

第三，把现场经验带回来——行业里反复出现的流程、接口、测试方法和 合规要求，能不能沉淀为可复用的平台能力。

FDE能力的两部分

FDE模式把过去分散在多个岗位上的能力压缩到一个小团队里，分为两类职能：Echo负责"该做什么"，Delta负责"怎么做出来"

Echo的核心是理解客户业务——钱从哪里来、流程卡在哪里、AI从哪个环节能撬动价值。不能只听客户说 要什么，还要判断客户说的是否是问题本身

Delta的核心是快速建原型、接系统、调模型，在真实环境中不断迭代

Echo与Delta不一定是两个岗位，而是两种角色。早期团队中一人可能兼有两种 能力，但随着项目规模扩大，一般会自然分化

FDE的本质：双向蒸馏

第一层是对客户的蒸馏，把散落在客户员工脑中的业务经验、流程规则和隐性知识，转化为 AI 能调用的知识库、规则系统、工作流、SOP和应用能力

第二层是对厂商自身的蒸馏，把KA项目中获得的行业知识、系统接口、测试方法、场景模板和失败案例， 沉淀为产品能力、行业模板、内部工具和平台组件

承载两层蒸馏的共同载体，就是本体层。本体本质上就是结构化的业务知识图谱，把不同系统差异化表达翻译成统一业务语言。从一个客户总结出来的本体，有机会复制到同行业另一个客户。

本体在于延迟收益和规模效应的叠加。沉淀本体的投入不会在当期项目中回收，第一个项目甚至前几个项目，成本会比纯项目制交付更高。但如果垂直领域有足够多的同类客户，做完一家标杆后，其他类似企业可以复用同一套本体，交付成本显著下降，交付周期明显缩短。

两者叠加，FDE模式是一种先投入后回收的商业逻辑，如果一个领域只有一两个客户，本体沉淀的性价比就不高；如果领域足够大、客户足够多，前期投入就能获得长期复利

判断团队是否是FDE

看项目结束后是否能沉淀Skill、模版、产品能力，沉淀后是否显著降低下个客户成本，如果都是，才是FDE

辅助判断的还有两个核心问题：产品边界每个季度是否在向产品侧移动，以及成熟客户的现场投入是否持续下降

FDE的3个判断前提：客户是否值得深耕（需求真实、业务参与）、项目能否沉淀资产（流 程有共性、数据可复制）、公司有没有机制复用（头部经验能传递到中腰部）。三项都不满足就是高端外包

知识沉淀载体的变化

早期知识图谱，构建和维护成本极高

后来工作流编排，降低了部分门槛，能解决大量流程问题，但仍需加强技术能力。Multi-Agent进一步增强了复杂任务协作能力，但系统设计和调试复杂度仍然不低

当前是Skill与连接器组合。本体解决"业务对象如何被理解 "，Skill 解决"能力如何被复用"，连接器 解决"系统如何被操作"，三者组合在一起构成一个可复用的行业解决方案

即使有AI辅助本体抽取，人工确认成本依然很高，AI生成的结果可能98%是正确的，但要找出那2%的错误，人必须读完100%。

Palantir实践经验

FDE在军方、情报机构、能源等高复杂度客户现场解决具体问题，同时把反复出现的流程、权限、数据关系和决策规则抽象为本体层和平台能力。客户越多，本体层越厚，服务同类客户的成本越低

这套模式Palantir能跑通，有三项条件同时成立：FDE与产品研发之间有高质量反馈链，客户现场经验能够被平台吸收，平台能力反过来提高下一个客户的交付效率。缺少任一环，FDE都容易退化为高端咨询

国内团队不应照搬Palantir的完整技术栈，而应抓住核心逻辑——*在数据与业务之间建立统一语义 层，让AI和FDE共同操作这层语义，而非直接面对原始系统*——用更轻量的方式（Skill+连接器+行业知识库） 逐步逼近本体层的效果

AI使FDE得以成立

AI使得3项业务动作成本降低

FDE模式不是新概念，Palantir在2005年就开始实践，但只有极少数公司真正跑通，最近火起来因为AI改变了3项成本结构，使过去"不划算"的业务动作变得可行

• 第一，行业知识蒸馏成本下降。过去客户现场团队从发现真实痛点，到等待后方产品开发出来中间隔着漫长反馈链。AI coding让一线FDE可以在现场直接搭建原型。
• 第二，定制开发成本下降。小型场景化开发、快速原型和客户侧流程适配，可以由更小团队完成价值验证
• 第三，复合型人才供给成本下降。AI工具弥补了部分工程、文档和产品能力，使更多一线人员具备跨业务与技术边界工作的可能

AI放大本体层价值

本体层不是AI时代才有的概念，过去没有大规模流行重要原因是最后一公里编码和交付成本太高

AI编程工具擅长根据清晰描述生成上层业务应用，本体层把业务对象、流程关系和操作规则讲清楚，AI可以更快的完成最后一公里实现

从加AI走向AI Native

多数传统企业仍处在"加AI"阶段：保留原有组织架构和业务流程，只希望用AI在局部环节节省人力

AI native企业则会反过来问：如果AI能力已经存在，这个业务本来应该怎么设计？它们愿意调整流程、岗位和组织方式，把AI当成业务架构的一部分，而不是外挂工具

这样的客户更难服务，但更容易形成标杆案例和高客单价

FDE一线落地实践经验

FDE与FDPM互补配对

一个人很难同时完成行业判断、客户沟通、方案设计、快速原型和产品反馈，成熟的团队将技术落地和客户牵引拆成互补角色：

• FDE更接近技术落地与产品改进的负责人，核心工作包括AI测试、Prompt开发、规则系 统搭建、产品代码修改和系统集成
• FDPM（前线部署产品经理）则更偏客户沟通、需求对齐和测试用例设 计，核心工作是理解客户业务逻辑，把需求翻译成可执行的技术方案，管理项目进度和客户期望

FDE一线实践四步法

FDE团队进入客户现场后的4步工作。核心原则是卖成果，不卖软件

• 第一步：摸清客户的钱从哪里来、业务卡在哪里、AI能从哪个环节撬动价值，要行业业务专家参与，把 SOP、知识库、业务链路和关键指标梳理清楚
• 第二步：协作搭建。业务专家和FDE一起把场景转化为Agent、工作流或应用原型
• 第三步：用工具保障质量，从真实聊天记录、历史工单、业务数据中生成测试集，进行自动评测和A/B测 试。
• 第四步：用业务结果验证价值，把AI组与人工组进行逐环节对比，用触达率、响应率、转化率、人效等指 标说服客户继续投入

从小而重要场景切入

如果FDE切入的场景不在CEO或业务负责人的优先列表，项目最终被搁置或降级

FDE模式对应的商业模式不是"大单一次性交付"，而是Land and Expand，初始项目可以很小，甚至 短期内不一定盈利——先用一个小范围试点证明价值，在客户内部建立信任；客户看到效果后，再从一个部门扩展到多个部门、从一个场景扩展到多个场景，合同金额和续费率逐步提升

按结果收费是一个方向，但前提是场景能够量化业务结果。 如果能建立清晰基线，就更适合探索效果付费。否则FDE很容易陷入按人天计费，重新回到传统服务模式。

成熟度判断框架

FDE需要一套成熟度判断框架， 帮助自己和客户评估当前处于哪个阶段、下一步该做什么

多数项目在L1到L2之间夭折。原因通常不是技术问题，而是三类卡点：

• 第一，试点用户没有被嵌入考核， "用不用都行"导致使用率下降；
• 第二，数据质量在Demo阶段被回避，进入真实环境后问题集中爆发；
• 第三， 组织审批流程没有提前打通，权限和合规成为最后一公里的拦路虎。

FDE的专业性，体现在能提前识别这些卡点并设计应对方案——而不是等问题出现后再救火

腾讯云FDE实践

腾讯云智能体开发平台及FDE模式演进

腾讯云智能体开发平台ADP的4个阶段及对应的FDE模式演进

平台进入自然语言构建阶段后，用户用自然语言描述需求即可配置应用，不再需要编程背景，FDE的价值因此从搭建者转为场景发现者、需求翻译者和方法教练

ADP落地通常要跨过四层门槛，这四层门槛解释了为什么很多客户"买了平台却用不好"

区域与生态：原厂打样、伙伴复制

中国市场复杂，原厂无法覆盖所有客户和行业，较稳妥的节奏是：当前阶段先由原厂在重点行业和标杆客户中跑通模式，沉淀Skill、模板、连接器 和方法 论；等方法论和培训体系稳定后，再逐步引入伙伴复制

WorkBuddy客户成功团队的全链路FDE实践

认知层Echo：面向企业客户，传递腾讯集团AI落地与组织转型经验。一线实践反复出现同一现象：产品试用初期使用频次很高，两三个月后如果没有嵌入日常流程就会下降。

问题不在功能，而在组织没有为AI调整工作方式。Echo的价值在于把腾讯内部从个人提效到组织转型的经验转译给客户， 帮助客户高层理解如何实现组织扁平化，如何基于业务组建敏捷小团队，如何让传统模式与新模式并行，如何 把超级个体能力传导为超级组织效能

工具层Delta：降低工程执行成本。很多客户缺的不是"能演示"的页面，而是把业务流程快速转化为可验证应用的能力，AI编程工具压缩低价值重复开发后，FDE更需要把精力放在需求澄清、架构判断、测试评估和可复用 封装上

商业闭环：被验证的独立定价能力。已有行业头部客户在工具采购之外单独为FDE陪跑服务付费，金额从百万级到五百万级不等，涵盖工作流梳理、人才培养、组 织转型辅助和效果评测等模块。

WorkBuddy团队的自运转逻辑也逐渐清晰：以服务包和培训认证形成短期收入，以持续消耗形成长期收入引擎，以半年度为周期向组织证明自负盈亏能力。

落地困难与解法

很多团队项目越做越重、知识越散、利润越薄，最终滑回传统外包。FDE实践层面的常见困难及解法如下文。所有风险本质上都指向同一个问题：有没有持续降低边际成本

本体层缺失的恶性循环

本体层建设是FDE规模化的必经之路，也是最容易被延期的事。项目多、人手紧时，团队会优先交付客户，沉淀永远排在后面；没有沉淀，下一个项目又从零开始；效率低、人更累，于是更没有时间沉淀

团队连最基本的Skill积累、行业模板和术语标准化都没有做，每次交付完全从零开始

反馈链断裂是这个循环的具体表现。一线Delta做完客户项目后，没有利益驱动把现场发现的新业务实体、新流程反馈给后端。考核只看项目是否交付，不考核对本体的贡献；沉淀回来的东西要改、要发布、要培训前线用，远不如直接在客户现场用AI coding搞定来得快

破解这个循环，需要管理层明确把沉淀Skill、模板和本体资产当作与项目交付同等重要的产出；需要有人专门负责资产整理和平台化，而不能所有人都被项目拉走

组织归属决定 FDE 的命运

FDE放在哪个组织里，会直接影响它变成什么。

• 放在销售体系，优点是贴近客户、响应快、签单动力强， 但风险是被当作签单赠品，免费做Demo换合同，沉淀动力弱。
• 放在交付体系，优点是项目管理规范、交付质量可控，但容易把FDE固化成项目制团队。
• 放在产品体系，最有利于知识沉淀和产品化，但也有远离一线客户的风险。

更合理的方式是矩阵制。FDE行政上应与产品和平台能力保持强连接，确保一线经验能回流；业务上要与 销售、客户成功、行业团队协作，确保贴近客户；考核上既看客户价值，也看知识产出。

LAND容易，EXPAND难

FDE模式的商业可持续性取决于客户续费和扩展。初始落地相对容易，难的是后续扩展：第一个场景做完后客户不知道下一步做什么；应用上线初期新鲜感驱动使用，几个月后如果没有嵌入流程，使用率下降。

提升Expand的关键，是在Land阶段就埋入扩展种子。第一个项目不能只证明单点能力，还要展示同一业务链路上还能做什么；上线后要用使用数据和业务指标证明价值；FDE要从IT部门扩展到业务部门，让真正使用者和价值受益者参与进来

利润率的结构性挑战

FDE模式的成本结构天然偏重，提升利润率有三条路径：

第一是产品化，把FDE沉淀的Skill、行业模板和标准方案封装为可复用产品，一次开发多次收费；

第二是杠杆效应，通过Echo与Delta分工、AI工具放大、伙伴体系复制，把少数高端人才的人效放大；

第三是价值定价，从按人天收费逐步转向按业务结果、使用量或客户收益收费。

价值定价在国内面临结构性障碍，"业务结果改善"很难写进合同条款。更现实的路径是产品化复用——把每次交付成本压低，而非把单次收费抬高

适合FDE的场景选择

a16z 在分析"万物Palantir化"趋势时提出一个决策矩阵：

如果处于低关键性、客户碎片化、简单集成的象限，更适合产品驱动增长模式而非重FDE。真正适合FDE 的，是业务问题尚未被清晰定义、客户需要共同探索、且探索结果有机会沉淀为平台资产的场景

人才、组织与考核机制

FDE缺人是行业典型问题，国内强FDE高溢价，弱FDE普通化，初级FDE 10—25K/月，中级AI交付25—45K/月，高级FDE和战略客户岗位50—80K/月甚至更高。

FDE能力图谱与角色分工

底层是工程能力保证能把东西做出来。中层是产品和系统能力，保证做出来的东西能稳定运行。上层是业务和组织能力，保证做的事情值得做、有人用、能扩展。越往上越稀缺，也越难被AI替代。

国内FDE人才挑战

国内FDE人才供给困难：优秀工程师未必愿意做长期出差、面对需求反复变化的客户工作；行业知识积累需要时间，行业都有自己的流程、语言和合规边界，不是短期培训能速成；国内现有岗位体系不完全适配 FDE，传统SA擅长方案包装但不一定能交付闭环，交付工程师能实现但不一定能定义问题

FDE不能全靠外部招聘。更可行的路径，是从现有架构师、解决方案、交付和行业专家中选拔不同能力类型的人，建立项目制培养机制，配套培训、考核和激励体系跟上。

国内一线存在一种组织陷阱：干得好就被调回总部，一线持续失血：一旦人员表现突出就调回总部做管理或产品。

FDE长期处在客户现场和内部产品团队之间，出差、项目压力、客户反复 变化都容易造成消耗。如果组织没有清晰的晋升路径和能力沉淀机制，FDE很容易成为高流动岗位

真正健康的机制应该让一线本身成为高级职级的主战场，而不是把它当成通往总部的跳板

FDE人才培养机制

FDE在真实客户问题中练出来，课堂教不出来，分层培养路径

FDE培训要走通"准入—跟项目—独立交付—经验积累—晋升分层"这条线，一个可操作的机制分四层：

考核维度覆盖三类指标：客户落地（按时上线、使用率、客户满意度、续费扩展），工程质量（稳定性、 权限安全、评测覆盖、故障响应），经验积累（Skill产出数量、反馈采纳率、模板复用率、跨客户节省工时）

让考核真正落地的三个操作要点，三个机制叠加，才能把"沉淀算绩效" 从口号变成可执行制度。

第一，绩效双轨制：Delta考核中"项目交付"占85%、"经验积累"占15% ，随团队成熟逐步提升至20—25%；Echo考核中"本体/平台质量"占 70%，"前线支持"占30%。

第二，内部结算驱动：Delta使用平台本体或行业模板时记账，提交的反馈被采纳后可抵扣费用——让前线有经济动力把发现传递回后端，让后端有动力保持资产质量。

第三，反馈标准化： Delta提交的每条反馈必须包含发现名称、客户场景、当前本体状态、改进建议和通用性判断，Echo按通用性分三级评审——高通用性立即采纳，中等积累验证，高度个性化不纳入。

FDE人才发展

FDE职业路径会分化：一类成长为行业解决方案负责 人，一类转向产品负责人，一类进入客户成功或商业岗位，还有一类会创业

年轻人最现实的路径：先打牢工程底子，再通过客户项目积累业务理解，逐步从Delta走向Echo

实操全流程指南

本节以一个虚拟的ERP案例为例，把每个阶段、每个角色该做什么、产出什 么、怎么考核、利益怎么分配，做了详细示范。

案例背景：某AI平台公司决定深耕ERP行业。公司内部有一个5人的Echo团队（本体与平台能力建设），以及多支Delta团队（客户前线交付）。目标客户是中型制造企业，行业内潜在客户约 80 家。

第一阶段Echo团队的工作如下，更多的各阶段具体工作情况详见白皮书

未来展望

AI越来越强，人类FDE如何演化

如果AI自己就能完成越来越多部署工作，企业还需要人类FDE吗？

报告认为未来FDE会分化。技术执行层被AI大幅压缩，FDE的重心从"前线部署"转向"前线问题定 义者"和"组织转型顾问"。

未来的FDE不一定写更多代码，但要更懂业务、更懂组织、更懂如何指挥 Agent 群完成任务，并能验收质量、管理风险和推动客户采纳

短中期（2026年-2028年），FDE会从非标准化岗位走向建制化、生态化、度量化、区域化。

用户企业的启示

如果企业买了AI平台却使用率很低，IT部门搭了系统但业务部门不用，或者有明确业务场景却不知道从哪里开始，FDE就有价值

如果只需要基础翻译、总结或通用问答，标准 SaaS即可解决；如果已有强大内部技术团队，也可以自建。

与FDE合作时，客户侧必须让业务负责人参与，而不能只由IT部门对接

要预留磨合周期——一个生产级Agent往往需要数周甚至数月完成场景校准、数据清洗、权限配置、用户培训和组织接受

云厂商和平台方的建议

平台方有三种定位：只做平台、平台加原厂FDE、平台加伙伴生态。更合理的路径是"0 到 1 原厂、1到N伙伴"。

伙伴生态还需要POC风险共担机制，平台方可通过行业模板、技术支持、联合市场基金 或阶段性保底机制，降低高潜项目的前期试错成本。

平台型组织还应建立统一资源调度机制，统一入口、统一报价和统一反馈机制， 是FDE能力从个人经验变成组织能力的前提

AI创业公司的启示

AI创业公司做FDE，本质上是用重交付换行业数据和认知。前期投入大、回款慢，但如果能在垂直行业跑通本体层和复用机制，壁垒会很高。

创业公司不宜做"全行业通用AI"，更适合选择业务流程复杂、行业知识密 度高、头部平台覆盖不足的细分赛道