最近整理两份关于 FDE 的笔记，我觉得里面最值得普通人关注的，不是“FDE”这个新名词，而是它背后的工作变化。

过去大家比的是：谁知道的工具多，谁会写提示词，谁能把模型用得更熟。

但企业真正愿意花时间解决的问题是：AI到底能不能进入业务流程，能不能被员工用起来，能不能持续产生可检查的结果。

这就引出了 FDE。

FDE 的全称是 Forward Deployed Engineer，通常译为“前线部署工程师”。简单说，它不是坐在后台做演示，而是和业务方一起，把 AI 从一个 demo 变成真实工作流程的一部分。

一、FDE解决的不是工具问题

很多企业并不是没有 AI 工具。

他们可能已经注册了好几个平台，也让员工试过聊天机器人，甚至做过一次内部分享。

但一段时间以后，工具还是工具，业务还是原来的业务。

原因通常有三个。

第一，没人知道 AI 应该落在哪个环节。

第二，没有把业务流程拆成清楚的输入、判断和输出。

第三，系统上线以后没人负责培训、修正和复盘。

所以，FDE 的价值不是再推荐一个工具，而是先进入业务现场，找到真正值得改造的环节。

二、一个FDE至少要做四件事

第一，做业务诊断。

先看企业每天到底在做什么，哪些工作重复、耗时、规则相对清楚，哪些环节最适合先试。

第二，搭出最小可用系统。

把选中的流程拆成输入材料、判断标准、AI 执行步骤、输出格式和保存位置。必要时再接知识库、Agent、Skills 或接口。

第三，让员工真正用起来。

系统不是交付一个链接就结束。要把使用方法讲清楚，观察员工在哪一步卡住，再根据真实使用情况调整。

第四，持续复盘。

检查系统是否减少了重复劳动，输出是否稳定，哪些地方仍然需要人工判断。能复盘，才有可能把一次交付变成可复制的方法。

三、普通人怎么开始准备

不需要一上来就把自己包装成“AI专家”。

可以先走四步。

第一步，选一个你熟悉，或者愿意长期研究的行业。

不要一开始就说“我能帮所有行业做 AI”。行业越宽，越难理解具体业务。

第二步，选一个具体场景。

比如内容整理、客户问题分类、销售线索记录、内部知识检索、日报周报生成。先选高频、规则清楚、结果容易检查的工作。

第三步，亲手跑通一个闭环。

你要能说清楚：输入是什么，AI做什么，输出是什么，保存在哪里，哪一步必须人工确认。

第四步，把过程沉淀下来。

记录你看到了什么问题，做过哪些调整，最后形成了什么模板、清单、工作流和验收标准。

这些东西，才是你以后继续交付时真正能复用的资产。

四、FDE和普通AI工具使用者的区别

会用工具的人，通常关注“这个工具能做什么”。

FDE 更关注“这个业务环节为什么值得改，以及改完如何验证”。

会用工具的人，交付的是一次输出。

FDE 交付的是一套能被使用、能被检查、能持续调整的流程。

会用工具的人，遇到问题容易换工具。

FDE 会先检查需求、流程、数据和使用方式，再判断是否真的需要换工具。

这不是说工具能力不重要。

而是工具能力只是起点，业务理解和交付能力决定了 AI 能不能留下来。

五、先别追风口，先做一个真实案例

关于 FDE 岗位数量、薪资水平、企业需求规模，原始笔记里有一些很有冲击力的判断，但目前没有在本地完成独立核验，本文不把这些数字作为事实依据。

更可靠的起点，是先做一个真实的小案例。

可以从自己的工作开始，也可以在获得同意的前提下，帮熟悉的人优化一个低风险流程。

把过程完整记录下来：原来的做法是什么，最费时间的是哪一步，AI如何介入，结果如何检查，使用者提出了什么反馈。

案例不需要一开始就很大，但必须真实、具体、可复盘。

当你能连续跑通几个这样的闭环，你才真正开始从“会用 AI”走向“能让 AI 落地”。

FDE 值得关注的地方，也许不在于它是不是一个热门职位，而在于它代表了一种更重要的能力：把技术翻译成业务，把一次尝试沉淀成系统。