阿里云「前沿部署工程师(FDE)」的 JD 末尾有一段能力特质，三条里的第三条原文是：「业务体感(交付业务价值而非算法指标)」。
这份 JD 在我们 2026-07-21 从腾讯、字节、阿里云、蚂蚁四家官方招聘站实抓的 28 条原文里。括号里那半句，像是写给算法出身的人看的。
先说立场：本文由一家做 FDE 方向职业培训的公司整理。结论：这个背景转 FDE 不是走错门，也谈不上降维打击。你最懂模型，这有用；但岗位考核的恰好不是你最会的那部分。
模型能力在 JD 里排在哪
我们用两种办法看过 FDE 岗位要什么，口径不同，分开说。
第一种是让 AI 逐条读那 28 条 JD 打能力标签。前三项是：把模糊需求变成方案、跟客户把价值谈明白、把方案部署上线接进客户系统。评测落在末两位，同一批原文判两遍末两名会对调，所以只报顺序。
第二种是自建的 jd-radar，每日抓腾讯、字节两家官方站按词表计数。2026-08-20 与 2026-09-15 两份快照的顺序一致：部署/集成、客户沟通/价值、Agent/工具调用、需求转化、评测/可观测、RAG/知识。
两种顺序不一样，但跟模型最贴近的几项都不在前面。「训练模型」「调参」在这套划分里压根不是单独一项。
微调在 JD 里出现的方式也值得看。阿里云写的是「在 Prompt Engineering / RAG / Agent / 微调等方案间做技术选型」，微调是四个选项之一；「SFT/RLHF 后训练实践」「顶会论文」放在加分项。
指标思维和对业务结果负责，差在哪
算法岗的日常是：拿到定义好的任务和测试集，把离线指标往上推。准确率、召回、AUC 是你的考核，也是你的语言。
FDE 的 JD 换了一套指标。腾讯云 FDE 岗的职责原文：「跟踪客户业务指标(交付周期缩短率、代码采纳率、办公效率提升等), 持续调优方案确保价值可感知」。字节火山引擎一份数据产品方向的 FDE，第一条职责写的是「对客户业务结果指标负责」。
两套指标之间隔着好几层。一个常见场景：给客服团队上知识问答助手，评测集答对率从不及格提到够用，按算法岗的定义你已经交差。但坐席不用。可能是答案要切三个窗口才看得到，可能是措辞不能直接发给客户，也可能主管考核通话时长，用它反而慢。
没有一个出在模型上。FDE 要对「坐席用不用、用了快没快」负责，查出原因、推动改掉，就是活的主体。
最容易犯的错：想调模型解决业务问题
懂模型的人遇到效果不好，第一反应是回到模型：换更强的底座、加数据微调、改损失函数。这在算法岗上是对的。
到了客户现场，这个本能经常把人带偏。效果不好，常见原因是知识库放着旧版文档、业务方说不清什么算对、流程里根本没有 AI 介入的位置。这些调模型调不好，只会拖长交付。
字节那份 JD 里有一条写得很直接：「识别"AI 可介入 vs 人工兜底"的边界」。有些环节的正确答案是不用 AI。阿里云能力特质的第二条是「技术审美(能区分"能跑"与"可上线")」：notebook 里跑出好分数的模型，离客户每天在用的系统，还差部署、监控、兜底和成本账。阿里云职责里明写「对线上质量、稳定性与成本负责, 建立监控、告警与兜底机制」。
能带走的，和要补的
能带走的，按有用程度排：
- 看得懂 AI 为什么错。 输出不对，你能分清是检索没找到、上下文被截断，还是模型本身答不了。别的出身要学很久。
- 评测设计。 阿里云 JD 要求「面向业务目标设计评测指标, 搭建自动化评测框架」。建评估集、控变量、看分布不只看均值，是你的老本行。区别在指标要从业务目标倒推，不能从论文里拿现成的。
- 数据处理。 清洗、标注、构建数据集，阿里云称之为「数据飞轮」。
评测这一项有个小信号。2026-09-15，「Agent Benchmark」「Benchmark」「RL」三个词第一次出现在 jd-radar 的词表之外，各命中字节跳动 2 份评测方向的 JD。只有一家公司，能说的只是它出现了，说不上趋势。
要补的：
- 需求拆解。 算法岗拿到的通常是别人定义好的问题。FDE 要从客户一句「能不能智能一点」开始自己定义问题。这项在两种排序里都靠前，你的经验却最少。
- 客户沟通。 跟业务方解释为什么只能做到大部分答对，谈出错到什么程度还能上线。这是交付本身，不是汇报技巧。
- 工程与部署。 很多算法团队交付的是模型文件或接口，服务化和上线由工程团队接手。FDE 这一段要自己扛。
- 从最优到够用。 算法岗习惯能再提一点就再提一点。交付岗上，够用就上线，把时间花到采纳上。
两种例外
做推荐、风控、增长这类业务算法的，日常已在看转化、坏账、留存，中间那道坎跨过了一半。做偏研究方向、几年没跟业务方打交道的，要补的比上面列的更多。
还有一条我们核不动：这个背景转 FDE 后实际做得怎么样，我们没有能公开的数据，不下结论。
不离职也能开始
找一个你做过、已经上线的模型，写一页纸回答三个问题：业务方每周看的是哪个数？你的离线指标和那个数之间隔了几层？上一次那个数变化，原因在不在模型里？
答不上来，就去业务方那坐一下午，看他们怎么用你的东西。
然后把一个小应用从头做到同事能用：需求自己问，部署自己做，效果用业务方认的数来证明。做完，你手里就不只是一个模型分数，而是一条对结果负过责的交付记录。
数据来源
- "四家大厂官方招聘站实抓的 28 条完整 JD 原文,逐条可具名可复核"（出处：我方调研记录（fdesky.com/market.html 可查）；采集 2026-07-21）
- "「Agent Benchmark」「Benchmark」「RL」三个词 2026-09-15 首次出现在词表外,各命中字节跳动 2 份 JD(评测方向)"（出处：我方调研记录（fdesky.com/market.html 可查）；采集 2026-09-15）
- "四周里六项能力组按词频命中从高到低的顺序始终是:部署/集成 > 客户沟通/价值 > Agent/工具调用 > 需求转化 > 评测/可观测 > RAG/知识(08-20 与 09-15 两份快照一致)"（出处：我方调研记录（fdesky.com/market.html 可查）；采集 2026-09-15）
想知道你现在的岗位离 FDE 差哪几件事？把简历发到 实战营页面 上的咨询微信，免费领一份《简历分析与职业发展建议》。我们不承诺就业、不承诺薪资，文中薪资均为公开招聘信息口径。