为什么最懂客户的人反而最焦虑
AI-FDE 转型之路 · 开篇
一、先说结论
我先说结论：AI 这一轮下来，最危险的不是"不会写代码"的人，而是只会传话的人、而是不会使用AI的人。而最有机会的，恰恰是常年泡在客户现场、知道业务怎么跑的那批人、懂得使用AI的人。
本人在客户现场待了十几年，做过实施、做过售前、做过管理、也救过很多次火。这两年跟同行聊天，焦虑是普遍性的，而且越懂业务的人焦虑越重。有时候不知道IT行业方向在哪里，也不知道在AI方向怎么发力。
原因不复杂：以前我们最值钱的能力是"把客户说的翻译成开发能听懂的，把开发做的翻译成客户能接受的"，这个翻译工作看上去能被 AI 直接吃掉。需求文档它能写，SQL 它能写，汇报 PPT 它也能写，用不到咱们了。我认为这个焦虑是有用的，起码发现了AI的价值，但是我们怎么更好的把握这次机会呢。
大家都说AI 会先吃掉"翻译"，再往上吃，这个是没错的“翻译”的工作肯定会吃掉。现实中事情：AI 最先吃掉的，是那些不需要承担后果的脑力活——写个初稿、查个资料、拼个方案。真正难被吃掉的是三件事：知道客户哪个需求是真痛点哪个是随口一说；知道一个系统在客户机房里跑起来要过哪些关；知道出了问题谁该在几点被叫醒。这三件事的共同点是都对结果负责。
我见过最典型的反面例子：一个团队把大模型接进了客户的知识库，Demo 当场效果很好，客户当场点头。上线第三周停用。不是模型不行，是没有人提前跟客户约定"答错了怎么办"，也没有人告诉客户经理哪些问题必须转人工。技术问题只占三成，剩下七成是没人负责定义边界。
怎么解决这类问题呢，这类活，行业里有个名字叫FDE。
二、什么是FDE
FDE（Forward Deployed Engineer，前置部署工程师） 不是一个新词，但是今年比较火，尤其是 AI 真正可以帮助企业解决问题的时候。这类活，之前叫驻场工程师，也可以叫外包人员，需要驻场在客户现场，与客户一起工作，帮助客户解决最后一公里的问题。FDE 岗位需要 T 型复合能力的人才，是一个紧缺的岗位。
个人认为，FDE与传统驻场工程师最大的区别：传统驻场工程师是从需求文档出发，而FDE是从业务观察出发。一个是被动接受需求，另一个是主动解决实际问题。
在AI+时代中，AI-FDE又是什么呢？把它翻译成一句大白话：站在客户现场，对 AI 系统的结果负责的那个人（以终为始）。他不是去客户那里写代码，而是保证这套东西在客户的环境里真的能用、真的有用、出了事真的有人兜底。可以不会写代码，但是可以借助AI工具完成目标工作。
三、AI-FDE需要哪些技能
要成为AI时代的FDE，需要哪些技能呢？
我做了一个 AI-FDE 的测评网页（使用 AI 帮忙做的），可以通过测评网页来评估自己的 AI-FDE 水平，看看自己可以得到多少分。
也可以扫描一下二维码（长按二维码，扫描跳转到测评网站）。
在测评中，我把AI-FDE岗位拆成了六大模块、53 项技能，每项标了等级和"怎么算会了"。这些技能，不是我拍脑袋列的，是根据客户现场需要什么能力、客户业务需求需要什么能力，然后根据需要的能力进行倒推。
AI-FDE的六大模块包括：
- Business · 业务发现
- AI Engineering · AI 工程
- Software Engineering · 软件工程
- Enterprise Integration · 企业集成
- Operations Engineering · 运维工程
- Delivery & Communication · 交付沟通
AI-FDE的53项技能包括:
AI-FDE六大模块中53项技能是怎么分布的呢，最主要是AI工程、业务发现、运维工程。
| 模块 | 项数 | 回答什么问题 |
|---|---|---|
| 业务发现 | 8 | 这个场景该不该做、值多少钱 |
| AI 工程 | 16 | 模型这条链路每一段在干什么、坏了怎么定位 |
| 软件工程 | 8 | 怎么接入现有系统、别人的活怎么验收 |
| 企业集成 | 7 | 身份、权限、审计、数据不出域这些硬门槛 |
| 运维工程 | 6 | 上线之后怎么活：可见、可算、能恢复 |
| 交付沟通 | 8 | POC、Demo、文档、合规、兜底、交接 |
四、怎么成为AI-FDE
根据AI-FDE自评能力地图，我会为每一项技能至少写一篇文章，用来帮助大家一些来了解和学习这一项技能，也就是至少55篇文章（含开篇+结束篇），也算一个大工程了。
55 项听起来吓人，但其中真正要求你动手写代码的，一双手数不过来，但是多双手就可以数过来，哈哈。大部分还是是判断力和业务流程的能力。
上面这个顺序是能力地图，用来回答"这个岗位到底要会什么"。但它不是学习顺序。
我按见效快慢重排了一条速成路径，本系列就按这个顺序发（可能期间有所调整）：
| 发布批次 | 模块 | 为什么先发它 |
|---|---|---|
| 第 1 批 | AI 工程（16 篇） | 地基。不懂链路，业务发现时你连"能不能做"都判断不了 |
| 第 2 批 | 运维工程（6 篇） | 运维背景的主场，最快变现，先把信心立住 |
| 第 3 批 | 业务发现（8 篇） | 懂了技术边界再谈需求，才知道该问什么 |
| 第 4 批 | 软件工程（8 篇） | 让技能更专业，主要是运用，不是讲语法 |
| 第 5 批 | 企业集成（7 篇） | 进不去企业流程，前面全白搭，怎么可以集成到企业内部 |
| 第 6 批 | 交付沟通（8 篇） | 更好进行现场交付，更好的服务客户 |
最重要的是前三个能力：AI-FDE必须要掌握AI工程的能力，其次是运维工程能力，因为客户上了您的AI，您肯定要优先保证不能影响客户的业务。有了以上两个基础能力外，就可以进行“业务发现”，可以根据企业的现状，进行AI能力的优化，也可以叫智能化升级。
最后三个能力：软件工程能力，可以让您更专业，您专业了可以更好的服务客户，更好的服务更大的客户；企业集成能力是在大企业中怎么嵌入到业务流程中；交付沟通能力，是让您可以更好的在现场从容的交付。
五、文档的形式是怎么样的呢
这系列文章是统一按照“文档标题 + AI-FDE转型之路+模块名称+编号”。例如：
“先搞清楚模型一定会错在哪｜AI-FDE转型之路·AI工程01”
意思是 AI 工程的文章的第1篇。不用全局连续号，是因为中途点进来的读者看到"第 39 篇"没有参照系，而且以后某卷要补章，全局号就得整批往后推。
六、这系列写给谁、怎么写
当然第一是写给我自己的，让自己整理日常工作的内容，让自己有一个回顾的地方。第二呢，如果我的文章可以帮助到别人，那更好了，互联网本来就是相互分享的。
基于第二个考虑，我尽量不写太技术的内容，让更多的人可以看得懂。让基本不写代码、但手上有真实客户和项目的人：实施、售前、运维、项目经理，可以看得懂，可以进行FDE技能的加持。
本系列的口径是低代码优先，代码只到"读得懂、改得动"为止。
还有一件事要提醒，本系列里出现的客户、项目、人名全部是虚构的——我不能拿真实客户的项目细节来写文章，你也别把虚构的那些数字当成行业基准。用到的数字都会标「示例数字，仅用于演示算法，不构成承诺」。
七、最后一些实话
看完这 55 篇不会让你自动变成 AI-FDE。它给你的是一张地图和一套自检标准，真正让你转型的是拿一个真项目把这些技能串一遍。别等学完再动手，边做边对照着看。
如果大家找不到方向，不知道干什么，又不知道自己喜欢什么。可以参考雷军说的“不知道喜欢什么，就先干起来，干着干着就找到了”。
希望咱们都可以找到自己喜欢的事情，可以找到可以长期做的事情，干起来吧！欢迎大家订阅、转发。
《AI-FDE 转型之路》：写给不写代码的 IT 实施 / 售前 / 运维，把已有的交付能力「AI 化」。全系列 55 篇，六大模块 53 项技能，一项技能至少一篇。