第 1 课 FDE 是谁：为什么要去现场看一次

这个角色从哪里来

前线部署工程师的英文是 Forward Deployed Engineer，简称 FDE。这个名称与 Palantir 早期的交付方式密切相关。Palantir 成立后尝试为情报机构做软件，却很难通过常规访谈弄清使用者真正怎样工作。早期演示产品与现场需求相去甚远，团队便让工程师进入客户的工作环境，直接听反馈、接入数据、修改产品。后来，这种既懂工程实现、又在客户现场解决问题的角色逐渐形成了专门岗位。

名称中的 Forward Deployed 借用了“部署到前线”的军事用语。Palantir 内部也把这类工程师称作 Delta。放到企业软件里，“前线”指客户实际使用产品、遇到问题的地方。

工程师进入客户现场的做法并不是 Palantir 独有。它在这门课里的意义，是让我们看见 FDE 为什么出现：产品在总部设计完成，到了客户现场仍可能缺少关键数据、流程和使用习惯。有人需要在两端之间把最后一段工作做完，并把现场发现带回产品团队。

生成式 AI 让这个问题更明显。一个演示可以很快做出来，但要进入企业的日常工作，还得接上真实数据、权限、审批、行动和结果记录。因此，FDE 的价值不止是把功能部署上线，还包括确认一线人员能否持续使用，以及结果是否可检查。

FDE 做什么

FDE 带着工程能力进入具体业务场景，和一线人员一起找出卡点，完成必要的连接与调整，并验证新的工作方式是否真正用得起来。本教程借鉴这种工作思路，不绑定 Palantir 或任何特定平台。后面的入门试点，也可能只需要一张共享表格和人工确认。

它和几个相近角色差在哪

FDE 也要讲清价值、做诊断、写代码，所以常被混同成别的角色。几个角色的差别，主要在“什么时候算做完”：

为什么非去现场不可

会议室里听到的需求，往往已经被转述过几轮。下面是贯穿本课程的练习场景。

教学案例：二号车间：一家中型机加工厂的二号车间。 旧流程：操作员发现设备报警 → 用手机拍下控制屏 → 发到“二车间设备群”，附一句“3号机又报警了” → 班组长看到后 @ 维修工 → 维修工回“收到” → 修完后常常不再回复 → 月底设备科翻聊天记录和纸质交接本做统计。

在会议室里，这件事可能被说成“要一个设备异常智能分析平台”。有几个问题却只有到现场才能回答：照片拍得清不清？夜班谁在看群？群里说的“3号机”，在设备台账里是哪个编号？修完之后，操作员怎么知道？

用一条闭环看流程

看流程时，我们把它拆成四段：数据，也就是发生了什么；判断，也就是要不要处理、多急、谁来；行动，也就是真的去做；反馈，也就是结果回到记录里，下次判断能用上。这四段连起来，标准说法叫“决策闭环”。

在旧流程里，数据有了，就是那张照片；判断在班组长脑子里；行动靠 @ 人；反馈几乎是断的。FDE 到现场的第一件事，是看清闭环在哪里断开，而不是先想用什么模型。

动手：旧流程五格卡

流程名称：
1. 起点：谁、在哪、看到了什么
2. 传递：用什么工具，发给谁
3. 判断：谁来判断，依据什么
4. 行动：谁去做，用什么系统或工具
5. 回流：结果记在哪里，谁会再看
只是听说、没亲眼见过的环节：

去现场之前，再写一份“不碰清单”：

• 不拍带有客户信息或他人隐私的屏幕。
• 未经授权，不把聊天截图和客户数据放进公开 AI 工具。
• 不在任何真实业务系统里点“保存”或“提交”。

今天先做一步

照着上面的教学案例填一张五格卡。再挑一个你身边熟悉的流程填第二张，把“只是听说”的环节圈出来。

本章产物

• 两张旧流程五格卡：教学案例一张，你的流程一张
• 一份不碰清单
• 验收标准：
• 每一格写的是具体岗位和工具，而不是“相关部门”
• 至少标出一个闭环断点
• 至少圈出一个需要去现场确认的环节

常见错误

• 把 FDE 当成“派去客户那里写代码的人”。功能写完了却没人用，不算做完。
• 还没看过现场，就先定了模型或平台。
• 把会议室里的需求原话当成现场事实。
• 为了“看得更真实”，把真实聊天截图拿到公开 AI 工具里试。