The difference between FDE and consulting; diagram by Vinoo Ganesh

FDE 拥有 AI 领域最热门的工作。各大实验室、初创公司和私募股权公司都在招聘工程师，让他们深入客户的业务运营中解决问题。但对于这些工程师应该完成什么任务，以及招聘背后的实际战略是什么，几乎没有人达成共识。

我是 Vinoo，Kepler 的 CEO，Kepler 是面向 AI 的确定性基础设施。在过去十多年里，我在三家不同的机构三次构建了前沿部署职能。以下是我所见证的成功经验、失败教训，以及我对这一方向未来走向的看法。

第一段经历是在 Palantir。我最初在产品开发部门工作，负责构建存储和检索系统，后来作为 FDE 被派驻到商业、国防部（DoD）与国家安全、医疗健康以及石油天然气等多个领域。我还领导了 Project Frontline，这是一个轮岗项目，将我们的软件工程师培养成前沿部署工程师。约有 250 人经历了这个项目，其中许多人如今在 OpenAI、Anthropic、xAI 和 Anduril 等公司领导前沿部署团队。

第二段经历是在 Citadel，我负责业务工程。我们的客户是投资组合经理，唯一重要的问题是：我们构建的数据和软件产品能否帮助他们创造 alpha 收益。

第三段经历就是现在的 Kepler。在这里，前沿部署职能隶属于产品部门而非销售部门，所处的领域中，一个看似合理的错误答案比没有答案更糟糕。

对 FDE 的误解

几个月前，a16z 推出了前沿部署工程师奖学金项目，我与几位曾经的同事一起被提名为研究员。这是一个很棒的项目，我非常享受其中的许多交流。上周，我参加了在旧金山举行的第一场研究员晚宴。

席间坐着来自 Snowflake、Anthropic 以及多家我曾在报道中读到的初创公司的 FDE。随着晚宴的进行，我逐渐意识到，我们都在用同样的两个词（前沿部署）来描述几乎毫无共同之处的工作。在对话的某一段里，FDE 是一个在“第二次通话”时才加入的售前工程师；在另一处，它是能写 Python、背负销售指标的客户代表；而隔几个座位，它又更像是带着笔记本电脑和工作说明书（SOW）的顾问，被请来交付产品本身无法实现的东西。

几天后，有人在我们的 WhatsApp 群里认真提问：他们的 FDE 团队应该如何与已经驻扎在客户处的咨询公司划分职责范围。这是一个合理的问题，但至少基于我对 FDE 本质的理解，需要回答这个问题本身就有些奇怪。

需要说明的是，我并不想对这个术语搞“守门”那一套；词义本来就会演变，而这个术语的演变速度比大多数都要快。但有趣的是，这个群体里的人——也就是当今的 FDE 专家们——所描述的其实是根本不同的工作，有着不同的汇报关系和不同的激励机制。难怪任何关于 FDE 的 YouTube 视频下面，总有一半的评论是某种版本的“这不就是换个说法的咨询吗？”

所以在本文剩下的部分里，我将讲述 Project Frontline 的故事——通过我曾参与犯下的一个错误这个狭窄的视角，讲述这个错误如何让我成为一名 FDE，以及它最终如何促成了那项把我们的软件工程师轮岗为 FDE 的机制。

## Project Frontline 的历史

先交代一些背景。几乎从创立之初，Palantir 就分为两个独立的职能。第一个是产品开发（Product Development，PD），负责构建平台。第二个是业务开发（Business Development，BD），尽管名字如此，它既包含技术型的 BD 人员（当时已经被称为 FDE），也包含非工程背景、面向客户的成员（我们称他们为嵌入式分析师，即部署策略师）。

在绝大多数情况下，PD 并不直接与客户打交道；而在绝大多数情况下，BD 也不直接参与构建核心的通用平台。PD 往往通过二手渠道进行客户探索——要么与 BD 聊天，要么把那些在客户现场成功构建的功能吸收进核心产品。但这些都不是正式流程，全靠人际关系运转——比如某个 FDE 恰好和某位 PD 工程师熟到能把他拉过来。于是一线传回的好洞察能否进入平台（或者被放弃），完全取决于当时谁在场。

