FDE，全称 Forward Deployed Engineer，可以理解为"前线部署工程师"。
FDE，是站在技术、业务、组织和流程的连接点上的人。

1. 为什么 FDE 会越来越受追捧

AI 时代的软件形态正在发生变化，软件一般在 GUI 上都会更加简单，甚至有些直接就没有 GUI（图形化界面），而是采用形式上极简的对话框式的CUI。
对于客户的上手难度来说会呈现两极分化，喜欢 CUI 的人极度推崇，甚至觉得可以像 OpenClaw 和 Hermes 一样，一些复杂任务也可以在手机上通过对话就能完成。

图：AI 在企业中落地的困难。

但对大部分企业业务来说，情况没有这么简单。

企业的流程不是一句"帮我处理一下"就能自动跑起来的。
它背后有审批规则、数据口径、权限边界和大量隐性知识。
CUI 虽然降低了表面操作门槛，却也带来了新的问题：用户习惯需要迁移，业务意图需要被准确理解，AI 能力需要被嵌入到真实流程里。
换句话说，AI 产品本身可能越来越简单，但 AI 落地反而变得更复杂了。

这是 FDE 被追捧的第一个原因：企业需要有人把 AI 能力翻译成可执行的业务方案。

另一个更大的原因，是 AI 带来的人才结构变化。

传统信息化已经走过了 30 多年，ERP、CMS、CRM，以及程序员常说的 CRUD 系统，对很多企业客户来说都不陌生。
企业内部通常也有信息化团队、IT 运维团队等。
但很少有大型企业已经具备成熟的 AI 部门、AI 业务架构师和 AI 项目运营团队。

所以，企业需要一种新角色：既懂 AI 系统，又能理解业务现场；既能和业务人员交流，又能和技术团队协作；既能做方案，也能推动实施。
FDE 的价值，正是在这里出现的。

从 2024 年 11 月开始，我们就一直在深入客户现场，从 LC 信息到 WZ 银行，以及后续一些客户，都存在大量现场交付工作。
经过这一年多的实践，我们越来越明显地感受到：客户并不会只关心你的产品是不是所谓"TOP 级"，他们真正关心的是——当他提出各种复杂问题时，你能不能接得住，能不能解决真实业务问题。

这也是 AI 落地和传统 SaaS 销售很不一样的地方。
AI 不是卖完账号、开完权限就结束了。
它需要在客户的真实业务环境里被反复调试、验证和迭代。
这个过程中，FDE 会越来越成为 AI 服务商和客户之间最关键的连接点。

2. FDE 主要做什么

图：我们对 FDE 的理解。

图：我们对 FDE 的理解。

FDE，全称 Forward Deployed Engineer，可以理解为"前线部署工程师"。
但如果只把它理解成"驻场工程师"，其实是不准确的。
FDE 不是简单在现场等需求、做开发，而是要在客户现场推动 AI 项目真正跑起来。

一般来说，FDE 主要做三类工作。

2.1. 需求分析和方案敲定

FDE 需要在客户现场与业务人员、技术人员充分沟通，找出真正值得被 AI 改造的业务环节，并制定合理目标和实施方案。

这里的重点不只是产品和技术方案，还包括客户侧的业务架构设计。
比如客户是否需要成立专门的 AI 推动小组？
项目由谁牵头？
哪些业务部门参与？
试点范围如何选择？
上线后如何培训？
效果如何考核？
这些问题如果不提前设计好，AI 项目很容易停留在"演示效果不错，但业务用不起来"的阶段。

在这个阶段，FDE 还可以通过现有产品和 AI 工具（我们目前一般用 Claude Code、CodeX 或 v0），快速搭建原型，让客户更直观地看到效果。
原型的价值不只是展示能力，更重要的是帮助双方对齐目标，减少抽象讨论带来的误差。

2.2. 推进实施进度

FDE 需要非常了解己方产品功能和技术储备，并能与内部产研团队一起拆解实施计划。

哪些功能可以第一批快速上线？
哪些系统对接必须优先完成？
哪些需求可以用现有能力解决？
哪些需要在项目中额外定制？
这些判断都需要 FDE 在现场做出。

同时，FDE 还要持续跟进实施进度，推动客户侧配合，组织培训和试运行。
很多 AI 项目不是一次性"大上线"，而是从局部场景开始试点，再逐步扩展到更多业务。
这就要求 FDE 既要有项目推进能力，也要有现场节奏感。

