最近我在重新思考 FDE 这个岗位。

很多人第一次听到 FDE，通常会把它理解成一种“更高级的交付工程师”：

既懂技术，又懂客户；既能写代码，又能做方案；能进现场，能快速搭 Demo，也能把客户的问题一路推进到上线。

这个理解不能说错，但它只看到了 FDE 最表面的那一层。

真正往下拆，会发现 FDE 的核心并不在“这个人有多全能”，而在于：

公司是否愿意用一种更高成本、更高不确定性，但更接近真实业务的方式去做产品。

所以我现在更倾向于把 FDE 理解成一种公司运行机制，而不只是一个岗位。

如果要判断一个 FDE 岗位到底是不是真的 FDE，我觉得至少要看四个方面：

机制、成本、现场实施，以及公司是否真正支持 FDE。

一、FDE 的核心机制，不是交付，而是“现场探索 → 产品收敛”

传统软件项目的逻辑通常比较清晰：

需求
↓
设计
↓
开发
↓
测试
↓
交付

问题在于，这套流程有一个默认前提：

客户知道自己要什么，公司也知道应该做什么。

但 AI 项目越来越多地打破了这个前提。

客户可能会说：

我要一个知识库。

但真实问题可能是：

信息散落在不同系统；
员工不知道应该去哪里找；
数据权限复杂；
老员工掌握大量隐性流程；
不同部门之间存在协作和利益边界；
即使技术做好了，用户也未必愿意使用。

这时候，“知识库”只是水面上的需求。

真正需要解决的问题藏在水面以下。

所以 FDE 的第一项能力不是开发，而是：

找到真正的问题。

我很喜欢用两个词来理解这个过程：

Echo：找到真正的问题

Echo 阶段不是简单做需求访谈，而是进入真实业务现场，去理解：

用户实际怎么工作；
哪些流程没有写进需求文档；
谁真正掌握数据；
谁拥有实际决策权；
哪些问题看起来重要，但其实并不产生价值；
哪些问题客户自己都没有准确表达出来。

这一步解决的是：

“我们到底在解决什么？”

Delta：快速把问题变成可运行方案

找到问题后，也不是马上做一个完整系统。

更合理的方式是：

先快速做出一个可运行、可验证价值的最小方案。

比如：

一个脚本；
一个简单 Workflow；
一个临时 Agent；
一套新的 RAG 方案；
一个新的文档解析能力；
一个轻量级内部工具。

这个阶段追求的不是“代码完美”，而是：

尽快验证这个方向到底有没有价值。

因此一个完整 FDE 流程更像：

进入现场
↓
理解真实工作方式
↓
发现真正问题
↓
快速构造方案
↓
让用户真实使用
↓
观察是否产生价值
↓
修正
↓
跨场景验证
↓
沉淀为产品能力

这里最重要的一步其实是最后一步：

沉淀为产品能力。

如果一个问题在项目 A 被解决了，到了项目 B 又重新做一遍，再到项目 C 继续手搓，那这并不是一个健康的 FDE 体系。

真正有价值的 FDE 应该形成这样的循环：

项目 A 发现问题
↓
现场验证解决方案
↓
形成通用能力
↓
产品团队吸收
↓
项目 B 直接复用
↓
FDE 去解决更高级的问题

所以我认为：

FDE 的价值不在于解决了多少问题，而在于解决的问题能不能产生复利。

二、为什么完整 FDE 一定是一种高成本模式

很多公司喜欢 FDE 这个概念，是因为它听起来非常高效：

派一个很强的人去现场，问题不就解决了吗？

但实际上，真正完整的 FDE 往往不是一种低成本交付方式。

恰恰相反，它非常贵。

而且这种成本不仅是工资。

1. 人员成本很高

一个成熟 FDE 通常需要同时具备很多能力：

软件工程；
AI / 数据；
系统架构；
需求分析；
业务理解；
沟通谈判；
产品判断；
快速原型；
项目推进；
现场排障。

这种人本身就属于比较昂贵的人力。

而且他的时间利用方式和普通研发完全不同。

普通研发可能大量时间花在：

设计、编码、测试。

而 FDE 可能是：

客户沟通
+
业务分析
+
现场排障
+
原型开发
+
跨部门协调
+
数据接入
+
方案设计
+
产品反馈

看起来什么都做了，但纯编码时间反而未必很多。

所以从公司短期财务视角看，FDE 并不便宜。

2. 驻场和差旅本身就是成本

真正深入业务，很多时候线上会议是不够的。

因为很多东西客户自己也说不清楚。

例如：

真实的工作流程；
谁在绕过哪些流程；
谁实际拥有权限；
哪些系统名义上在使用，实际上没人用；
哪个部门真正推动项目；
哪个部门只是表面配合。

这些信息往往必须现场才能观察到。

因此 FDE 天然伴随着：

