基础认知 · 小白也能看懂
什么是FDE？
FDE = Forward Deployed Engineer，也就是深入业务一线、把技术真正落地的人。
三个英文单词，到底是什么意思？
往前走，到一线去
这里不是网页开发里的“Frontend（前端）”，而是指工程师不只坐在总部等需求，而要靠近客户、靠近用户、靠近真实业务现场。
部署到真实环境
不是做完演示就结束，而是把方案接进企业的数据、权限、系统和岗位流程，让它能在每天的工作里运行。
用工程方法解决问题
既要理解技术，也要会拆问题、做原型、处理异常、定义指标，并把一次经验整理成以后可以复用的能力。
企业真正缺的，往往不是另一个AI工具
很多企业已经买了AI工具、组织了培训，也做过看起来很厉害的演示，可过几天员工还是回到Excel、微信群和手工复制粘贴。就像家里买了一台很贵的洗碗机，如果水管没接、厨房放不下、家里人也不知道怎么用，它最终只会变成一个昂贵的柜子。
问题通常不是AI不够聪明，而是它没有接上企业的数据、权限、系统和日常流程。销售完成签约，顾问交完方案，开发做完功能，每个人都完成了自己的任务，却可能没人一直追问：员工到底用没用？时间有没有省下来？错误有没有减少？
FDE从哪里来？
FDE的经典原型通常追溯到美国软件公司 Palantir 的早期实践。Palantir当时服务的不是普通网店，而是情报、国防、执法等高度复杂的机构。难点在于：客户很难直接说清楚需求，有些工作甚至不能完整对外描述；不同部门的数据、术语和流程也完全不同。
于是团队采用了一种很“笨”、但非常有效的方法：先做一个能看的小版本拿到客户面前。客户看完说“这根本不好用”，他们不急着争辩，而是继续追问：“具体哪里不对？你真正工作时需要看到什么？”然后把反馈带回去，迅速修改，再拿回来试。
这就像裁缝第一次给人做西装。客户很难只靠嘴把肩宽、活动习惯和穿着场合说清楚，但先做一件样衣，让他穿上走两步，哪里紧、哪里长就一目了然。FDE的起源，本质上就是用真实使用代替凭空猜需求。
早期现场小队：一个找准问题，一个快速做出来
Palantir早期的现场模式不是让一个“全能英雄”包办一切，而是把两种能力放在一起：一类人深度理解客户和业务，另一类人快速把想法做成能运行的东西。
懂现场的人：先找到真问题
长期和用户交流，观察他们每天怎样判断、怎样协作、哪里最痛苦。他不只记录“客户想要一个按钮”，还要追问这个按钮背后真正想解决什么。
懂工程的人：把想法迅速变成原型
不追求第一版就完美，而是尽快做出可试用版本。只要真实用户一用，就能知道方向对不对，再决定哪些地方值得继续投入。
放到今天的中国企业里，这两种人有时由同一个FDE承担，有时由“业务顾问＋AI工程师”共同完成。形式可以不同，但两种能力缺一不可：只懂业务，方案容易停在纸上；只懂技术，做出来的东西可能没人使用。
从“碎石路”到“高速公路”是什么意思？
FDE模式有一个很形象的比喻：第一次解决某家企业的问题，就像先铺一条能通车的碎石路。它不一定漂亮，也不适合所有人，但能让这家企业先走起来。
当不同客户反复遇到相似问题时，总部产品团队再把这些零散做法整理成标准接口、通用组件和稳定流程，就像把碎石路修成高速公路。以后遇到类似客户，不需要每次从泥地里重新开路。
现场开路
先为一个真实问题做出能用的小版本。
反复验证
观察用户怎样使用，记录失败和例外情况。
沉淀通用能力
把重复部分做成模板、组件或平台能力。
FDE模式的三个动作：做成、证明、复用
先做成一个关键问题
不一上来改造整家公司，而是找到一个重要、具体、可以衡量的小问题，把它真正放进流程。
用结果证明有价值
看员工是否采用、处理时间是否减少、错误是否下降，而不是只看演示时大家有没有鼓掌。
把经验变成可复用能力
把项目中的通用部分整理成模板、连接器、知识库或工作流，降低下一个项目的成本。
从一个小场景逐步扩展
先在一个岗位跑通，再扩展到相邻团队和流程，避免一开始就铺得太大、最后谁也用不好。
为什么FDE现在突然变火？
今天的AI和早期复杂软件遇到了相似问题：模型能力很强，却没有一本现成说明书告诉企业“应该把它放到哪条流程、接哪些数据、怎样处理失败”。尤其是智能体可以读文件、调用工具、执行多步骤任务以后，产品探索必须进入真实业务，FDE因此重新受到关注。
AI能力变强了
以前很多需求根本做不到，现在模型能读文档、看图片、写代码、调用工具，企业终于有了真正改流程的可能。
工具越来越多了
选择多不等于会落地。就像建材市场商品越多，普通人反而越需要一个懂施工的人帮忙组合。
演示和使用差距很大
五分钟演示很漂亮，真正上线却会遇到权限、脏数据、异常处理和员工习惯，这些都需要现场解决。
企业开始要结果
老板不再满足于“我们也用了AI”，而会追问省了多少时间、减少多少错误、有没有带来收入。
FDE日常怎么工作？
它不是一次性项目，而是一个反复循环：先看现场，再做小版本，拿真实结果验证，然后继续调整。像医生看病一样，不能只看一张体检报告就开一年的药，而要问症状、做检查、先试用、看反应，再调整方案。
进入业务现场
先理解企业真正怎么工作：数据在哪里、谁在使用、流程卡在哪里、失败会造成什么影响。
把AI做进流程
不止展示一个聊天窗口，而是连接企业现有数据、权限、系统和具体岗位动作。
用结果持续校验
提前定义准确率、采用率、处理时间、人工接管率等指标，上线后持续修正。
把经验沉淀复用
将重复出现的问题整理成模板、连接器和工作流，让下一个项目更快、更稳。
FDE不是什么
不是只提建议的顾问
建议只是开始，还要把方案做成企业能够真实使用的系统。
不是只讲方案的售前
不以完成演示和签约为终点，而要面对生产环境中的真实问题。
不是只按需求写代码的外包
需要判断哪些需求真正影响结果，而不是被动实现一张功能清单。
不是卖完工具就离场的厂商
重点是工具如何进入岗位和流程，以及员工为什么愿意持续使用。
一个靠谱的FDE，需要哪些能力？
FDE不是“什么都会一点”这么简单，更像球队里的中场：既要听懂教练的战术，也要看清场上局势，还要能把球送到合适的位置。
- 听得懂业务人员在说什么，也能追问出真正的问题；
- 了解模型、工作流、数据接口和系统集成；
- 知道哪些数据能用、谁有权限、怎样保护隐私；
- 能快速做出小版本，而不是先写几十页大方案；
- 会定义效果指标，不拿“感觉不错”当验收；
- 能培训用户、处理抵触，并推动新的工作习惯形成；
- 知道什么时候应该用AI，什么时候普通自动化更合适；
- 能把一次项目沉淀成下一次可以复用的模板。
什么情况下，企业可能需要FDE？
- 做过AI试点，但一直停留在演示阶段；
- 买了很多工具，却没有进入核心工作流程；
- 业务部门和技术部门互相听不懂；
- 项目涉及内部数据、权限、审批或多个系统；
- 企业希望先从一个小场景验证，再逐步扩展；
- 需要有人同时对工程实现、用户采用和业务指标保持关注。
FDE123在其中扮演什么角色？
FDE123首先是一个信息与导航平台：帮助企业理解AI落地方法，找到工具、场景、案例、FDE和服务商。平台会进行基础资料核验，但不参与项目合同、收款、实施和验收，也不对第三方服务结果作担保。