现场部署工程师的崛起与正确做法

驻场工程师的崛起，以及如何把这份工作做对

FDE 与咨询的区别；插图来自 Vinoo Ganesh FDE 拥有 AI 领域最炙手可热的工作。实验室、创业公司和私募基金都在招工程师，让工程师进驻客户的业务现场解决问题。但在这些工程师究竟应该完成什么任务、招聘背后的策略到底是什么上，几乎没有两家公司意见一致。

我是 Vinoo，Kepler 的 CEO，我们做的是面向 AI 的确定性基础设施（deterministic infrastructure for AI）。我曾在三家不同的机构里三次搭建驻场工程师（Forward Deployed Engineer，FDE）职能的各个组成部分，前后跨度十余年。

下面是我见过有效的方法、见过失败的教训，以及我个人对这个方向未来走向的看法。

第一次是在 Palantir。我最初在产品开发部门，负责构建数据的存取系统，后来作为 FDE 被派驻到商业、国防与国家安全（DoD and NatSec）、医疗以及油气领域的客户现场。

我还主导了 Project Frontline，这是我们公司把软件工程师轮岗培养成驻场工程师的项目。

大约有 250 人从这个项目走出来，其中很多人现在在 OpenAI、Anthropic、xAI 和 Anduril 等公司领导驻场团队。

第二次是在 Citadel，我负责商业工程（Business Engineering）。我们的"客户"是投资组合经理，唯一重要的问题是：我们构建的数据和软件产品有没有真正帮他们赚到超额收益（alpha）。

第三次就是 Kepler。在这里，驻场工程师职能归在产品部门下面，而不是销售部门，而且我们所处的领域里，一个看起来合理的错误答案比没有答案更糟糕。

关于 FDE 的误解

几个月前，a16z 启动了 Forward Deployed Engineer Fellowship，我被提名为 fellow 之一，和几位我以前的同事并列。这是个很棒的项目，我非常享受其中的许多对话。上周我去旧金山参加了第一次 fellow 晚宴。

围坐在桌旁的是来自 Snowflake、Anthropic 以及几家我一直在关注的创业公司的 FDE 们。晚宴进行过程中逐渐清晰的一件事是：我们在用"驻场"（forward deployed）这两个同样的词，描述的工作却几乎没有任何共同点。

对话中有人的 FDE 是从"第二个电话"开始加入的销售工程师（sales engineer），别处又是能写 Python、身上背着销售配额的业务代表，再隔几个座位，则更像带着笔记本电脑和一份工作说明书（statement of work）的顾问，被请进来交付产品自身做不到的事情。

几天后，有人很认真地在我们的 WhatsApp 群里问：他们的 FDE 团队应该怎么和已经驻扎在这个客户那边的咨询公司划分工作范围。

这是个合理的提问，但也是一个本不该需要回答的问题，至少按我个人对 FDE 的理解是这样。

说清楚，我无意守着一个词的边界不放；词义会变，这个词变得尤其快。但有意思的是，这个群里的成员都是当下 FDE 领域的专家，却在描述说到底截然不同的工作，汇报关系不同、激励机制也不同。

怪不得任何一条关于 FDE 的 YouTube 视频下面，总有一半评论在问："这不就是把咨询重新发明了一遍吗？"

因此在这篇文章剩下的部分，我会通过我所亲历的一个错误的狭小视角，讲述 Project Frontline 的故事：那个错误如何把我变成了一个 FDE，又如何最终启发了一个把我们的软件工程师转变为 FDE 的轮岗项目。

Project Frontline 的来龙去脉

先交代一些背景。从几乎最初开始，Palantir 就分成两个独立的部门。第一个是 Product Development（产品开发，简称 PD），负责搭建平台。第二个是 Business Development（业务开发，简称 BD），虽然名字如此，里面却既包含技术型 BD 同事（已经叫作 FDE），也包含非工程师出身、面向客户的同事（我们叫他们 Embedded Analyst，或者 Deployment Strategist）。

PD 在绝大多数情况下不直接接触客户；而 BD 在绝大多数情况下也不直接参与构建核心的、通用的平台。PD 通常通过和 BD 聊天，或者把在现场成功搭出来的功能吸收进核心产品的方式，二手地完成客户调研。

不过这些都不是流程化运作的，整个机制靠关系驱动，比如哪个 FDE 恰好和哪个 PD 工程师熟到能抓过来帮忙。某条来自一线的好洞察能否进入平台（或被丢弃），取决于当时谁在场。

我在阿富汗巴格拉姆空军基地驻场时的照片。