Me forward deployed in Bagram Airfield, Afghanistan.

2013 年，我加入 Palantir 不久，参与开发了一个名为 Phoenix 的事务存储系统。这个系统由我共事过的最优秀的几位工程师设计，设计极为干净，针对一组明确的客户用例。不过，这些用例是二手转述给我们的。我们了解并理解设计需求——其中聚焦于保留期限等商业需求——并且有巧妙的方案对数据进行分桶，从而支持存储一个滚动时间窗口的数据。在我们控制的每一个环境中，它的行为都完全符合规格。

然后我们把它部署到一家银行，结果发现真实的金融数据存在我们的测试数据中从未出现过的空洞。一个空白的时间戳会回退到 epoch 起点，于是保留逻辑尽职地为 1970 年 1 月 1 日至今的每一个窗口请求一个十分钟的桶。算下来大约是 230 万个 keyspace，而底层技术 Cassandra 每个文件句柄大约需要 5 MB。服务器理所当然地 OOM 了（内存耗尽），而要重新启动它需要 14 TB 的内存。也就是说，这个流程实际上在上线之初就已宣告死亡。

这里的根本原因并不是你可能猜到的那样——缺乏用户调研。我们有规格说明，理解自己的用例，也读过大量关于这类机构如何存储数据的资料。但我们从未做过的是：当系统在他们的生产数据上运行时，亲身站在那栋大楼里。这意味着我们这边没有人负责弥合设计与日常现实之间的差距。我们对那家银行的所有了解都是二手转述的，而且转述者都是善意的人，对他们来说，糟糕的数据不过是另一种常态。

就这样，我成了一名 FDE——这算是对实际发生的事情的一种慷慨描述。随着 Phoenix 在 Palantir 的商业客户群中铺开，我发现自己频繁飞往各地去修复我们交付的产品，这让我第一次直面我们的真实用户。在这个案例中，用户是 Palantir 自己的 FDE，这对我来说是件幸事，因为他们能用我已经熟悉的语言告诉我哪里出了问题。我开始围绕他们想要做的事情来构建和扩展系统。

所以，这也是一个关于我如何从切身体验而非书本知识中领悟 FDE 思维方式的故事。

通常这类故事到这里就结束了，总结出一条“要关注你的用户”之类的教训。但 Phoenix 后来演变成了更有意思的东西。它成为一个平台，Palantir 的 FDE 开始在其上构建网络安全、KYC、AML，以及一系列没人预先规划过的长尾用例。最终，我们（产品开发团队）不得不思考如何扩展 Phoenix 平台以支持所有这些用例。

我当时没有意识到，但这个迭代循环正是整个理念的核心。FDE 通过解决客户问题来获得洞察，而这些洞察决定了接下来要构建什么。这个角色是产品团队的延伸。

## 今天的 FDE

现实是，如今你看到的绝大多数 FDE 都不具备这种心态。这个头衔已被挪用，含义变得接近于“一个做着某种 vaguely 涉及客户的工作的人”，于是你会看到“前沿部署股票研究员”或“前沿部署售前工程师”这样的招聘启事。尽管这些头衔很荒唐，但这种挪用背后的直觉是对的，因为客户如今比五年前重要得多，而且其重要的原因非常具体。

唾手可得的果实已经摘完了。那些可以通过一个精心设计的产品、以完全相同的方式卖给一千家公司就能解决的问题，基本上都已被解决。剩下的是那些藏在围墙之内的工作——存在于混乱、无文档记录、几乎无法从外部推断的工作流中。这就是为什么突然人人都“前沿部署”了。你无法通过一次探索性电话推断出某家具体公司是如何结账的，而问题中抗拒推断的那部分，恰恰就是如今剩下的那部分。

