万字血泪史丨硅谷爆火的 AI 新职业 FDE，到底是干啥的？
内容作者丨大燕麦logic
内容排版丨特工小天
最近关于 FDE 的讨论非常多。观猹平台上的作者 @大燕麦logic 发表了三篇层层递进的帖子，在站内引发热烈反响。这三篇文章分别探讨了 FDE 的定义、切入点以及交付流程，评论区不少从业者直呼“太真实了”。
经本人同意，我们将这三篇文章整理成合集发布，方便大家一口气读完。
FDE 的真正面目：不只是工程师，而是“AI HRBP”
FDE 的全称是 Forward Deployed Engineer，直译过来叫前线部署工程师。
这个岗位最早由 Palantir 开创。由于 Palantir 的产品非常复杂，客户购买后往往不会使用，也不知道如何将其接入自己的业务流程。普通实施顾问不懂代码，普通工程师又离客户太远，因此 Palantir 采取了一种新模式：直接把工程师派到客户现场——一边听业务需求，一边写代码、调接口、搭数据管道，现场把方案做出来。
这是 FDE 的原始定义：
FDE = 被部署到业务一线，打通「理解需求 → 现场开发 → 交付方案」的人。
但到了大模型时代，这个定义已经不够用了。以前的 FDE 是帮客户用好软件；今天的 FDE 是帮客户把 AI 塞进业务流程里，重新定义“谁干什么、谁不用干了”。因为 AI 改变的是判断、整理、沟通、执行等工作流。
所以，今天我们讲 FDE，可以用一句话概括：
FDE 是一个被部署到业务一线，用 AI 把多个岗位的工作合并成一套方案的人。
为什么 FDE 像 HRBP？
我们为什么要把 FDE 和 HRBP（人力资源业务合作伙伴） 叠在一起看？
- HRBP 是老板派到业务部门里，重新配置“人”的人。组织要不要扩员、哪些岗位要裁、变革怎么推下去，这些都是 HRBP 要处理的问题。
- FDE 是老板派到业务现场里，用 AI 重新配置“人 + 工作流”的人。原来一个流程里有产品、开发、测试、运营、客服，现在 AI 能不能接住？哪些岗位可以合并？哪些人不再需要那么多？这是 FDE 要回答的问题。
两者的结构是一样的。所以 FDE 的真正面目不是工程师，而是 AI HRBP：
用 AI 这个杠杆，帮老板重新定义组织里谁干什么、谁不干什么。
这也是为什么 FDE 经常遇到工作无法推进的问题，这通常跟 HRBP 遇到的问题本质上是一样的：你被派进来了，但权力没有跟着你一起进来。 如果你没有人事权、预算权、流程权限、系统权限和老板背书，你就是摆设。
FDE 到底吃掉了什么？
FDE 不是给公司新增一个岗位，而是用一个人 + 一套 AI 工具，吃掉原来多个岗位之间的协作成本。
你不是去教客户用 AI 的，你是去帮老板证明：有了 AI，这些岗位可以不要这么多人了。
这就是为什么说 FDE 吃的是“人血馒头”。你的价值，一部分来自效率提升；另一部分来自岗位消失。
FDE 赚的是存量的钱
赚钱有两种逻辑：
1. 增量逻辑：帮公司开新业务，多赚了钱，分你一部分。
2. 存量逻辑：帮公司省掉人力成本，省下来的钱，分你一部分。
FDE 主要赚的是第二种钱。 一个 FDE + AI 工作流，覆盖了原来 3 个岗位的工作。公司省下 2 个人的工资，拿其中一部分付给你，剩下的归公司。
所以这件事必然带来三个结果：
1. FDE 注定被旧岗位的人恨，因为你赚的钱对应着他的岗位被吃掉。
2. FDE 注定离不开老板撑腰，因为没有权力，你连真实流程都拿不到。
3. FDE 的落地率不只取决于技术能力，更取决于你有没有政治支撑。
这份工作的本质是利益再分配，不是技术升级。
你的对手是谁？
FDE 真正难的地方不在代码。代码可以让 AI 写，接口可以调，页面可以改，流程可以搭。
真正难的是：你在动别人的饭碗。
- 项目经理为什么不配合你？因为你证明了一个人 + AI 能干他半支团队的活。
- 中层为什么表面欢迎、暗地卡你？因为你让老板看见“原来不用养这么多人也能跑”。
- 老员工为什么不交知识、不交流程？因为 AI 一旦吃掉他的核心产出，他就只剩下人情这一张牌。
- 甚至你自己这边的领导，也未必真的想让你成功。他嘴上说“拥抱 AI”，心里可能只是想做一个试点，证明公司没有落后，而不是让你真的把旧体系拆掉。
所以 FDE 不是一堂 AI 技术课，而是一堂立场课。人事被人骂“老板的狗”，FDE 被人骂“AI 的狗”。骂名一样，立场也一样：
你站在老板那边，帮老板用 AI 替代人的生产力。
这一点不面对，后面所有学的技术都是白搭。
FDE 怎么活？
FDE 有“两种死法”，也有对应的“两种活法”。
先帮忙，后合并。
不要一上来就亮明“我来取代你”。先帮他们用上 Codex、Claude、Agent，让他们爽到，让他们发现 AI 真能省事。等他们依赖上这套工具，等老板看到“原来这些活真的可以被 AI 接住”，再逐步推出岗位合并方案。顺序不能反。
- 先成功，后取代，容易死。
- 先帮忙，后成功，才有活路。
这也是为什么 AI 产品经理 比 FDE 更安全。AI 产品经理的叙事是“我来帮你升级”，FDE 的叙事是“我来替代你”。做的事情可能很接近，但对抗性完全不同。
FDE 实战指南：进场先从哪里切入？
我从事 AI 产品经理这个岗位，差不多已经有一年半的时间了。从一开始的实习，到后面的正式工作，中间在两个不同的业务场景里都做过 AI 产品经理。而在最开始那几年，AI 产品经理这个岗位还没有那么成熟的时候，它其实很像今天大家在讨论的 FDE。
你要懂 AI，要懂业务，要进到现场，要让别人真的用起来。你不是写一份 PRD 就结束了，你要面对流程、数据、系统、权限、人情，还有各种说不清楚的组织问题。
既然第一篇讲的是 FDE 到底是什么，那第二篇要讲的是：FDE 到了一家公司，应该先从哪里切入？
很多人第一反应是：当然要找核心业务。因为核心业务最赚钱，老板最关注，业务价值最大。
我认为这个判断是错的。FDE 的第一战场，不应该是核心业务，而应该是业务第一线。
核心业务为什么不能动？
核心业务是什么？就是公司最赚钱、最稳定、最不能出事的业务线。
比如一家公司的运营项目里，最赚钱的那个运营组，就是核心业务。它可能看起来很乱，流程不规范，靠几个老员工撑着，很多动作说不清楚，甚至像一堆 bug 套 bug。但只要它还能赚钱，就是好的。
就像兄弟们修代码一样，一个系统里有很多 bug，但它现在还能跑、还能收钱，你不会为了修一个 bug，把整个系统重构掉。因为你不知道那个 bug 是不是真的 bug。有些 bug，可能已经变成了业务的一部分。
核心业务也是这样。很多已经在赚钱的项目，不是靠“效率”两个字维持的。它里面有经验，有人情，有客户关系，有老员工之间的默契，也有很多说不清楚的玄学。
你一上来用 AI 去改它，本质上是在打破旧平衡。当你打破了旧平衡，你就必须创造新的平衡。问题是：作为一个刚进去的 FDE，你有能力创造这个新平衡吗？答案很明显：你大概率没有。
你没有足够的业务信用，没有足够的组织权力，也没有足够的历史信息。你可能会做出一个看起来更高效的 AI 流程，但它一上线，业务就会出现问题。最后大家会说：AI 也不怎么样嘛，还是不是我来干才可以？结果就是这条路根本行不通。
所以做 FDE，切忌不能选择核心业务下手。
什么是业务第一线？
很多人会把“核心业务”和“业务第一线”混在一起。但它们不是一回事。
- 核心业务，是公司最赚钱、最不能出问题的地方。核心业务强调的是钱。
- 业务第一线，是离真实客户、真实流程、真实问题最近的地方。业务第一线强调的则是问题。
FDE 早期最应该找的，不是最赚钱的地方，而是问题最真实、阻力相对最小、最需要帮助的地方。
我还是拿运营项目举例。不要一上来就选公司最赚钱的运营组做 AI 赋能。那个组已经赚钱了，老板盯着，中层盯着，老员工也盯着。你进去以后，每个人都会想：你来干什么？你是不是要动我的东西？
你真正应该选的，反而是下游一点的项目。比如没那么赚钱的运营组，没那么受重视的项目，项目经理压力很大但资源不够的团队。这些地方不一定光鲜，但它们更接近 FDE 的机会。因为他们是真的痛。
他们缺人，缺工具，缺规范，缺支持。很多重复劳动没人愿意做，很多流程烂在那里也没人管。你这时候进去，不是以“改造者”的姿态进去，而是以“帮忙的人”的姿态进去。这两个姿态差别非常大。
你说“我要用 AI 改造你们”，对方第一反应是防着你。你说“我跟你们一起处理这些破事先”，对方才有可能让你进来。
FDE 进场第一步，选明白立场
FDE 最容易犯的错，就是一进场就展示工具。你看，Claude 可以写方案，Codex 可以写代码，Agent 可以自动跑流程。这些都没错，但对业务团队来说，他们真正关心的不是你工具有多先进。
他们关心的是：你到底站队哪边的？
- 你是老板派来考核我的人？
- 你是来证明我可以被替代的人？
- 你是来把我的经验变成流程，然后让我失去价值的人？
如果他们这么看你，你后面就很难推进。所以 FDE 切入业务第一线，第一步不是讲 AI，而是跟团队站在一起。跟他们一起开会，一起看数据，一起处理客户问题，一起熬那些没人想干的重复活。说难听点，就是先同甘共苦。你要让他们感觉到：你不是站在岸上指挥他们游泳的人，你是跟他们穿一条裤子的人。
只有这样，他们才会把真实流程告诉你。他们才会告诉你：老板知道的那套流程，只是汇报流程，不是他们真实做事的流程；真正落地的时候，其实是另一套走法。他们才会告诉你：这个数据一直很重要，但过去从来没有人系统整理过，更没有人把它自动化处理起来。他们才会告诉你：公司接触的客户其实分好几类，每一类客户背后的诉求、关系和风险都不一样，所以处理方式也不能一样。
这些东西，文档里没有，系统里没有，培训手册里也没有。但这些才是业务。FDE 如果拿不到这些东西，后面所有 AI 工作流都是纸上谈兵。
先做小成绩，不要上来改组织
FDE 进入业务第一线之后，不要急着说“这个岗位可以合并”“这个流程可以替代”。先做小成绩，比如：
- 把运营日报自动化。
- 把客户反馈整理成结构化问题。
- 把重复话术做成可复用模板。
- 把项目经理每天手工汇总的表，变成自动生成。
- 把新人培训材料，用 Claude 整理成一套 SOP。
- 把前端小页面、内部工具、数据看板，用 Codex 快速做出来。
这些事情不一定性感，但很重要。因为它们不会一上来就触碰岗位生死。它们先解决的是痛苦，不是利益。你先帮团队把每天最烦的活减掉一点，把混乱的动作规范一点，把交付结果稳定一点。他们会先爽到。
等团队爽到了，你再往后走。这时候 AI 不是威胁，而是工具。你不是来替代他们，而是先帮他们在业务第一线活下来。只有这个关系建立起来，后面你才有资格谈更深的合并。
FDE 早期要找的团队，应该长什么样
不是所有团队都适合 FDE 早期切入。我觉得一个适合 FDE 第一阶段切入的团队，有几个特点：
注意，这里说的不是“边缘团队”。边缘团队的问题是，业务太远，结果太虚，你做了也没人看见。FDE 要找的是业务第一线里的非核心团队。离真实问题足够近，但又没有核心业务那么高的保护墙。这类团队最适合 FDE 打第一仗。
做 FDE 最重要的是借力打力
做 FDE，或者做任何 AI 赋能，最重要的一件事是：借力打力。
大家用 AI，本质上就是在借力。你借 Codex 的力写代码，借 Claude 的力写方案，借 Agent 的力跑流程。但只会借 AI 的力还不够。你做业务的时候，还要学会借业务的力。
为什么我们前面一直说，不要先碰核心业务，要先去业务第一线里的非核心团队？不是因为这些团队不重要。恰恰相反，是因为这些团队更容易帮你借到第一股力。他们痛苦更真实，资源更少，重复劳动更多，也更希望有人来帮他们解决问题。你不是拿 AI 去压他们，而是先跟他们站在一起，帮他们把事情做顺。
这时候你借的是业务第一线的力。借他们的痛点，借他们的真实流程，借他们愿意改变的动力。然后再借 AI 的力，在这里做出一个能被看见的结果。这样你就可以借到第二股力：成功案例的力。
当你有了案例，就不再只是嘴上说说的“AI 可以赋能”。你可以拿着结果去给老板看：这个团队原来是什么状态，接入 AI 之后省了多少时间、规范了多少动作、提升了多少效率。老板看到成果之后，你就能借到第三股力：老板的力。
这个时候，再去推动核心业务，就不是你一个新人跑过去求人家接纳 AI 了。而是老板拿着已经跑出来的案例，去问核心业务：为什么他们可以，你们不行？这个压力就变了。在没有成果之前，核心业务不接受你，是你的问题。但当你已经在业务第一线跑出了结果，老板也看到了结果，核心业务还不接受，那就变成了他们的问题。
而这就我所说借力打力：
1. 先借业务第一线的痛点切进去。
2. 再借 AI 的能力做出成绩。
3. 再借案例的结果说服老板。
4. 最后借老板的权力，反过来推动核心业务转型。
这就是 FDE 的第一战
第一课我们讲过，FDE 是一堂立场课。第二课说到底其实还是立场。只不过第一课讲的是：你最终站在老板那边，用 AI 重配人力。第二课讲的是：你一开始不能只站在老板那边，你还得先站到业务第一线里面去。
这或许听起来有些矛盾，可这恰恰就是现实的情况。打好 FDE 的第一战，本质上就是把自己放到正确的位置上。不要先碰核心业务，先去业务第一线。
FDE 不是硬打硬冲。FDE 是借业务的力、借 AI 的力、借案例的力、借老板的力，去推动原本推不动的事情。
亲手跑完一次交付：从观点到筹码
前两篇发出去之后，确实在观猹内部引起了不少讨论，也收到了很多点赞。这也说明，大家其实是愿意看这类内容的，后续我会继续跟大家分享更多有趣的 AI 知识。
同时也很开心，能把自己这几年做 AI 产品经理踩过的坑、吃过的亏，还有慢慢摸出来的一些理解分享出来，让大家看到。
之前发的这两篇算不上是 FDE 的课程。第一篇讲的是：FDE 到底是什么？ 第二篇讲的是：FDE 到了一家公司，应该从哪里切入？ 这两篇更多是在讲我自己的一些个人理解。说白了，就是 FDE 这门课里比较容易被忽略的那部分：人情世故。
你怎么理解业务，怎么判断权力，怎么选团队，怎么别一上来就去碰核心业务，怎么先站进去，再借力打力。这些东西很重要。但只看懂这些，还不够。因为 FDE 最后不是靠观点吃饭的，FDE 最后是靠交付吃饭的。
你得真的拿一个业务命题，把需求挖出来，把范围定下来，把 Agent 原型做出来，把业务经验沉淀成 Skills，把企业系统接进去，再用 Evals 去证明：这个东西不是一个 Demo 表演，而是真的有机会进生产。这就不是靠几篇文章能解决的了。文章只能让你知道：这件事大概长什么样，坑在哪里，为什么不要把 FDE 理解成一个单纯的工具岗位。但真正要会做，还是得亲手跑一遍。
所以第三篇，我就不继续写“我来讲 FDE 第三课”了。剩下的，交给观猹 FDE 共学营（还不快来报名！）
报名链接：https://watcha.cn/r/4rRMhv
观猹这次课做的事情很明确：从业务命题到企业级 Agent 交付。
不是单纯教你 Claude Code 怎么用，也不是让你堆一堆工具名。观猹这门课程会带你完整走一遍：需求挖掘、范围界定、Agent 原型、Skills 工程、企业系统接入、Evals、作品集和 Demo Day。
这里面我觉得最关键的，反而是 Skills 和 Evals。
- Skills 是把业务里的 SOP、专家经验、判断标准沉淀下来。
- Evals 是证明你的东西不只是能演示，而是真的能被验收。
没有 Skills，Agent 很容易变成一个会聊天的壳。没有 Evals，Demo 再顺也只是表演。
如果你只是想了解 FDE 是什么，看前两篇其实差不多了。但如果你真的想往 FDE、AI 产品经理、企业 Agent 交付、AI 赋能这些方向走，那最后还是要拿出东西。文档、Demo、Eval 报告、作品集。这些才是你面试、转岗、接项目时真正能拿出去说话的筹码。
前两篇，算是我给大家提前递了一张地图。后面怎么走，怎么真的把东西做出来。就跟着观猹的课，自己亲手跑一遍吧。
最后的交代：这个社会既残酷也温柔
借助孙割的话结个尾。
这个时代很残酷。它不会因为你是应届生、刚入行、刚学 AI，就把问题变简单。你一上来面对的可能就不是代码题，而是真实业务、真实权力、真实岗位变化。AI 带来的不只是机会，也会带来替代、合并和冲突。
但这个时代也很温柔。放在过去，一个年轻人想进入真实业务现场，可能要熬很多年。现在不一样了。AI 给了普通人一条很短的梯子：只要你学得快、敢下场、能把事情做出来，你就有机会比过去更早站到前线。
我想说的是：并不是每个人都适合做 FDE。
走这条路之前，先问自己两个问题：
- 你能不能接受，你的价值有一部分建立在别人的岗位消失之上？
- 你能不能接受，推进工作的本质不是跟代码对抗，而是跟人对抗？
如果两个答案都是“是”，FDE 这条路你可以走。如果有一个答案是“否”，建议先做 AI 产品经理。叙事更温和，能力积累一样在做，市场也更容易接受。
而这就是 FDE 第一课。