2013 年，我刚加入 Palantir 不久，参与了一个叫 Phoenix 的事务存储系统。这个系统由我共事过的最优秀的工程师之一设计，架构非常干净，范围紧扣一组明确的客户用例。

不过这些用例都是二手传达给我们的。

我们知道并理解了设计需求，这些需求重点关注保留期（retention periods）的商业侧要求，还巧妙地设计了把数据分桶（bucket）的方法，让系统可以存储一个滚动窗口（rolling window）的数据。系统在我们自己控制的所有环境里都严格按照规范运行。

然后我们把它部署到一家银行，真实的金融数据里却出现了我们的测试数据从未有过的空洞。

一个空白的 timestamp 落到了 epoch（Unix 时间起点），于是保留期逻辑忠实地为 1970 年 1 月 1 日到今天之间每个窗口请求一个十分钟的桶。结果产生大约 230 万个 keyspace，而底层用的 Cassandra 每个文件句柄大约需要 5 兆字节。服务器理所当然地 OOM（Out-Of-Memory，内存溢出）了，重新启动它将需要 14 TB 的 RAM。

也就是说，这个流程基本上是胎死腹中。

根源并不是像你可能猜的那样是缺少用户调研。我们有规范，理解用例，也读过大量关于这类机构如何存储数据的资料。

我们从未做过的事情是：站在大楼里，看着系统跑在他们的生产数据上。也就是说我们这边没有人为"设计与日常现实之间的鸿沟"负责。

我们关于那家银行所知道的一切，都是二手转述得来的，而转述者是善意的人，对他们来说，糟糕的数据只是又一种日常。

这就是我变成 FDE 的经过，这其实是对当时发生的事情的一种美化说法。随着 Phoenix 在 Palantir 商业客户群中铺开，我发现自己飞到各地去修补我们交付出去的问题，而那也是我第一次站到我们真正的用户面前。

在这种情况下，用户其实是 Palantir 自己的 FDE，对我来说这是件幸运的事，因为他们能用我已经熟悉的语言告诉我哪里出了问题。我开始为他们要做的事情构建和扩展系统。

所以这也是我如何不是靠智力、而是靠血肉之躯学会 FDE 思维方式的故事。

普通版本的故事到这里就结束了，留下一条关于"关注用户"的教训。Phoenix 后来变得比这更有意思。

它演变成了一个平台，Palantir 的 FDE 们开始在它之上构建网络安全、KYC（Know Your Customer，了解你的客户）、AML（Anti-Money Laundering，反洗钱）以及一长串没人预先规划过的用例。

最终，我们（产品开发部门）不得不思考如何扩展 Phoenix 平台来支撑所有这些用例。

我当时没看出来，但那个迭代循环就是全部要义。

一个 FDE 解决客户问题，是为了赢得能告知下一步该建什么的洞察。

这个角色是产品团队的延伸。

当下的 FDE

现实是，这些根本不是你今天看到的大多数 FDE 的心态。

这个词已经被挪用为大致接近"一个做点跟客户沾边的事情的人"，于是你就会看到诸如"驻场股票研究员"或"驻场销售工程师"这样的招聘启事。这种挪用背后的直觉是对的，即使标题很傻，因为客户比五年前更重要了，而且这种重要性有一个具体的原因。

容易摘到的果子已经摘完了。

那些可以靠一个设计良好的产品、以完全相同的方式卖给一千家公司的问题，基本上已经解决。

剩下的是那些发生在围墙之内、流程凌乱、缺乏文档、几乎不可能从外部推断的工作。

这就是为什么大家突然都"驻场"了。你不可能从一次 discovery call（需求挖掘电话会议）里推断出一家具体公司的账是怎么平的，而抵抗推断的那部分问题，正是现在被剩下的部分。

也就是说真正的圣杯已经悄悄转移了。很长一段时间它都是那种可重复的动作，同一个 SaaS 产品、同样的方式一遍又一遍地卖，而如果卖的是 token（模型计费单位）、字节或者某种实物，这仍然是对的雄心。

对其他所有人来说，价值已经迁移到了定制化、最后那一步（last mile）、以及工作流中任何产品都预料不到的 20%，而正是这 20% 决定了另外 80% 能否被真正用起来。

"驻场"已经成了解决那最后一步的代名词。

但解决它只是这个角色一半的使命。你在某一个客户那里解决的"最后一步"问题，就是告诉你平台的哪一块需要被泛化的信号。

一个只解决"最后一步"却从不把信号传回总部的 FDE 团队，不过是一个挂着更好听头衔的服务/咨询团队。

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

我主张：作为 FDE，你的本职工作应该是收集名词和动词。让我展开说说。

