年薪百万的FDE，为什么火了？
CMKT咨询圈
最近，随着大模型和智能体火爆，有个技术工种也跟着火了，这就是FDE。
FDE是英文Forward Deployed Engineering的缩写，翻译过来就是：前端部署工程师。
其实，就是把工程师前置到客户现场，直接围绕客户业务结果写代码、接系统、做部署、做迭代的一种工程交付模式。
它不是传统解决售前，也不是普通售后交付，更不是项目经理。
它更像是：解决方案架构师+业务顾问+产品经理+交付负责人+实施工程师的混合体。
为了更直白的理解这个岗位，我贴一下鹅厂正在热招的这个具体岗位的JD，大家来琢磨琢磨。
怎么样，看完是不是有点懵逼，有点像研发直接走到前端做项目了，这个岗位的要求相当全栈。
在AI toB项目里，FDE好比是把大模型、智能体标准能力与企业业务场景连接起来的桥梁，让AI/模型/智能体能进入企业流程，并且稳定、安全、可量化地跑起来。
他们更现实：能不能降本？能不能提效？能不能少出幻觉？能不能进生产系统？
每个企业的数据格式、系统接口、组织权限、审批流程、业务口径都不一样。
模型本身再强，也不知道这家公司内部有效订单怎么算，风险客户怎么定义，合规红线在哪里。
聊天机器人回答错了、闹了乌龙，最多也就是体验不好，被骂两句。
Agent 如果接入企业系统，就可能真的去查数据、改表单、发邮件、提交审批、调用接口、触发任务，这些都是严肃场景，出错了可能就是真金白银的笋丝。
这时候就必须考虑权限、日志、审计、失败重试、人工确认、回滚机制、成本控制、模型评测。
真实项目里，可能同时用到 OCR、RAG、向量数据库、工作流引擎、权限系统、日志系统、BI、数据湖、ERP、CRM、OA、私有化模型、公有云 API。
FDE的角色，就需要有能力把碎片拼成一个能跑的系统。
FDE在客户现场会看到很多真实问题：产品哪里不好用，API哪些地方缺，甲方最在意哪些指标，哪些需求可以标准化。
这些东西如果能回流到产品团队，就能把项目经验变成下一次可复制能力。
传统售前当然也很强，尤其优秀的行业售前，业务理解非常深，但很多售前的边界在“方案/产品表达”。
FDE对传统售前的冲击在于：只会讲方案的人会越来越吃亏，能把方案做成可运行系统的人会越来越值钱。
过去，很多售前的主要技能是画架构图、讲案例、写方案、拉List、友商对比。
AI时代客户会问：你能不能接我的系统？能不能用我的数据试跑？能不能把智能体做出来？能不能给我一套验收指标？
到这里，大部分产品型售前都会懵逼吧，即便是软件行业售前，也会如坐针毡。
售前喜欢讲产品模块(即便是AI售前)：大模型平台、知识库、向量库、智能体平台、安全网关、私有化部署。
FDE 更关心流程：这个岗位每天做什么？哪个节点最耗时？哪类错误最多？哪些判断可以自动化？哪些动作必须人工确认？
客户买的一个可以融入现有环境的AI应用，并且获得明确的业务指标，比如：审批快一点、客服准一点、报表少出错、风控更及时。
很多售前讲AI，容易停留在RAG、Agent、多模态、微调这些小词上。
RAG的文档怎么切分？向量召回不准怎么调？Agent 调工具失败怎么办？模型幻觉怎么评测？权限怎么和企业账号打通？成本怎么控？
把客户业务语言翻译成工程任务，把工程限制翻译成客户能听懂的交付边界。
FDE做完一个项目，要思考哪些能力可以产品化：行业模板、Prompt 模板、评测集、连接器、Agent 工具包、数据模型、交付方法论。
FDE岗位爆火的本质，是AI时代ToB交付方式跟以前不一样了↓
现在：进现场，懂业务，写代码，接系统，跑指标，沉淀能力。
所以对传统IT售前来说，FDE是一个很明确的转型方向，也是一个巨大挑战。
如果你觉得转型路径太陡峭，也不用太慌，毕竟AI发展很快，正在一步步技术平权，连副局长都能手搓救灾app，售前把自己搓成FDE又有什么不可能。
另外，在FDE这个大分支里，还有个细分岗位叫做FDE Consultant，对“动手能力”要求相对低一点，大家不妨先对齐这个岗位的需求↓
AI正在以周甚至以天为单位飞速进化，祝大家都能保持敏感，跟上变化。
