FDE 是什么
FDE 是 Forward Deployed Engineer 的缩写，直译是部署在前方的工程师。前方来自军队用语。不是在总部做通用产品的人，而是进到客户公司里，坐在对方的数据、会议和卡住的位置上写代码的人。
这个名字是 Palantir 起的。在 Palantir 内部，角色常分成两个。Forward Deployed Software Engineer（FDSE）负责在客户环境里接产品、做开发、做部署。Deployment Strategist 在前面选问题、对齐利益关系。韩国现在说的 FDE，常常是把这两件事绑在同一个人身上。
Toss、AWS、微软、谷歌、OpenAI 这类要把自家方案种进客户里的公司都在招这个位子。不是因为名字好听。人一离开客户大楼，真正的问题就看不见。面向消费者的产品可以用问卷和界面去看。B2B 的问题，不进那家公司，就看不到决策卡在哪。
和 SI 大约重合八成
SI 是系统集成：把客户正在用的系统接起来，或按客户要求把系统做完再交付。韩国的 SI 行业很久了。去现场、收需求、搭建、过验收，这条路本来就有。
FDE 也去客户现场，听需求、接方案、让它跑起来。Hype Check EP.3 把重合估在八成上下。那不是测量值，是把工作要素摊开之后的判断。国外也有人问，这不就是解决方案架构师、顾问、SI 工程师换了个名字吗。这个疑问并不错。只看驻场、搭建、离开的外形，两者很像。
招聘启事改成 FDE，工作不会自动变。入职之后如果还是按客户写下的画面清单实现，那个人和 SI 工程师没有差别。分开的地方不是头衔，是需求文档由谁来写、什么时候写。
另外两成，是谁来写需求
RFP 是 Request For Proposal，客户把“请做这些”整理成的建议请求书，也就是需求文档。传统 SI 往往等这份文档足够细才开始开发。画面、功能、日程、验收标准已经写在上面。开发者的工作更接近实现和发布这份文档。
写文档的人常常不是现场操作的人。咨询公司把客户的话具体化。咨询公司的工作是把客户想要的愿景写进文档。客户自己也不完全清楚问题。不是瓶颈的事会被放大，真正的堵塞会被漏掉。这样锁死的文档一旦交到开发，开发者没有工时再回去重新摸现场。只能去对齐已经定好的结构。
FDE 把这个顺序反过来。不等客户把需求写完。第一件事不是开发，是观察。先看人们在看什么数据、按什么顺序做事、决策在哪里停住。客户说“做个仪表盘”时，不先画画面，先问这个画面要解决什么。进现场之后，问题可能不是缺少仪表盘，而是各部门在用同一指标却读出不同含义。那要做的就不是画面，而是指标定义。
| 项目 | SI | FDE |
|---|---|---|
| 需求来源 | 客户或咨询公司的 RFP | 现场观察后的问题定义 |
| 第一周交付 | 画面和功能清单 | 观察笔记 |
| 开发工时锁定 | 开工之前 | 重新写完问题定义之后 |
| 现场留下什么 | 交付就结束 | 数据结构和决策模式 |
合同里要写进的四句
只改名字不够。公司跟客户签约时，必须写明“我们按这个顺序做事”。FDE 自己也要离开“我是实现客户所说之人”的自我定位。只改一边，现场还是会回到按 RFP 实现。
下面四句可以直接放进提案或 SOW（工作说明书）。这是法律审阅之前的实务草稿。真正要改的只有一件：把第一周交付物从画面改成观察笔记。
没有这一条，客户第一周就会要画面，供方在工时锁定之后也没有拒绝的依据。有了这一条，“请做仪表盘”就不再是承诺，而是提问的开始。
第n条（发现周）
1. 最初五个工作日的交付物是观察笔记，不是软件。
2. 委托方提出的功能清单是假设。发现周结束时双方重写问题定义。在此之前不锁定开发工时和画面规格。
3. 若委托方要求的画面与现场观察不符，受托方在进入实现前有权也有义务修改问题定义。
4. 发现周确认的数据结构、决策模式、指标定义，作为委托方内部文件单独留下，与交付软件分开。第一周，从周一到周五
条款写了、现场节奏不变，就没有用。发现周的五天可以这样过。不需要开发环境。需要一本笔记，以及跟着一项工作过一天的许可。
周一：不收画面清单。跟着一项工作过一天。记下谁打开哪个画面、在哪里填数字、问了谁、在哪里停住。周二：选一个会上常出现的数字，比如销售额、库存、等待时间。问两个以上的部门怎么读这个数。周三：选出一个卡住的决策。只写一行，值不值得解决。不要做画面。
周四：只针对那个问题写最小假设。“A 部门和 B 部门用同一个名字却不同算法。把名字对齐，会议就会变短。”这就是假设。此时还不锁定开发工时。周五：和客户一起重写问题定义。开发范围从这里打开。如果周五的问题和客户最初的功能清单一样，那份清单就不是假设，而是确认过的问题。不一样也可以。不一样，才是这一周的成果。
现场写出来的问题变成数字的地方
Palantir 公开案例用来说明这个顺序和“按规格交付”有何不同。数字来自医院和 Palantir Impact，不用自动字幕。
坦帕总医院（Tampa General Hospital）从 2021 年起使用 Palantir Foundry。医院 2024 年 6 月 5 日的新闻稿写：病人安置时间减少 83%，麻醉后恢复室（PACU）滞留减少 28%。那不是预先写好的“灾害应对画面规格”。病人信息、人力、床位散落在不同系统里，安置判断因此变慢。
松下能源北美（Panasonic Energy of North America）把熟练技师脑子里、私人笔记和旧工单里的故障处理，收进名为 Ask Atom 的现场辅助工具。Palantir Impact 上的维修经理 Tara Meisinger 说，原来要三到六个月的学习曲线变成了几周。那不是把文档整包丢进聊天机器人的结果。传感器、维修工单、非结构化文件连上之后，新技师才能问到同一个问题。
空客在 2015 年用 Foundry 把 A350 的日程、人力、零件和缺陷收到同一块屏幕上。Palantir Impact 写 A350 交付加快了 33%。2017 年这个结构长成航空业平台 Skywise。形态是先钉住一座工厂里尖锐的堵塞，再扩到整个产业。FDE 的护城河不是交付的画面，而是从现场捞回来、回到公司内部的数据结构和决策模式。
实现越便宜，错误的 RFP 堆得越快
说生成式 AI 让 SI 死了，言过其实。变的是写代码、画画面的成本。如果需求已经精确写好，客户内部的 AI 团队也能用更少的人做出同样的画面。那不是外部 FDE 的价值。
变贵的是定义问题。客户真正难的，往往不是缺少画面，而是不知道该自动化什么。问题定义错了再用 AI 去实现，错误的画面会更快变多。那是 slop。代码写得多不是成绩。
所以运行 FDE 的公司必须在客户合同里写明顺序，FDE 本人也必须问得出所要画面底下的意图。从策划到发布由一个人负责，负担很重。这份负担也是这个位子看起来很贵的原因。名字不重要。以后所谓开发，只会更接近提出问题、做出来、并说服别人这就是该做的事。
今天先做这一步
打开正在进行或即将开始的项目合同、工作说明书。如果第一周写的是画面、功能清单或原型，把那一行改成观察笔记。把上面四句草稿贴进去。在法律审阅之前，关键是客户是否先同意这个顺序。
在本周会议上常出现的数字里选一个。销售额、库存、等待、不良率，只要名字相同就行。问两个以上的部门怎么算这个数。读法分开，就把这个差异写成本周的问题定义。不分，就换下一个数字。
客户已经把 RFP 送来，发现周仍然可以打开。不是把文档扔掉。在功能清单旁边写上“假设”，五天后再写同一份清单。留下来的，才是这个项目真正的范围。