在一个公司里待上一周，你就会注意到同一个概念通常至少有四种不同的名字。销售叫 customer，运营叫 client，财务记一个 billing entity，工程代码里写 org_id，而每两条团队之间的接缝都藏着一层翻译，一旦有人改了定义它就崩。

这些名字是表面，底下才是运营模式（operating model）。

也就是说，你真的可以通过学习他们的名词和动词来代理（proxy）一家公司的运作方式。

名词是一家公司的员工视之为"真实存在"的东西。

通常它是一个"thing"，一笔仓位（position）、一笔交易（trade）、或者一个交易对手（counterparty）。通常按团队来算，只有少数几个对象撑起整个运营，而其中没有哪一个是按照教科书上的定义来的。

这是因为两家公司可能在一张幻灯片上把一笔仓位描述得一模一样，在代码里却完全不同。这不是 bug，这就是公司之所以独特的地方。我是说，如果每家公司都拥有完全相同的一组名词，那你其实只需要一家公司就够了。

动词是名词如何流动。

比如一笔交易是怎么录入（booked）的，账本能关掉之前必须满足哪些条件，晚上十一点谁批一条例外情况，这个人休假时又由谁顶上。

这些几乎都没有写在文档里，它们是活出来的。

它是组织赖以运作的运行系统（system of operations）。它就是文化。

它住在六位在那里待得够久、久到不再注意到它的员工的脑袋里，住在某个四年前有人建的、整个团队现在默默依赖着的电子表格里。这就是它为什么这么值钱，也同样是你不可能开口要到的原因。

名字是表面，底下才是运营模式。

通常，掌握这些知识的人并不知道自己拥有它。

在我之前参与的一家创业公司里，我们花了将近一年试图把一个客户从 CSV 迁到 Parquet，每次都被一位数据质量工程师挡下来。

我们始终搞不懂为什么，理由每次都换，但总是"Parquet 更差"、"它没法用"、"对我来说没意义"之类的变体。我们搬出客户存储量下降的论点、计算资源最小化的论点、流水线优化的论点……都没能说服她，因为这些都不是真正的问题所在。

后来我们派了一位 FDE 进去，跟着这位数据质量工程师观察她是怎么工作的。

她做的事情是从 S3 把 CSV 拉到一台 Windows 笔记本上，双击打开，用肉眼一行行看。这就是她的数据质量检查。当时 Parquet 没有原生的查看器，所以我们提议的方案会夺走她手头唯一的数据质量工具，却什么替代品都没给她。

她不是难相处，她只是在保护那个唯一能让她干活的工具。

我们当晚就做了一个 Parquet 查看器，两天后她批准了迁移，流水线的执行时间从大约十七个小时缩短到两个小时。

她在任何一次访谈里都不会说出这些。

从她的视角看，原因显而易见，不值一提。

理解并定义这位分析师的"运行系统"，也就是名词与动词，让我们不仅理解了问题，还能打造一个解决方案，进而交付给存在同样问题的一批客户。

输出必须是产品

理解名词和动词让问题有了上下文，但产出必须是一个产品，而不只是一个满意的客户。

名词和动词告诉你一个问题真正是什么。它们并不告诉你该怎么做；而这正是大多数 FDE 职能悄悄翻车的地方，因为解决眼前的问题让人满足、也容易讲清楚，而且当周就会有人因此感谢你。

让客户满意是一项真实的工作，也是一项好工作。它属于解决方案架构师（Solutions Architect），他们的考核指标理应放在这件事上。

驻场工程师的工作，是把一线教给你的东西变成今后每一位客户都能拿到的东西。

一场 FDE 介入最终只换来一个开心的客户、而上游什么也没改，那这件事就失败了这个角色存在的唯一意义。你拿到了上下文，却把它就地花掉了。

我学到了这一课，而且代价不菲。有一次一个客户需要一个数据保留任务，我随手拼凑了一个叫 vinoo.groovy 的 groovy 脚本应付一下，一下午的活，本来就没打算让它活过那一周。一年后，它跑在一家覆盖近十万人的客户那里，我的名字和它焊在了一起。这事荒唐到我的团队开始叫我 vinoo.groovy。

我们修好了问题，却没有把补丁变成产品，于是我们花了几年时间维护一个本该死掉的临时方案。你交付的每一条捷径，最终都变成了你必须为之负责的东西。

这里的原则是：知道哪些修法属于平台、哪些修法要在完成使命的那一刻刻意扔掉。

那个分叉

整个事情在这里分叉了。如果底下什么都没有就去做这些工作，你只会学到一家公司的模型、做出正好贴合它的东西，然后在项目结束的时候把这一切全部丢掉。

下一个客户从零开始，下下个客户也是。这就是咨询。

