FDE，全称Forward Deployed Engineer，可以理解为“前线部署工程师”。
FDE，是站在技术、业务、组织和流程的连接点上的人。
一、为什么FDE会越来越受追捧
AI时代的软件形态正在发生变化，软件一般在GUI上都会更加简单，甚至有些直接就没有GUI（图形化界面），而是采用形式上极简的对话框式的CUI。对于客户的上手难度来说会呈现两极分化，喜欢CUI的人极度推崇，甚至觉得可以像OpenClaw和Hermes一样，一些复杂任务也可以在手机上通过对话就能完成。
但对大部分企业业务来说，情况没有这么简单。
企业的流程不是一句“帮我处理一下”就能自动跑起来的。它背后有审批规则、数据口径、权限边界和大量隐性知识。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服务商和客户之间最关键的连接点。
二、FDE主要做什么
FDE，全称Forward Deployed Engineer，可以理解为“前线部署工程师”。但如果只把它理解成“驻场工程师”，其实是不准确的。FDE不是简单在现场等需求、做开发，而是要在客户现场推动AI项目真正跑起来。
一般来说，FDE主要做三类工作。
1. 需求分析和方案敲定
FDE需要在客户现场与业务人员、技术人员充分沟通，找出真正值得被AI改造的业务环节，并制定合理目标和实施方案。
这里的重点不只是产品和技术方案，还包括客户侧的业务架构设计。比如客户是否需要成立专门的AI推动小组？项目由谁牵头？哪些业务部门参与？试点范围如何选择？上线后如何培训？效果如何考核？这些问题如果不提前设计好，AI项目很容易停留在“演示效果不错，但业务用不起来”的阶段。
在这个阶段，FDE还可以通过现有产品和AI工具（我们目前一般用Claude Code、CodeX或v0），快速搭建原型，让客户更直观地看到效果。原型的价值不只是展示能力，更重要的是帮助双方对齐目标，减少抽象讨论带来的误差。
2. 推进实施进度
FDE需要非常了解己方产品功能和技术储备，并能与内部产研团队一起拆解实施计划。
哪些功能可以第一批快速上线？哪些系统对接必须优先完成？哪些需求可以用现有能力解决？哪些需要在项目中额外定制？这些判断都需要FDE在现场做出。
同时，FDE还要持续跟进实施进度，推动客户侧配合，组织培训和试运行。很多AI项目不是一次性“大上线”，而是从局部场景开始试点，再逐步扩展到更多业务。这就要求FDE既要有项目推进能力，也要有现场节奏感。
3. 试运行、目标检查与迭代
AI项目真正的挑战，往往从试运行才开始。
FDE在现场需要配合客户完成业务梳理、知识准备、业务测试、效果检查、问题分析和改进方案制定。比如知识库答案不准确，到底是解析问题、切片问题、检索问题，还是业务流程本身没有定义清楚？这些都需要有人在现场快速判断。
然后，FDE需要把现场问题转化为明确的迭代目标，与客户和己方产研团队一起推动优化。这个过程本质上不是“交付一个系统”，而是“让AI能力在业务中稳定产生价值”。
三、AI服务商需要作出的改变
其实在FDE概念变热之前，我们对内部人员的要求已经在发生变化。
2025年，我们的AIS小分队曾在深圳某银行客户现场驻场长达6个月。当时我们就在思考：如果未来不断面对银行、能源、政企等高安全行业客户的AI实施需求，就必须有更多能在现场沟通、开发和直接解决问题的工程师。所以从今年开始，我们在人员结构上也在主动往这个方向调整，需要建立更快速、更机动的现场团队。
虽然Vibe Coding让产品升级迭代速度成倍提升，但一些现场工作依然无法被替代。尤其是在企业AI项目中，客户的数据环境、网络环境、权限体系、业务流程和组织结构都不一样，而且很多高安全行业的客户的数据无法出域，很多问题只有进入现场才能真正看清楚。
所以我们一直有一个很明确的判断：解决客户问题永远是第一位。
但这里也必须强调一点：FDE和传统外包完全不同。
外包更多是客户安排任务，供应商按需求完成交付。而FDE不是被动接单的人，而是AI项目最核心的推动者之一。FDE要拉着甲方业务和技术团队，以及己方产研团队一起，把项目真正落地。
FDE交付的基础是己方产品，目标是弥合产品能力与客户真实需求之间的差距。FDE需要参与客户会议、直接上手操作、部署系统、组织培训、记录问题、反馈需求、制定迭代计划，甚至在现场完成一些编码或交付任务。
为了降低FDE在现场的开发工作量，我们也对AIS产品做了很多调整。比如开放知识库管理、对话服务、应用管理、组织权限管理、系统设置、Skill管理、MCP管理和原子命令等API/SDK，让现场团队可以更轻量地利用API进行二次开发。同时，我们也会为每个项目成立火力支援小组，为FDE提供技术、文档和产品迭代等方面的支持。
这背后其实代表着AI服务商的一种组织变化：不能只依赖销售、售前和交付的传统分工，而是要形成“产品能力 + 现场工程能力 + 快速迭代能力”的闭环。
四、对从业人员的影响
我不知道像我们这样已经在改变的公司有多少，但随着AI落地进程的深入，我相信类似FDE这样的角色，在组织中的占比只会越来越高。
这并不意味着每个人都要成为FDE，但它确实会改变很多岗位的能力要求。对于研发人员、产品经理、解决方案人员来说，未来都需要具备更强的复合能力。
培养全栈能力。尽快弱化“前端、后端、产品经理”这种过于固定的岗位边界，尽量往全栈能力转变。AI时代的项目节奏会更快，一个人越能跨环节解决问题，价值越大。
需要提升交流和倾听能力。很多时候，客户并不能一开始就准确表达自己要什么。你需要和客户一起梳理问题、确定目标、制定计划。也许不是每个人都需要备具整个项目的架构能力，但一些局部任务依然需要这种能力。
学习行业知识。比如让自己深入理解2到3个行业的业务Know-how，通过不断实践积累对这些行业的理解能力。AI落地不是纯技术问题，行业理解会越来越重要。
适应快速机动。可能要适应中短期出差和现场工作，除非你真的相信，只靠在线会议和文字沟通就能快速解决复杂问题。否则还是要记住那句话：解决客户问题永远是第一位。我们要深入现场。
回到标题的问题：FDE会是2026年AI落地之道吗？
我觉得它不一定是唯一答案，但大概率会成为非常重要的一条路径。因为AI真正进入企业，不只是模型能力的问题，也不是产品功能堆叠的问题，而是要有人把技术、业务、组织和流程连接起来。
而FDE，正是站在这个连接点上的人。
