FDE:AI时代的关键角色和技能

如果把 AI 应用时代的软件开发角色重新划分,你会发现 FDE(Forward Deployed Engineer) 的出现几乎是必然的。
传统软件时代,最大的挑战是“把需求变成代码”;AI 时代,最大的挑战变成了“把能力变成价值”。
模型已经提供了能力,但这些能力如何落到真实业务里,远比训练一个模型困难得多。这也是为什么 Anthropic、OpenAI、Palantir 等公司都越来越重视 FDE 这样的角色。
为什么 AI 应用需要 FDE?
AI 产品有一个与传统 SaaS 最大的不同:模型能力是通用的,而业务问题永远是具体的。
同一个 GPT-5,可以做客服、法律分析、医疗问答、机器人控制、科研助手,但每一个场景真正成功,都需要解决大量具体问题:
用户真正的问题是什么?
哪些任务适合交给 LLM?
哪些必须由工具完成?
哪些应该让人确认?
Prompt 应该怎样设计?
Context 如何组织?
哪些地方需要 RAG?
哪些地方需要 Agent?
Eval 怎么设计?
什么时候模型已经足够好,什么时候应该继续优化?
这些问题没有统一答案。
因此 AI 产品最大的瓶颈,已经不是模型,而是最后一公里(Last Mile)。
FDE 就是专门解决最后一公里的人。
他站在客户现场,也站在工程团队前面,把抽象的 AI 能力,真正变成业务价值。
FDE 的核心工作是什么?
很多人误以为 FDE 就是“帮助客户部署”。
实际上,这只是最表面的工作。
真正优秀 FDE 的工作,是不断完成下面这个闭环:
理解业务 → 抽象问题 → 设计 AI Workflow → 快速验证 → 收集反馈 → 优化系统 → 沉淀产品能力。
如果拆开来看,大概包括几件事情。
第一,是业务理解。
真正理解客户每天到底在做什么。
不是听需求,而是观察工作流。
很多时候客户说需要 Agent,其实真正需要的是一个自动化 Pipeline。
客户说需要 RAG,其实问题是知识结构混乱。
客户说模型太笨,其实 Context 已经严重污染。
第二,是系统设计。
包括:
Prompt Engineering
Context Engineering
Tool Calling
MCP
Agent Workflow
Human in the Loop
Memory
Evaluation
Guardrail
这些组合起来,才是真正的 AI Application。
第三,是快速实验。
AI 应用最大的特点不是设计,而是实验。
FDE 每天都在回答:
“如果把 Context 改一下,会不会提升?”
“如果换 Tool 顺序呢?”
“如果让模型先规划再执行?”
“如果加 Reflection?”
“如果换 Eval Case?”
整个过程更像科学实验,而不是传统开发。
第四,是产品反馈。
优秀 FDE 不只是交付项目。
他们会不断发现:
为什么十个客户都会踩这个坑?
为什么这个 Prompt 每个人都要写一次?
为什么所有客户都需要这个 Tool?
这些最终都会反馈回产品团队,变成平台能力。
所以很多 AI 公司,产品路线图其实大量来自 FDE。
FDE 能做出成果的前提是什么?
很多人觉得 FDE 最重要的是 Prompt。其实完全不是。
真正决定一个 FDE 上限的,是三个层次。
第一层,是系统理解能力。
理解 LLM 为什么成功。
为什么失败。
Context Window 怎么工作。
Attention 如何影响结果。
Token 为什么污染。
Tool 为什么失效。
Eval 为什么不稳定。
没有这些基础,很难定位问题。
第二层,是业务抽象能力。
这是最稀缺的能力。
客户说:
“我们审批效率太低。”
真正的问题可能是:
任务拆解错误。
责任边界不清。
知识没有结构。
信息流断裂。
Agent 无法观察状态。
优秀 FDE 能把业务语言翻译成 AI 可以解决的问题。
第三层,是快速实验能力。
AI 产品没有标准答案。
优秀 FDE 不会争论。
他们一天可以做二十个实验。
快速建立假设。
快速验证。
快速否定。
快速迭代。
本质上,他们更像研究员,而不是开发者。
FDE 与传统开发工程师最大的区别是什么?
很多开发者的思维方式是:
需求 → 设计 → 编码 → 上线。
而 FDE 的思维方式更接近:
问题 → 假设 → 实验 → 学习 → 产品化。
普通开发工程师主要优化的是:
“代码是否正确。”
FDE 更关注:
“系统是否创造价值。”
普通开发工程师主要面对的是代码。
FDE 面对的是:
模型、用户、业务、数据、工作流、组织。
普通开发者最大的资产是代码库。
优秀 FDE 最大的资产是:
对问题模式(Problem Pattern)的理解。
他们知道:
什么样的问题适合 AI。
什么样的问题千万不要做 Agent。
什么时候需要 Workflow。
什么时候需要多 Agent。
什么时候应该让人介入。
什么时候应该放弃。
所以,一个优秀 FDE 写代码未必最多,但他几乎总能找到系统真正的瓶颈。
FDE 的本质
普通开发工程师负责构建系统,FDE 负责让系统在真实世界产生价值。
他们不是单纯的工程师,也不是产品经理,更不是售前。
他们更像 AI 时代的“现场架构师(Field Architect)”。
他们需要同时理解模型、工程、产品、用户和业务,并不断把现场获得的经验,沉淀为可以复制的平台能力。
从这个角度看,FDE 并不是一个过渡性岗位,而很可能会成为 AI 应用时代最具价值的工程角色之一。
随着 Agent、Context Engineering 和 Eval Engineering 成为 AI 应用的核心竞争力,FDE 的价值将越来越体现在:把一次成功的客户实践,转化为下一百个客户都能复用的产品能力。
