FDE 是 Forward Deployed Engineer 的缩写，中文一般译作「前置部署工程师」。它指的不是某一种技术岗位，而是一种交付方式：把工程师直接派驻到客户的业务现场，和客户一起把系统做出来，并且按业务结果验收。
这个角色最早在硅谷的数据公司里成型。逻辑很简单：当软件要解决的问题高度依赖客户自己的业务细节时，坐在自己办公室写代码，写出来的东西一定不对。
一句话说清它和外包的区别
传统外包是「你给我需求，我报价开发」；FDE 是「我进你的现场，我们一起找出值得做的需求，再由我把它做出来，并且交给你的人」。
前者卖的是工时，后者卖的是结果。这个差别决定了三件事：需求谁来找、风险谁来担、以及项目结束之后能力留在谁手里。
三种交付方式的差别
| 维度 | 买标准产品 | 传统项目外包 | FDE 驻场交付 |
|---|---|---|---|
| 需求从哪来 | 客户自己梳理，去适配产品 | 客户写成需求文档 | 工程师到现场和业务方一起找 |
| 谁承担落地风险 | 客户 | 基本由客户承担 | 服务商，按业务指标验收 |
| 交付物 | 账号和功能 | 一套系统 | 系统 + 跑起来的流程 + 被教会的人 |
| 离场之后 | 继续付订阅费 | 改一个字都要付钱 | 客户团队能自己维护和扩展 |
为什么 AI 项目特别需要这种模式
不是所有项目都需要驻场。但 AI 类项目有三个特点，让远程交付的成功率明显更低。
一、需求在会议室里问不出来
AI 项目最值钱的部分，往往藏在客户自己也描述不清的环节里。坐在会议室问需求，问出来的通常都是「能不能做个知识库」这种大而空的答案；到现场待三天，才会发现真正卡住人的是每天要手工比对两百张送货单。
差别不在于谁更聪明，而在于信息密度。现场有噪声、有例外、有人绕过去的土办法，这些才是需求的真实形状。
二、数据和系统都在现场
做 AI 项目，模型能力早就不是瓶颈。真正的瓶颈是两个：能不能拿到干净的数据，能不能打通那个十年前上线、没有文档、原厂已经不管的老系统。
这两件事离开现场做不了。数据字典在某个工程师的脑子里，接口权限要走三道审批，字段含义要靠请一顿饭问出来——这就是真实情况。
三、验收只能用业务指标
AI 的能力是概率性的。同样一个识别任务，准确率 92% 和 95% 在演示时看不出区别，在生产线上一个是可用一个是不可用。
如果用「功能是否实现」验收，双方一定会扯皮；用「人工处理量下降多少」「平均响应时间缩短多少」验收，才有唯一答案。而业务指标只有在现场才测得准。
一个 FDE 团队通常由谁组成
- FDE 交付负责人：统筹驻场全流程，对业务结果负责，通常也是客户唯一的对接人
- 算法工程师：模型选型、微调、RAG 检索链路
- 后端架构师：系统集成、数据打通、权限与稳定性
- 前端工程师：业务界面和驾驶舱，让一线愿意用
- 交付经理：进度、质量、风险
小项目里一个人可以兼几个角色，但「对业务结果负责」这个角色不能缺。缺了它，项目就会退化成按功能清单交付。
什么情况下不该用 FDE
说实话，有两种情况不该花这个钱。
第一种，标准产品就能解决。开票、考勤、报销这类流程高度标准化的需求，买现成 SaaS 更便宜也更快，没必要为了「定制」而定制。
第二种，业务问题还没想清楚，也不打算投入时间对齐。FDE 的核心动作是「和客户一起找问题」，如果客户方没有能拍板、能投入时间的人，驻场会变成一个人在办公室里猜。
怎么判断一个 FDE 服务商靠不靠谱
看四条就够了，都不需要技术背景。
- 敢不敢先做小验证。愿意先用两周做一个小范围验证、再谈整体合作的，通常比一上来就报整体方案的更靠得住。
- 验收条款是不是业务指标。拿「功能清单」当验收标准的，本质还是外包；拿「某个岗位每天的工时下降多少」当标准的，才是对结果负责。
- 有没有能力移交环节。项目结束时，客户团队能不能自己改提示词、自己加知识文档、自己看监控。如果这些都要回头找服务商，那能力并没有留下来。
- 交付记录能不能追问到数字。问一句「上一个项目，上线前和上线后分别是什么数」，答得出来和答不出来，差别很大。
小结
FDE 不是一个新鲜概念，它只是把一件本来就该做的事说清楚了：软件要解决的是业务问题，所以做软件的人必须离业务问题足够近。
对制造、外贸、能源这类流程复杂、系统林立的行业来说，这个「足够近」不是修辞，是物理距离。
如果你正在评估一个 AI 项目该怎么做，可以先看我们的 FDE 驻场交付服务，或者直接约一次 30 分钟的场景沟通。