FDE 技能清单：从全栈到 AI 工程到业务软技能

上一章讲了 FDE 的能力三要素与 T 型结构，这一章把它落到一张可操作的技能清单上。技能是能力的「外显」，但清单本身不是目的——豆包线程报告在列举技能时也暗示，落地能力才是终点。本章按「全栈工程、AI 工程、业务软技能」三层展开技能地图，并接入行业 JD 数据与真实招聘片段作为参照，最后提醒：技能是手段，落地才是目的。

一、全栈工程能力

FDE 需要亲手把方案搭起来、接进去、跑起来，因此全栈工程是底座。豆包报告列出的工程栈包括：Python、Go、Rust、TypeScript、PostgreSQL；容器与编排 Docker、Kubernetes 与云；以及 HuggingFace、PyTorch 等框架【主源·豆包】。

行业侧对 JD 的统计分析可提供交叉印证。aibuilders.academy 对 1000 多份 FDE 相关 JD 分析后给出核心技能占比：Python 约 66%、TypeScript/JavaScript 约 35%，此外普遍要求 SQL 与数据管道、Docker/Kubernetes/云、LLM 生产级调用、RAG、Agent 框架、Evals 等【第三方·已核验】。其 Python 66% 的高占比，与豆包把 Python 列为首选语言一致。

把两组对照看，全栈工程对 FDE 的要求是「广度优先、关键处够深」：语言上 Python 几乎是硬通货，TS/JS 关系到前端与原型，SQL 与数据管道关系到打通客户数据；Docker/K8s 与云则关系到部署形态。这一层解决的是「能不能把东西做出来并放上去」。

逐项展开应用场景：Python 用于写数据清洗脚本、模型调用与评测，是 FDE 的默认瑞士军刀；Go 与 Rust 在需要高并发或低延迟的服务里顶上，例如把模型包成稳定推理接口；TypeScript 用于给客户搭可交互的原型界面，让业务方「看见」方案而非只看文档；PostgreSQL 既是业务数据落地的载体，也常借助 PGVector 直接承载轻量向量检索；Docker 与Kubernetes 解决「在我机器上能跑」到「在客户环境也能跑」的鸿沟，尤其是私有化交付时几乎离不开；云（公有云或客户专有云）则决定方案的弹性与成本边界。每一项都不是孤立技能点，而是对应交付链上的一道具体关卡。

二、AI 工程能力

在通用工程之上，FDE 需要专门的 AI 工程能力。豆包报告将这部分拆为：RAG 实战、向量库 Milvus/Qdrant/PGVector、Agent 框架 LangChain/AutoGen、MCP、以及耐久化执行 DBOS/Restate【主源·豆包】。推理侧还列出 vLLM、Ollama、TGI 等加速方案，以及 Qwen、DeepSeek 等主流开源模型与量化技术。

aibuilders 的 JD 分析同样把 LLM 生产级调用、RAG、Agent 框架、Evals 列为高频要求【第三方·已核验】。这里值得单独提的是 Evals（评测）：很多团队重训练轻评测，但 FDE 在客户现场必须能证明方案「有效且稳定」，评测体系是把模糊价值变成可度量指标的关键工具。

AI 工程这一层解决的是「模型如何变成可用的产品能力」：从选模型、写 Prompt、搭 RAG 检索、用 Agent 编排多步任务，到用评测守住质量底线。它与全栈工程的交界处，正是 FDE 区别于普通 AI 研究岗的地方。

逐项展开：RAG 用于把客户私有知识接进模型，避免幻觉也避免重训，是知识密集型场景的标配；向量库承担检索底座，选型要在召回质量、运维成本与规模间取舍；Agent 框架把多步任务编排起来，适合流程长、需调用多个工具的场景，但也要防「自说自话」跑偏；MCP 让模型能标准地接外部系统与工具，降低集成摩擦；推理加速（vLLM、Ollama、TGI）决定吞吐与单请求成本，直接关系到客户愿不愿意为调用付费；量化技术则让开源模型能在资源受限的边缘或内网跑起来。这些都要求 FDE 既懂「怎么用」，更懂「什么场景该不该用」。

三、业务软技能

技术之外，FDE 的大量时间花在「人」与「翻译」上。豆包报告把业务软技能列为：沟通、抗压、合规意识、英语【主源·豆包】。这一层对应前几章反复出现的「模糊性」——把业务语言翻译成技术语言，再把技术结果翻译回业务价值，是 FDE 的日常。

