FDE 是 AI 领域最火的岗位。实验室、初创公司和私募股权（PE）机构都在招聘工程师，让他们驻扎在客户的业务现场，解决客户的问题。但几乎没人能就这些工程师到底该完成什么、招聘背后的战略究竟是什么达成一致。
我是 Vinoo，Kepler 的 CEO，Kepler 是面向 AI 的确定性基础设施。十多年来，我在三家不同的机构先后三次搭建过前沿部署职能的一部分。下面是我见过哪些做法有效、哪些失败，以及我认为这个方向会走向何处。
第一家是 Palantir。我最初做产品研发，构建存储与检索系统，后来作为 FDE 被派驻到商业、国防部与国家安全、医疗以及油气等多个领域。我还牵头了 Project Frontline，这是一个把我们的软件工程师轮岗转型为前沿部署工程师的项目。大约 250 人经历过这个项目，其中许多人如今在 OpenAI、Anthropic、xAI 和 Anduril 等公司负责前沿部署团队。
第二家是 Citadel，我在那里负责业务工程。我们的客户是投资组合经理，唯一重要的问题是：我们构建的数据和软件产品能否帮助他们创造阿尔法收益。
第三家是 Kepler，在这里前沿部署职能归属于产品而非销售，而它所处的领域里，看似合理的错误答案比没有答案更糟糕。
对 FDE 的误解
几个月前，a16z 推出了前沿部署工程师奖学金计划（Forward Deployed Engineer Fellowship），我被提名为入选者之一，同批还有几位我以前的同事。这是个很棒的项目，我很享受其中的许多交流。上周，我参加了在旧金山举办的第一次入选者晚宴。
同桌的有来自 Snowflake、Anthropic 的 FDE，还有一些我早就在关注的初创公司的人。整个晚上下来，我们逐渐发现：大家用同样的两个词（前沿部署）来描述几乎毫无共同点的工作。在一段对话里，FDE 是参加“第二次通话”的售前工程师；另一处，FDE 是背着销售指标、会写 Python 的销售代表；再往下几个座位，FDE 更像是带着笔记本电脑和工作说明书（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 工程师熟到能把人拉过来。于是，来自现场的好洞察能否进入平台（或被搁置），取决于当时谁在场。
2013 年，我刚加入 Palantir 不久，参与了一个名为 Phoenix 的事务存储系统。这个存储系统由我共事过的一些最出色的工程师设计，设计极其干净，范围明确地针对一组清晰的客户用例。不过，这些用例是二手转述给我们的。我们了解并理解设计需求，其重点是商业场景中的数据保留期限要求，并且有巧妙的方案把数据分桶，以支持存储滚动窗口内的数据。在我们所能控制的每一个环境中，它的表现都与规格完全一致。
然后我们把它部署到一家银行，结果发现真实的金融数据存在测试数据里从未出现过的缺漏。一个空白的时间戳落到了 epoch（1970 年 1 月 1 日），于是保留逻辑尽职地为 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，都不是这种心态。这个词已被挪用，意思近乎“做某些与客户沾点边的事的人”，于是才会出现招聘前沿部署股票研究员或前沿部署售前工程师的岗位。即便头衔荒唐，这种挪用背后的直觉却是对的，因为客户比五年前更重要了，而且重要有其特定的原因。
唾手可得的果实已经被摘光了。那些只要一款设计精良、原样卖给上千家公司的产品就能解决的问题，基本已经解决了。剩下的是藏在围墙之内的工作，存在于混乱、没有文档、几乎不可能从外部推断的工作流之中。这就是为什么人人突然都成了“前沿部署”。你无法通过一次探索性通话，推断出某家具体公司如何完成结账，而难以推断的那部分问题，正是现在剩下的部分。
这意味着“圣杯”已悄然转移。很长一段时间里，它指的是可重复的打法，即同一款 SaaS 产品以同样的方式一遍遍地售卖；如果你卖的是 token、字节或某种实物，这仍然是正确的目标。而对其他所有人来说，价值已经迁移到了定制化，迁移到了最后一公里，也就是那 20% 没有任何产品能预见的工作流环节，它决定了其余 80% 究竟会不会被使用。“前沿部署”已经成了解决最后一公里的同义词。
但解决问题只是这个角色的一半职责。你在某个客户那里解决的最后一公里问题，是一个信号，告诉你平台的哪一部分需要变得可泛化。如果一个 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 就是产品团队的延伸；其他一切都由这个结构性决策衍生而来。
我们的客户包括对冲基金、投资银行、PE 机构和其他金融机构。这些机构的本质各不相同，使命也不同，但它们都有一条不容商量的共同要求：数字必须正确，而且必须有人能说明它们为什么正确。这就是我们围绕设计的约束，事实证明它很有用，因为它迫使运营模型显露出来。我们接触的任何一家公司，都不可能在没有清晰溯源链条支撑每一个数字的情况下产出工作成果。这条不变量定义了我们的平台，也为我们的执行提供了基石。
这些问题是普遍的，词汇却不是。
这些公司底层运行的都是同一套本体（ontology）的某种版本，而每家的描述方式都不同。在同一家银行里，“头寸”在信贷交易台上是一个意思，在股票交易台上则是相近但不同的意思。两只基金在收益率计算上使用完全相同的措辞，却对分母里该放什么存在分歧。这些差异大多是因为某人在（比如）2011 年做了一个合理的决定，而这个决定比做决定的人活得更久；而且，它没有被写在任何你能找到的地方。
识别并填补这道缺口，就是 FDE 的工作。模式（schema）告诉你存储了什么，却不会告诉你它意味着什么，而两者之间的距离，恰恰是一个听上去正确的系统算出错误数字的地方。
溯源对我们的客户来说是正确性要求，但对我们自己，它还起到另一个作用：它让现场工作产生复利。一个能绕过糟糕编码即兴发挥的系统，永远不会告诉你编码有问题。我们的系统从不即兴发挥。当我们误解了某家公司如何定义某个概念时，这种误解会以失败的形式暴露出来，而不是变成一个看似合理的答案。犯错的工程师是从系统那里发现问题的，而不是六周后在会议上从客户口中得知。
部署随后会告诉我们平台该扩展什么，这是个比听上去更窄的问题。我们并不是想弄清某只基金想要哪个功能。我们是想找出平台太窄、容不下我们反复遇到的东西的地方。三家公司要求同一个功能，很容易注意到，但价值相对有限。三家公司需要溯源层无法表达的东西，才是我们真正在意的信号；它通常悄无声息地出现，表现为一位工程师第三次绕开同一个限制。
如果你在别处做同样的事，下面是我希望你从这一切中带走的部分。
产品杠杆买到的是实验的权利。每一项落入平台的能力，都让下一次部署更廉价地尝试，而廉价的尝试正是小公司快速学习的方式。没有这种杠杆，你对每个客户只有一次昂贵的猜测。你小心地划定范围，花几个月构建，如果猜错了，你就花掉了一个客户账户和一个季度才发现这一点。我们宁愿一个月错四次，因为每一次尝试的成本都比上一次更低。
这就是汇报线不是行政细节的原因。如果让这个职能向销售汇报，激励就会变成拿下眼前的客户，那是一份真实的工作，公司里也应该有人去做，但不是这份工作。如果让这个职能向产品汇报，每一次部署都被要求产出下一次部署可以起步的东西。
护城河在哪里
那么，这是我认为这个时代护城河所在的位置。不是模型，模型每个月都在贬值，而且无论如何你用的都是从别人那里租来的。也不是人才，因为所有实验室都在争抢同样的几百个人，这个价格早已被发现。
也不是任何单个客户的地图。几年前就是如此，现在依然如此，因为提取几乎是免费的，任何人一个下午就能起草出一家公司的运作方式。
草稿不是资产，知道草稿哪些部分是错的才是资产，而这只能来自被纠正的经历。
因此，对我们来说，护城河是对一个垂直行业中的公司实际如何运作的、累积的、最新的、经过验证的理解，它存放在一个能保持其最新并能证明其正确性的平台中。这里的每个词都承重。“累积”，因为一次部署只是轶事，第十次才是模式。“最新”，因为运营会漂移，一个陈旧的模型会在 AI 系统底下悄无声息地失效，而在分析师面前它从不会这样。“经过验证”，因为一个看似合理的编码和一个正确的编码看上去完全一样，直到出了问题，而坚持溯源的全部意义，就在于让你知道自己手里的是哪一种。
这是买不来的。竞争对手可以挖走你的工程师、抄走你的界面、读到这篇文章（我们的竞争对手这三件事都在尝试！）。他们无法走捷径的，是那一整个序列：在客户那里犯错、被纠正、把纠正融入平台，然后带着已经知道哪些问题承重的认知，去到下一家公司。每一轮循环都让下一轮更廉价，而这种复利就是你所拥有的东西。
我见证过这个职能被搭建了三次，每一次规律都成立。真正重要的工程师，不是那些为客户交付最多东西的人，而是那些回头来改变了我们所构建之物的人。
雇用前沿部署工程师只能买到一样东西，那就是识别哪些问题值得解决的权利。大多数公司连这一步都走不到。但这只是入场费，而不是奖品。
我是 Vinoo Ganesh，Kepler 的 CEO，我们正在构建本文所讲的那一层，即让 AI 产品能把每个数字追溯到来源的基准真相（ground truth）。在 Kepler 之前，我在 Palantir 主导 Spark 并创建了 Project Frontline，之后在 Citadel 负责业务工程。如果你也在这个方向上构建，或者认为我哪里说错了，欢迎在 LinkedIn 上与我争论。