什么是 FDE：一个嵌入客户现场的"产品探索者"
AI 都能写代码了，为什么最值钱的工程师反而跑到了客户现场？这篇文章聊聊一个正在悄悄火起来的新角色——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 和售前、交付、售后的边界
很多人第一次听 FDE 这个概念，会问："那他和售前有什么不一样？"
售前做的事：看需求、做方案、做 POC、讲 PPT、投标。
FDE 做的事：进现场之后，负责任何一个 AI 产品经理都做不了的事——把 demo 跑成生产系统。
用一个流程图来拉齐概念：
flowchart LR
A[售前<br/>方案 + POC] --> B[FDE 进场<br/>诊断真问题]
B --> C[场景验证<br/>跑通最小闭环]
C --> D[现场施工<br/>填 gap / 写生产代码]
D --> E[上线验收<br/>上生产 + 指标达标]
E --> F[沉淀变现<br/>模块产品化]
style A fill:#e1f5fe,stroke:#0288d1
style B fill:#fff3e0,stroke:#f57c00
style C fill:#fff3e0,stroke:#f57c00
style D fill:#fff3e0,stroke:#f57c00
style E fill:#fff3e0,stroke:#f57c00
style 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 需要的能力其实是四维的：
quadrantChart
title FDE 能力四象限
x-axis "技术深度" Low --> High
y-axis "业务理解" Low --> High
quadrant-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 现场交付，欢迎在评论区交流你的经验和踩过的坑。
关于作者：AI 交付领域实践者，持续更新 FDE 一线实战经验。
系列目录：《FDE 业务落地实战》