展开来看，三类软技能最关键：

翻译与沟通：在客户、产品、算法之间做信息中枢，减少失真。
快速学习：每换一个客户行业，都要快速读懂其业务规律。
合规与抗压：在约束严格的客户环境里推进，并承受驻场的不确定性。

英语在涉外或文档密集型场景中是加分项，但具体权重因公司而异【待核实】——本文未掌握可靠的岗位英语占比统计，不对此做量化断言。需要指出，软技能常被低估，却是 FDE 在客户现场「能不能待下去」的决定因素。技术再强，若无法让客户信任、无法在高压下稳住节奏，方案依然推不动。

具体地说：翻译与沟通体现在一次需求会上，把业务方口中的「要智能一点」转成「用分类模型把工单自动分给三个组、准确率不低于八成」；快速学习体现在进场第一周啃完客户行业手册与历史工单，让自己能听懂现场对话；合规与抗压则体现在客户环境反复变更、演示前夜接口崩掉时，仍能按预案推进而不乱阵脚。这些场景里的每一次「接住」，都比简历上的框架名更说明问题。

四、真实 JD 片段示例

为了让技能清单不悬空，这里引用两则真实招聘片段作为岗位要求的样例（非薪资断言）：

万联易达 FDE（来源 ima.qq.com）：深入客户现场观察真实业务流程、用 AI 半天搭原型验证、把经验反馈给产品团队、沉淀 SOP。值得注意，其反馈去向是「自己的产品团队」而非客户，这恰是 FDE 与外包实施的分水岭【第三方·已核验】。
泛微「AI 智能应用（FDE）工程师」（来源 ima.qq.com）：协助资深 FDE 完成数智化办公场景智能体部署调试、参与需求调研、API 对接测试、交付培训、沉淀通用模板。该 JD 显示薪资 15-25K，但因来自截图而非官方统计，此处标注【待核实】。

对泛微这则 JD 再读一层：它写的是「协助资深 FDE」，说明岗位处于梯队里的执行侧，新人通常在资深者带领下，从部署调试、需求调研、API 对接这类具体活儿上手，再逐步接触方案设计；「数智化办公场景」「智能体部署调试」点出落地形态是 Agent 而非单纯模型调用，意味着要懂编排与工具接入；「交付培训」「沉淀通用模板」则把软技能与 owner 意识写进了职责。至于「薪资 15-25K」，由于仅来自截图、既无样本量也无城市与年限分层，无法判断是起薪、中位数还是上限，更不能据此推断行业薪资水位，故仍标【待核实】。把它当作「某一企业在某时点对某层级岗位的报价」即可，切勿上升为行情结论。

这两则片段印证了前文结构：JD 既要求工程与 AI 技能（部署调试、API 对接），也要求业务软技能（需求调研、交付培训），还隐含 owner 意识（沉淀模板、反哺产品）。

五、技能是手段，落地是目的

最后需要提醒：清单越长不等于越好。豆包报告列出的技能覆盖面很广，但 FDE 的护城河不在「会多少工具」，而在「能否在客户真实环境里把方案推上台面」。技能是手段，落地能力才是目的。对学习者而言，与其贪多求全，不如围绕一个真实场景把「数据打通到部署上线」的完整链路跑通一遍，这比罗列框架名更有价值。对招聘方来说，衡量一名 FDE 也应看「端到端交付过几个真实场景」，而非简历上列了多少工具。

补充一点：技能清单会随模型能力演进而变，今天高频的某些框架明年可能过气，但「把客户问题翻译成可验证方案」的内核不变，这也是为何本章把软技能与落地意识单列强调，而不是让工具名堆满简历。

小结

FDE 的技能地图分三层：全栈工程（Python/TS/SQL/Docker/K8s/云）、AI 工程（LLM 调用、Prompt、RAG、向量库、Agent、Evals）、业务软技能（翻译/沟通/快速学习）【主源·豆包】【第三方·已核验】。真实 JD 片段印证了这一结构，但技能只是手段，能否在客户现场落地才是 FDE 的真正目的。

参考与延伸

豆包线程 AI 生成报告（技能清单摘录） — 内部主源，无公开 URL
aibuilders.academy（JD 技能占比分析） — https://aibuilders.academy
ima.qq.com（万联易达与泛微真实 JD 片段） — https://ima.qq.com