从 AI Coding 到 AI Office，岗位合并正把应用层的研发统一成 AI 工程师，产品侧同步长出 AI 产品经理，中间多出一个 FDE。作者把三者的能力边界、SOP 与数据两个维度、十二象限的定位拆开讲清楚。

FDE 是近期的一个热词，我预测他在今明两年都会频繁出现，会是个热门岗位。

为什么呢？

因为各个公司被小龙虾洗脑后，加之 AI Coding/AI Office 工具越发强大，在先驱者尝到 AI 的甜头后，各行各业“见贤思与齐”，都陆续开始了 AI 转型，而结合近半年的线下 AI 陪跑/培训情况：

几乎所有的转型结果都是岗位合并，而岗位合并一定会带来岗位消亡

比如，从研发体系来说，前端这次是真的“要死了”，并且不单是前端“要死了”，后端岗位也会迎来很大的变化，毕竟现在代码都不是自己写，所谓 Java、PHP、python 与否其实都不太重要了。

现在的情况与趋势是，所有的应用层研发岗位都会统一为 AI 工程师，这首先是技术发展的结果，其次是各个企业希望看到的结果。

而由于 Coding 技术门槛的降低，产品经理也开始同步扩展边界，衍生出 AI 产品经理的岗位，甚至有些激进的公司直接将产品与研发岗合并，追求真正的 AI 全栈工程师，只不过从实践来说 AI 全栈暂时还不太行。

或者换个说法，产品很难成为 AI 全栈，而研发对于产品的活要么兴趣不高、要么不太擅长，这里仍有大量走展空间。

再从技术版本迭代来说，AI 的影响自然不只是产研，真正的 AI 转型一定是面向公司整体做设计的，这意味着大家的工作方式都会发生变化，这背后所带来的是信息通道的重建、评价体系的重建。

作为员工直接能看到的就是组织结构的变化、工作依赖系统/平台/工具的变化，因为上层发生了变化，所以各个岗位都不能幸免，业务前端如售前、销售，职能部门如 HR、财务、PMO 等等都会跟着变……

那么这里问题就来了，业务侧、产品侧的工作改造已经被 AI 工程师/AI 产品经理包圆了，那么公司内部的 AI 改造应该由谁来进行？

答案是由他们自己进行，毕竟各个部门是有自己独立专业 KnowHow 的，于是乎各个公司正在进行 AI 转型，或者因为 AI 转型而诞生的新岗位出现了，他的名字就是：FDE。

至少从我所观察/服务过到的 10 多家公司来说，FDE 都是因 AI 转型而诞生的岗位，他也是岗位合并的结果。

同样的，很多公司就是自己搞不懂/搞不定 AI 转型，所以会请乙方 FDE 驻场协助，其中包含三点需求：

1. AI 工具学习；
2. 组织如何变化；
3. 具体项目开发；

而很多人会放大其中 AI 项目开发的比重，于是业内关于 FDE 最通用的误解就来了：FDE 就是外包。这就是典型的一知半解了。

综上，大家对 FDE、AI 产品经理、AI 工程师有了初步了解，但作为进入 AI 行业的三大重要岗位，他们具体的差异是什么，多数人还是懵的。

FDE 的目标与能力要求

可以说现阶段 AI 就是为蒸馏或替代而生的：

GEO 的目标是 SEO、AI 漫剧的对象是演员体系，还有 AI 医生、AI 律师等都是为了完整替换或者部分替换真人而出现的。

所以每个公司其实有两套系统：

• 一套业务系统，为解决某一行业问题，核心由产研负责的体系，这个大家相对清晰；
• 一套管理系统，就是解决公司内部运转问题的，这套系统暂时是 FDE 在负责；

综上所有内容，FDE 的目标就很清晰了，就是为了完成这套管理系统的升级：推动组织完成 AI 转型。

目标清晰后，FDE 对应工作也就很确定了，这里无论是甲方自己的 FDE 还是外部请的 FDE 顾问，工作内容都一样：

首先第一，员工 AI 能力的培训，这里核心又会涉及两点，常用AI工具的学习与业务 KnowHow 转换为 SOP 的方法论；

其次第二，组织适应于 AI 的改造，这里会涉及组织架构的变化、工作流程的变化，做得深的还会涉及系统性的员工、工作任务评价方式的 AI 化，如果更进一步还会涉及公司级 AI 操作系统的搭建；

最后才是第三点，AI 对业务上的改造，将业务里面能够基于 AI 重新实现的做一次，或者完全根据 AI 的特性将原来固有的产品完全重新设计，以达到效率更好的目标，这里一般有与产研合作，作为辅助角色/业务专家角色参与。

