最近连续和两家做企业 AI 落地的公司交流，大家都提到了同一个角色：FDE。

FDE 的全称是 Forward Deployed Engineer，最早由 Palantir 提出。直译是“前线部署工程师”，但这个说法容易让人误以为它只是一个负责部署系统的技术岗位。放到企业 AI 落地的语境里，我更愿意把它理解成一句话：

FDE，是深入客户现场，把真实业务问题变成可运行系统的人。

这句话里的重点有两个：一是“真实业务问题”，二是“可运行系统”。前者要求 FDE 能进入现场、理解业务、问清事实；后者要求 FDE 不停留在方案和 PPT，而是把数据、流程、权限、AI 能力和软件工程真正串起来。

企业 AI 落地，难点不只在模型

今天做一个 AI Demo 已经不难。接入一个大模型、搭一个知识库、做一个 Agent，对很多团队来说都不是特别高的门槛。

真正难的是进入企业现场之后，发现问题远比“调用模型”复杂得多：

  • 客户的业务到底是怎么运转的？
  • 数据从哪里来，口径是否一致？
  • 哪些指标真的重要，哪些只是习惯性在看？
  • 什么情况算异常，异常发生后谁负责处理？
  • 流程怎么闭环，怎么判断问题已经解决？
  • AI 应该嵌入哪个环节，哪些环节其实不适合用 AI？

这些问题如果没有搞清楚，模型再强，也很容易做出一个“看起来很智能，但业务用不起来”的东西。

所以企业 AI 项目的分水岭，往往不在模型参数，也不在工具清单，而在有没有人能把业务、数据、流程、软件和 AI 串成一套真正能跑的系统。这就是 FDE 的价值。

FDE 不是程序员，也不是传统顾问

FDE 很容易被误解成两类角色。

一种误解是把 FDE 当成“高级程序员”。但 FDE 的第一任务通常不是写代码，而是把问题定义清楚。客户说“我想做 AI 预警”，并不代表问题已经被定义好了。FDE 要继续追问：过去发生过什么异常？谁发现的？依据什么数据？影响有多大？谁处理？如何确认关闭？

另一种误解是把 FDE 当成“会讲方案的顾问”。但 FDE 不能只交付诊断报告，它最终要把方案做成系统，推动客户真的用起来，并根据使用反馈继续迭代。

FDE 的本质区别是：它不是只负责“讲清楚”，也不是只负责“写出来”，而是负责把客户现场的复杂问题转译成可交付、可使用、可迭代的系统。

一个好的 FDE，需要五种能力

如果把 FDE 的工作拆开看，它至少包含五种核心能力。这五种能力连在一起，才构成从业务现场到系统交付的完整闭环。

1. 业务访谈能力：问清事实，而不是照单接需求

客户表达出来的，往往是一个想法，而不是已经被定义好的问题。

比如客户说：“我们想做一个 AI 经营预警系统。”如果马上开始设计 Agent，很可能会做偏。FDE 更应该先追问：过去最严重的经营异常是什么？异常是怎么被发现的？是收入异常、费用异常、库存异常，还是利润异常？发现之后通知谁？处理结果如何复盘？

这些追问看起来很基础，却决定了系统是否真的有用。业务访谈的目标不是把客户的话记录下来，而是把事实、指标、风险和流程责任问清楚。

2. 业务与数据建模能力：把业务语言翻译成系统语言

客户说的是业务语言：分公司、客户、订单、经营指标、负责人、异常情况。系统需要的是对象、字段、关系、状态、规则和流程。

以“预警事件”为例，FDE 要把它拆成一组可被系统处理的结构：它有哪些字段？关联哪个组织？由谁负责？触发规则是什么？处理状态有哪些？关闭条件是什么？管理层看什么维度的汇总？

这一步对 AI 落地尤其重要。AI 不能长期面对一堆模糊描述和口头经验，它需要结构化的业务对象、关系和规则。业务建模越清晰，AI 能发挥作用的位置就越明确。

