最近 FDE 很火，我就思考什么人可以转 FDE 岗？转 FDE 最好的起入点是什么？
我做了 5 年甲方 HR 产品，近两年专注 HR AI 落地。拿我的背景举例，适不适合转岗 FDE 呢？
首先，最近我看了一些 AI 赛道主讲 FDE 的博主的观点，结合我最近和5、6个传统企业（这里指的是传统意义上的“甲方”）的 HR 数字化 / AI负责人交流，虽然他们没有提到 FDE 这个词，但是从用人需求里，也可以看出，他们想要的是一个既懂他们的真实业务，又懂 AI 技术落地的人。
我的感受是：
能不能转 FDE，不取决于你现在的 title，而取决于你有没有补齐「技术、业务、落地」这三块能力。
现在都比较把 FDE 认为是一个AI 新岗位，好像只要会大模型、会 Prompt、会搭 RAG，就能转。但从我最近接触到的用人需求和我实际工作场景转变来看，企业真正想找的不是「会用 AI 工具的人」，而是「能把 AI 放进真实业务系统里的人」。
我认为这两者差别很大，为什么这么说，我们就拿几个比较接近近 FDE 的岗位来讲。
如果你是后端或全栈工程师，你的优势是系统能力强，知道接口、权限、数据流、部署和稳定性。但很多后端转岗候选人面试很容易栽在业务理解上。业务部门往往听不懂系统怎么搭，他们只会问你为什么这个流程怎么用 AI 去改，业务为什么要这么用，最后效果用什么去衡量，大多数企业要的是两个字：提效。
如果你是算法或大模型工程师，你的优势是理解模型和技术边界。但你需要补的是工程集成和业务现场。很多企业不是缺一个更强的模型，而是缺一个能把模型接进HRM、 CRM、ERP、MES、知识库、客服系统或内部工作流的人。
如果你是售前、解决方案或咨询背景，你的优势是懂客户、懂业务表达、能讲清楚场景。但你最大的短板通常是 hands-on experience。FDE 不能只讲方案，它需要真的知道数据怎么接、接口怎么调、workflow 怎么跑，上线后怎么处理异常，异常如何兜底。
如果你是甲方产品经理（企业内部 AI / 业务产品），甲方产品天天泡在内部业务部门，最懂公司真实痛点、组织流程、业务部门诉求，知道业务流程里哪些环节效率最低、哪些地方需要改造、哪些环节重复消耗人力，这是天然优势。但大部分甲方产品转岗会卡在需求与技术的平衡上。甲方产品服务的企业自己，老板一个需求下来，你没有第三方视角的“优势”去选择“做还是不做，不管简单重复查询还是复杂流程推理，一律上模型和 Agent 解决，什么场景用传统自动化、什么场景做 RAG、什么场景才值得上多模态智能体，还要考虑数据安全、成本，企业内部的 infra 侧能不能支持得上。
如果你是乙方产品经理（SaaS/AI 厂商交付产品），乙方产品常年对接外部客户，擅长拆解客户零散需求、标准化输出产品方案，清楚一套 AI 产品要适配不同行业客户的差异化诉求。但短板在于容易悬浮在方案层，乙方产品熟练输出高水准的 PRD、客户流程，面对脏数据治理、多系统集成这类每个企业特有的需求场景练手。不是所有场景都适合 Agent，也不是所有问题都需要大模型。有些需求实际上应该先做数据治理，有些适合 RAG，有些适合workflow，有些用传统自动化会更高效。
不管是甲方还是乙方产品，需要补齐的短板在于工程交付。FDE 的交付物不再是 PRD文档，而是能跑通的 AI 工作流、agent。
FDE 不允许只画原型、写方案，企业会需要看到：当业务自己都说不清楚需求的时候，你能不能去搞明白真实业务痛点？你有没有跟进过模型对接进入真实业务流程？业务数据不规范、一些系统不开放接口时，你要怎么跨部门协调落地、给出折中可行方案？
即便你去面试，企业真正会问的是：你有没有做过真实业务场景？有没有接过系统？有没有处理过脏数据？有没有推动上线？有没有让业务团队持续使用？有没有可衡量的结果？
一个企业要把 AI 用到工作流程里，需要一个角色来帮它们去梳理流程、梳理组织、梳理上下文、梳理数据库，这个角色可能就会是 FDE。就像是今天你做出了一个数字员工，我要怎么培训让这个数字员工上岗，上岗后出了问题你要怎么解决，项目上线后如何证明可衡量的业务价值？
一句话总结：从流程梳理、模型适配、数据治理、工作流搭建，到上线运维、问题兜底、价值量化，这是 FDE 的核心价值。
所以，我认为，FDE 不是“一个人”，是一个高度默契的小型特种部队，至少目前的这样。
就说发明 FDE 这个岗位的“鼻祖”Palantir——FDE 这个岗位最早就是他们做出来的，经典落地模式是Echo+Delta 双人小分队，不是让一个人全包：Echo 是行业业务专家，负责吃透客户流程、梳理真实痛点；Delta 也就是狭义 FDE 工程师，负责把业务逻辑快速写成可运行代码、打通系统、落地工作流，两人搭配驻场交付。