驻场；
差旅；
酒店；
补贴；
人员管理；
长期出差带来的流失风险。

这也是一笔很高的隐形成本。

3. 更大的成本是：公司必须接受部分项目“不赚钱”

这一点我觉得是判断一个公司到底懂不懂 FDE 的关键。

如果 FDE 的目标是探索未知，那么结果一定不是：

10 个项目
=
10 个成功项目

更可能是：

项目 A → 找到强需求
项目 B → 方向一般
项目 C → 完全失败
项目 D → 发现新产品机会
项目 E → 做出来但没人用

这才符合探索的客观规律。

所以真正的 FDE 体系必须允许：

部分现场部署被当作研发投资，而不是标准服务订单。

这意味着管理层不能同时要求：

所有项目都赚钱；
所有项目都准时验收；
所有客户都满意；
所有需求都要实现；
所有方案都必须复用；
同时还要求持续探索未知。

这几个目标之间本身就是冲突的。

如果公司要求：

每个项目都必须立即达到标准 SaaS 毛利。

那么 FDE 最后一定会变成传统交付。

因为没人敢失败。

三、FDE 现场真正难的，往往不是技术，而是组织

很多人谈 FDE，容易把重点放在：

技术能力要强。

这当然没问题。

但实际进入企业现场后，会发现真正最复杂的问题经常不是代码。

而是：

人、权限、流程和利益。

1. 需求清单无法表达真实业务

一个需求文档可能写：

新增某某功能。

但你真正去现场后，可能发现：

这个功能之所以一直没做好，并不是技术难。

而是它跨了三个部门。

部门 A 掌握数据。

部门 B 掌握业务流程。

部门 C 负责最终审批。

于是一个简单的技术集成，背后其实是组织边界。

这时候如果只盯着接口和功能，会一直觉得：

为什么这么简单的事情推进这么慢？

但 FDE 必须看到更深一层：

技术接入本身就在改变组织的权力关系。

2. 数据集成经常不是技术问题

技术上：

API
↓
鉴权
↓
拉数据

可能一天就能做完。

但真实世界里，问题可能变成：

谁允许你调用这个接口？

谁批准数据跨部门流动？

谁为数据泄露负责？

如果系统上线以后出问题，责任算谁的？

于是你会发现：

“能不能拿到数据”很多时候不是工程问题，而是组织政治问题。

所以 FDE 不能只会看系统架构。

还必须理解：

正式权力；
非正式权力；
部门利益；
决策链；
推动者；
阻力来源。

3. 做出来不代表会被使用

这是 AI 项目一个非常常见的问题。

我们经常会讨论：

准确率；
延迟；
并发；
Token；
RAG；
Agent；
模型能力。

但最终还有一个更现实的问题：

用户到底用不用？

一个技术效果很好的系统，也可能完全没人使用。

原因可能是：

原有流程更顺手；
新系统增加了工作；
用户不信任结果；
系统改变了某些人的权力；
使用后责任归属不清；
没有激励。

所以 FDE 要解决的不是单纯：

怎么把系统做出来。

而是：

怎么让系统嵌入真实工作流程。

四、为什么真正的 FDE 往往不是一个人，而是一支小队

这是我觉得国内很多 FDE 实践特别容易走偏的地方。

理想中的 FDE Team，可能是一个小型跨职能团队：

FDE Lead
+
AI / Data Engineer
+
Software Engineer
+
Product / Design
+
必要时 Infra / Security

它其实很像：

把一支小型创业团队部署到客户内部。

团队可以快速完成：

发现问题
↓
判断价值
↓
设计方案
↓
开发原型
↓
接入数据
↓
部署
↓
验证
↓
再迭代

这种机制才有资格承担“端到端”。

但现实中很多公司学成了：

一个 AI 工程师
↓
长期驻场

然后要求这个人负责：

需求；
方案；
产品；
Python；
后端；
RAG；
Agent；
OCR；
部署；
测试；
运维；
客户沟通；
验收。

公司会把这种情况描述成：

端到端 Ownership。

但我觉得必须区分两个概念：

端到端 Ownership

和

端到端背锅

完全不是一回事。

真正的 Ownership 意味着：

你拥有目标，同时拥有调动资源的能力。

如果只有责任，没有资源，那么所谓 FDE 很容易退化成：

高能力驻场救火队。

五、判断公司是否真的支持 FDE，要看这三种“代价”愿不愿意付

如果一家公司真的希望做完整 FDE，我认为至少必须接受三种代价。

第一种代价：产品权力

FDE 在现场发现：

现有平台能力不够。

那么公司是否允许：

临时创造新的能力？

更进一步：

这些新能力是否有机会推动核心产品改变？

如果现场只能说：

“产品现在就是这样，你自己想办法适配。”

那么这个 FDE 实际上没有产品权力。

结果就会变成：

产品能力不足
↓
现场魔改
↓
产生项目分支
↓
下一个客户继续魔改
↓
维护成本越来越高

