FDE 真正该较真的，是项目结束留下了什么
FDE 不是又一个岗位名，而是乙方把 AI 真正接进甲方业务的一种交付方式——它的成色，看项目收尾时留下了什么。
在一个项目上，客户侧有位负责人跟我闲聊：「你们派的那个 FDE，比我们自己的团队还摸得清业务门道。」
这话听着是夸奖，但我不太想要。因为如果 FDE 只是「比客户更懂客户的驻场实施」，那它再熟练，也还是高端外包：人一撤，经验跟着走，客户手里什么都没留下。
带着团队把工程师往客户前线派，做的都是同一件事——把 AI 从 Demo 接进真实业务。跑过的项目不算多，但几个现象已经反复撞到我面前：FDE 这个词被用得太泛，真正该较真的不是「派了谁去」，而是「项目结束留下了什么」。
上面这些，是我在客户前线跑出来的观察，也参考了腾讯研究院 2026 年 8 月那份《FDE模式行业观察与实践》的调研。说句实在话，FDE 这个概念还很新，我们也是边干边摸索，谈不上什么成熟体系，只是这段时间攒了一些实践心得，加上我个人对公开报告和同行交流的调研与思考。观点来自我和 CheersAI 团队的实战复盘，已做脱敏处理，不对应任何一家客户的完整情况。
报告里有个数字我一直记着：60% 的企业 AI 尝试仍停留在试点阶段。瓶颈不在 Demo 能不能跑，而在怎么接入系统、嵌入流程、满足合规、产生可衡量的业务价值。换句话说，从 Demo 到生产，中间横着一条很长的沟——这条沟，就是 FDE 被反复提起的真正背景。
我在前线见到的两种 FDE
FDE，全称 Forward Deployed Engineer，字面是「前线部署工程师」。我在前线接触下来，最容易被字面带偏的，就是把它理解成「更懂 AI 的驻场实施」——人长期待在客户现场，把系统装上、接好、调通，项目验收后转场。
这套活儿我团队也在干，但它只说中了外壳。我在好几个项目里反复看到同一个结局：名字叫得响，最后做成了换壳的高端外包。
真正分水岭在第三步：项目结束后，现场经验能不能带回来，沉淀成可复用的能力。少这一步，FDE 就退化为换了个名字的高端外包；多这一步，它才变成我愿意拿来要求团队的东西。
过去这段时间，我越来越确信一件事：FDE 的本质不是岗位，而是一种前线学习机制——交付与学习能不能同时发生。
一份报告，把我看到的现象说透了
我在前线反复撞见的现象，后来在腾讯研究院那份报告里被一个词点破：双向蒸馏。
为什么有的团队做完一个项目只是多了一个客户，有的团队做完一个项目多了一套能力？报告概括得准：区别在于经验往哪边流。
第一层是对客户的蒸馏。 把散落在员工脑子里的业务经验、流程规则、隐性知识，转化成 AI 能调用的知识库、工作流、标准作业流程和具体的业务应用。客户因此得到更稳定、更可复制的执行能力。我在两家客户身上都验证过：同样一套审批流程，蒸馏成 SOP 后，新人上手快了一截。
第二层是对厂商自身的蒸馏。 把在一个项目里摸到的行业知识、系统接口、测试方法、场景模板和失败案例，沉淀成 Skill、模板、测试集和产品能力。厂商因此能在同类场景里越做越快、越做越深。这恰恰是我们团队这段时间慢慢变轻的原因。
承载这两层蒸馏的共同载体，是「本体层」——把不同系统里同一个业务对象的不同字段名、不同编码，翻译成统一的业务语言。从一家客户总结出来的本体，有机会复制到同行业另一家客户：不是把数据拿去训练，而是把行业知识沉淀成可复用的抽象。
两层蒸馏叠起来，过去那种很重、很贵、强依赖高端团队的模式，才有可能在更多行业跑得通。 这也是我在前线越来越看重本体层的原因。
一张表，看清真假 FDE
判断一个团队是不是真在做 FDE，报告给了一块「试金石」，和我自己在前线用的其实一个意思：不看它叫不叫这个岗位名，而看项目结束后留下了什么。
| 项目结束后留下了什么 | 它是什么 | | --- | --- | | 只留给客户一个系统 | 外包 | | 带回一些经验，但没法复用 | 项目制交付 | | 沉淀为 Skill / 模板 / 产品能力 | FDE | | 沉淀后显著降低下一个客户成本 | 可规模化的 FDE |三个前提决定这块试金石能不能通过：客户值不值得深耕（需求真实、业务方参与）、项目能不能沉淀资产（流程有共性、数据可复制）、公司有没有机制复用（头部经验能传递到中腰部）。三项都不满足，就是高端外包；三项都满足，才可能是行业知识的「蒸馏机器」。
一个很实在的辅助判断，我在前线一直用：如果你的第一个客户要 10 个人月，做到第十个同类客户仍然要 10 个人月，那这个模式就没有跑通。OpenAI 前首席研究官 Bob McGrew 在公开访谈里也强调过类似的度量原则——衡量两件正确的事：交付的成果价值，以及产品杠杆（单位价值对应的现场投入应该下降）。
我们复盘过的项目，也是这条分水岭
在我们自己复盘过的企业 AI 落地项目里，这条分水岭同样清晰。能不能把现场经验沉淀成可复用的 Skill 和模板，是我判断一个交付团队是不是真 FDE 的试金石。 只交付一个系统、人一走经验就散的，做十个项目还是十个孤立项目；能在每个项目里把共性抽出来、让下一个项目少踩一遍坑的，才是在积累「交付复利」。
这也是为什么我说，企业 AI 落地难的不是模型够不够强，而是交付与学习能不能同时发生——把一次项目的经验，变成组织长期的能力。
我自己在前线用来快速判断的三句话
落到自己团队，我一般会用下面三句话快速判断：
- 看收尾：一个项目结束，留下的是「一个系统」，还是「一套能复用的东西」？
- 看杠杆：做第二个、第十个同类项目，现场投入是不是明显下降？
- 看归属：沉淀下来的经验，是锁在某几个人脑子里，还是变成了团队和平台能调用的资产？
三条都答不上来，那它大概率还停留在外包或项目制；三条都沾边，说明你们已经在做真正有价值的 FDE。
不过也要说清楚边界：FDE 不是所有 AI 项目的标准答案。它最适合业务复杂、流程有共性、且值得长期深耕的场景；对一次性的小尝试硬套 FDE 框架，反而会增加交付负担。先判断值不值得沉淀，再谈怎么沉淀。
这也是这个系列想一直往下聊的主线：AI 落地难的不是模型，而是谁在把前线经验变成组织能力。下一篇，我聊一个反常识的问题——为什么 FDE 最后很容易做成外包。
这篇文章里的方法，我整理成了可直接套用的模板（含字段说明和填写示例），放在知识星球「球者AI进化论@CheersAI」，进星球搜关键词即可自取。星球的定位是「给已经在推 AI 的团队一份能落地的工具箱」——只放干货，不做广告群。 对应星球帖（FDE 试金石自评表）：https://wx.zsxq.com/group/51115518555144/topic/45548855452428488