AI 时代最难招的岗位之一，可能就是 FDE 了。
其难点不在于会调用模型、搭知识库、写工作流的人太少，而在于很少有人能够同时接住两头：一头是业务现场里模糊、变化、充满例外的问题，另一头是必须真正做出来、接进系统、跑出结果的技术工作。
这也是为什么，我不太愿意把 FDE 简单定义成“懂业务的工程师”。这个说法没有错，但还没有解释清楚 FDE 为什么叫 Forward Deployed。
FDE 首先是一种机制，然后才是一类岗位
Forward Deployed Engineering 是一种把工程和产品判断前置到客户真实业务环境的产品开发与交付机制。
产品和工程人员不再只根据需求文档、工单和会议纪要做判断，而是进入真实使用环境，与用户一起定义问题、构建系统、验证业务结果，再把实际使用中暴露的问题和证据带回产品迭代。
Forward Deployed Engineer，则是承担这项工作的角色。
“Forward”不是一种更积极的姿态，也不只是地理意义上的驻场。它代表产品和工程判断被向前移动，直接接触业务现实。现场因此既是交付现场，也是产品发现和产品验证的现场。
这条闭环大致是：
产品能力进入现场 → 真实使用并生成验证数据和证据 → 现场发现进入产品判断 → 产品继续迭代改进
如果工程师只是按已经写好的需求完成开发，或者长期留在客户那里处理零散工单，这条回路并没有真正建立起来，而且也跟传统的外包大同小异，新瓶装旧酒。
FDE面对的通常不是一张写好的需求单
客户很少会清楚地说：“请把这条每周反复发生、目前需要大量人工整理的工单升级流程，做成带人工复核的 AI 工作流。”
更常见的说法是：“我们也想做一个智能客服。”“销售团队效率不高，能不能上个 Agent？”“别人都有企业知识库，我们是不是也应该建一个？”
FDE 的第一项工作不是马上回答能不能做，而是把这些话翻译成一个可以观察和验证的问题：谁在什么时点，根据什么信息，作出什么判断；现在要花多少时间，错一次会发生什么；如果产品或 AI 参与进来，哪一步应该改变，又由谁来验收。
这要求的不是单纯的业务理解，也不是单纯的技术实现，而是同时具备业务操盘能力和技术操盘能力。
业务这一头，要能把问题、流程、责任和价值理清；技术这一头，要能把方案做成、接进系统、设置边界并跑出证据。两方面都懂一点，只够站在起点。真正的 FDE 要能够把两头连成一条结果链，并且能评估对于客户现有运营模式的影响。
AI 越强，人的要求反而越不像“会用 AI”
模型会继续进步，搭建一个原型也会越来越快。可正因为构建变快了，选择什么不做、如何判断结果、怎样限制动作、什么时候让人接管，反而变得更重要。
未来优秀 FDE 的区别，可能不在于他能背出多少模型和框架，而在于他能不能完成四个转换：
- 把模糊期待转换成一个可验收的业务任务；
- 把模型能力转换成一条有人负责、风险可控的工作流；
- 把现场问题转换成能够支持产品取舍和迭代的证据；
- 把自己的判断和操作转换成客户团队能自己接手的能力。
第三项延续了 FDE 原本的产品学习机制。第四项，则是 FFDE 面向中小企业特别会去加强的部分。
FFDE 补的是中小企业的实施缺口
经典 FDE 往往依托一家已有成熟产品和工程体系的技术公司。可许多中小企业缺的不只是某个产品功能，还缺少场景选择、数据与知识、工作流、安全治理、人员培训和交接等实施条件。
我所设想的 FFDE，是面向中小企业的快速增强型 FDE：既保留深入现场、共同构建和用真实证据推动产品改进的内核，也把这些缺口一起补上。
它可以用两种方式进入企业。
一种是帮助尚未形成成熟 AI 实施能力的企业跑通第一条工作流，并把运行和改进方法交给客户团队。
另一种是与客户已有的内部产品或 AI 团队并肩进入业务部门，推动产品真正被采用、验证和改进，帮助客户逐步建立自己的内部 FDE 能力。
所以，如果今天要重新写一份 FDE 的招聘说明，我不会先从 Python、RAG 或 Agent 框架写起。
我会先写一句：能够理解甲方的运营模式并进入真实业务，在不完整的信息和现实约束中，说清楚问题、理顺关系、做出系统、交付结果，再让这些证据进入产品和组织的下一步。
这可能才是 AI 时代最稀缺的 FDE 能力。
#FFDE #FDE