这意味着圣杯已经悄然转移了。很长一段时间里，它指的是可重复的动作——同一个 SaaS 产品以同样的方式一遍又一遍地销售；如果你卖的是 token、字节或某种实体产品，这仍然是正确的目标。而对其他所有人来说，价值已经转移到了定制化上，转移到了最后一公里，转移到了工作流程中那 20% 没有任何产品能够预见、却决定了另外 80% 是否会被使用的部分。前沿部署已经成为解决这最后一公里的同义词。

但解决最后一公里只是这个角色使命的一半。你在某一家客户那里解决的最后一公里问题，正是告诉你平台中哪一部分需要变得可泛化的信号。一个只解决最后一公里、却从不把这个信号传回公司的 FDE 职能，不过是一个头衔更好听的服务/咨询团队。

那么，今天的 FDE 应该做什么？

我认为，作为 FDE，你的工作应该是收集名词和动词。让我们展开来说。

在一家公司里待上一周，你就会发现同一个概念通常至少有四种不同的叫法。销售说“客户”，运营说“客户”，财务记的是“计费实体”，工程写的是 org_id，而这些团队之间的每一道缝隙里都藏着一种翻译，一旦有人改了定义，这种翻译就会失效。这些名称只是表象，表象之下是运营模式。也就是说，通过学习一家公司的名词和动词，你就能真正地近似还原这家公司的运作方式。

名词是企业中的人们视为真实存在的东西，通常是一个“事物”。一个头寸、一笔交易、一个交易对手。通常，就每个团队而言，整个运营都围绕着少数几个对象运转，而它们没有一个是以教科书式的定义来定义的。这是因为两家公司会在幻灯片上用完全相同的方式描述一个头寸，却在代码里用截然不同的方式实现它。这不是 bug，这正是让公司彼此独特的原因。我的意思是，如果每家公司都拥有完全相同的名词集合，那你其实只需要一家公司就够了。

动词是名词运动的方式。比如一笔交易是如何入账的，或者账目关账之前必须满足什么条件，或者谁在深夜十一点审批一个例外情况，以及那个人休假时会发生什么。

这些东西几乎没有任何书面记录——它们是被活出来的。它们是组织赖以生存的运营体系。它们是文化。它们存在于那六个在公司待得足够久、早已对其习以为常的人的脑子里，也存在于某个人四年前搭建的、如今整个团队都在默默依赖的一张电子表格里。这就是为什么它如此有价值，也是为什么你无法直接开口要来。

The names are the surface and underneath them is the operating model.

通常，掌握这些知识的人自己并不知道他们拥有它。在我之前的某家创业公司里，我们花了将近一年时间试图把一个客户从 CSV 迁移到 Parquet，而一位数据质量工程师每次都从中阻挠。我们始终无法理解原因，理由也总是变来变去，但无非是“Parquet 更糟”、“它不好用”、“我觉得不合理”之类的说法。我们用过客户存储成本降低的论据、计算资源最小化的论据、流水线优化的论据……但都没能打动她，因为这些论据没有一个触及真正的问题。

后来我们派了一名 FDE 去现场观察这位数据质量工程师的工作方式。她把 CSV 从 S3 下载到一台 Windows 笔记本电脑上，双击打开，然后用肉眼逐行检查。这就是她的数据质量检查。当时 Parquet 还没有原生查看器，所以我们提议的方案等于夺走了她唯一的数据质量工具，却什么也没有给她。她并不是故意刁难，她只是在保护让她能够完成工作的那一件东西。

我们当晚就做了一个 Parquet 查看器，两天后她批准了迁移，流水线执行时间从大约十七小时缩短到两小时。她在任何面试中都绝不会说出这些。从她的角度看，原因显而易见，根本不值一提。

理解并定义这位分析师的运营系统，或者说名词与动词，让我们不仅理解了问题，还构建出一个解决方案，随后可以交付给一批有着同样问题的客户。

产出必须成为产品