2.3. 试运行、目标检查与迭代

AI 项目真正的挑战，往往从试运行才开始。

FDE 在现场需要配合客户完成业务梳理、知识准备、业务测试、效果检查、问题分析和改进方案制定。
比如知识库答案不准确，到底是解析问题、切片问题、检索问题，还是业务流程本身没有定义清楚？
这些都需要有人在现场快速判断。

然后，FDE 需要把现场问题转化为明确的迭代目标，与客户和己方产研团队一起推动优化。
这个过程本质上不是"交付一个系统"，而是"让 AI 能力在业务中稳定产生价值"。

3. AI 服务商需要作出的改变

其实在 FDE 概念变热之前，我们对内部人员的要求已经在发生变化。

2025 年，我们的 AIS 小分队曾在深圳某银行客户现场驻场长达 6 个月。
当时我们就在思考：如果未来不断面对银行、能源、政企等高安全行业客户的 AI 实施需求，就必须有更多能在现场沟通、开发和直接解决问题的工程师。
所以从今年开始，我们在人员结构上也在主动往这个方向调整，需要建立更快速、更机动的现场团队。

虽然 Vibe Coding 让产品升级迭代速度成倍提升，但一些现场工作依然无法被替代。
尤其是在企业 AI 项目中，客户的数据环境、网络环境、权限体系、业务流程和组织结构都不一样，而且很多高安全行业的客户的数据无法出域，很多问题只有进入现场才能真正看清楚。

所以我们一直有一个很明确的判断：解决客户问题永远是第一位。

但这里也必须强调一点：FDE 和传统外包完全不同。

外包更多是客户安排任务，供应商按需求完成交付。
而 FDE 不是被动接单的人，而是 AI 项目最核心的推动者之一。
FDE 要拉着甲方业务和技术团队，以及己方产研团队一起，把项目真正落地。

FDE 交付的基础是己方产品，目标是弥合产品能力与客户真实需求之间的差距。
FDE 需要参与客户会议、直接上手操作、部署系统、组织培训、记录问题、反馈需求、制定迭代计划，甚至在现场完成一些编码或交付任务。

为了降低 FDE 在现场的开发工作量，我们也对 AIS 产品做了很多调整。
比如开放知识库管理、对话服务、应用管理、组织权限管理、系统设置、Skill 管理、MCP 管理和原子命令等 API/SDK，让现场团队可以更轻量地利用 API 进行二次开发。
同时，我们也会为每个项目成立火力支援小组，为 FDE 提供技术、文档和产品迭代等方面的支持。

这背后其实代表着 AI 服务商的一种组织变化：不能只依赖销售、售前和交付的传统分工，而是要形成"产品能力 + 现场工程能力 + 快速迭代能力"的闭环。

4. 对从业人员的影响

我不知道像我们这样已经在改变的公司有多少，但随着 AI 落地进程的深入，我相信类似 FDE 这样的角色，在组织中的占比只会越来越高。

这并不意味着每个人都要成为 FDE，但它确实会改变很多岗位的能力要求。
对于研发人员、产品经理、解决方案人员来说，未来都需要具备更强的复合能力。

• 培养全栈能力。尽快弱化"前端、后端、产品经理"这种过于固定的岗位边界，尽量往全栈能力转变。
  AI 时代的项目节奏会更快，一个人越能跨环节解决问题，价值越大。
• 需要提升交流和倾听能力。很多时候，客户并不能一开始就准确表达自己要什么。
  你需要和客户一起梳理问题、确定目标、制定计划。
  也许不是每个人都需要备具整个项目的架构能力，但一些局部任务依然需要这种能力。
• 学习行业知识。比如让自己深入理解 2 到 3 个行业的业务 Know-how，通过不断实践积累对这些行业的理解能力。
  AI 落地不是纯技术问题，行业理解会越来越重要。
• 适应快速机动。可能要适应中短期出差和现场工作，除非你真的相信，只靠在线会议和文字沟通就能快速解决复杂问题。
  否则还是要记住那句话：解决客户问题永远是第一位。 我们要深入现场。

图：FDE 对于从业人员的影响。

回到标题的问题：FDE 会是 2026 年 AI 落地之道吗？
我觉得它不一定是唯一答案，但大概率会成为非常重要的一条路径。
因为 AI 真正进入企业，不只是模型能力的问题，也不是产品功能堆叠的问题，而是要有人把技术、业务、组织和流程连接起来。
而 FDE，正是站在这个连接点上的人。