1
信息散在多个系统里13 个现场
真相被切在几个互不相通的系统里，人肉搬运就是全部的流程。
Career FDE · 前线部署工程师的职业档案
AI 落地最难的一公里，由 FDE 走完。
以知识图谱为索引轴、案例与需求为撮合面、人为连接层的 FDE 职业社交平台。
什么是 FDE
FDE 是什么，快速看懂这个岗位
FDE 是什么、怎么工作、能解决哪些问题，企业眼下正面临什么、不动又会怎样、 为什么非得要它。要会什么、要掌握哪些能力，紧跟着的下一段讲。
FDE 是什么 · 四个面缺一不可
客户现场CONTEXT深入客户的真实环境，看清真正卡在哪
生产代码CODE亲手把方案写到生产，不是 demo 和 PPT
指标校准CALIBRATION用真实指标做 eval，调到真的有用
经验回流COMPOUNDING把现场反复出现的摩擦沉淀成模块
只懂现场的是顾问，只会写代码的是工程师，只盯指标的是分析师， 只想着产品化的是 PM。真正定义 FDE 的，是把这四个面收在同一个责任主体上。
一个现场怎么走 · 十步闭环
- 01账户 / 场景选择
- 02Discovery：业务发现
- 03Technical scoping：技术定界
- 04Architecture：系统设计
- 05Prototype：快速原型
- 06Eval：评估体系
- 07Productionization：生产化
- 08Adoption：用户采用
- 09Generalization：沉淀为产品能力
- 10Commercial expansion：商业扩展
第 1–8 步解决「这一个客户」，第 9–10 步决定「下一个客户是否更快」—— 强调色那两步就是 FDE 与外包的分水岭：把一次交付沉淀成产品能力，再向同行业复制。
能解决哪些问题 · 六类现场
2
老师傅的判断说不清9 个现场
关键判断只存在于个人经验里，出了事复盘不到根因，也复制不了。
3
讲不出为什么值这笔钱4 个现场
没有一条能验收的口径，双方对「做完了」的理解相差很远。
4
试点很多，一个都没跑起来8 个现场
概念验证全通过，然后就没有然后——价值锁在演示里。
5
没人对结果负责3 个现场
老板要的是指标，一线要的是顺手，中间没人把这两件事对上。
6
上下游的口径对不上3 个现场
同一个东西在每家、每个平台上的叫法和规格都不一样。
条目名后面的「n 个现场」是该类的真实成员数：按站上 40 个现场归纳，六类互斥、不重不漏；每类下面两条可直接点进去核对。
这几个场景，你中过几个
场景 1
演示那天，会议室里所有人都说好
大模型对答如流，数据大屏流光溢彩，连最挑剔的高管都挑不出毛病。当场拍板，签合同，合影，发新闻稿。
三个月后：系统还在跑，服务器还开着，只是没有任何一个业务部门真的在用。
场景 2
功能全交付了，价值没到货
供应商交付了合同里的每一项功能，你付清了合同里的每一笔钱。
唯一没有到货的，是「价值」。
场景 3
工具进了车间，流程没动
「网上说一切都变了，回到我们车间，什么都没动。」
一位制造业首席运营官的原话。他不缺预算，也不缺工具——缺的是有人把工具塞进车间真实的流程里。
场景 4
想找个人对这件事负责，找不到
每个部门都只负责自己那一段：需求被工单、纪要、周报层层转述，每转述一次就失真一层。
而真正的工作流，藏在没人写进文档的表格里、口耳相传的惯例里、「这事得问老王」的隐性知识里。
四个场景都不是比喻：前两个逐句取自手册 《第 1 章 FDE 的崛起》开头那个「死掉的数百万美元」， 第三个是一位制造业首席运营官的原话。
拖下去，这道沟只会更深
模型每月都在变强，你的流程一步没动
任何人五分钟就能做出惊艳的演示，可把演示接进真实的数据、权限、合规和工作流，难出一个数量级。
落差不是在缩小，是在拉大。
同行已经把它接进核心流程了
高盛把自研 AI 助手铺向全行、内测阶段就覆盖上万名员工；Klarna 的 AI 客服上线第一个月，接下了三分之二的客服会话。
同一批客户，晚一步的人拿不到。
你缺的不是预算，也不是工具
走访的几乎每一家企业都不缺预算、不缺工具——缺的是有人把工具塞进真实的流程里。
钱能买到模型，买不到「有人对结果负责」。
「模型之外那一层」只会越来越值钱
Palantir 的 AI 平台之所以值钱，恰恰因为它不是模型，而是长在「模型之外、和企业其余部分打交道」的那一层。
模型越强，这一层越值钱——而你现在没有这一层。
⚠️ 行业侧的那些数字（烧进去三四百亿美元里 95% 没有可衡量的财务回报、 岗位一年涨 729%、4.6 万亿的量级）都收在手册里，这里故意不摆上来—— 它们回答的是「行业怎么了」，而这一段要回答的是「我怎么了」。 真要引用那个 95%，得连着口径一起读：报告把「失败」定义为六个月内没有可衡量的财务报表影响、 只认利润 / 成本 / 收入三项、样本以大型企业为主，且发布方自己就在研究智能体互联网。 所以取的是方向，不是精确值——精确到个位数的失败率本身就是一种伪精确。 出处：《第 1 章 FDE 的崛起》。
哪些企业需要 FDE · 真实在招岗位
按行业
按公司规模
最值得注意的一格：100 人以下的公司招了 73 个岗位，5000 人以上的大厂是 85 个—— 规模不是门槛。
两组都取自站上真实岗位快照（2026-10-15）， 与「趋势」「岗位市场」那两段是同一份数据；点任意一格进岗位库看那一类下的真实岗位与 JD。 行业是从 JD 正文判出来的（覆盖 229/569 条）；公司规模只有 发布方自己标了的 217 条有——BOSS 那 528 行没有这一列，回填不了，没标的 不计入，所以规模那一组的合计明显小于岗位总数（那是数据本身的缺口，不是漏统计）。 底色深浅按同一把尺算（两组合起来最大的那一格 = 85 条）——行业那半整体浅一档，是因为它那一组的最大值（44）只有规模那组（85）的一半不到。
企业为什么一定需要 FDE
THE MODEL ISTHE EASY PART
难的是它接不进去的那一层
- DATA
- PERMISSION
- AUDIT
- EVAL
- OWNER
01
demo 能跑，进生产就卡住
数据散在 CRM、ERP、数仓、工单、邮件、权限系统里；还要 SSO、RBAC、审计、合规、评估、回滚、成本与延迟。这些都不是模型自己能解决的。
02
值钱的是流程重构，不是单点调用
真正的 ROI 来自把流程改掉——而流程在现场。站在远处调模型，改不动任何一条流程。
03
越关键的系统，越要有人对结果负责
权限、审计、数据治理、责任边界，都得有人认领。所以有个反直觉的结论：AI 越强，短期内反而越需要 FDE。
04
稀缺的是采用速度，不是模型能力
模型每月都在变强，企业把它接进核心流程的速度却远远跟不上——这道剪刀差正在拉到最大。
模型越强，企业越想把它接进核心流程；而核心流程越关键， 就越需要权限、审计、数据治理、工作流重构与责任边界——这些都不是模型自己能解决的。 所以「AI 越强，短期内反而越需要 FDE」。
四条取自手册 《为什么现在爆火》—— 那一篇讲的是行业侧的三股推力，这里按「企业为什么非得要人来做」重排。 岗位数量与增长率是原报道的历史口径，不代表当前招聘规模。
FDE 风向 · 更新至 2026-10
为什么 FDE 会成为趋势
岗位需求 · 逐年（条 · 信号库口径）
20122020202120222023202420252026
JD 里最常被要求的能力点
常用工具箱
undefined 条岗位
MVD 最小可行部署
undefined 条岗位
把含糊的业务问题翻译成系统
undefined 条岗位
演示循环
undefined 条岗位
边聊边出 Demo
undefined 条岗位
数据接入与清洗
undefined 条岗位
带权限的检索
undefined 条岗位
Agent 编排
undefined 条岗位
口径：547 条在招 FDE 岗位的职责 + 任职要求 + 加分项全文， 按能力点的关键词表匹配，一条岗位提到几个就算几个（不抽样，所以同一个能力点 会同时出现在很多条里）。点任意一行去知识图谱看这个能力点。
FDE 与大模型 · 逐年新增（信号库口径）
FDE
大模型
口径：站上提到 FDE 或 提到大模型的资料条数，不是人数—— 共 736 条（有年份的）。⚠️ 两条线不是互斥划分：一条资料可以同时提两个， 两边都算，所以两条线相加会大于这个总数。
在招 FDE 岗位 · 最想要你哪段背景
一条岗位只进一类（按 JD 里最先写死的那条背景判）。可重叠覆盖率： Python 351 条（64%） · 大模型 / Agent / RAG 452 条（83%） · 客户与业务对接 455 条（83%）。
行业分布 · 真实在招岗位
互联网与平台软件与 IT 服务工业与硬件制造汽车与新能源人工智能与云计算专业与商务服务教育与科研消费与生活服务金融房地产与建筑医疗与制药
岗位市场 · 快照 2026-10-15
在招的 FDE 岗位，要什么样的人
BOSS直聘 · 猎聘 · 智联招聘（公开岗位），按岗位名去重后 569 条（原始 603 条）；覆盖 BOSS直聘 339 · 猎聘 195 · 智联招聘 35。薪资区间取月薪上限，中位 35K。
经验要求（n=230）
5 年以上3–5 年3 年以下经验不限
学历要求（n=230）
本科学历不限硕士及以上大专及以下
公司规模（n=217）
5000 人以上100 人以下100–500 人500–5000 人
城市（n=569）
上海北京杭州深圳广州
薪酬分布 · 真实在招岗位（月薪上限 · K，n=565）
20K 以下20–40K40–60K60–80K80K 以上
档位按发布薪资的月薪上限归类，同一个岗位只进一档。 中位与四分位写在右边「平均薪资」那张卡上——同一件事不在一段里说两遍。
平均薪资 · 真实在招岗位
44K
月薪上限的算术平均
543 条带薪资的岗位
543 条带薪资的岗位
中位 35K · 四分位 22K – 60K。 均值与分档同一把尺：都取每条岗位薪资区间的上限。 只写日薪或「面议」的岗位不计入，所以这里的条数比薪酬分档那张少一点。
岗位要求 · JD 里最常出现的 10 条
-
01 沟通表达 54%
-
02 Python 51%
-
03 大模型 / LLM 50%
-
04 客户对接 · 售前 49%
-
05 Agent · 智能体 47%
-
06 项目交付 45%
-
07 RAG · 检索增强 43%
-
08 跨部门协作 41%
-
09 私有化部署 39%
-
10 数据库 · SQL 29%
口径：拿站上 547 条真实岗位的任职要求逐条匹配关键词， 一条岗位提到就算一次（同一句里写三遍不加重）；只看任职要求，不看职责。 关键词表是本站归纳的，所以它说的是「有多少条岗位要这个」， 不是「这个词出现了多少次」。条长按本表最大值（293 条）归一。
统计量取自公开招聘信息，企业名与 HR 姓名已清洗，页面上不出现。
我该怎么走
要会什么、到什么程度、走几步、你从哪出发
前一段讲 FDE 是什么，这一段讲你怎么办。要会什么（五层技术栈、 能力图谱、七个能力域）、到什么程度、走几步、你从哪出发——四个问题， 最后一张按你的出身分岔：先找到自己，再谈路线。
要会什么 · 五层技术栈
01
编程与全栈
10 项
前端、后端、数据、部署一把抓——客户现场往往没有现成的团队帮你补齐任何一环。
02
LLM / RAG
10 项
难点不是把文档丢进向量库，而是权限过滤、数据新鲜度、引用溯源与答案可信。
03
Agent / Workflow
12 项
从「问答」升级到「可执行」，难点远超普通聊天机器人。
04
Eval / Observability
11 项
LLM 系统是非确定性的，没有评估与可观测就上不了生产——这是 AI FDE 与传统软件交付最大的不同。
05
Cloud / Infra / Security
10 项
决定 AI 系统能不能进受监管或高安全的环境。
五层、共 53 个技术点，全部来自手册 第 11 篇《技术栈全景》。 这一篇的原文说得很清楚：FDE 不需要把每个工具都用到精通，但需要一张完整的武器库地图—— 所以这张表是让你先知道「有什么」，不是让你照着刷完。
FDE 到底要掌握哪些能力 · 图谱
上面这张球，就是 FDE 要掌握的技术能力： 53 个技术点分在 5 层里，5 层再收在中心的 FDE 上。 五层各回答一个问题——编程与全栈：能不能自己把东西跑起来；LLM / RAG：答得对不对；Agent / Workflow：能不能真的动手做；Eval / Observability：能不能上生产；Cloud / Infra / Security：能不能进受监管的环境。 它比一张清单多出两样东西：归属（每个点属于哪一层）与关联 （点与点之间的横向关系，比如 Docker 与 Kubernetes、PostgreSQL 与「权限感知检索」）。 同一批技术点，在上面「要会什么 · 五层技术栈」那张卡里是一条条列出来的； 摆成这张图才看得出它们是连着的。
其中技术点之间那些细线，是本站按手册第 11 篇对每个点的表述 归纳出来的（「这两件事是一回事」），不是从数据里推出来的—— 与上面「六类问题」同一种做法：人工归纳，口径写在页面上。
图例
编程与全栈LLM / RAGAgent / WorkflowEval / ObservabilityCloud / Infra / Security
拖动可以转这个球 · 停在任意一个点上，与它相连的都会亮起，点一下钉住 · Ctrl/⌘ + 滚轮缩放
需要掌握哪些技能 · 七个能力域
七块的面积差不多大，这不是画得均——是站上 58 个能力点真的这么分。
- 1模式认知FDE 是什么、为什么存在、谁适合干。入行前的第一块领地。6 个能力点
- 2问题定义解决正确的问题，比正确地解决问题更要紧。PSF、MVD 与用户调研。9 个能力点
- 3赢得客户从进门到拿到第一份信任。演示循环、灯塔客户与定价。8 个能力点
- 4激活部署把系统写到生产、被真实用起来。数据接入、权限、eval 与采用。11 个能力点
- 5守住续约交付之后才是开始。采用度、指标与客户成功。7 个能力点
- 6扩展增收从一个用例长到更多用例、从一个部门长到整个组织。7 个能力点
- 7规模化复制把现场经验沉淀回产品。产品化阈值与组织建设。10 个能力点
顺序不能跳：先弄懂 FDE 是什么，再学怎么找对问题，然后是拿到信任、 用到生产、守住续约、做更多、沉淀回产品。
到什么程度 · 三档
看得懂
有一张完整的武器库地图：知道每个位置有什么，能判断技术取舍，能跟工程师对话。
算到了：一页 FDE 定义；一张 FDE vs SA vs SWE vs PM 对比表；10 个关键能力清单。
第 12 篇 · 第 1 阶段
做得出
能独立做一个接了真实数据的端到端小系统，而不是一个玩具聊天机器人。
算到了：一个权限感知的企业知识助手：检索、引用溯源、权限过滤、eval、部署，一样不少。
第 12 篇 · 第 2 阶段
连得起
能把五层连成在客户现场跑得起来、可衡量、可复用的生产系统，并对结果负责。
算到了：一次模拟客户部署的完整交付包，加一份「哪些该产品化」的复盘。
第 12 篇 · 第 4–5 阶段
这三档是本站按手册 第 11 篇结尾那三句归纳的（武器库地图 → 动手做一遍 → 连成生产系统）， 原文并没有给档位起名字；每一档的「算到了」直接引 第 12 篇对应阶段的真实产出物，不是另写的一套标准。
怎么走 · 90 天五阶段
-
建立概念框架 1–2 周 · 到「看得懂」
目标：理解 FDE 到底是什么，不被 title 迷惑，能区分它与售前 / SA / SWE / PM。
产出物：一页 FDE 定义；一张对比表；10 个 FDE 关键能力清单；5 个模式风险清单。
-
补 AI 应用工程 2–4 周 · 到「做得出」
目标：能独立做一个企业级 RAG 原型，而不是一个玩具聊天机器人。
产出物：文档解析、chunking、embedding、向量检索、reranking、权限过滤、引用溯源、用户反馈、eval set、延迟与成本日志、前端与 Docker 部署。
-
补 Agent 与 Workflow 4–6 周 · 到「做得出」
目标：从问答系统升级到可执行系统——能调用工具、维护状态、处理失败、请求人工审批。
产出物：工单分类、知识检索、工具调用、草稿回复、人工审批、状态机、错误回退、trace viewer、eval cases、成本与延迟监控。
-
模拟客户部署 6–8 周 · 到「连得起」
目标：练 discovery、scoping 与上线思维——FDE 与普通工程师最大的差异就在这一步。
产出物：客户访谈提纲、当前流程图、痛点与成功指标、MVP scope、技术架构、风险清单、eval 方案、rollout 计划、产品化机会。
-
产品化与商业化思维 8–12 周 · 到「连得起」
目标：不只是做完项目，而是把项目变成可复利的产品能力——FDE 与高级外包工程师的分水岭。
产出物：哪些模块可复用、哪些连接器该产品化、哪些 eval 该标准化、哪些模板可跨行业复制、哪些需求不该做。
五阶段的名字、周数、目标、产出物全部来自手册 第 12 篇《90 天学习路线》原文。 原文里还有一句话值得单独抄在这里：每个阶段的项目都不要停在 demo—— 要逼自己加上数据接入、权限、评估、日志、成本、部署这六件「不酷但决定生死」的事。
你从哪出发 · 11 条出身
偏代码型起点
3 条
你能把系统跑起来，缺的是走出 IDE。要主攻的是 Context：找一个真实业务方做一次 discovery，搞清楚「结果卡在哪」，而不是「要哪个功能」；并对上线后的采用率负责。
Java 出身
你已经有的
工程规范与类型系统、并发与性能、企业系统集成（JVM 生态、中间件、事务）。手册第 10 篇第 1 维把 Java 与 Python 并列为「至少一门熟练」的语言——而第 3 维（企业集成）正是你的天然优势。
你最缺的
AI 应用工程那一层的手感：RAG 怎么切、Agent 怎么编排、eval 怎么设计；以及在 Python 生态里快速试错的速度。
- 1 0–30 天 补 AI 应用工程：把通用工程能力升级到 LLM 栈——RAG、Agent / 工具调用、eval、成本与延迟。别只做聊天框，要能讲清「为什么这样切 chunk、为什么这个答案算对」。
- 2 30–60 天 做一次真实的 discovery：找一个真实业务方（哪怕是公司里的运营、客服），坐过去看他们一天怎么干活，画出流程图、量化最贵的环节。
- 3 60–90 天 上线并对采用负责：把方案给真实用户用起来，盯采纳率和失败案例，迭代到指标真的变好。
第一个项目怎么选
在自己公司内部找一个真有人受苦的流程，自己既当甲方又当乙方，跑完 discovery → 构建 → 上线全程。
天花板与陷阱
工程师最容易陷的是代码洁癖与 demo 自满：纠结架构是否优雅，却没人用。能跑起来并改变业务结果，永远高于代码漂亮。
现实落点 · FDSWE / Applied AI Engineer
手册第 7 篇没有单列 Java——下面这条三步路线沿用「传统软件工程师 → FDE」那一条。
Python 出身
你已经有的
数据与 AI 生态里最顺手的那一套：数据处理、模型 SDK、向量库、脚本化。手册第 10 篇第 2 维（AI 应用工程）你上手最快——RAG、Agent、eval 全在母语生态里。
你最缺的
生产级工程：部署、权限、可观测、类型与测试；以及「对采用负责」的习惯——脚本跑通和系统被用起来是两件事。
- 1 0–30 天 补 AI 应用工程：把通用工程能力升级到 LLM 栈——RAG、Agent / 工具调用、eval、成本与延迟。别只做聊天框，要能讲清「为什么这样切 chunk、为什么这个答案算对」。
- 2 30–60 天 做一次真实的 discovery：找一个真实业务方（哪怕是公司里的运营、客服），坐过去看他们一天怎么干活，画出流程图、量化最贵的环节。
- 3 60–90 天 上线并对采用负责：把方案给真实用户用起来，盯采纳率和失败案例，迭代到指标真的变好。
第一个项目怎么选
在自己公司内部找一个真有人受苦的流程，自己既当甲方又当乙方，跑完 discovery → 构建 → 上线全程。
天花板与陷阱
最大的坑是停在 notebook：脚本跑得漂亮，但没部署、没权限、没 eval、没人用。FDE 的完成线是被用起来了。
现实落点 · Applied AI Engineer / FDSWE
手册第 7 篇没有单列 Python——下面这条三步路线沿用「传统软件工程师 → FDE」那一条。
数据分析师 / 数据科学家
你已经有的
代码（数据、建模侧）——4C 里的 Code 面你已经占了。
你最缺的
工程化上线 / 客户现场。
- 1 0–30 天 补 AI 应用工程：把通用工程能力升级到 LLM 栈——RAG、Agent / 工具调用、eval、成本与延迟。别只做聊天框，要能讲清「为什么这样切 chunk、为什么这个答案算对」。
- 2 30–60 天 做一次真实的 discovery：找一个真实业务方（哪怕是公司里的运营、客服），坐过去看他们一天怎么干活，画出流程图、量化最贵的环节。
- 3 60–90 天 上线并对采用负责：把方案给真实用户用起来，盯采纳率和失败案例，迭代到指标真的变好。
第一个项目怎么选
在自己公司内部找一个真有人受苦的流程，自己既当甲方又当乙方，跑完 discovery → 构建 → 上线全程。
天花板与陷阱
转型难度中，已有的面决定终点：能上线就是 Applied AI Engineer / FDSWE，停在分析就还是分析师。
现实落点 · Applied AI Engineer / FDSWE
手册第 7 篇没有单列这条——三步沿用「传统软件工程师」那一条；第 6 篇的转型地图里有它的完整一行。
偏现场型起点
5 条
你最大的资产是懂客户、懂业务、懂买单逻辑，现场这一面别人补起来很慢。要主攻的是 Code：从能读代码，到能独立把一个带权限、带评估的小系统写到上线。
咨询顾问
你已经有的
结构化拆解模糊问题、量化业务痛点、对齐高管的成功指标、行业 know-how——这些是 discovery 和 technical scoping 的核心，工程背景的人往往要练好几年。
你最缺的
亲手把方案写到生产。咨询的产出止于「应该怎么做」，FDE 要对「它真的跑起来了、还被用起来了」负责。
- 1 0–30 天 把分析能力翻译成可运行的代码：选 Python，把你最擅长的某类分析做成一个能接真实数据、能跑出结果的小服务，而不是一张 Excel。
- 2 30–60 天 做一个带权限的小系统并上线：权限感知的企业知识助手——接一份真实文档、加检索与出处引用、按角色过滤、配一套 eval。重点是上线给人用，不是本地能跑。
- 3 60–90 天 把行业 know-how 变成可复用模板：挑你最熟的那个行业流程沉淀成连接器或模板，并写清「换下一个客户怎么复用」。
第一个项目怎么选
选你前职业里最熟的那个行业场景（投研、合规、供应链……），用熟悉的业务知识抵消工程上的生疏。
天花板与陷阱
最大的坑是惯性地交报告：把 FDE 面试当成案例分析，大讲框架却拿不出能跑的东西。
现实落点 · Deployment Strategist / AI Solutions Engineer
销售（AE / 大客户）
你已经有的
客户关系、商业嗅觉、买单者视角、把技术价值翻译成业务语言的能力。在一个 FDE 小队里，这套能力极其稀缺。
你最缺的
工程，几乎从零。FDE 面试不会因为你会卖就放水。
- 1 0–15 天 先选定一条现实路线：诚实评估——硬转工程 FDE 周期很长；更现实的是先做 Deployment Strategist，再慢慢加工程。
- 2 15–60 天 补到能读系统、能拼原型：借助 AI 编程助手，从「看得懂架构图」练到「能自己拼一个接了真实数据的可跑原型」。
- 3 60–90 天 主导一次真实部署：找一个工程伙伴组队，由你主导一个真实客户从 discovery 到上线的全过程。
第一个项目怎么选
从你正在跟的某个大客户里挑一个小而真的痛点，绑定一名工程师做成可上线的试点——你的客户资源就是别人没有的入场券。
天花板与陷阱
最大的坑是只会讲价值、给不出能跑的东西：把 FDE 当成「更技术的销售」去面，必然碰壁。
现实落点 · Deployment Strategist（偏商业）
售前 / 解决方案工程师
你已经有的
客户技术沟通、方案设计、PoC 能力、对客户系统与集成的理解。4C 里你已经占了一面半，起点比大多数岗位都好。
你最缺的
生产级工程，以及「对结果负责」的心态。demo 跑通和系统上线之间，隔着权限、评估、可观测性、脏数据和长期维护一整层。
- 1 0–40 天 把 demo 升级成生产系统：挑一个你过去演示过的方案，这次真正接上客户级的数据与权限，让它能在真实基础设施上跑。
- 2 40–70 天 补上生产化的硬骨头：系统学 eval、可观测性、权限过滤、错误回退——这些正是 demo 里被你跳过、却决定能否上线的部分。
- 3 70–90 天 接手一次完整上线并盯采用：对采纳率和业务指标负责，而不是签完单就转身离场。
第一个项目怎么选
把你 demo 过最多、最有把握的那个场景，认认真真做成一个能上线、可衡量的真实系统。
天花板与陷阱
最大的陷阱是只会 demo：习惯了「演示通过即成功」，而 FDE 的成功是生产里被持续用起来。
现实落点 · AI Solutions Engineer / FDE（路径最短）
交付 / 实施项目经理
你已经有的
上线推进、跨团队协调、组织政治处理、风险管理、对交付负责的习惯。
你最缺的
亲手构建与系统设计。从「管别人写」到「自己能写、能设计系统」，是你必须跨过的坎。
- 1 0–40 天 补工程基础，能亲手改系统：从能读懂并修改一个真实代码库开始，练到能独立做一个端到端的小应用。
- 2 40–70 天 补 AI 应用工程：补 RAG / Agent / eval，理解 LLM 系统和传统软件交付的根本差别——它不是确定性系统，必须靠评估来管理。
- 3 70–90 天 独立跑一个端到端技术交付：不只管进度，而是亲手参与构建、上线、盯指标。
第一个项目怎么选
复刻一个你过去管过的上线项目，但这次自己写关键部分，体会「管交付」和「做交付」之间的差距。
天花板与陷阱
最大的坑是退回甘特图舒适区：继续做协调、把技术脏活全外包出去。
现实落点 · Technical Deployment Lead
客户成功经理（CSM）
你已经有的
用户采用视角、对价值兑现的敏感度、长期客户关系、把「上线了」和「被用起来了」区分开的直觉。
你最缺的
代码与系统设计，基本从零。FDE 不是「更懂技术的 CSM」，它要求你能亲手把东西做出来。
- 1 0–15 天 先定方向，别硬刚：想清楚是硬转工程，还是走偏采用与价值的 Deployment Strategist。后者更贴你的优势。
- 2 15–60 天 补编码与系统设计基础：扎实补一门语言和基本的系统设计，至少做到能读懂、能改、能拼出一个小工具。
- 3 60–90 天 把采用专长变成可上线的东西：做一个真能帮到用户采用的小工具，或一套 adoption 的 eval。
第一个项目怎么选
挑一个你亲眼见过客户「买了却不用」的场景，亲手做一个能提升采用的小系统。
天花板与陷阱
最大的陷阱是停在关系维护：以为「更懂客户」就够了，回避硬工程。
现实落点 · Deployment Strategist（偏采用）
偏回流型起点
1 条
你对「什么该被产品化」最敏感，回流的判断力是稀缺资产。但 FDE 要求你同时落到一手现场、还能亲手实现，所以 Context 与 Code 要一起补，否则只能停在 Technical PM。
产品经理
你已经有的
用户 discovery、需求拆解与优先级、把模糊问题收敛成「做什么、为什么做」、对成功指标与采用负责、跨职能对齐。
你最缺的
亲手构建。你习惯写 PRD、把实现交给工程师，而 FDE 要自己下场写代码、设计系统、把东西送进生产。
- 1 0–40 天 从写 PRD 转向亲手实现：借助 AI 编程助手，从「看得懂方案」练到「能独立做一个接了真实数据的端到端小应用」。
- 2 40–70 天 补 AI 应用工程，把指标直觉用上：理解 LLM 系统是非确定性的、必须靠评估来管理，把这份直觉变成给系统设计 eval 与成功标准的能力。
- 3 70–90 天 端到端做一个并对采用负责：这次不写 PRD 交给别人，而是自己从 discovery 到上线全做一遍。
第一个项目怎么选
挑你最有把握判断「什么值得做」的那个产品场景，这次自己一个人从头做到上线。
天花板与陷阱
最大的坑是退回「定义与协调」的舒适区：继续写 PRD、画路线图、把实现全交出去，那只是套了 AI 主题的 PM。
现实落点 · FDE / Applied AI PM
不成为，只用
2 条
你不打算换 title，也不打算下场写代码。那这一组要回答的不是「怎么转」，而是「怎么用」——用它的工作方式，或者用做这个的人。
企业主
你已经有的
真实问题、真实数据、决策权——FDE 最贵的那一面（现场）你天然就拥有。别人要花几个月才能摸清的「哪一环最贵、现在怎么干、谁在受苦」，就长在你的业务里。
你最缺的
一个能对结果负责的人或小队。你缺的不是 AI，是那个能把模糊问题拆开、亲手写进生产、并且被你追指标的人。
- 1 先问清问题 不是「要个 AI 功能」，而是：哪个环节最贵、现在怎么干、一天花多少人工、成功用什么量。说不清这三样，做出来的东西一定没人用。
- 2 再找对人 要的不是供应商，是能下场写、能被你追指标的人——可以是招一名 FDE，可以是组一个小队，也可以把需求交给平台 FDE 顾问先做可行性评估。
- 3 按四面验收 能跑（不是 demo）、有人用（有采纳率）、有指标（业务真的变好）、能复用（下一个场景接得上）。四条缺一条就不算落地。
第一个项目怎么选
从你最痛的那一个流程开始，别铺开做平台。一个流程跑通、指标真的动了，再谈第二个。
天花板与陷阱
最大的坑是把 AI 项目当采购：买一个 demo 回来，演示时很好看，然后没人用，也没人负责——钱花了，问题还在。
现实落点 · 你不需要成为 FDE，你需要用 FDE
这一条是本站写的——站上原本没有「企业主」这个位置， 他不是要转行，是要买。其余出身的五栏都是手册第 7 篇原文的压缩。
留在原岗位
你已经有的
你现在的位置本身就是资产：销售更懂技术取舍、PM 的需求更贴一手现场、工程师更在乎业务结果——这些差别同岗位的人补起来很慢。
你最缺的
没有必须补的缺口。这一条要的不是转型，是换一套工作方式。
- 1 换判据 把「我这一段做完了」换成「最终结果有没有变好」——哪怕结果不在你的 KPI 里。
- 2 横穿环节 主动跨过交接线：工程师去见客户、PM 去读代码、销售去问技术取舍。
- 3 攒复利 把每次现场摩擦记下来，沉淀成模板、清单或组件——下一次遇到同类问题不用重来。
第一个项目怎么选
挑一个你手上正在做的事，用「对最终结果负责」的标准重做一遍，看看会多出哪些动作。
天花板与陷阱
不需要改 title，也不会有身份风险——这是风险最低的一条路。
现实落点 · 大 FDE：不转岗，也能用它的工作方式
正在看「咨询顾问」。点同一枚标签收起，或点别的出身换一条。
分组与「偏代码型 / 偏现场型 / 偏回流型」三段话，取自手册 第 6 篇《从你的岗位看 FDE》自己的分法； 每条出身的路线细节取自 第 7 篇《各岗位转型路线》。 Java / Python / 企业主 三条是本站补的——前两条按第 10 篇第 1 维点名的语言拆开， 路线沿用「传统软件工程师」那一条；企业主站上原本没有。
接下来
接下来，见证一个现场是怎么被做出来的
上面讲的是「要会什么、到什么程度、走几步」。但 FDE 的活儿到底长什么样， 光看清单看不出来——真正的现场里，业务被拆成本体、对象与关系，数据挂上去， Agent 在上面跑起来，每一步都可以点开看。
FDE 演示沙盘
进入 FDE 演示沙盘 →
四个真实行业现场，每个都是一套完整可翻的作业台：本体图、链路图、数据图， 以及现场里那几个 Agent 的 Prompt / RAG / MCP / Soul / Skill。 可以拖、可以点、可以切视角，数据是模拟的、结构是真的。
从哪开始
不知道从哪下手，先确认你是哪一边
现在开始