第二种代价：资本投入

如果每一次部署都必须赚钱，那就很难探索真正的新问题。

完整 FDE 必须允许：

一部分现场项目本质上属于研发。

它带来的价值不是当期利润，而可能是：

新产品方向；
新平台能力；
新行业 Know-how；
新交付模型；
新的可复制方案。

所以 FDE 本身更像：

把部分研发预算前移到客户现场。

第三种代价：组织容忍

真正探索未知一定会产生：

重复开发；
局部失败；
不同方案竞争；
项目间差异；
临时方案；
看起来“不够标准”的代码。

管理层必须允许这些东西暂时存在。

因为真正合理的过程可能是：

现场 A → 方案 A
现场 B → 方案 B
现场 C → 方案 C
↓
真实使用竞争
↓
方案 A 被大量采用
方案 B 边缘使用
方案 C 失败
↓
产品团队收敛 A

这其实是一种：

先允许分散创新，再进行集中收敛。

如果公司在探索刚开始时就要求：

所有人必须使用统一标准方案。

那么表面看管理更规范了。

但同时也可能把真正的创新空间杀死。

六、FDE 最终应该形成什么样的公司飞轮

我认为一个健康的 FDE 组织应该形成这样的飞轮：

高层提出方向
↓
多个现场自主探索
↓
真实用户验证
↓
有效方案被其他团队采用
↓
形成事实上的最佳实践
↓
产品团队收敛
↓
进入核心平台
↓
平台能力增强
↓
下一轮 FDE 解决更难的问题

注意这里有一个特别重要的变化：

FDE 解决的问题应该越来越难，而不是一直重复解决同一类问题。

例如：

第一年：

解决文档解析。

后来文档解析产品化。

第二年：

解决跨系统知识协同。

再产品化。

第三年：

解决复杂业务 Agent。

这才说明组织在成长。

如果三年以后还是：

项目 A 修 OCR
项目 B 修 OCR
项目 C 还是修 OCR

那虽然工程师经验越来越丰富，但公司的系统能力其实没有增长。

七、为什么很多公司的 FDE 最后会变成“高级驻场开发”

我觉得原因其实很简单。

因为很多公司只学到了 FDE 最直观的部分：

驻场；
强工程师；
快速开发；
客户共创；
一个人解决复杂问题。

却没有学真正昂贵的部分：

产品权力；
独立资源；
允许失败；
允许重复探索；
产品团队回收能力；
组织协同；
长期研发投入。

于是就形成了一种非常典型的状态：

FDE 越来越强
↓
能解决的问题越来越多
↓
公司越来越依赖 FDE
↓
所有困难项目都找 FDE
↓
FDE 越来越忙

但：

公司核心产品能力
并没有明显提升

这其实是一个危险信号。

因为：

一个真正健康的 FDE 体系，应该不断减少组织对个人英雄主义的依赖。

而不是不断强化这种依赖。

八、我现在怎么理解 FDE

如果要让我用一句话重新定义 FDE，我会这样说：

FDE 是把研发、产品发现和部分组织变革能力部署到客户现场，通过真实业务环境快速探索问题，再把被验证的能力收敛回核心产品的一种高成本组织机制。

所以判断一个 FDE 岗位，不应该只问：

要不要驻场？

也不应该只问：

技术要求高不高？

而应该问四个问题。

第一：

现场发现的问题，能不能反向改变产品？

第二：

公司是否愿意为探索失败和非标准化阶段付钱？

第三：

FDE 到现场以后，是不是拥有足够资源和决策空间？

第四：

现场产生的经验，有没有机制回流并形成组织能力？

如果四个答案都是肯定的，那么 FDE 是一个非常有价值、也非常锻炼人的岗位。

但如果答案是：

产品不能改
+
项目必须赚钱
+
客户需求不能拒绝
+
总部没资源
+
问题只能现场自己解决

那它可能并不是 FDE。

只是换了一个更好听的名字：

驻场 AI 全栈工程师。

写在最后

我并不认为 FDE 是一种天然优秀的组织模式。

它甚至可以说是一种效率并不高的方式。

因为它主动接受：

高人力成本；
高探索成本；
高失败率；
高组织复杂度。

但它换来的是另外一种东西：

公司更快接触真实问题的能力。

对于 AI 这种技术变化很快、需求尚未完全稳定、很多场景甚至客户自己都不知道应该怎么落地的行业来说，这种能力可能非常有价值。

因此 FDE 真正的核心不是：

“把最强的人派到前线。”

而是：

“让前线有能力发现答案，并且让整个公司能够吸收这个答案。”

如果只有前半句，没有后半句，那么再强的 FDE，最终也只能成为一个不停救火的人。

而真正成熟的 FDE 体系，应该让今天的现场探索，变成明天所有项目都可以直接使用的平台能力。