夜雨聆风
这两年，很多企业搞AI都有一个共同感受：
演示很好看，落地很难看。
PPT里是“AI重构流程”，现场是“数据接不上、系统打不通、员工不会用、权限批不下来、效果说不清”。
最后项目变成了：领导汇报有亮点，基层使用没感觉，系统上线没人点。
问题出在哪？
不是模型不够强，也不是企业不重视，而是中间缺了一个关键角色：FDE。
FDE，全称是 Forward Deployed Engineer，直译叫“前线部署工程师”。这个角色最早被 Palantir 带火，核心做法是把工程师直接放到客户现场，不是在办公室闭门写代码，而是贴着客户的业务、数据、系统和流程，把技术真正做成结果。
现在，FDE正在成为AI公司抢人的重点岗位。OpenAI官方招聘页面对FDE的描述很明确：这个团队要和客户一起，把研究突破转化为生产系统，工作位置处在客户交付和核心平台开发的交叉点。 
注意这句话里的关键词：生产系统。
不是Demo，不是样板间，不是聊天机器人，而是能进入真实业务、真实流程、真实系统、真实考核的生产系统。
这就是FDE和普通技术岗位最大的区别。
传统软件工程师主要面对代码。
售前工程师主要面对方案。
咨询顾问主要面对分析和建议。
交付工程师主要面对实施和上线。
而FDE面对的是一个更复杂的现场：客户的业务问题、历史系统、脏数据、组织流程、安全合规、用户习惯、上线压力和最终效果。
所以，FDE不是单纯写代码的人，也不是单纯讲方案的人。
它更像是“懂业务的工程师”和“能写代码的业务架构师”的结合体。
拿企业AI落地来说，FDE通常要做六件事。
第一，找到真正值得做的场景。
企业经常一上来就说：“我们想做AI助手。”
但FDE不能停在这个层面。他要继续追问：
这个助手解决谁的问题？
每天在哪个环节用？
输入数据从哪里来？
输出结果谁确认？
错了谁负责？
节省多少时间？
能不能进入现有流程？
如果这些问题回答不清楚，所谓AI助手大概率只是一个“新入口”，不是一个“新能力”。
真正的FDE不会先问“用哪个模型”，而是先问“哪个流程值得被AI改造”。
第二，把业务流程拆成可执行的技术链路。
比如客户说：“我们想提升工单处理效率。”
普通说法是：用AI自动分析工单。
FDE要拆成更细的链路：
工单从哪个系统产生？
字段是否标准？
历史工单能不能作为知识样本？
客户诉求如何分类？
AI判断后是直接处理，还是给人工建议？
处理建议如何回填原系统？
是否需要审批？
是否保留日志？
如何评估准确率和节省时长？
拆到这个层面，AI项目才从“概念”变成了“工程”。
第三，处理企业最麻烦的数据问题。
AI项目最容易被低估的，不是模型，而是数据。
很多企业的数据不是没有，而是散在不同系统里；不是不能用，而是口径不统一；不是价值不高，而是缺少治理和调用机制。
FDE要面对的往往不是干净的训练数据，而是：
历史Excel、老系统接口、内部知识库、审批文档、客户资料、工单记录、业务日志、权限清单、部门口径差异。
所以，FDE必须懂数据接入、数据清洗、权限隔离、知识库构建、RAG检索增强、API调用、日志追踪和效果评估。
这里有一个关键判断：
企业AI落地的难点，70%不在“回答问题”，而在“拿到正确上下文”。
没有上下文，大模型只是一个会说话的通用工具；
有了业务上下文，AI才可能变成企业自己的生产力系统。
这也是为什么OpenAI近期专门成立 OpenAI Deployment Company，并宣布收购 Tomoro，把约150名有经验的FDE和部署专家带入新公司，目标就是帮助企业把AI转化为运营优势。 
第四，把AI嵌入原有系统，而不是另起炉灶。
很多AI项目失败，是因为它们停留在“多了一个AI页面”。
员工本来就在CRM、OA、工单、ERP、财务、人力、项目管理系统里工作。你再给他一个AI聊天窗口，他反而觉得多了一件事。
真正有价值的AI，不应该让人围着AI转，而应该让AI进入人的工作流程。
比如：
客服不用复制客户问题给AI，而是在工单系统里自动生成回复建议；
销售不用单独问AI客户情况，而是在CRM里自动弹出客户画像和跟进建议；
财务不用把合同传来传去，而是在审批流程里自动识别风险条款；
产品经理不用手工整理需求，而是系统自动归类、聚类、生成版本建议。
这才叫AI进流程。
Palantir对AI FDE的描述也体现了这个方向。它的AI FDE可以通过自然语言操作Foundry，执行数据转换、管理代码仓库、构建和维护本体等操作。也就是说，AI不只是回答问题，而是参与数据和系统操作。 
第五，持续调优，而不是上线即结束。
传统IT项目经常是“上线即交付”。
AI项目不是这样。
AI上线后，一定会遇到问题：
回答不稳定；
知识库检索不准；
模型幻觉；
权限边界不清；
用户不会提问；
场景设计太泛；
业务部门反馈“能用但不好用”；
领导问不出量化效果。
FDE的价值就在这里。它不是把系统装上就走，而是要在现场不断迭代：
调提示词；
调知识库；
调工作流；
调接口；
调权限；
调评价指标；
调用户使用方式。
AI项目本质上不是一次性交付，而是持续运营。
第六，把技术效果翻译成业务结果。
这是最关键的。
AI项目不能只讲“调用了大模型”“建设了智能体”“上线了知识库”。
这些都不是结果，只是手段。
真正要说清楚的是：
减少了多少人工处理时间；
缩短了多少业务流程；
降低了多少错误率；
提升了多少响应速度；
节省了多少人力成本；
增加了多少收入机会；
形成了多少可复制场景。
FDE最终交付的不是代码，而是业务影响。
这也是为什么FDE在AI时代突然变重要。
过去软件时代，产品可以相对标准化。厂商做好软件，客户安装使用。
但AI时代不一样。AI的效果高度依赖业务上下文、企业数据、流程嵌入和现场调优。
同一个大模型，在不同企业里效果完全不同。
不是因为模型变了，而是因为数据、流程、权限、场景和使用方式不同。
所以AI公司现在发现，只卖模型不够。模型只是底座，真正的收入和价值要靠部署、集成、场景改造和持续运营。路透社也报道，OpenAI正在加大企业AI部署方向投入，重点是把专业工程师嵌入组织，识别高影响力的AI部署机会。 
对企业来说，这里面有一个很大的启发：
不要再把AI落地简单理解成“买一个平台、接一个模型、建一个助手”。
真正的AI落地，至少需要四层能力：
第一层是模型能力。
也就是大模型、多模态模型、推理模型、语音模型、视觉模型。
第二层是数据能力。
包括知识库、企业数据治理、接口打通、权限管理、日志体系。
第三层是流程能力。
把AI嵌入审批、客服、营销、运维、管理、生产、研发等真实流程。
第四层是组织能力。
有人懂业务，有人懂技术，有人能协调资源，有人能持续运营。
FDE正好站在这四层能力的交界处。
所以，FDE不是一个孤立岗位，而是AI落地组织方式的变化。
过去企业做数字化，常见模式是：
业务部门提需求；
技术部门做系统；
供应商搞交付；
领导听汇报；
基层被动使用。
这个模式做传统系统还勉强能跑，但做AI会很吃力。
因为AI场景很难一次说清楚，效果也很难一次做准。它需要现场共创、快速试错、持续迭代。FDE的价值，就是把“需求—开发—部署—反馈—优化”这条链路压缩到一起。
这对个人也有很现实的启发。
未来最有价值的人，不是只会说“我会用AI”，而是能说清楚：
我能用AI改造哪个流程；
我能接入哪些数据；
我能设计什么工作流；
我能把结果嵌入哪个系统；
我能用什么指标证明效果。
会用AI工具，只是起点。
能把AI变成业务结果，才是竞争力。
如果放到企业内部，很多岗位都可以向“类FDE”能力转型。
产品经理要更懂技术实现；
技术人员要更懂业务流程；
解决方案人员要更懂数据和系统；
项目经理要更懂AI迭代逻辑；
业务骨干要更懂如何把经验沉淀成知识库和智能体。
说到底，FDE火起来，不是因为多了一个新名词，而是因为AI落地已经进入了新阶段。
第一阶段，大家比谁模型强。
第二阶段，大家比谁应用多。
第三阶段，大家就要比谁能真正进流程、进系统、进考核、进生产。
现在正在进入第三阶段。
所以今天讲FDE，不是为了追一个热点，而是要看懂一个趋势：
AI时代，企业最缺的不是会演示AI的人，而是能把AI干成事的人。
