名称出现之前，问题已经在那里

把一台机器交给客户之后，工作有时才刚开始。

1960 年前后，IBM 的系统工程师会帮助客户给账务机器的控制板布线，使机器适应具体业务；后来，他们的工作越来越多地涉及应用程序与系统设计。这是 IBM 工程师 T. G. Peck 在 1985 年回顾公司系统工程历史时留下的记录。文章还记载，IBM 在 1960 年 12 月 5 日正式宣布设立一组系统工程岗位。¹

这里没有今天的大语言模型，也没有 FDE 这个名称。但困难已经容易辨认：供应商知道机器能够做什么，客户知道自己要完成什么工作，两种知识之间还有一段需要工程劳动才能跨过的距离。

这段距离会改变形状。控制板需要接线，软件需要配置，数据需要解释，自动执行的系统需要知道何时停下。工具进步可以让其中一些工作消失，也可能让更多原本不值得做、做不了的工作进入人们的计划。于是，一个反复出现的组织问题浮出来：由谁走到用户身边，把技术能力变成可用的工作方法？

理解 FDE，最好从这里出发。寻找它的起源，不只是寻找一个人第一次说出三个英文词的时刻。我们还要区分一种工作怎样出现，一个名称怎样传播，以及企业怎样给这项工作配置责任、权限和资源。把这些历史混在一起，就容易把熟悉的劳动写成突然诞生的奇迹，也容易因为它有前例，就忽略后来组织方式的变化。

旧问题，并没有一个统一的旧名字

系统工程、客户工程、应用工程、技术支持，这些名称看起来相近，承担的责任却未必相同。甚至在同一家公司、同一时期，服务大型客户的人与负责小型系统安装的人，也可能面对不同的工作。对历史最稳妥的读法，是看他们实际改变什么，而不是把今天的岗位表贴回过去。

Peck 的文章还记载了一个经营上的变化：1969 年，IBM 将部分系统工程服务作为收费选项提供，编程和详细设计都可纳入其中；随后，收费服务与分支机构的营销支持逐渐形成不同安排。¹ 同一种技术劳动，既可能帮助卖出产品，也可能成为客户单独购买的服务。它由哪个部门承担、用哪笔收入支付，会影响团队怎样选择项目。

这件事值得在 FDE 的历史开头停留。今天讨论“它到底属于产品还是服务”，容易把两者想成天然分开的两类人。可是客户并不会按供应商的部门边界遇到问题。一次安装可能暴露产品缺陷，一项付费服务可能产生值得重复使用的工具，一个销售阶段的技术判断也可能决定后续交付是否可行。劳动可以跨界，经营责任仍然需要划清。

IBM 的另一个历史记录把这种交叉呈现得更具体。公司关于信息管理系统 IMS 的回顾称，1963 年，IBM 与客户方的工程人员为航天项目研究零件跟踪和版本管理；设计团队还包括其他参与方。相关技术后来面向商业市场，IBM 在 1968 年宣布推出 IMS。² 本书不把这称为早期 FDE 项目，也没有证据把这支团队直接连到后来 Palantir 的组织。但它提供了一个必要的比较：客户特定问题转成可销售的软件，早已是计算机产业需要处理的事情。

在这个比较里，不能省去“转成”两个字。零件管理项目能工作，并不表示它天然适合其他机构。原项目中的名称、规则和人员安排需要被辨认出来：哪些是这一家客户的习惯，哪些是更广泛的软件能力？一项功能进入产品之后，谁承担兼容、文档和长期维护？这些问题不会因为最初来自一个重要客户，就自动得到答案。

反过来，也不必要求所有现场劳动都孕育产品。修复一台设备、完成一次迁移、培训一支客户团队，本身就可能是值得购买的结果。若一开始承诺的就是这些工作，用“没有变成平台”来否定它们并不公平。真正需要警惕的是承诺与实际经营方式不相符：公司按可重复销售的产品讲故事，收入却长期依赖每次重新投入的人；或者客户以为买到了持续服务，供应商却认为一次功能交付已经结束。

因此，FDE 的前史不是一张历代称号替换表。它是若干旧问题不断重组的历史：产品与使用之间的距离，专门知识与业务经验之间的距离，以及眼前项目与长期产品之间的距离。它们说明新名称有可以比较的对象，却没有证明所有对象之间存在一条单向传承线。

两种时间记录：当事人回忆与同期词证

2009 年 7 月 24 日，《Science》刊出了 John Bohannon 关于网络分析的报道。文章开头记述 Palantir 的 Shyam Sankar 与 Asher Sinensky 展示数据分析，直接把两人的职衔写成 forward-deployed engineers。³