理解名词与动词能为问题提供背景，但产出必须是一个产品，而不只是一个满意的客户。

名词与动词告诉你问题究竟是什么。它们不会告诉你该怎么解决；而大多数 FDE 职能正是在这里悄然出错，因为解决眼前的问题是令人满足且清晰可见的，同一周就会有人向你道谢。

让客户满意是一份真实且有价值的工作。它属于解决方案架构师，他们的考核也理应以此为标准。而前沿部署工程师的职责，是把一线经验转化为每一位未来客户都能获得的东西。如果一次 FDE 交付最终只让一个客户满意，而上游没有任何改变，那它就在这个角色存在的唯一意义上失败了。你拿到了背景信息，却把它消耗在了本地。

这个教训我付出了高昂的代价才学到。有一次，一位客户需要一个数据保留任务，于是我临时拼凑了一个名为“vinoo.groovy”的 Groovy 脚本来应急——那是一个下午的工作成果，本来没打算活过一个星期。一年后，它已经运行在一家拥有近十万名员工的客户那里，而我的名字也和它牢牢绑在了一起。这件事荒唐到我的团队都开始叫我 vinoo.groovy。我们解决了问题，却从未把解决方案做成产品——于是我们花了数年维护一个本该立刻消亡的临时补丁。你交付的每一个捷径，都会变成你要负责的东西。关键在于纪律：要分清哪些修复应该沉淀到平台里，哪些修复在完成使命的那一刻就该被刻意丢弃。

分岔口

这就是整件事的分水岭。如果做这项工作时下面没有任何支撑，你学到的只是一家公司的业务模型，交付的是完全贴合那一家公司的东西，而当项目结束时，这一切都会归零。下一个客户从零开始，再下一个客户也是如此。那是咨询。它报酬丰厚，人才优秀，但它不会产生复利。

如果在同样的工作下面放一个平台，那么你绘制的每一家公司都会让下一次部署更快、产品更锐利，因为工程师带回来的东西有了安身之处。这就是出售工时和构建资产之间的区别。而我对这场淘金热的诚实判断是：其中大多数公司都在做前者，却向董事会描述的是后者。

这就是你的职责：构建平台。

我们在 Kepler 的做法，以及你能从中借鉴什么。

在 Kepler，我们从第一天起就这样设定这个职能，那时我们还没有足以证明其合理性的客户。另一种做法是等到第十四个月才发现你的工程师一直在为错误的目标优化。从一开始，我们的 FDE 就作为产品团队的延伸而运作；这是所有其他安排都由此衍生的结构性决策。

我们向对冲基金、投资银行、私募股权公司以及其他金融机构销售产品。这些机构在本质上是不同的，有着不同的使命，但它们都共享一条不可妥协的底线：数字必须正确，而且必须有人能够证明它们为什么正确。这就是我们设计时所依据的约束条件，而事实证明这是一个有用的约束，因为它迫使运营模式浮出水面。与我们合作的任何机构，都无法在没有清晰溯源链条支撑每个数字的情况下产出工作成果。这一不变量定义了我们的平台，并为我们提供了执行的基石。

这些问题是普适的。但词汇不是。

这些公司中的每一家，底层运行的其实都是同一个本体的某种版本，但每一家对它的描述都不一样。“头寸”在信用交易台上是一个含义，在同一家银行的股票交易台上又是另一个相近的含义。两家基金会用完全相同的术语描述收益率计算，却在分母应包含什么上产生分歧。这些差异大多源于某个人在（比如说）2011 年做出的一个合理决定，而这个决定比做决定的人活得更久；而且，它没有写在任何你能找到的地方。

识别并填补这个缺口，正是 FDE 的工作。Schema 告诉你存储了什么，却不告诉你它的含义，而这两者之间的距离，恰恰就是一个听起来正确的系统产出错误数字的地方。