工作内容确定后，对应的难点卡点也就出来了，因为从我们线下实践的数据来说，每个公司都呈现出了相似的情况（数字会不同）：

一个公司，30% 的人在创造价值，40% 的人直接在摸鱼，40% 的人在互相创造工作，互相创造价值，他们可能在创新（假装很忙，表演工作）

而 AI 转型的残酷性也就出现了：

做 AI 原生组织转型就是找到那 20% 愿意拥抱AI的并且【有价值】的人，转化其中 40% 的【中间派】，干掉 40% 的顽固派，这就是 AI 原生组织转型

那么进一步解释下什么是愿意拥抱 AI 呢？就是愿意积极主动整理、贡献出自己的业务 KnowHow 蒸馏自己、蒸馏自己的团队、形成 SOP，然后用 AI 去承载这些 SOP…

所以，AI 转型是一个挤牙膏行为，不断去把团队里面可以被自动化的部分全部干掉，最后留下必须人参与的部分…

从这个角度去看，AI 原生组织效率肯定就高了，一方面是自动化程度高、一方面是组织人少了，管理内耗会少很多……

并且，无论从目标还是过程去看，做 AI 转型会遭遇到的冲突会变得非常频繁且具体，相应着对 FDE 的能力要求也不太低，总结下来就是三个专家：

一、管理专家

为什么要是管理专家，因为我们之前也说了：做AI原生组织转型就是找到那 20% 愿意拥抱 AI 的并且【有价值】的人，转化其中 40% 的【中间派】，干掉 40% 的顽固派。

所以，你能不能有效识别谁是朋友，能不能借势拉拢中间派，打击顽固派，这是非常费力不讨好的事情，很容易得罪人，这里面任何一件事都是故事。

正因如此，从目标上就会要求 AI/FDE 负责人要是个非常能折腾的人，这个能折腾当然不能是无垠之水，一定是这次AI原生组织转型能给他带来不小的收益，这里可能是升职加薪、也可能是团队盘子过大。

也就是说 AI/FDE 负责人其实是要身带杀气的，老油条、老滑头、好好先生都做不好 AI 原生组织转型，很容易遇到点事情就散了、就退了。

AI 原生组织转型是一件外儒內法的事情，是一件脸上笑嘻嘻心里 MMP 的事情，对一号位的要求还挺高的。

大家判断自己是不是管理专家，可以测试下下面问题：

• 第一，AI 原生组织转型会遭到什么阻碍，或者他们是如何失败的
• 第二，他们是如何成功的，应该如何掌握节奏

二、AI 专家

说完了管理专家，接下来是 AI 专家，这个事情就比较具体了，是硬实力的绝对体现，也是 FDE 这个事情的专业门槛。

当然，这里并不是要求大家一定要多么会写代码，但关于 AI 核心的历史，以及大概的知识框架，这个是一定要具备的。

比如，随着 GPT 发布一来，经过近3年的发展，AI 世界一天一个样，那他到底是变化得快还是变化得慢，这个基本的判断大家是必须具备的。

当然，这里面最为核心的是对 AI 工具的掌握和应用，如何配合业务专家的能力做出实际的成绩。

三、业务专家

业务专家就不过多赘述，就是要将业务 KnowHow 转为可以落地执行的 SOP/Workflow，业务专家这个角色，无论什么时候都不会过时，他可能的产出物如下：

综上，可以看出 FDE 核心的能力有两点：

1. 输出自己的 SOP/蒸馏自己；
2. 拥有一套输出 SOP/蒸馏别人 的方法论，可以做其他领域的 FDE；

除此之外就是最基础的通用能力了，需要掌握几个常用 AI 工具，详细可以参考这个体系：

FDE → AI 产品 → AI 工程师

至于说，FDE、AI 产品经理、乃至 AI 工程师到底有什么相似的地方和不同的地方，要真说清楚这东西又得引出我们最核心的 AI 框架了：

这里核心其实是一个属性 KnowHow，他会被分解为 SOP 和 Data，由此可以形成一系列 AI 项目类型：

这里 FDE 的舒适区就很清晰了，就是工作流 AI

这里中间部分的内容，AI 产品经理和 AI 工程师的能力区间会稍有重合，但越往下就越是只能 AI 工程师切入了，这里最核心的差异也就很清晰，是对数据复杂度的驾驭能力，举个例子：

如果我们对 FDE 的目标是协助公司做组织 AI 转型，那么他做的个人系统的体验、权限、并发、迭代等问题是无所谓的，甚至部门内使用上述问题都可以克服。

这里最核心的原因就是：我们自己用，我们有一定容错率。

但一旦涉及生产级业务 AI 的时候，往往只能 AI 工程师出手，当然我也看到过产品出手的情况，但前提是他们在研发建立的平台，比如 Coze 平台上去做节点层级的动作。