3. 工程实现能力：用合适的方式最快验证价值

FDE 最终要把方案做出来。但“做出来”不等于所有东西都从零开发，也不等于技术越复杂越好。

有些阶段，用飞书多维表格、明道云这类零代码工具就能跑通流程；有些场景，用低代码或少量自定义代码做 MVP 更合适；有些项目确实需要写后端服务，连接数据库、处理接口、权限和审计，再接入 LangChain、DAG Graph 等 AI 编排工具。

判断标准不是技术栈是否炫，而是：在客户当前阶段、预算和组织能力下，什么方式能最快验证业务价值。

4. AI 落地判断力：知道 AI 应该放在哪里

很多企业 AI 项目容易走向一个误区：哪里都想加 AI。

但 FDE 要清楚，AI 不是万能模块。有些判断用固定规则更稳定，有些流程用传统工作流更清晰，有些节点必须保留人工审批。AI 更适合放在需要总结、归因、分析、辅助判断或生成建议的环节。

所以 FDE 的判断不是“这个功能能不能用 AI 做”，而是“AI 放在这里，是否比规则、工作流或人工处理更有业务价值”。

5. 交付与产品化能力：从项目里长出可复用能力

FDE 做完一个项目，不应该只是项目结束。更重要的是从一个客户身上看到一类客户的共性问题。

这次做了集团经营预警，就要继续沉淀：访谈问题能不能复用？经营指标能不能抽象成模板？预警规则能不能形成规则库？流程节点能不能变成产品组件？技术方案能不能成为下一次交付的基础？

这一步决定了团队是在做一次性交付，还是能从项目中逐步长出产品能力。

案例：集团经营预警系统怎么做

以集团经营预警系统为例，表面需求可能是“做一个 AI 预警系统”，但真正要交付的是一套经营管理闭环。

数据来源：把收入、成本、费用、利润等经营数据从各业务系统汇总到统一平台。
规则触发：定义经营指标、阈值、趋势规则和异常识别逻辑。
预警通知：把异常通过消息卡片或系统通知推送给对应负责人。
反馈处理：负责人填写原因说明、处理动作和改善计划。
闭环管理：跟踪处理进度，确认问题解决后关闭预警事件。
管理看板：让董事长或管理层看到整体预警数量、处理状态和风险趋势。

在这套系统里，AI 不是一上来就替代所有判断。更现实的做法是：规则负责稳定触发，流程负责责任闭环，AI 负责辅助归因、生成摘要、提示可能原因、整理管理层可读的说明。

FDE 在其中要做的，是设计数据模型、预警规则、流程状态和 AI 应用点，并推动客户持续使用、持续反馈、持续迭代。

如何培养 FDE 能力

FDE 不是靠学一个工具就能养成的，它来自真实项目的反复训练。比较有效的路径可以拆成五步：

  • 走进业务现场：多做真实项目，深入一线调研，理解业务语言、组织关系和实际痛点。
  • 练访谈与建模：把访谈结果转化为对象、流程、规则、指标和数据模型。
  • 提升工程落地力：熟悉零代码、低代码、自定义开发和 AI 编排工具，能快速搭 MVP。
  • 训练 AI 判断力：理解模型、Agent、规则和工作流的边界，知道什么时候该用 AI，什么时候不该用。
  • 持续沉淀复用：每做完一个项目，都沉淀模板、组件、规则库和方法论。

最后

企业 AI 落地越往深处走，越会发现真正稀缺的不是“会调用模型的人”，而是能进入客户现场、理解真实问题、串起业务和技术，并把系统交付出来的人。

FDE 的价值正在这里。它不是一个新鲜岗位名称，而是一种复合能力：懂业务、懂数据、懂工程、懂 AI，还能跟客户沟通，并对最终系统是否跑起来负责。

一句话总结：FDE，就是把真实业务问题变成可运行系统的人。