什么是 FDE：一个嵌入客户现场的"产品探索者"

一、AI 时代的一个悖论

2024 年之后，技术圈最热的话题大概就是"AI 替代程序员"。Cursor、Copilot、Devin 轮番登场，每出一个新工具，就有人计算又有多少工程师要失业。

但与此同时，另一群人正在成为行业里最抢手的资源。他们不是在办公室里写代码，而是在客户现场和业务方一起开会、一起调试、一起解决问题。

这群人叫 FDE（Field Delivery Engineer，现场交付工程师）。

一个反直觉的现象：AI 写得越多，FDE 越贵。

为什么这么说？AI 确实把“代码怎么生成”这件事往前推了一大步，但“这段代码究竟该生成什么”，它依然无能为力。

后一个问题，靠坐在办公室里翻需求文档，通常摸不透。真正要弄明白，得贴着客户的业务现场去看。

• 看他们怎么流转流程
• 听他们怎么吐槽现有系统
• 必要的时候，陪着他们拿起笔，在纸上把真实的数据流向一笔一笔画出来

二、FDE 到底是什么？

FDE 的全称是 Field Delivery Engineer，中文叫现场交付工程师。但这个翻译其实很模糊，它容易让人联想到"驻场开发"或者"外包派驻"。

FDE 的真正定义应该更精确。

核心区别在于交付的不是代码，而是效果。

一张表说清楚 FDE 和传统驻场/外包的区别：

维度	传统驻场/外包	FDE
核心目标	按人天交付代码	按效果交付业务价值
工作方式	接需求→写代码→提交	诊断→验证→施工→沉淀
决策权	几乎为零，听甲方安排	有一定自主权，推动场景选择
产出物	代码、文档	上生产的系统 可复用的产品模块
对公司的价值	按人天收费，线性增长	反哺产品，形成壁垒

换句话说，FDE 不是"高级人力外包"。

它是公司嵌入客户侧的"产品探针"。

三、FDE 和售前、交付、售后的边界

很多人第一次听 FDE 这个概念，会问："那他和售前有什么不一样？"

售前做的事：看需求、做方案、做 POC、讲 PPT、投标。

FDE 做的事：进现场之后，负责任何一个 AI 产品经理都做不了的事——把 demo 跑成生产系统。

用一个流程图来拉齐概念：

flowchart LRA[售前
方案   POC] --> B[FDE 进场
诊断真问题]B --> C[场景验证
跑通最小闭环]C --> D[现场施工
填 gap / 写生产代码]D --> E[上线验收
上生产   指标达标]E --> F[沉淀变王见
模块产品化]style A fill:#e1f5fe,stroke:#0288d1style B fill:#fff3e0,stroke:#f57c00style C fill:#fff3e0,stroke:#f57c00style D fill:#fff3e0,stroke:#f57c00style E fill:#fff3e0,stroke:#f57c00style F fill:#e8f5e9,stroke:#388e3c

流程图注解：FDE 核心交付链路

• 售前（蓝色）：负责方案和 POC，拿到合同后退出主舞台。
• FDE 进场（橙色）：从诊断真问题开始，到上线验收结束——这四步是 FDE 的核心战场。
• 沉淀变王见（绿色）：单个客户交付完成之后，将成果抽象成可复用的产品模块——这是 FDE 和传统交付的最大区别，也是价值复利的关键。

再回到和传统角色的对比：

• 售前负责"让人想买"
• 传统交付负责"把活干完"
• 售后负责"坏了修"
• FDE 负责的是中间那个巨大的真空地带——"让东西真的用起来，并且用出效果"

这个东西在传统企业软件里叫"实施顾问"或者"解决方案架构师"，但 AI 项目有几个特性让传统角色不够用了：

• AI 项目的需求是模糊的——客户说不清楚，你也猜不准。
• AI 项目的效果是不确定的——不像 ERP，上了就是上了，AI 的准确率需要持续调优。
• AI 项目的壁垒是私有数据——通用大模型谁都有，但客户的数据只有你见过。

