— 2026.10 · FDE

FDE 浪潮里的一线视角：
当工程师走进客户现场

过去一年，FDE（Forward Deployed Engineer，前沿部署工程师）忽然成了 AI 圈的热词，招聘页上随处可见。我自己有相当一部分时间，是在客户的会议室、机房和业务部门里度过的。身处其中，我对这股浪潮的感受，和外面的讨论不太一样。

一个老角色，为什么现在又火了

FDE 并不新鲜。Palantir 很早就把工程师直接派驻到客户那里，用平台能力去解决对方最具体的问题。这个模式在大模型时代重新被重视，背后是一道越来越明显的落差：模型能力几乎每个季度都在进步，可企业里真正稳定跑起来的场景，远远没有跟上。

落差卡在“最后一公里”。业务流程该怎么拆，散落各处的知识怎么整理，数据从哪里来，准确率由谁说了算，上线以后谁来运营，这些问题没有标准答案，坐在办公室里也想不出来，必须有人到现场，和业务人员一起把它们一条条理清。模型厂商、云厂商和解决方案公司纷纷组建 FDE 团队，原因就在这里。在内地和港澳的政企市场，客户对“有人在现场”的期待尤其强烈。

它和驻场外包差在哪里

我听到最多的质疑是：这不就是换了个名字的驻场开发？说实话，从外表看确实很像，都是工程师坐在客户那里干活。差别在于交付的东西。驻场外包交付的是功能，按需求清单做完就算结束；FDE 交付的是业务结果，还要把现场学到的东西带回去，变成下一次可以复用的资产。

一个好的 FDE 到了现场，往往先花不少时间弄清楚业务人员每天到底在做什么，再把模糊的诉求收敛成可验证的场景，用平台快速搭出原型，拿真实数据去跑。项目结束后，还会把这次踩过的坑整理成调研提纲、规范、模板和评测集，交给下一个项目和产品团队。少了这最后一步，FDE 就退化成了驻场外包，而且是一种很难规模化的外包。

两种做法拉开的差距，放在单个项目里看不太出来，要拉长到几个项目才看得清楚：

这份工作需要什么样的人

做下来，我觉得 FDE 需要三种能力同时在线。第一是听得懂业务，能和投研、合规、法务的同事聊到一块去，知道哪些环节值得自动化，哪些其实不值得。第二是扎实的工程能力，能独立把原型推进到可上线的系统，懂知识库、检索、工作流和评测，也懂企业内网、权限和安全那一套。第三是交付和沟通，管得住客户预期，能把技术方案讲给业务负责人甚至董事长听，出了问题也扛得住。

这三种能力，过去分散在销售、售前、项目经理和工程师身上，现在要集中到一个人或一个小团队里。岗位难招，人也容易累，都是这个原因。

热闹背后的几个隐忧

我对 FDE 的前景是乐观的，但有几件事一直放在心上。

一是太依赖人。如果每个项目都靠高手到现场“救火”，规模一上来，质量就会参差不齐，成本也降不下来。二是经验被锁在个人身上。现场积累的判断力如果没有沉淀成文档和工具，人一走，能力也就跟着走了。三是被当成万能补丁。产品本身没打磨好，就派 FDE 去填坑，短期能救急，长期看对产品和团队都是消耗。

让这件事可持续

在实际项目里，我们慢慢摸索出几种做法。交付资产尽量标准化，调研提纲、场景定义模板、技术规范、评测集和上线检查清单都做成标准件，新人到了现场也有章可循。能力转移写进合同，项目目标不只是交付一套系统，还包括客户团队能自己维护知识库、调整工作流、发起新场景。现场发现的共性问题，定期反馈给平台和产品，让下一次交付更轻。至于怎么衡量 FDE 的价值，我们看准确率、处理时长、人工复核比例这些业务指标，而不是上线了多少个智能体。

给想走这条路的工程师

如果你是工程师，对 FDE 感兴趣，我的建议很朴素：多去现场，少在会议室里想象业务；把每个项目都当成一次沉淀方法的机会；手上的功夫不要丢，同时练习把技术讲清楚。AI 让写代码越来越容易，真正稀缺的，是能把技术放进真实业务、并让它持续产生价值的人。

这股浪潮过去以后，留下来的大概是两样东西：可以被复制的方法，和能在现场做出判断的人。我希望自己两样都能攒下一些。