中文全文译本
# Forward Deployed Engineer（前线部署工程师）的崛起——以及如何把这活干对
在联合创办 Kepler 之前，Vinoo Ganesh 曾在 Palantir 领导 Spark，并打造了 Project Frontline——一项面向 Forward Deployed Engineer 的开创性轮岗项目。他带我们走一遍 FDE 的最佳实践。
*Latent Space · 2025-09-12 · 约 17 分钟阅读*
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。一晚上下来很清楚：我们都在用同样两个词——forward deployed——描述几乎毫无共同点的工作。有的对话里，FDE 是「第二通电话」才加入的售前工程师；别处它是能写 Python、还背配额的销售；再几个座位开外，它更接近带着笔记本和 SOW 的顾问，被请来交付产品本身交付不了的东西。
几天后，有人认真在 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 的交易存储。设计来自我合作过的一些最顶尖工程师，设计干净，范围也对准了一组清晰的客户用例。但那些用例是二手转述给我们的。我们理解和掌握了设计要求——重点在商业侧的保留期——也有聪明办法把数据分桶，以便存滚动窗口。在我们控制的环境里，它表现得完全符合规格。
然后我们把它部署到一家银行，真实金融数据里的空洞是测试数据从未有过的。一个空时间戳落到了 epoch，于是保留逻辑忠实地为 1970 年 1 月 1 日到今天之间每一个窗口请求一个十分钟桶。结果大约 230 万个 keyspace；后台是 Cassandra，每个文件句柄大约要 5MB。服务器理所当然 OOM 了；要再拉起来大概需要 14TB RAM。等于这套东西一落地就死了。
根因并不是「缺用户研究」——你可能以为是。我们有规格，理解用例，也读过很多关于这类机构如何存数据的材料。我们从未做过的是：站在大楼里面，看着系统对着他们的生产数据跑。这意味着，设计和日常现实之间的缝隙，我们这边没人负责。关于那家银行我们知道的一切，都是善意的二手转述；而对他们来说，坏数据只是又一种常态。
就这样我成了 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；这些团队之间的每一道缝，都藏着翻译——定义一变就断。名字是表层，底下是运营模型。也就是说，学会他们的名词和动词，你就能真正代理推断一家公司怎么运转。
名词是业务里的人当作「真实」的东西，通常是一个「物」：仓位、交易、对手方。通常按团队看，整盘操作围着少数几个对象转，没有一个会按教科书定义。两家公司可以在幻灯片上把仓位说得一模一样，在代码里却完全不同。这不是 bug，正是公司之所以独特的地方。我的意思是：如果每家公司的名词集合完全一样，你其实只需要一家公司。
动词是名词怎么移动：一笔交易如何入账，关账前必须为真的条件是什么，夜里十一点谁签例外，那个人休假时又怎样。
这些几乎都没写下来——它是活出来的。它是组织赖以生存的操作系统，是文化。它住在待得够久、已经不再察觉它的六个人脑子里，也住在四年前某人建的、整队人如今默默依赖的一张电子表里。这就是它为什么值钱，也是为什么你问不出来。
通常，持有这些知识的人并不知道自己有。在我上一家创业公司，我们花了将近一年想把客户从 CSV 迁到 Parquet，一位数据质量工程师每一次都挡下来。我们永远搞不懂为什么，理由每次都变，但总是「parquet 更差」「不行」「对我没意义」这类变体。我们用过存储降本、计算最小化、管线优化……全没打动她，因为全都不关真正的问题。
然后我们派一名 FDE 进去看这位数据质量工程师怎么干活。她把 CSV 从 S3 拉到 Windows 笔记本上，双击打开，肉眼扫行。那就是数据质量检查。当时 Parquet 没有原生查看器，于是我们提议的东西会拿走她唯一的质检工具，却什么也不还回去。她不是难搞，她只是在保护让她能干活的那一件东西。
我们当晚做了 Parquet 查看器，两天后她批准了迁移，管线执行从大约十七小时降到两小时。这些她永远不会在访谈里说出来。从她的位置看，原因显而易见、不值一提。
理解并定义这位分析师的操作系统——名词与动词——让我们不仅理解问题，还能做出可交付给有同类问题的整批客户的方案。
## 产出必须是产品
理解名词和动词能把问题情境化，但产出必须是产品，而不是只让一个客户开心。
名词和动词告诉你问题到底是什么。它们不告诉你该怎么做；多数 FDE 职能悄悄走偏的地方就在这里——因为解决眼前问题很满足、很可感知，同一周就会有人谢你。
让客户开心是真工作、好工作。它属于解决方案架构师，他们正该按这个被衡量。前线部署工程师在场，是为了把现场教给你的东西，变成每一个未来客户都能拿到的东西。一场以一个开心账户收场、上游却毫无改变的 FDE 对接，在这个角色存在的唯一目的上失败了。你拿到了上下文，却把它花在了本地。
这堂课我付过贵学费。有一次客户需要数据保留任务，我下午拼了个叫「vinoo.groovy」的 groovy 脚本顶一阵——从没打算活过那一周。一年后，它在一家近十万人的客户那儿跑着，我的名字焊在上面。故事荒谬到团队开始叫我 vinoo.groovy。我们修了问题，却从未把修复做成产品——于是花了几年维护本该立刻死掉的 hack。你交出去的每个捷径，都会变成你要拥有的东西。纪律在于：知道哪些修复该进平台，哪些在完成任务的那一刻就该故意扔掉。
## 分叉
整件事在这里分叉。底下什么都没有地做这活，你会学到一家公司的模型，交一个完全贴着它长出来的东西，对接一结束全部丢掉。下一个客户从零开始，再下一个也是。那是咨询。钱好赚，人优秀，但不复利。
在同样的工作底下放一个平台，你映射过的每一家公司都会让下一次部署更快、产品更锋利，因为工程师带回家的东西有地方住。这就是卖小时和建资产的差别；我对这场淘金热的诚实判断是：多数公司在建前者，却对董事会描述后者。
那就是你的工作：建平台。
## 我们在 Kepler 怎么做，以及你可以带走什么
在 Kepler，我们从第一天就这样搭职能，那时还没有足够客户来「证明」它。替代方案是在第十四个月才发现工程师一直在为错误的东西优化。从一开始，我们的 FDE 就是产品团队的延伸；其余一切都跟着这个结构性决定走。
我们卖给对冲基金、投行、私募和其他金融机构。它们机构不同、使命不同，但共享一个不可妥协点：数字必须对，而且得有人能说明为什么对。我们对着这个约束设计；它很有用，因为它把运营模型逼到明处。我们参与的任何一家公司，都没法交出一份没有清晰来源轨迹支撑每个数字的工作产物。这个不变量定义了我们的平台，也给了我们执行的基岩。
这些问题是普遍的。词汇表不是。
这些公司底下跑的是某种同一本体的不同版本，描述却各不相同。仓位在同一家银行的信贷台和股票台含义相邻却不同。两家基金会用完全相同的话描述收益计算，却对分母放什么意见不合。多数差异是因为某人在（比方说）2011 年做了一个合理决定，决定比人活得久；而且哪儿也找不到写下来的版本。
识别并填上那道缝，就是 FDE 的工作。Schema 告诉你存了什么，不告诉你意指什么；两者之间的距离，正是「听起来对、产出的数字却错」的系统所在。
来源（provenance）对我们的客户是正确性要求；对我们还有另一层作用：让现场工作复利。一个能围绕坏编码即兴绕过去的系统，永远不会告诉你编码是坏的。我们的系统不即兴。当我们误解一家公司如何定义某物时，误解会以失败浮现，而不是以「看起来合理」的答案浮现。搞错的工程师从系统得知，而不是六周后在会议上从客户得知。
部署随后告诉我们平台该往哪儿扩展——问题比听起来更窄。我们不是想知道某只基金想要哪个功能。我们是想找到平台太窄、装不下我们一再撞上之物的地方。三家公司要同一个功能很容易注意到、却相对不值钱。三家公司需要来源层表达不了的东西，才是我们真正在意的信号；它通常悄无声息到来，形态是一名工程师第三次绕开同一个限制。
如果你在别处搭建，我会从这一切里带走这一段：
产品杠杆买下你实验的权利。每一个落到平台的能力，都让下一次部署更便宜去尝试；便宜的尝试，是小公司高速学习的方式。没有那杠杆，你每个客户只有一次昂贵猜测。你仔细定范围、建几个月，猜错就烧掉一个账户和一个季度才知道。我们宁可一个月错四次，因为每一次尝试都比上一次便宜。
所以汇报线不是行政细节。把职能对准销售，激励就变成关眼前这笔单——那是真工作，公司里该有人做，但不是这份。把职能对准产品，每一次部署都被要求产出下一次部署能接着用的东西。
## 护城河在哪儿
所以我会把这个时代的护城河放在这里。不是模型——它按月贬值，而且你反正是从别人那儿租。也不是人才——每家实验室都在竞价同一批几百人，价格已经被发现了。
也不是任何一家客户的「地图」。几年前如此，现在也一样：抽取几乎免费，任何人都能在一个下午起草一家公司如何运转。
草稿不是资产。知道草稿哪部分是错的才是资产，而这只来自被纠正过。
所以对我们来说，护城河是：对某个垂直里公司实际如何运转的、累积的、当前的、经过验证的理解，保存在一个能保持它当前、并能证明它的平台里。每个词都承重。累积，因为一次部署是轶事，第十次是模式。当前，因为运营会漂移，过时模型会在 AI 系统底下静默失败，方式是它从前对着分析师时从未有过的。验证，因为说得通的编码和正确的编码在出事之前看起来一模一样；坚持来源的全部意义，就是让你发现自己拿的是哪一种。
那买不到。竞争对手可以挖你的工程师、抄你的界面、读这篇文章（他们三个都试过）。他们没法抄近路的，是在客户里面做错、被纠正、把纠正折进平台、再到下一家公司时已经知道哪些问题承重的那串序列。每个周期都让下一个更便宜，那种复利才是你拥有的东西。
我看着这个职能被建过三次，模式每次都成立。真正重要的工程师，不是给客户交得最多的那些，而是回来改变我们建什么的那些。
招前线部署工程师只买你一件事：识别哪些问题值得解决的权利。多数公司从未走到那一步。但那是入场费，不是奖品。
我是 Vinoo Ganesh，Kepler CEO。我们在建这篇文字所谈的那一层：让 AI 产品能把每个数字追回源头的事实地基。Kepler 之前我在 Palantir 领导 Spark、打造 Project Frontline，后来在 Citadel 负责业务工程。如果你也在这儿建，或者觉得我哪里说错了，可以在 LinkedIn 上跟我辩。