FDE 一天都在干什么
先说结论:这个岗位的时间,大部分不花在写代码上。
从 28 条大厂官方 JD 原文里反复出现的职责看,一个 FDE 的工作大致落在四段上——而且这四段是循环,不是一次性走完。
① 搞清楚客户到底要什么(最容易被跳过的一段)
客户说的是「我们希望效率高一点」,你要得到的是「订单审核环节平均耗时 45 分钟,目标压到 10 分钟以内,准确率不能低于现在」。
这段的产物不是代码,是一份写清楚了边界和成功指标的文档。
阿里云 JD 把这项能力拆成了五条,第一条就是:「数学思维——抽象能力强」,第二条是「语文表达——写出好的 Prompt」。
注意排序:表达能力被写在了架构能力前面。
② 判断这件事能不能做、值不值得做
能拒绝,是这个岗位的一部分。
不是所有需求都该接。数据不具备、指标定不下来、老板要的是"看起来很 AI"而不是解决问题——这些情况下硬做,三个月后一起承担后果的是你。
这一段没有产物,只有一个判断,以及把判断说清楚的能力。
③ 做出来,并且接进客户的真实系统
这段最像"传统开发",但难的地方不在写代码:
- 客户的数据是脏的,格式不统一,有历史包袱
- 要接的老系统没有文档,当初写它的人已经离职了
- 数据不能出内网,模型得私有化部署
- 接口调不通,而对方 IT 部门一周只能配合你两小时
蚂蚁的 JD 直接列了工具清单:「Dify、n8n、LangGraph、ADK、Spring-AI、CrewAI、OpenAI Agent SDK、A2A、MCP、GUI-Agent、Memory 构建」。
没有一把万能钥匙,认清工具的边界、在对的地方换对的工具,本身就是能力的一部分。
④ 证明它是对的,然后盯着它别退化
模型不是装完就完事了。上线之后:
- 怎么证明它答得准?拿什么数据、按什么标准
- 准确率掉了怎么发现?靠谁反馈还是靠监控
- 客户换了个说法它就答错了,算不算 bug
- 三个月后还有人在用吗
字节的 JD 写的是:「保障 AI 应用成功上线,实现长期稳定运行和高使用率」。
「高使用率」这四个字,把责任一直拉到了交付之后。
那到底写不写代码
写。但更准确的说法是:你要对代码负责,不一定要亲手敲每一行。
现在这个岗位普遍在用 AI 编程工具——字节的 JD 甚至明写要求「熟练掌握 Vibe coding 并在实际工作中有充分应用」。
工具会替你写。但工具不会替你判断需求对不对、不会替你跟客户解释为什么延期、更不会在系统出问题时替你担责。
依据:腾讯、字节跳动、阿里云、蚂蚁集团官方招聘站实抓 28 条完整 JD 原文(2026-07-21),逐条可具名。四段划分为我方归纳,欢迎推翻。
FDE 和售前、运维、外包、算法,到底差在哪
如果只能用一句话说清楚:
别人交的是"东西",FDE 交的是"这东西在客户那儿真的跑起来了"。
下面这几组对比,每一条的右列都来自大厂官方招聘站的 JD 原文(2026-07 实抓,逐条可具名)。
不是售前
|
售前 / 解决方案 |
FDE |
| 交付边界 |
讲方案,签完合同就交出去 |
签完才开始 |
| 对什么负责 |
方案能不能打动客户 |
上线结果 |
JD 原文:「主导落地交付——场景适配、系统集成、效果调优、上线护航」
一句话:签完合同才是开始。
不是运维
|
运维 / SRE |
FDE |
| 核心目标 |
保证系统别挂 |
决定系统该长什么样 |
| 介入时点 |
系统建好之后 |
系统还没有的时候 |
JD 原文:「独立完成技术架构决策」
一句话:不是等它挂,是不让它长歪。
不是驻场外包
|
驻场外包 |
FDE |
| 计价方式 |
按人天出工 |
按结果 |
| 听谁的 |
听甲方指挥 |
对业务结果指标负责 |
JD 原文:「对客户业务结果指标负责」
这一条差别最微妙,也最关键——行业里管前者叫"高级驻场外包",差别就在这一行。
不是算法工程师
算法工程师的战场在模型本身:训练、调参、把指标往上顶。
FDE 的战场在模型和业务之间那一公里:客户的数据是脏的、系统是旧的、接口没有文档、用的人不信任它。
模型再强,这一公里过不去就等于零。 而这一公里,恰恰不是算法问题。
不是"会用 AI 写代码"
这是最容易混淆的一组,因为表面动作很像——都在用 AI 生成东西。
区别在于你对什么签字:
- 会用 AI 写代码 = 我做出来了
- FDE = 我做出来的东西,客户验收了、上线了、在用
中间隔着:需求到底是什么、数据从哪来、准不准怎么证明、出事了谁负责、三个月后还有人用吗。
那 FDE 到底在干什么
把上面几条正过来说,这个岗位一天的工作大致落在六件事上:
- 把客户一句模糊的话,变成能干活的方案
- 让 AI 准确回答公司自己的资料
- 让 AI 自己调工具、连系统、干多步骤的活
- 把 Demo 真正部署上线、接进客户系统
- 说清楚"它到底准不准",并盯住它别退化
- 跟客户把话谈明白,把价值说清楚
这六件不是我们编的分类,是从 28 条大厂官方 JD 原文里反复出现的职责归纳出来的。
数据来源:腾讯、字节跳动、阿里云、蚂蚁集团官方招聘站实抓 28 条完整 JD 原文(2026-07-21),逐条可具名可复核。归类为我方人工判断,欢迎推翻。
能力地图:说到底就这六件事
把 28 条 JD 原文里的要求去掉黑话、合并同类项,剩下的是六件事。
这六件不是按难度排的,是按交付顺序——上一件没做好,下一件就是空中楼阁。
① 把客户一句模糊的话,变成能干活的方案
这是唯一一件"没有它其余全废"的能力。
需求错了,后面写得再漂亮都是白干;而且错误往往要到上线后才暴露,那时改的成本是最初的几十倍。
难在:客户自己也不知道自己要什么;他说的和他想要的经常不是一回事;真正的约束(预算、死线、IT 部门配合度、谁能拍板)往往要问三层才问得出来。
② 让 AI 准确回答公司自己的资料
也就是常说的 RAG。技术方案是成熟的,难的从来不是搭起来。
难在:文档是扫描件;表格嵌套三层;同一个概念在三个部门有三种叫法;新旧两版制度并存而没人告诉你哪版有效。
③ 让 AI 自己调工具、连系统、干多步骤的活
Agent、工具调用、MCP 都属于这一件。
难在:多步骤意味着错误会累积;调外部系统意味着会失败;而且当它做错事的时候,你得能说清楚它当时为什么那么决定。
④ 把 Demo 真正部署上线、接进客户系统
Demo 和上线之间隔着的东西,比很多人以为的多。
国内尤其如此:数据不出内网是常态,私有化部署、国产模型适配、离线依赖包——这些在海外课程里基本不讲,在国内是第一道门槛。
⑤ 说清楚"它到底准不准",并盯住它别退化
评测(Eval)与可观测。
阿里云 JD:「面向业务目标设计评测指标,搭建自动化评测框架(LLM-as-Judge)」
字节 JD:「构建高性能的评估管道和可观测性框架」
大厂把这一条单独写进 JD,恰恰因为它最容易被跳过。 老板问"这东西靠谱吗",答不上来的项目最后都停了。
⑥ 跟客户把话谈明白,把价值说清楚
最被低估的一件,也是最难被 AI 替代的一件。
包括:向不懂技术的人解释为什么这个做不了;延期时怎么说;上线后怎么让业务方真的用起来(而不是装好了没人碰);怎么把 token 成本换算成客户听得懂的账。
怎么用这张地图
别六件平均用力。 现实的做法是:
- 找出你已经会的那几件——多数有工作经验的人至少占两件
- 找出你所在行业最卡的那件(制造卡集成、金融卡担责、医疗卡资质、零售卡流程,详见行业路径)
- 从这两者的交集开始
在我们 2026-08-19 公开课直播间的现场投票里(n=11),观众自评最缺的是第①件「把客户一句模糊的话变成能干活的方案」(45.5%),而第②件 RAG 零人选择。
⚠️ 样本很小、且来自我们自己的传播渠道,不构成市场统计,只作为一个参考视角。
六件事归纳自腾讯 / 字节 / 阿里云 / 蚂蚁官方招聘站实抓的 28 条 JD 原文(2026-07-21)。JD 引文为原文摘录,归类为我方人工判断。
谁转过来更容易
先说一句可能反直觉的:这个岗位最看重的不是"AI 学得多好"。
从 JD 看,它要的是能把一件事从提出来到有人用、完整推完一遍的人。而这种经验,恰恰是工作年头换来的。
所以下面不排名、不分档,只说一件事:你手里已经有的是什么,还缺什么。
| 你现在是 |
你的存量优势 |
你要补的 |
| 后端 / 全栈开发 |
系统怎么搭、接口怎么连,你不用从头学 |
客户视角。技术上"能跑"和客户认为"能用",是两件事 |
| 前端开发 |
交互和呈现,你比谁都清楚"人会怎么用它" |
后端与部署链路;以及"测试"不等于自己手点一遍 |
| 测试 / QA |
⭐ 你天然懂"怎么证明它是对的"——这是第⑤件事的底子 |
从"找 bug"转向"定义什么算对";以及主动设计评测集 |
| 运维 / SRE |
部署、监控、稳定性,第④⑤件事你是主场 |
你熟的是让系统别挂,FDE 要的是让客户信 |
| 产品经理 |
需求拆解和沟通,第①⑥件事你有底子 |
动手做出来。方案讲得再好,交付不出来就不算 |
| 数据 / BI |
数据从哪来、脏在哪、怎么清,你有直觉 |
工程化与上线;从"出报表"转向"出一个在跑的系统" |
| 售前 / 解决方案 |
你最会讲价值、最懂客户决策链 |
从"签完就交出去"转向"签完才开始" |
| 传统 IT 实施 / 集成 |
⭐ 你干过真正的交付——脏集成、老系统、甲方扯皮 |
AI 侧的能力面;但你的交付经验是最难速成的那部分 |
非互联网行业从业者
(医药 / 物流 / 电力 / 制造 / 金融) |
⭐ 你的行业经验就是门票——这些行业都在招,而外面的人进不来 |
技术面要补;但你懂的业务,技术强的人补不上 |
三个要想清楚的情况
完全没有工作经验 / 在校生。 不拦你,内容也学得会。但这个岗位的核心是"把事推完",而推事的经验只能在真实项目里长。要到能上手干活,得多练几轮实战,时间会比有经验的人长。
只想学个工具。 工具几天就会。难的是判断——什么该做、什么该拒、准不准怎么证明。只学工具,替代性最强。
想速成换高薪。 这里没有速成。市场在招的是能担责的人,而"能担责"这件事,是靠一次次交付攒出来的。
一个更现实的路径
如果你已经在一家有业务的公司里,未必要跳槽。
市场上有一整类岗位是「留在你现在这家公司,当把 AI 落地的那个人」——不出差、不驻场,考核的是内部提效和采纳率。对有经验的人来说,这条路风险最低、也最能发挥你的存量优势。
→ 详见:内部 FDE:你不一定要离职
⚠️ 本站不提供任何就业、薪资承诺,也不代表任何雇主。上表为我方基于公开 JD 的判断,欢迎推翻。
内部 FDE:你不一定要离职
关于这个岗位,流传最广的一个误解是:转 FDE = 跳槽去大厂做交付,还得出差驻场。
那是其中一类,不是全部。
市场上有一整类岗位,是"留在你现在这家公司"
在猎聘 FDE 招聘聚合页实拉的 37 条在招职位里,至少 4 条的岗位名直接写明了这件事:
| 岗位名 |
城市 |
月薪 |
| 内部 FDE AI 负责人 |
上海 |
4.0–5.5 万 · 16 薪 |
| AI 赋能内部 FDE 负责人 |
上海 |
4.5–7.5 万 · 16 薪 |
| AI BP / 内部 FDE / AI 部署工程师 |
杭州 |
3.5–5.5 万 |
| AI Captain / AI Business Partner / Internal FDE |
上海 |
4.5–7.0 万 |
来源:猎聘 FDE 招聘聚合页实拉样本,采集于 2026-08-15,n=37。平台聚合口径,含部分"蹭词"岗位;公开招聘信息口径,不代表承诺。
它和"乙方型 FDE"的根本区别
|
乙方型 FDE |
内部 FDE |
| 服务对象 |
外部客户 |
自己公司的业务部门 |
| 出差驻场 |
是,JD 明写"接受出差驻场" |
否,就在自己公司 |
| 考核什么 |
客户的业务结果指标 |
内部提效 / 采纳率 |
| 怎么转过去 |
要跳槽进大厂交付体系 |
在现公司内部就能转 |
为什么这条路对有经验的人反而更现实
跳槽去做乙方交付,你要同时跨两道坎:新公司和新岗位。
而内部 FDE 只跨一道——岗位变了,业务没变。
而且它把"有工作经验"从劣势变成了最大优势:
- 你知道公司哪个环节最痛、哪个部门配合、哪个流程碰不得
- 你知道数据在谁手上、系统是谁维护的、审批要走几层
- 你说的话业务方听得懂,因为你本来就是他们的同事
这些恰恰是外部来的人最缺、也最难在短期内补上的。 AI 能力可以学,对一家公司的理解不能。
现实一点说
这条路不是躺赢,有三个真实门槛:
- 得有人愿意让你干。 这类岗位很多不是招聘来的,是内部提出来的——你要能说服一个愿意为结果买单的人。
- 得选对第一个项目。 选一个"痛得明显、范围够小、三个月内能见效"的,而不是最宏大的那个。
- 得能说清楚它值多少钱。 内部项目没有客户付款单,考核靠"采纳率""省了多少人天"——这些指标要你自己定义并盯住。
难点从来不在"会不会用 AI",而在你能不能把一件事从提出来到有人用,完整推完一遍。
⚠️ 口径说明:上表 4 条来自 37 条平台样本,样本小、且为平台聚合口径,只能说明"这类岗位真实存在且有一定规模",不能据此推断市场整体比例。我们自建的另一组一手数据(28 条大厂官网 JD 原文)以乙方型为主,不覆盖这一类——这也正是我们把它单独列出来的原因:它容易被整个漏掉。