溯源（Provenance）对我们的客户而言是正确性要求，但对我们来说它还有另一个作用：它让这个领域的工作产生复利效应。一个能在糟糕的编码周围随机应变的系统，永远不会告诉你编码是糟糕的。我们的系统不会随机应变。当我们误解了某家公司对某个概念的定义时，这种误解会以失败的形式浮现出来，而不是以一个仅仅看起来合理的答案的形式。搞错的工程师会从系统那里得知，而不是在六周后的会议上从客户那里得知。

这些部署随后会告诉我们该在平台上扩展什么，而这个问题比听起来要窄。我们不是要了解某家基金想要什么功能。我们是要找到平台过于狭窄、无法容纳我们不断遇到的东西的地方。三家公司要求同一个功能，很容易注意到，但价值相对有限。三家公司需要某种溯源层无法表达的东西，这才是我们真正关心的信号；而且它通常悄然而至，表现为某位工程师第三次绕过同一个限制。

如果你在别处构建产品，以下是我希望你能从这一切中带走的部分。

产品杠杆是让你获得实验权利的东西。平台中落地的每一项能力，都会让下一次部署的尝试成本更低，而低成本的尝试正是一家小公司快速学到任何东西的方式。没有这种杠杆，你每个客户只能做一次昂贵的猜测。你小心翼翼地界定范围，开发数月，如果猜错了，你就花掉了一个客户和一个季度才弄明白。我们宁愿在一个月里错四次，因为每一次尝试的成本都比上一次更低。

这也是为什么汇报线不是行政细节。把这个职能指向销售，激励就变成拿下眼前的客户——这是一份真实的工作，公司里也确实应该有人去做。但它不是这份工作。把这个职能指向产品，每一次部署都被要求产出能让下一次部署从中起步的东西。

护城河在哪里

所以，这就是我认为这个时代的护城河所在。它不是模型——模型每个月都在贬值，而且无论如何你都是从别人那里租来的。也不是人才，因为每家实验室都在竞相争夺同样那几百个人，价格早已被市场发现。

它也不是任何一家客户的流程图。几年前就是如此，现在依然如此，因为提取流程几乎零成本，任何人都能在一个下午内草拟出一家公司的运作方式。

草稿不是资产。知道草稿中哪些部分是错的，才是资产——而这只有被纠正过才能获得。

所以，对我们而言，护城河是对某个垂直行业内企业实际运作方式的积累性、时效性、经过验证的理解，并保存在一个能保持其时效性且能加以证明的平台中。这里的每个词都至关重要。“积累性”，因为一次部署只是个例，第十次才是规律。“时效性”，因为业务流程会漂移，而过时的模型在 AI 系统之下会悄无声息地失效——这种失效方式在分析师面前从未发生过。“经过验证”，因为一个看似合理的编码和一个正确的编码在出问题之前看起来一模一样，而坚持溯源的意义就在于让你弄清楚自己拥有的是哪一种。

这是买不来的。竞争对手可以挖走你的工程师、抄袭你的界面、读这篇文章（我们的竞争对手这三件事都在做！）。但他们无法走捷径的是这样一个过程：在客户那里犯错、被纠正、把纠正融入平台，然后在面对下一家企业时已经知道哪些问题是关键所在。这个循环的每一轮都会让下一轮成本更低，而这种复利效应才是你真正拥有的东西。

我亲眼见证过这个职能被构建了三次，每一次规律都成立。真正重要的工程师，不是那些为客户交付最多成果的人，而是那些回来改变我们产品构建方式的人。

招聘前沿部署工程师只能买到一样东西，那就是识别哪些问题值得解决的资格。大多数公司从未走到这一步。但这是入场券，不是奖品。

我是 Vinoo Ganesh，Kepler 的 CEO，我们正在构建本文所讨论的那一层——让 AI 产品能够将每个数字追溯至源头的 ground truth。在 Kepler 之前，我在 Palantir 领导 Spark 并创建了 Project Frontline，随后在 Citadel 负责业务工程。如果你正在这个领域构建产品，或者认为我的某个观点有误，欢迎在 LinkedIn 上与我辩论。