现阶段来说，要给 2C 用户用的系统，对迭代有要求，错一点损失很大的系统，还是会让 AI 工程师最后兜底。

所以，当前 FDE 和 AI 产品在某个阶段的工作是类似的，他们从提供 SOP（意见）、提供需求文档，变成了提供 Demo，甚至可以用起来接近生产环境的 Demo。

从蒸馏角度看三者舒适区

这里再具体一点，我们从员工蒸馏的角度来看三者的区别：

员工蒸馏 = 将员工某一段 KnowHow 程序化；而 KnowHow 又可以被拆解为 SOP/Workflow 和 Data。

所以，这里就会出现两个核心指标：SOP复杂度（或者叫Workflow复杂度）x 数据复杂度（数据量、数据结构），我们这里来依次做下拆解。

SOP 复杂度

这里对SOP的描述不用非常复杂，大家就按高中低来理解就行：

第一，所谓低 SOP，就是个人流程，几步就可以走完那种工作流。典型的场景是身份证、简历信息识别，公众号文章生成.skill，或者查询AI率的工具。

第二是中 SOP，大家可以简单理解成两种，单人 SOP 步数很长或者需要多人协作那种工作流。典型场景是 HR 招聘流程、销售线索分配流程，一整套公众号文章编写发布流程。

第三是高 SOP，这个往往是非常复杂的流程了，可能会形成回路，步数呈网状结构，会有回退步骤，或者就是参与的人极多。这里典型场景就是我们之前做的电商企业全案业务 AI 化 SOP 了。

就我们前面的论述，FDE 最核心的能力就是整理出这些 SOP。

数据复杂度

然后就是数据复杂度了，数据是行业 KnowHow 的经验数字化，他是为了配合 SOP 而出现的，行业里面处理数据这块的工作被称为数据工程，数据工程的任务是用数据去理解或者解释真实的业务世界，所以这块可能很难。

我们按高中低无四个等级来划分：

第一是数据无，也就是没有私有数据需求，或者私有数据极少，放到提示词中就完事了，模型当前材料已经足够完成任务了。

第二是数据中，这种开始需要调用私有数据了，但往往数据量较小，处理起来很简单。

第三是数据高，这个场景需要多数据源了，比如做一个客户全景档案，就需要从 CRM、投诉客服系统、付款系统等不同地方拉数据。

第四部分，数据复杂度极高，也就是今天会涉及的部分，这个场景中数据之间是存在关联关系的，可能会用到知识图谱这种技术，维护、更新成本极高

十二象限

这个时候，我们再从蒸馏的角度去填这个 12 象限，他是这样的：

而 FDE 就只在第一列三个象限，AI 产品经理后面三列都需要参与，但很难独立完成工作，反过来虽然 AI 工程师能够在工程能力上完全覆盖这 12 个象限的项目，但他并不能独立工作，因为他需要业务知识，无论是其中的 SOP 生成还是后续长期的 Data 维护，都需要业务专家的切入。

综上，FDE、AI 产品经理、AI 工程师的能力边界和工作内容就相对清晰了：FDE 当前更偏向于组织内管理侧的 AI 组织重构、AI 产品经理更偏向于业务重构，而他们想要平台化、生产化暂时都离不开 AI 工程师。

综上，三者的差异是：

三大 AI 岗位的相关性

讨论到这里，大家应该能看出来，三者之间有大量重合：都要理解业务，都要梳理任务，都要使用 AI，都要做出东西，也都要证明效果。

三者都在将业务 KnowHow 拆成 SOP 和 Data，再交给 AI 承载，差异在于主要负责什么以及对什么进行兜底，但这里对于 AI 产品可能有个较为尴尬的点：KnowHow 来自业务、工程门槛在技术，产品经理的不可替代性其实很低。

我们今天说的 FDE，重心是组织转型，核心能力是业务梳理、管理协调与变革推进，最终要让组织的工作方式发生变化。

产品经理，曾经的重心是产品定义与价值验证。当前很多 AI 产品经理其实在覆盖完成 FDE 乃至工程师的工作。

AI 工程师，重心是数据与生产工程。核心能力是数据建模、系统架构与可靠性设计，解决拿到、拿对、拿全、不拿多及持续运行的问题。

三者的交集也很清晰：

• FDE × 产品经理：业务重构、SOP 共创与规则提炼。
• 产品经理 × 工程师：产品行为、知识结构与评测设计。
• FDE × 工程师：工具集成、现场联调与问题回流。

数据和生产要求越复杂，越需要工程能力；而业务知识的提供、验证与维护，始终需要专家参与。一个人可以兼任多个角色，相应的责任也要一起承担。