这是一条有用的同期记录：最迟在那个时候，这个名称已经出现在对 Palantir 人员的公开介绍中。它所证明的事情很明确，也很有限。报道没有说这一天设立了岗位，没有宣布谁发明了名称，更没有给出从第一位员工到整个组织的完整沿革。

公司成立日期是另一种日期。Palantir 的上市文件把公司创办放在 2003 年。⁴ 这能帮助读者安排公司史，不能直接回答 FDE 何时开始使用。成立一个企业、发布一款产品、写出一篇招聘介绍，都是可以标在时间轴上的事件，但它们不是同一个事件。

2024 年，Shyam Sankar 在本人署名文章中提供了另一条线索：他回忆自己在 2007 年给这种工程安排命名为 forward deployed engineering。⁵ 因而这里需要并列两条时间记录：2007 年是当事人多年后的命名回忆，2009 年是本书已核到的同期公开词证。它们可以互相参照，不能合成一份不存在的 2007 年文件。

这种处理并不会使历史失去故事。相反，它把注意力从争夺“第一”移到真正值得解释的变化：工程师为什么不只接受一份需求文档，而要直接参与客户的问题？他们能修改的是什么？解决完以后，软件公司留下了什么？第3章 Palantir的现场与产品会沿 Palantir 的具体材料展开这些问题，这里先给读者一把辨认它们的尺子。

还要注意，早期记录不是一份成功认证。《Science》的同一篇报道讨论了网络分析的效果争论，提醒读者模型中的联系与现实中的重要联系并不总是一回事。³ 这使“靠近问题”的含义更完整：靠近使用者，可以帮助工程师理解信息；靠近客户，并不能自动保证信息可靠、判断正确或用途合理。工程交付仍然需要接受使用范围之外的质疑。

如果只把这种历史讲成工程师克服官僚阻碍，读者就会漏掉另一半责任。客户能够解释业务，却也可能带着自己局部的目标；系统提供更强的能力，也可能把原有错误放大。一个新岗位可以帮助找到错误发生的位置，不能代替组织对目的、证据和后果的判断。

历史改变的，是工程劳动怎样被组织

这些记录之间有空白，不能画成IBM直接传给Palantir的谱系；但可以比较发生了什么变化。

IBM的1969年材料把一部分工程劳动变成可以单独购买的服务。经营问题随之显现：哪些工作由产品销售承担，哪些要另行支付？Palantir的材料则把另一种张力放进岗位分工：一部分人面向客户结果，一部分人建设共同产品，两边需要持续往返。在Palantir的现场与产品一章可以看到，允许前线贡献代码，与产品团队实际接受建议，也不是同一件事。

这里有两种不同的历史解释。第一种强调技术：客户的使用条件不能被单一产品规格穷尽，所以需要共同工程。第二种强调经营：供应商要促成采用、扩大账户，也就愿意承担客户附近的劳动。真实组织可能同时受到两者推动；一位工程师帮助签下合同，并不能说明他的产品贡献很少，贡献过产品也不能证明整个模式经济可持续。

因而，本书追踪转折时会把客户困难、产品能覆盖的范围、工程人员的权限和投入来源一起放进来。只有看到其中的前后变化，才能讨论组织为何需要调整。一个名称的出现是可定位的事件，一种模式能够持续则需要更多解释。

先把名称史与工作史分开

为了比较不同公司的材料，本书采用一个有意保持开放的工作定义：FDE 是贴近客户实际工作、承担实质工程交付的人员；Forward Deployed Engineering 也可指支持这种工作的组织方法。这里的“实质”意味着能指出实际建设和改变。本书还会追踪所学能否回到软件或平台建设中：这是判断一种组织安排能否积累能力的重要问题，不要求每个项目都发布一项公共功能。

这是本书用来提问的定义，不是全球职业认证。企业自称 FDE 时，我们会记录其原话，再检查它承诺的职责与公开项目是否相符。企业没有使用这个名称，却表现出相似机制时，我们会说明相似之处，也保留名称差异。只有使用 AI、与客户合作，或者购买了某家平台的软件，还不足以被归入同一种组织实践。

至此可以保留两条同时成立的线索：贴近客户的工程劳动早于FDE这个名称；命名又可能推动企业重新配置产品与交付责任。现有记录尚不足以填满两条线之间的全部空白。下一章从售前、咨询和实施出发，判断一个具体岗位究竟增加了什么责任，再进入Palantir的组织实践。