概述
这一两年，FDE（Forward Deployed Engineer，前线部署工程师）突然火了：招聘平台上的相关岗位一年涨了七倍多，OpenAI、Anthropic 都在抢人，有风投直接称它为"科技行业最热门的岗位"。一边是企业 AI 项目大面积"成功上线却没人用"，一边是这个岗位被疯抢，两件事放在一起，很难不让人好奇。
通过本文，你可以大致了解两件事：
- FDE 到底是什么：它要解决企业软件的"传话游戏"问题；它从 Palantir 的"笨办法"中诞生，本质是把现场定制从服务成本改记为产品研发；它和售前、外包、顾问、平台工程师有什么区别；它为什么偏偏在大模型时代火起来；以及它既当"修理工"又当"战地记者"的双重身份，需要什么样的人。
- FDE 进场后做什么：不是先写代码，而是先用 PSF 三道关确认问题选对了，用影子工作法在现场找到真痛点；再用"窄而深"的最小可行部署（MVD），按"读旧写新"的原则接入客户环境，在几周内用业务数据证明价值。
「给间谍做软件的一个挑战是：我不认识任何间谍。」—— 鲍勃·麦格鲁（Bob McGrew）
先说一个"成功上线"的失败
很多人见过这样的项目：演示很漂亮，合同签了，系统按期上线，验收报告上每一项都打了勾。半年后再去看，没人在用。服务器还开着，业务部门还在用 Excel。
书里引了麻省理工 NANDA 实验室《生成式人工智能的鸿沟》报告里的一个结论：过去三年，企业在生成式 AI 上投了三四百亿美元，大约 95% 的项目没能产生能写进财务报表的价值。这个数字的统计口径有争议，我更愿意把它当成一个方向性的信号：
大部分企业 AI 项目不是死在技术上，而是死在"最后一公里"上。
模型很聪明，可它不在员工的工作流里，不记得上次的反馈，也不懂这家公司的规矩。
读到这里，我脑子里冒出一个比喻：传话游戏。
需求从一线出发，经过主管、IT、采购、销售，一路传到研发手里。每个环节都没有恶意，只是都按自己的视角把需求"改写"了一遍：店长说的是"周末鲜奶断货"，到了研发那里变成了"做一块销量预测大屏"。研发做出来的东西完全符合拿到手的那份需求，却解决不了最初那个人的问题。
书里的说法是：造软件的地方，和价值产生的地方，不在同一个地方。行业为了缩短这段距离想过很多办法，比如需求文档、用户调研、实施方法论、客户成功团队，但只要还是"转述"，每多一道就多一层损耗。FDE 的思路很直接：别传话了，把人送过去。
Palantir 的笨办法，和它改写的一笔账
这套做法最早成形于 Palantir。它早年的客户是情报机构，麦格鲁的原话很妙：要给间谍做软件，可你根本不认识间谍；就算碰巧认识一个，问他"平时到底怎么工作"，他通常也不会告诉你。
用户访谈和需求文档都派不上用场，只剩一个笨办法：
- 先做个粗糙的东西拿过去；
- 听对方说"这完全不对"，追问"哪里不对"；
- 回去改，再拿过去。
这个循环跑多了，慢慢变成了制度：工程师直接驻扎在客户那里，一边听意见一边改代码。
书里有两个细节让我印象很深：
- 伊拉克战场的地图小工具。路边炸弹是巡逻队最大的杀手，但士兵们从没开口要过"炸弹预警"，在他们眼里，危险路段本来就是巡逻的一部分。驻场工程师跟着车队走了几趟，看到大家在可疑路段前犹豫，就当场拼了个能在地图上标记危险路段的小工具，全队实时可见。这个工具后来沉淀成了平台的标准功能。
- 空客 A380 的燃油泵。一个燃油泵故障反复发作，空客自己的工程师查了两年没头绪。Palantir 的人把传感器数据接进平台，两周就找到原因：飞机爬升时，燃油会晃离泵体。
两个故事有个共同点：答案都不在需求里，而在现场。士兵没提过需求，空客的工程师也不缺能力，缺的是有人把数据和现场放到一起看。
不过我觉得这一部分真正的重点不在故事，而在一个记账方式的改变上。
打个比方：同样是厨师去食客家里做饭，如果餐厅把这当成"外卖服务"，就会想办法少去、快回；如果当成"新菜研发"，就会认真记下每家人的口味，回来改菜单。动作一样，记账方式决定
