主题
FDE 是一组能力，不只是一个岗位：从跑通模型到交付系统
本章要回答的问题：为什么现在值得学这套东西？我已有的经验能用在哪儿？学完能做出什么？
先从一个客户现场说起
"把我们厂十年的维修记录用起来。"
这句话听起来像一个需求。真拆开，是一串没有答案的问题：记录在哪？是纸质扫描件还是 Excel？字段谁定的？能不能出内网？答错了谁负责？答得"好"又怎么算？
过去，你交付的是一个确定的东西：一个页面、一组接口、一张能跑起来的报表。需求清楚，边界清楚，验收标准能写成测试用例。现在，客户要的是一个"会回答问题的系统"，而这句话里没有一条能直接变成接口文档。
这不是工程师的危机，反而是工程师的主场。确定的东西正在变成商品，不确定的东西才需要人来交付。
为什么是现在
过去两年，模型能力本身越来越像基础设施：权重可以下载，推理引擎可以安装，接口大多兼容 OpenAI 风格。你可以在一台笔记本上跑起一个能用的模型，也可以租一张卡，把更大的模型服务化。
真正稀缺的，不是"再训一个模型"，而是把模型接进一堆具体的、脏的、有权限和合规要求的业务系统里。模型像水电，但把水电接进这栋老楼，一直缺人干。
这件事没有标准答案，只能靠工程判断一步一步试出来。也正因为没有标准答案，它才值钱——会写代码只是入场券，能把一堆不确定的东西拼成一个能验收的系统，才是稀缺能力。
FDE：把模型接到业务上的工程师
这类角色有一个常见的名字：FDE（Forward Deployed Engineer，前向部署工程师）。Palantir 把它定义为：直接嵌入客户现场、用公司已有的平台去解决客户最难的问题的软件工程师。它和产品研发岗的分工，官方说法是"Dev 做的是一个能力服务很多客户，FDSE 做的是很多能力服务一个客户"（引用 [1]）。
这句话里有三个容易被忽略的点。
第一，FDE 是工程师，不是售前，也不是实施顾问。他要写代码、调参数、看日志、改配置，出了问题要能在生产环境里定位。区别只在于，他的工作围绕"这个客户的问题"组织，而不是围绕"产品路线图"组织。
第二，FDE 的产物是跑起来的系统，不是 PPT 或方案书。PPT 可以讲清楚一个不存在的系统，但客户现场只认能不能用。判断一个 FDE 是否合格，看的是"这套东西现在能不能用、有多快、错的时候错在哪"，而不是"讲得清不清楚"。
第三，FDE 处在产品与现场的接缝上。现场出现的共性需求，会回流成产品能力；产品能力的边界，又要在现场被解释成客户能接受的说法。这个位置不轻松，但它让你同时看见技术的上限和业务的下限。
不同公司的叫法不一样：解决方案工程师、AI 应用工程师、交付工程师、平台工程师，做的可能是同一类事。本书用 FDE 统称"把模型能力接进真实业务，并对结果负责"的工程角色。
它不是一张必须投递的岗位说明书，而是一组可以拆开学习、组合使用的能力。
你已有的经验，正是起点
听到这里，你可能会问：这些能力我是不是要从头学？
先说结论：你已有的工程经验，大部分不是沉没成本，而是这个方向上的稀缺品。 模型原理、推理性能、检索质量这些，可以补到"够用"；工程判断力补起来要慢得多。
这本书不要求工龄，也不要求 AI 背景。它只假设一件事：你写过能跑的东西，愿意照着命令动手。
下面这张表，可以帮你对号入座：
| 你的背景 | 已经具备的能力 | 在本书对应的工作 | 这本书帮你补上 |
|---|---|---|---|
| 前端 | 状态管理、流式渲染、交互设计、错误态处理 | 第八部分的服务架构与流式输出；聊天界面的"引用出处""停止生成""重试" | 服务端并发、显存与延迟的关系 |
| 后端 | 接口设计、数据库、缓存、队列、权限、可观测性 | 第三、五、八部分：服务化、索引与元数据、权限过滤、监控 | 模型推理的两阶段特征、量化的代价 |
| 全栈 | 端到端串起来、快速做原型、在约束下取舍 | 序章的全景图；第六部分的评估闭环；第二部分的选型决策 | 性能测量的严谨性（别用"感觉快了"当结论） |
| 数据 / 平台 | 数据管道、SQL、数据质量、权限模型 | 第五部分的文档解析、切分、元数据与增量更新 | 检索质量与生成质量的评估 |
| 测试 / 运维 | 复现、监控、故障定位、变更管理 | 第三部分的性能测量；第六部分的消融实验；第八部分的离线部署 | 模型行为的不确定性、非确定性输出怎么验收 |
| 工控 / 制造业 IT | 离线环境、老设备、脏数据、停机成本、现场沟通 | 第五部分的文档解析与切分；第八部分的离线部署与断网验证 | 现代检索栈、评测方法 |
把这张表读成一句话：你已经会造房子，这本书教你在房子里装一套会说话的管线。 管线有它的物理规律（显存、带宽、上下文），但施工组织、验收标准、故障排查，还是你熟悉的那一套。
这本书带你走一遍完整链路
本书按一条交付链路组织。你可以把它想成五步：
- 看懂图纸：显存、带宽、上下文各自占多少，延迟花在预填充（prefill）还是逐字生成（decode）；再看量化怎么把显存压下来（第一、四部分）。
- 选好设备：按硬件和场景选模型，搞定格式、引擎、对话模板、采样参数、OpenAI 兼容接口（第二、三部分）。
- 铺好管线：把一份脏文档变成能检索的知识库，走一遍检索增强生成（RAG）的完整链路：解析、切分、向量化（embedding）、混合检索、重排（第五部分）。
- 做好验收：让回答带出处、查不到会拒答，并用测试集证明它变好了（第五、六部分）。
- 交钥匙：离线部署、断网验证与交付文档（第八部分）。
第七部分讲怎么把这套系统搬到 GPU 服务器上，需要一张 NVIDIA 卡（或云 GPU），可以按需阅读。本书的重点始终是把已有模型用好——对绝大多数企业离线场景，选型、量化、检索和评估的收益，远大于自己训一个模型。
如果你只想要一个最小的成果，按 0.4 的最短路径走，可以先做出一个能回答真实问题、带引用出处的原型。
学完以后，你可以拿它做什么
不一定是为了换一个叫 FDE 的岗位。它至少有三种用法：
- 换岗：去做 AI 应用工程师、解决方案工程师、FDE，或者加入一个正在做企业 AI 落地的团队。
- 不换岗：在后端、前端、数据或平台团队里，成为那个"能把 AI 接进现有系统"的人。
- 做作品：不管面试还是内部汇报，一套能跑、能测、能解释取舍的系统，比"我了解大模型"有说服力得多。
薪资因地区、行业和公司阶段差异很大，本书不引用招聘网站的数字。它给你的是路径和作品；剩下的，靠你把它跑起来。
现在就能开始的三个问题
把"我想学 AI"拆成可验证的问题，比收藏一堆课程有用：
- 我能不能在一台自己的机器上，把一个模型跑起来，并说清它为什么占这么多内存？
- 我能不能给一个具体业务问题，搭出一条能答、能引用出处、答错能定位的链路？
- 我能不能用数字证明它比昨天更好，而不是靠演示时的几个漂亮例子？
这三个问题，分别对应本书的第一、五、六部分。接下来先看全景图：一个能回答"我们厂设备怎么保养"的系统，到底由哪几块拼起来。
参考资料
- Palantir. A Day in the Life of a Palantir Forward Deployed Software Engineer. https://blog.palantir.com/a-day-in-the-life-of-a-palantir-forward-deployed-software-engineer-45ef2de257b1