FDE 是 AI 领域当下最炙手可热的职位。实验室、初创公司和私募股权公司都在招聘工程师，让他们深入客户的运营现场，解决客户的问题。但对于这些工程师究竟应该达成什么目标，或者招聘背后的战略到底是什么，几乎没有人有共识。
我是 Vinoo，Kepler 的 CEO，我们做的是 AI 的确定性基础设施。在过去十多年里，我在三家不同的机构中，三次从零搭建了前沿部署职能的各个部分。以下是我见证过哪些做法行之有效、哪些做法以失败告终，以及我认为这件事将走向何方。
第一家是 Palantir。我在那里从产品开发做起，构建存储与检索系统，后来作为 FDE 被部署到商业、国防与国家安全、医疗健康以及石油天然气等领域。我还领导了 Project Frontline，这个轮岗项目将我们的软件工程师培养成前沿部署工程师。大约有 250 人经历了这个项目，其中很多人现在在 OpenAI、Anthropic、xAI 和 Anduril 等公司管理前沿部署团队。
第二家是 Citadel，我在那里负责业务工程。我们的客户是投资组合经理，唯一重要的问题是：我们构建的数据和软件产品是否帮助他们产生了 alpha。
第三家是 Kepler，在这里，前沿部署职能隶属于产品部门而非销售部门，而且在这个领域里，一个看似合理的错误答案比没有答案更糟糕。
FDE 的种种误解
几个月前，a16z 推出了 Forward Deployed Engineer Fellowship，我被提名为 fellow 之一，与几位我曾经共事过的人一起入选。这是一个很棒的项目，我在其中享受了很多对话。上周，我参加了在旧金山举办的第一次 fellow 晚宴。
围坐在桌旁的，是来自 Snowflake、Anthropic 以及许多我一直在关注的初创公司的 FDE。在那个晚上，我逐渐意识到，我们都在用同样两个词（前沿部署）来描述几乎毫无共同之处的工作。在对话的某一部分，FDE 是一个参加“第二次通话”的销售工程师；在另一处，FDE 是一个会写 Python 的背负配额的销售代表；再隔几个座位，FDE 更接近于一个带着笔记本电脑和工作说明书的顾问，被请来交付产品本身无法交付的东西。
几天后，有人在我们的 WhatsApp 群里认真地问道，他们的 FDE 团队应该如何与已经进驻该客户的咨询公司划分工作范围。这是一个合理的问题，但不得不回答这个问题本身就很奇怪——至少基于我对 FDE 构成要素的理解而言。
需要说明的是，我无意对这个术语进行守门；而且词义会变化，这个词的变化比大多数词都快。但有趣的是，这个群体中的人——当前 FDE 领域的专家们——所描述的却是根本不同的工作，有着不同的汇报线和不同的激励机制。难怪任何关于 FDE 的 YouTube 视频下面，有一半的评论都是某种版本的“这不就是在重新发明咨询吗？”
所以在本文的剩余部分，我将通过一个我参与犯下的错误的狭窄视角，讲述 Project Frontline 的故事——这个错误如何让我成为了一名 FDE，以及它最终如何催生了那个将我们的软件工程师转变为 FDE 的轮岗项目。
Project Frontline 的历史
首先，交代一些背景。几乎从一开始，Palantir 就被拆分为两个独立的职能。第一个是产品开发（PD），负责构建平台。第二个是业务拓展（BD），尽管名字如此，它既包含技术型 BD 人员（当时已被称为 FDE），也包含非工程背景、面向客户的人员（我们称他们为嵌入式分析师，或部署策略师）。
在绝大多数情况下，PD 并不直接与客户接触；而在绝大多数情况下，BD 也不直接参与构建核心的、通用化的平台。PD 往往通过二手方式来做客户发现——要么与 BD 交流，要么把在实地成功构建的功能吸收进核心产品。然而，这一切都不是流程。它靠的是关系——比如某个 FDE 恰好和某个 PD 工程师熟到能把对方拉过来。于是，来自实地的好洞见能否进入平台（还是被丢弃），取决于当时屋子里坐着谁。
2013 年，在我刚加入 Palantir 的早期，我参与了一个名为 Phoenix 的事务存储系统。这个存储系统由我共事过的最优秀的一些工程师设计，设计极为干净，范围明确地限定在一组清晰的客户用例上。然而，这些用例是二手转达给我们的。我们了解并理解这些设计需求，它们侧重于保留期方面的商业要求，并且有巧妙的方案来对数据分桶，从而支持存储滚动窗口的数据。在我们控制的每一个环境中，它的行为都完全符合规格说明。
然后我们把它部署到了一家银行，结果真实的金融数据中存在的空洞，是我们测试数据里从未有过的。一个空白时间戳落到了 epoch（1970 年 1 月 1 日），于是保留逻辑忠实地为从 1970 年 1 月 1 日到当下的每一个窗口请求一个十分钟的桶。这算下来大约是 230 万个 keyspace，而底层技术 Cassandra 每个文件句柄大约需要五兆字节。服务器理所当然地 OOMed［内存耗尽］，而重新启动它需要 14 TB 的内存。这意味着这个进程实际上刚一启动就死了。
这里的根本原因，并不像你可能猜想的那样，是缺少用户研究。我们有规格说明，我们理解自己的用例，我们也读过大量关于这类机构如何存储数据的资料。我们从未做过的是，站在那栋楼里，看着系统针对他们的生产数据运行。这意味着我们这边没有人对设计与日常现实之间的落差负责。我们关于那家银行所知道的一切，都是二手转达的，而且转达者都是善意的人，对他们来说，坏数据不过是又一种常态。
我就是这样成了一名 FDE，这其实是对实际发生之事的一种美化的说法。随着 Phoenix 在 Palantir 的商业客户群中推广开来，我发现自己要飞出去修复我们已经交付的东西，而这让我第一次站到了真正的用户面前。在这个案例中，用户就是 Palantir 自己的 FDE，这对我来说很幸运，因为他们能用我已经会说的语言告诉我哪里出了问题。我开始构建和扩展系统，服务于他们想要做成的事。
所以，这也是一个关于我如何从切身体会而非理性认知中学会 FDE 思维方式的故事。
这个故事的普通版本到此为止，结尾通常会附上一些关于关注用户的教训。但 Phoenix 变成了比这更有意思的东西。它变成了一个平台，Palantir 的 FDE 开始在其之上构建，覆盖网络安全、KYC、AML，以及一长串没人预先规划过的用例。 最终，我们（产品开发团队）不得不思考如何扩展 Phoenix 平台来支持所有这些用例。
当时我并没有意识到，但那个迭代循环就是整个理念的核心。FDE 解决客户问题，是为了获得洞察，从而指导下一步该构建什么。 这个角色是产品团队的延伸。
今天的 FDE
现实是，这一切都不是你今天看到的大多数 FDE 的心态。这个术语已经被挪用，含义接近于“一个做某种模糊涉及客户的事情的人”， 这就是为什么你会看到“前向部署股权研究员”或“前向部署销售工程师”这样的招聘启事。这种挪用背后的直觉是正确的，即使头衔很荒唐，因为客户现在比五年前更重要，而且他们更重要有一个具体的原因。
低垂的果实已经没了。 那些可以通过一个设计良好的产品以相同方式卖给一千家公司来解决的问题，基本上已经被解决了。剩下的是那些藏在围墙之内的工作，存在于混乱、无文档、几乎无法从外部代理的工作流中。 这就是为什么每个人突然都“前向部署”了。你无法从一次探索性电话中推断出一家特定公司如何结账，而问题中抗拒推断的那部分，现在正是剩下的部分。
这意味着圣杯已经悄然转移。很长一段时间里，它是可重复的动作，同一个 SaaS 产品以同样的方式一遍又一遍地销售；如果你卖的是 token、字节或某种实物，这仍然是正确的抱负。对于其他所有人来说，价值已经迁移到了定制化，迁移到了最后一公里，迁移到了工作流中那百分之二十——没有任何产品能够预见到，却决定了另外百分之八十是否会被使用。前向部署已经变成了解决最后一公里的同义词。
但解决它只是这个角色的一半目的。你在一个客户那里解决的最后一公里问题，是告诉你平台中哪一部分需要变得可通用的信号。一个只解决最后一公里却从不把信号传回家的 FDE 职能，就是一个头衔更好听的服务/咨询团队。
那么今天的 FDE 应该做什么？
我认为，你作为 FDE 的工作应该是收集名词和动词。让我们来拆解一下。
在一家公司里待上一周，你会注意到同一个概念通常至少有四个不同的名字。销售说 customer，运营说 client，财务记的是 billing entity，工程写的是 org_id，而这些团队之间的每一个接缝都隐藏着一种翻译，一旦有人改变了定义就会断裂。那些名字是表面，而在它们之下是运营模型。 也就是说，你确实可以通过学习一家公司的名词和动词来代理他们的工作方式。
名词就是企业里的人视为真实存在的东西。 它通常是一个“事物”。一个头寸，或一笔交易，或一个交易对手。通常，在单个团队的层面上，整个运营所围绕的只有少数几个对象，而且它们没有一个是按照教科书的方式来定义的。 这是因为两家公司会在幻灯片上以完全相同的方式描述一个头寸，却在代码中以完全不同的方式描述它。这不是缺陷，这正是让公司独一无二的原因。我的意思是，如果每家公司都拥有完全相同的一组名词，那你其实只需要一家公司就够了。
动词是名词如何移动的方式。 比如一笔交易如何入账，或者账目结账前必须满足什么条件，或者谁在晚上十一点批准一项例外，以及当那个人休假时会发生什么。
这些几乎没有任何东西被写下来——它是被活出来的。它是一个组织赖以生存的运营系统。它就是文化。 它存在于那六个待得足够久、久到已经不再注意到它的人脑中，也存在于四年前某个人搭建的一张电子表格里，而如今整个团队都在悄悄依赖着它。这就是为什么它如此有价值，也是为什么你没法直接索要它。
通常，掌握这些知识的人并不知道自己拥有它。 在我最近参与的创业公司之一里，我们花了将近一年时间试图让一个客户从 CSV 迁移到 Parquet，而一位数据质量工程师每一次都把它拦了下来。我们始终无法理解原因，而且理由总是在变，但总是某种变体：“parquet 更差”“它不管用”“我看不出它有什么意义”，等等。我们用了客户存储缩减的论据、计算最小化的论据、流水线优化的论据……但没有一个能打动她，因为没有一个触及真正的问题。
后来我们派了一位 FDE 进去，观察这位数据质量工程师的工作。 她从 S3 把 CSV 下载到一台 Windows 笔记本电脑上，双击打开，然后用肉眼逐行查看。那就是数据质量检查。当时 Parquet 没有原生查看器，所以我们提议的做法会夺走她唯一的数据质量工具，却不给她任何替代。她不是在故意刁难，她只是在保护那件让她能完成工作的东西。
我们当晚就做了一个 Parquet 查看器，两天后她批准了迁移，流水线执行时间从大约十七个小时降到了两个小时。她永远不会在面试中说出这些。 从她的角度来看，原因是显而易见的，不值得一提。
理解并定义这位分析师的运营系统，也就是名词与动词，使我们不仅能够理解问题，还能构建出一个解决方案，进而把它交付给一大批面临同样问题的客户。
输出必须是一个产品
理解名词与动词能让问题变得有上下文，但输出必须是一个产品，而不只是一个满意的客户。
名词与动词告诉你一个问题实际上是什么。它们不会告诉你该对它做什么；而这正是大多数 FDE 职能悄悄出错的地方，因为解决眼前的问题令人满足、也清晰可见，而且当周就会有人为此感谢你。
让客户满意是一项实实在在的工作，而且是一份好工作。它属于解决方案架构师的职责，他们理应以此被衡量。前向部署工程师的职责，是把一线经验转化为未来每一位客户都能获得的东西。 一次 FDE 合作如果以一个满意的客户告终、而上游什么都没改变，那就在这个角色唯一存在的意义上失败了。你获得了上下文，却把它消耗在了本地。
我是花了大代价才学到这一点的。有一次，一个客户需要一个数据保留任务，于是我拼凑了一个名为“vinoo.groovy”的 Groovy 脚本帮他们应急——一个下午的工作量，本就没打算撑过一周。一年后，它运行在一个近十万人的客户那里，我的名字和它绑在了一起。这成了一个如此荒唐的故事，以至于我的团队开始叫我 vinoo.groovy。我们解决了问题，却从未把解决方案变成产品——于是我们花了数年时间维护一个本该立刻消亡的临时方案。你交付的每一个捷径都会变成你要负责的东西。真正的纪律在于知道哪些修复属于平台，哪些在完成使命的那一刻就该被有意丢弃。
分岔口
这就是整件事分道扬镳的地方。做同样的工作，底下什么都没有，你学到的是一家公司的模式，交付一个完全贴合它的东西，然后在合作结束时失去这一切。下一个客户从零开始，再下一个也是。这就是咨询。 它报酬丰厚，人才优秀，但它不会产生复利。
在同样的工作底下放一个平台，你描绘的每一家公司都会让下一次部署更快、产品更锋利，因为工程师带回来的东西有地方安放。这就是卖时间和建资产之间的区别，而我对这波淘金热的诚实判断是：身处其中的大多数公司正在建第一种，却向董事会描述第二种。
那就是你的工作：建平台。
我们在 Kepler 做什么，以及你能从中借鉴什么。
在 Kepler，我们从第一天起就这样设置这个职能，那时我们还没有足以证明它合理的客户。另一种选择是在第十四个才发现你的工程师一直在为错误的东西做优化。从一开始，我们的 FDE 就作为产品团队的延伸来运作；这是结构性的决定，其他一切都由此而来。
我们销售给对冲基金、投资银行、私募股权公司和其他金融机构。这些是使命各异的根本不同的机构，但它们都有一个不可妥协的共同点：数字必须正确，而且必须有人能够说明它们为什么正确。 这就是我们据以设计的约束，事实证明它很有用，因为它迫使运营模式浮出水面。与我们合作的任何公司都不能在产出工作成果时，其每一个数字背后没有清晰的可追溯来源。 这个不变量定义了我们的平台，给了我们执行的基石。
这些问题是普遍的。词汇不是。
这些公司中的每一家，底层都在运行着同一套本体论的某个版本，而每一家对它的描述都各不相同。 在信贷部门，“头寸”意味着一种东西；在同一家银行的股票部门，它意味着某种相近却不同的东西。两家基金可能用完全相同的措辞来描述收益计算，却对分母该包含什么各执一词。这些差异大多之所以存在，是因为某个人在（比如说）2011 年做了一个合理的决定，而这个决定比那个人活得更久；而且，它也没有被写下来放在任何你能找到的地方。
识别并填补这一鸿沟，正是 FDE 的工作。 模式（schema）告诉你存储了什么。它不会告诉你那意味着什么，而这两者之间的距离，恰恰就是一套听起来正确的系统产出一个错误数字的地方。
溯源对我们的客户来说是一项正确性要求，但对我们来说，它还起到了另一个作用：它让现场工作产生复利。 一套能够围绕糟糕的编码即兴发挥的系统，永远不会告诉你那个编码是糟糕的。我们的系统不做即兴发挥。 当我们误解了一家公司对某事物的定义时，这种误解会以失败的形式浮现，而不是以一个仅仅看起来合理的答案的形式出现。搞错了的工程师是从系统那里得知的，而不是在六周后的一次会议上从客户那里得知的。
这些部署随后会告诉我们，平台中该扩展什么，而这个问题比听起来要更狭窄。我们并不是试图了解某个特定基金希望拥有哪个功能。我们试图找出的是：平台在哪些地方过于狭窄，容纳不下我们不断遇到的东西。 三家公司要求同一个功能，这很容易被注意到，但价值相对较小。三家公司需要某种溯源层无法表达的东西，这才是我们真正在意的信号；而它通常悄无声息地到来，形式是某位工程师第三次绕过同一个限制。
如果你是在别处创业，以下是我会从这一切中拿走的部分。
产品杠杆才是为你买来试验权利的东西。 每一项落入平台的能力，都会让下一次部署的尝试成本更低，而低成本的尝试正是一家小公司快速学到任何东西的方式。没有这种杠杆，你每个客户只能得到一次昂贵的猜测。你仔细划定范围，构建数月，而如果猜错了，你就已经花掉了一个客户和一个季度才发现。我们宁愿在一个月里错四次，因为每一次尝试的成本都比上一次更低。
这就是为什么汇报关系不是行政细节。 把这个职能指向销售，激励就变成了拿下你眼前的这个客户——这是一项真实的工作，也是公司里应该有人去做的工作。但它不是这一项。把这个职能指向产品，那么每一次部署都会被要求产出某种下一次部署可以从中起步的东西。
护城河在哪里
所以，这就是我会在这个时代把护城河放在哪里。它不是模型，模型每个月都在贬值，而且无论如何你都是从别人那里租来的。它也不是人才，因为每个实验室都在竞逐同样那几百个人，而那个价格早已被发现。
它也不是任何一个客户的图谱。 这在几年前就已经成立，现在也一样，因为提取几乎免费，任何人都能在一个下午草拟出一家公司如何运作。
草稿不是资产。知道其中哪些部分是错的才是资产，而这只能来自被纠正的经历。
所以，对我们来说，护城河是积累的、当前的、经过验证的关于某个垂直领域公司实际如何运营的理解，它被保存在一个能保持其时效性并能证明它的平台上。 这里的每个词都至关重要。积累的，因为一次部署只是轶事，第十次才是模式。当前的，因为运营会漂移，而过时的模型会在 AI 系统底层悄无声息地失效，这在分析师面前从未如此。经过验证的，因为一个看似合理的编码和一个正确的编码看起来一模一样，直到某些东西出问题，而坚持溯源的全部意义就在于你能发现你拥有的是哪一种。
这是买不到的。竞争对手可以挖走你的工程师，复制你的界面，并阅读这篇文章（我们的竞争对手试图做全这三件事！）。他们无法走捷径的是在客户内部犯错、被纠正、将纠正融入平台，并在到达下一家公司时已经知道哪些问题是关键的这个过程。每一次这样的循环都让下一次更便宜，而这种复利就是你拥有的东西。
我见证了这个职能被建立三次，每次模式都成立。重要的工程师不是那些为客户交付最多的人，而是那些回来改变我们所构建的东西的工程师。
招聘前置部署工程师只为你买到一件事，那就是识别哪些问题值得解决的权利。 大多数公司从未走到那一步。但这是入场费，不是奖品。
我是 Vinoo Ganesh，Kepler 的 CEO，我们正在构建这篇文章所讨论的层，即让 AI 产品能够将每个数字追溯回源头的地面真相。在 Kepler 之前，我在 Palantir 领导 Spark 并构建了 Project Frontline，然后在 Citadel 负责业务工程。如果你正在这里构建，或者你认为我在这件事上有哪里弄错了，你可以在 LinkedIn 上与我争论。