它赚钱不少，团队的人也很优秀，但它不产生复利。

在同样的工作底下垫一个平台，你每映射一家公司，下一次部署就更快、产品也更锐利，因为工程师带回总部的东西有了落脚之处。

这就是"按工时卖"和"构建资产"的区别。我对当下这波淘金热坦率的判断是：其中的大多数公司在建第一种东西，却向董事会描述成第二种。

这就是你的工作：建那个平台。

我们在 Kepler 的做法，以及你能带走的部分

在 Kepler，我们从第一天起就这样设置这个职能，那时候我们还没有足够的客户来为这个设置辩护。另一种做法是等到第 14 个月才发现你的工程师一直在为错误的东西优化。

从一开始，我们的 FDE 就作为产品团队的延伸存在；这是一切其他决策所依据的结构性决定。

我们卖东西给对冲基金（hedge funds）、投资银行（investment banks）、私募基金（PE firms）以及其他金融机构。这些是根本不同的机构，有着不同的使命，但它们共享一个不容商量的事实：数字必须是对的，而且必须有人能说明它为什么是对的。

这是我们设计的约束条件，结果证明这个约束很有用，因为它迫使运营模式浮到水面上。

和我们打交道的每一家公司，其产出的工作成果背后都必须有清晰的来源追溯（provenance）链条，覆盖其中每一个数字。

这个不变式（invariant）定义了我们的平台，也给了我们一块坚实的执行基座。

这些问题是通用的，但词汇不是。

每一家这类公司都在底层运行着某个版本的同一种本体（ontology），每一家描述它的方式都不一样。

一笔仓位（position）在信用交易台（credit desk）上是一个意思，在同一家银行的股票交易台（equities desk）上又是一个相邻的意思。两家基金可能用完全一样的语言描述一个收益计算，却对分母里该放什么意见相左。这些差异大部分是因为某个（比如说）2011 年的人做了一个合理的决定，这个决定后来活得比那个人还久；而且它也不在任何你找得到的地方被写下来。

识别并填补这道鸿沟，就是 FDE 的工作。

模式（schema）告诉你存了什么。它不告诉你"意思"是什么，而这两者之间的距离，正是"听起来对的系统产出错误的数字"这种状况的精确位置。

来源追溯对我们的客户来说是一个正确性要求，但对我们来说还有另一层作用：它让一线的工作可以复利。

一个能在糟糕的编码方式周围临场发挥的系统，永远不会告诉你"这个编码方式很糟糕"。

我们的系统不会临场发挥。

当我们误解了一家公司对某个东西的定义时，这种误解会以一次失败浮出水面，而不是以一个"看起来挺合理"的答案蒙混过关。理解错的工程师会从系统那里得到反馈，而不是在六周后的会议上从客户那里听到。

然后这些部署会告诉我们平台上需要扩展什么，这个问题比听起来更窄。我们并不是在试图了解"某一家基金会喜欢什么功能"。

我们是在找平台中那些太窄、容不下我们反复撞到的现实的地方。

三家基金要求同一个功能，这很容易注意到，价值也相对有限。三家基金都需要"来源追溯层无法表达"的某个东西，这才是我们真正在意的信号；它通常悄无声息地到来，表现为某位工程师第三次撞上同样的局限，只好再次绕过去。

如果你是在别的地方建类似的东西，下面是我希望你能从这一切中带走的那部分。

产品杠杆（product leverage）才是买到你去尝试的权利的东西。

平台里落下的每一项能力，都让下一次部署的尝试成本更低；而低成本的尝试，是一家小公司高速学习的唯一途径。没有这种杠杆，每个客户你只够做一次昂贵的猜测。你谨慎地定范围、耗时数月去构建，如果猜测错了，你花掉一个客户和一整个季度来发现这件事。我们宁可一个月里错四次，因为每一次尝试的成本都比上一次更低。

这就是为什么汇报关系不是行政细节。

把职能指给销售部门看，激励就会变成"签下眼前的客户"，这是一项真实的工作，也确实该由公司里的某个人去做。但它不是这项工作。

把职能指给产品部门，每一次部署都会被要求产出"下一次部署可以从中起步的东西"。

护城河在哪里

所以在当下这个时代，我会把护城河放在这里。

护城河不是模型，它每个月都在贬值，而且不管怎样你都是在从别人那里租用它。

也不是人才，因为每家实验室都在竞标同一批几百号人，价格已经被发现。

也不是任何单一客户的业务图谱。

这一点几年前就成立，现在依然如此，因为抽取（extraction）的成本几乎为零，任何人都能花一下午就把一家公司的运作方式草拟出来。

草图不是资产。知道草图的哪几处是错的，才是资产，而这只能