夜雨聆风最近，FDE突然火了。
不少科技博主开始介绍这个岗位，越来越多AI公司也在招聘FDE。
2026年6月底，AWS宣布投入10亿美元成立Forward Deployed Engineering团队，计划让数千名AI工程师直接进入客户团队，共同开发和部署智能体应用。OpenAI目前也在新加坡、东京、首尔等地招聘FDE，并把这个岗位的职责明确写成：
从业务发现、技术范围界定、系统设计和开发，一直负责到生产环境上线。(AWS官方介绍；OpenAI FDE职位列表)
FDE，全称Forward Deployed Engineer，通常被翻译为“前线部署工程师”或“前沿部署工程师”。
但这篇文章不准备讨论FDE能拿多少薪资，也不准备把它包装成一个新的热门职业。
我们更关心的是：
为什么模型越来越强、AI产品越来越多，企业反而开始需要一批深入业务现场的工程师？
答案可能并不复杂。
企业AI的主要矛盾，正在从“有没有能力”，转向“能不能产生结果”。
01｜AI公司开始发现：把产品卖给客户，并不等于客户真正用起来
过去的软件产品，通常有相对明确的使用方式。
财务软件管理账务，CRM管理客户，ERP连接采购、库存和生产。产品虽然需要实施，但核心功能和操作路径大体是确定的。
AI不是这样。
同一个大模型，放进不同企业、不同部门和不同流程，产生的价值可能完全不同。
一家企业说要做AI客服，真正的问题可能不是缺少一个会回答问题的机器人，而是：
• 产品资料散落在不同文件里；
• 售后问题没有统一分类；
• 历史服务记录无法查询；
• 复杂问题不知道转给谁；
• 错误回答缺少审核和追溯机制。
一家企业说要用AI优化库存，真正需要处理的也不只是“做一个预测模型”，而是：
• 销售预测如何形成；
• 门店和总部如何提报需求；
• 在途订单能不能及时更新；
• 库存异常由谁判断；
• 补货建议由谁确认；
• 最终结果如何回写系统。
这些问题不可能仅靠交付一个账号、一个模型或者一个Agent解决。
AI产品提供的是能力。
企业需要的却是一个能够持续运行的业务闭环。
这两者之间，还有很长的一段路。
02｜FDE多做的，不只是“驻场开发”
很多人第一次听到FDE，会把它理解成：
派一个工程师到客户现场，根据需求做定制开发。
如果只是这样，FDE并不新鲜。
软件实施、技术顾问、解决方案工程师和外包开发，过去一直都在做类似的工作。
FDE真正不同的地方，在于它通常不会只负责其中一个环节，而是要对一条更完整的路径负责：
发现业务问题→ 界定项目范围→ 设计解决方案→ 开发和连接系统→ 推动生产上线→ 观察真实使用→ 根据结果继续迭代
OpenAI对FDE岗位的定义中，不仅包括发现、设计、开发和上线，还明确要求用生产采用情况、工作流产生的可衡量影响，以及持续评估反馈来判断项目是否成功。(OpenAI官方职位说明)
也就是说，一个FDE不能只说：
• 模型已经接好了；
• Agent可以运行了；
• Demo已经演示过了；
• 功能符合需求文档。
他还要继续回答：
• 员工是否真的在使用？
• AI输出有没有进入下一步流程？
• 错误时由谁接管？
• 原来的工作时间是否缩短？
• 业务结果有没有发生变化？
• 这套方案离开项目团队后还能不能继续运行？
FDE交付的不是一个功能，而是一个可以被业务使用和验证的结果。
03｜一个FDE进入企业后，实际需要做什么？
不同公司对FDE的定义并不完全相同。
但从企业AI项目的实际需要看，至少包含以下几类工作。
第一，听懂企业真正想解决的问题
客户说“想做AI”，通常只是需求的起点。
“提高效率”“建设知识库”“做数字员工”“实现智能决策”，这些都还不是可以直接实施的项目目标。
FDE需要继续追问：
• 具体是哪一类人员效率低？
• 哪个环节花费的时间最多？
• 目前由谁完成？
• 输入数据从哪里来？
• 输出结果给谁使用？
• 做错以后会产生什么损失？
• 最终准备通过什么指标判断效果？
很多AI项目并不是技术做不出来，而是从一开始就没有把问题定义清楚。
第二，把业务流程拆到足够具体
AI不能直接进入“客服”“供应链”“销售”这样的大概念。
它只能进入一个个具体任务。
例如，所谓AI客服，可能需要继续拆成：
客户问题识别→ 查询审核后的知识→ 生成回答→ 判断是否需要人工介入→ 转交相应人员→ 记录本次服务→ 将新问题反馈给知识库负责人
拆到这一步，才能判断：
哪些环节适合由确定性程序完成，哪些环节需要调用模型，哪些节点必须由人确认。
第三，把AI连接到企业已有的系统和数据
能在聊天窗口里回答问题，不代表已经进入企业。
真正上线时，AI可能需要连接：
• 企业知识库；
• Excel或数据库；
• CRM、ERP和客服系统；
• 飞书、企业微信等协同工具；
• 权限、审批和日志系统。
模型只是其中一部分。
数据质量、系统接口、权限边界和异常处理，往往决定了项目最终能不能运行。
第四，设计人机协同，而不是一味追求无人化
企业AI项目最危险的设计之一，就是为了展示“智能”，把所有工作都交给AI。
真实业务中，更合理的结构通常是：
AI负责读取、整理、分析和提出建议，人负责确认、授权和承担最终责任。
特别是涉及价格、采购、对外回复、客户数据和经营决策时，必须提前设计：
• 哪些动作可以自动执行；
• 哪些动作需要人工批准；
• 哪些情况必须升级；
• 出现错误后如何停止和回退。
第五，对生产使用和业务指标负责
项目上线并不是结束。
如果员工不愿意用、输出不稳定、知识长期不更新、流程经常绕开系统，再好的Demo也没有意义。
因此，FDE还需要和业务团队一起观察：
• 使用率；
• 采纳率；
• 错误率；
• 人工接管率；
• 单次任务耗时；
• 最终业务指标。
然后继续修改流程、规则、数据和系统。
这也是FDE与一次性交付项目最大的差别之一。
04｜FDE为什么会在AI时代重新走红？
FDE并不是大模型出现以后才有的岗位。
Palantir很早就采用了类似模式，让工程师深入客户现场，在真实数据和业务环境中解决问题。如今，OpenAI、AWS、Databricks等公司又开始扩展FDE团队。Databricks在2026年宣布成立FDE组织时，也明确把目标定义为加速客户通过AI取得业务成果。(Palantir官方架构说明；Databricks AI FDE团队介绍)
FDE重新受到关注，背后反映的其实是AI行业的一次变化。
过去两年，大量精力被投入到模型、算力、Agent平台和各种AI工具上。
这些能力仍然重要。
但企业现在开始追问更现实的问题：
买完以后，谁来把它变成业务结果？
AI的通用能力越强，这个问题反而越突出。
因为通用不等于开箱即用。
每家企业都有自己的：
• 业务规则；
• 系统环境；
• 数据结构；
• 权限体系；
• 员工习惯；
• 经营目标。
模型可以标准化，企业现场却很难完全标准化。
所以，企业AI不会只有“标准产品”这一种交付方式。
它还需要有人站在产品和客户之间，把通用能力转化为具体工作流，再把项目中的共性需求反馈给产品团队。
FDE的价值，正是在标准化产品与非标准企业现场之间搭桥。
05｜但FDE也不应该变成“高级外包”的新名字
FDE很火，不代表只要驻场、写代码、做定制，就可以叫FDE。
如果一个项目结束以后：
• 只有原来的开发人员懂系统；
• 客户团队无法自己维护；
• 每个客户都重新开发一套；
• 数据和流程没有形成规范；
• 业务效果没有被持续验证；
• 定制代码越来越多，技术债越来越重；
那么FDE很容易退化成成本更高的项目外包。
真正有价值的FDE，不仅要解决这一次的问题，还要留下可以继续使用的能力：
• 清晰的业务流程；
• 可维护的系统；
• 明确的权限和责任；
• 完整的操作记录；
• 可以复用的组件和方法；
• 能够自己运营的客户团队。
AWS在介绍其FDE模式时，专门强调了一点：项目结束后，客户应该能够独立运行和继续创新，而不是永久依赖外部团队。(AWS官方介绍)
所以，FDE不是靠无限定制创造价值。
恰恰相反，它还要不断判断：
哪些需求应该定制，哪些问题应该改变流程，哪些能力应该沉淀成标准产品。
06｜企业真正需要的，未必是马上招聘一个FDE
看到FDE成为热门岗位后，企业不必急着增加一个新职位。
中小企业尤其没有必要照搬大模型公司的组织架构。
更值得先确认的是：
自己的AI项目，有没有人对从问题发现到上线结果的全过程负责？
这个责任可以由一名复合型人才承担，也可以由一个小团队共同完成。
但至少需要同时具备三类角色：
业务负责人
明确要改善什么结果，提供业务规则，并对流程调整作出决定。
AI实施人员
把业务需求转化为数据、系统、工作流和模型方案。
项目负责人
协调业务、技术和管理层，推动试点、验收、使用和后续迭代。
在大型科技公司，这些能力可能集中在FDE身上。
在中小企业，则更可能采用：
企业业务负责人＋外部AI落地团队＋内部技术或运营人员
共同推进。
岗位叫什么并不是最重要的。
重要的是，不能再把企业AI项目拆成几个互不负责的环节：
顾问负责写方案，软件公司负责开发，员工负责使用，最后却没有人对业务结果负责。
07｜回头看，我们正在做的，其实也是FDE的工作
我们不会因为FDE成为热点，就把自己包装成拥有大量成熟案例的FDE团队，也不会把尚未上线的方案写成已经取得成果的成功案例。
但回看我们与一家茶饮连锁供应链团队的交流过程，会发现我们正在采用的工作方式，与FDE非常接近。
我们没有先推荐模型和工具。
而是先了解：
• 预测是如何形成的；
• 订单如何传递；
• 在途信息如何跟踪；
• 库存异常如何发现；
• 哪些工作依赖Excel和人工判断；
• 业务负责人真正希望改善什么结果。
交流之后，我们需要做的也不是立刻开发一个“供应链Agent”，而是继续把预测、订单、在途、库存和补货连接成一条完整流程，判断第一个项目应该从哪里切入，哪些数据仍需补充，哪些环节必须保留人工确认。
这次经历也让我们更加确定：
企业AI最难的部分，往往不是把模型接进来，而是把业务问题看清楚，把流程重新设计好，再陪着企业把它真正跑起来。
这或许就是FDE突然受到关注的真正原因。
它不是又创造了一个听起来高级的新岗位。
而是AI行业终于开始承认：
从技术能力到业务结果之间，必须有人负责。
下一篇，我们会具体拆解：第一次进入一家企业做AI，我们到底看了什么、问了什么，又是如何从一堆需求中梳理出真正值得继续验证的问题。
如果你也想判断公司哪些场景适合先做AI，可以回复【FDE】或【诊断】，领取《企业AI落地自检清单》。
也可以添加企业微信，告诉我：
所在行业
团队规模
每天重复发生、最想先解决的问题
不急着换系统，先找一个每天都在发生的问题。