这三件事，都不是会议室里能解决的，必须在现场。

四、典型的 FDE 一天：在现场到底做什么？

说概念容易飘，我们直接来看一个真实 FDE 的典型日常（以金融行业为例）：

• 09:00 — 和客户业务团队开早会。重点不是汇报进度，而是把昨天发现的三个 bad case 当场掰开说清楚。

  这些情况在业务侧到底算不算真正的问题，要现场确认。比如，AI 风控模型误判了某一类交易，业务方给出的反馈很直接——“这一类误判还在可接受容忍范围内，但另一个问题你们必须尽快改掉。”

• 10:30 — 在客户给的测试环境里跑新的 prompt 策略。不是从零写代码，而是用 AI 工具辅助迭代 prompt chain，在客户的真实数据上验证。

• 13:00 — 和客户的 IT 安全团队沟通数据合规。FDE 不是自己决定"能不能用"，而是把公司的安全方案翻译成客户的安全语言，推动审批。

• 15:00 — 和后方产品团队同步：今天在现场发现客户有一个需求是通用的，现有产品没有覆盖。

  "我建议你把这个 feature 加到下个版本，我已经帮你测过三个客户的场景了。"

• 17:00 — 写当天的交付日志：今天验证了什么、排除了什么、明天要做什么。

  这不是汇报给领导看，而是沉淀成"这个行业的 FDE 操作手册"。

你会发现，FDE 一天中真正写代码的时间不超过 30%。

更多的时间在：

• 理解需求
• 验证假设
• 沟通对齐
• 沉淀经验

五、FDE 的核心能力模型

基于上面的日常工作，FDE 需要的能力其实是四维的：

quadrantCharttitle FDE 能力四象限x-axis "技术深度" Low --> Highy-axis "业务理解" Low --> Highquadrant-1 "全能型 FDE"quadrant-2 "业务专家型"quadrant-3 "待成长"quadrant-4 "技术专家型""售前": [0.3, 0.8]"传统交付": [0.7, 0.2]"FDE": [0.65, 0.75]"纯研究": [0.9, 0.1]

图表注解：

• 售前擅长业务沟通（高业务、中技术），但在工程落地层面不足。
• 传统交付擅长写代码（高技术、低业务），但对业务场景理解偏弱。
• FDE 在两个维度上都要求中高水平——不需要是顶级的算法研究员，但必须能改模型策略；不需要是行业 VP，但必须能和业务方在同一层面讨论问题。
• 这个交集区间在市场上非常稀缺，所以好的 FDE 现在极其昂贵。

六、为什么 FDE 正在成为 2B AI 公司的核心竞争力

最后回答一个本质问题：为什么 2B AI 公司必须要有 FDE？

答案藏在 AI 商业化的价值链里。一个 AI 产品从实验室到客户现场，需要走过：

模型能力 → 工程化封装 → 行业适配 → 场景落地 → 持续迭代

前两步可以在办公室完成。后三步，每多走一步，对现场的依赖就指数级增加。

这解释了一个现象：很多拿了巨额融资的 AI 公司，技术很强，demo 很炫，但就是做不出一个真正在客户现场跑通的项目。

不是技术问题，是缺少那个能把 demo 翻译成生产系统的人。

FDE 就是这个翻译者。

写在最后

FDE 不是一个新发明的岗位名称——在很多公司它可能叫"解决方案架构师"、"交付专家"、"资深实施顾问"。

但在 AI 时代，这个角色的权重正在发生根本性的变化：

从"辅助交付"变成"核心交付"。

因为 AI 产品的最大成本不在研发，在于让客户用起来。

而这件事，没有捷径，只能现场作战。

下一篇文章，我们聊聊 FDE 和咨询、外包、驻场到底有什么区别——为什么 FDE 不是高级外包，而真的是公司的核心资产。

本文是《FDE 业务落地实战》系列第一篇，欢迎关注后续更新。

如果你也在做 AI 现场交付，欢迎在评论区交流你的经验和踩过的坑。