FDE 在客户楼里做的事：
收集名词和动词，再把解法带回家

FDE，全称 Forward Deployed Engineer，即前沿部署工程师，是厂商派到客户现场、坐进客户业务里解决问题的工程师。Vinoo Ganesh 曾在 Palantir 负责计算平台方向，并创建了把软件工程师训练成 FDE 的轮岗项目 Project Frontline，后来在对冲基金 Citadel 负责业务工程，现在是 Kepler 的 CEO 兼联合创始人。十余年里，他在三家机构三次参与搭建 FDE 职能，每次搭的都只是其中一部分。这篇文章讲的是他在这个过程中看到的成与败。

在风投 a16z 办的 FDE 奖学金项目（Forward Deployed Engineer Fellowship）的一次晚餐上，来自 Snowflake、Anthropic 和一批创业公司的 FDE 坐在同一桌，却发现大家用同一个词描述的工作几乎没有共同点。有人说，FDE 是加入“第二通电话”的售前工程师；有人说，是能写 Python、背销售配额的销售；还有人说，是带着笔记本和工作说明书进场，替客户做产品本身做不到的事的顾问。几天后，群里又有人问：FDE 团队该怎样跟已经驻在客户现场的咨询公司分工？

Ganesh 不想垄断这个词的定义，词义本来就在变化。但在他看来，这些工作不仅内容不同，汇报线和激励也完全不同。相关 YouTube 视频下，一半评论都在问：“这不就是重新发明咨询吗？”

他在数据平台公司 Palantir 从产品开发转成 FDE，后来带领 Project Frontline，约 250 人经过这个项目，其中不少人现在在 OpenAI、Anthropic、xAI 和 Anduril 带 FDE 团队。之后他去了 Citadel，再创办 Kepler。要解释他心中的 FDE，故事得从 Project Frontline 之前的一次错误讲起。

但在他看来，词语被挪用，背后的直觉并没有错。好做的事已经做完。那些可以做成一个精心设计的产品、原样卖给一千家公司的问题，大体已经解决。剩下的工作藏在机构内部，是混乱、没有文档、从外面几乎无法推断的流程。一通需求调研电话，问不出一家公司究竟怎样关账。可复制的销售动作，对卖 token、字节或实物的公司来说仍然是对的。对其他所有人，价值已经转移到定制工作、最后一公里，以及没有任何产品能预料到的那 20% 的工作流。这 20% 的工作流决定另 80% 用不用得上。

在 Ganesh 看来，解决最后一公里只是 FDE 的一半工作。在一家客户那里解决掉的问题，同时也是一个信号，告诉你平台哪一部分应该变得通用。只解决最后一公里、从不把这个信号带回产品团队的 FDE 团队，是换了个更好头衔的咨询团队。

后来，一名 FDE 被派去观察这位数据质量工程师怎样工作。这名 FDE 看到，她从云对象存储 S3 下载 CSV 文件，放到 Windows 笔记本上，双击打开，再用眼睛逐行扫过去。这就是她的数据质量检查。Parquet 当时没有原生的查看器。迁移到 Parquet，等于拿走她唯一的质检工具，却没有提供替代品。在 Ganesh 看来，她只是在保护唯一一件让自己能完成工作的工具，谈不上难缠。

团队当晚做出一个 Parquet 查看器，两天后她批准迁移。管道执行时间从约 17 小时降到 2 小时。Ganesh 说，这些话她在访谈里永远不会说，因为在她看来，自己的工作方式显而易见，根本不值得特别说明。FDE 通过观察，摸清了她实际怎样工作，以及其中的名词和动词。最终形成的方案不只解决了一个人的问题，还能交付给一批面对相同障碍的客户。

在 Ganesh 看来，各家金融机构底层跑的都是同一套对象和关系模型的某个版本，他称之为 ontology（本体），只是各家描述它的方式不同。同一家银行里，信用交易台和股票交易台对 position 的理解可能不同；两家基金算收益时用的是同一个词，分母却可能不一样。许多差异来自某个人多年前（他举的例子是 2011 年）做出的合理决定。当年的决定一直沿用下来，却没有留下可查的记录。schema 只能说明存了什么，不能说明它意味着什么。一个听起来没问题的系统算出错误数字，错就出在这两者之间的距离里。三家客户要求同一个功能，很容易发现，价值却相对不大。Kepler 在意的信号，是三家客户都需要平台无法表达的东西。这种信号通常来得很不起眼：某个工程师第三次绕过同一个限制。

平台里每多一项能力，下一次部署的成本就更低，尝试的成本低，小公司才学得快。没有这层积累，每个客户都是一次昂贵的赌注，赌错了要搭上一个客户和一个季度才知道。Ganesh 的选择是“一个月错四次”，而且每次都比上一次便宜。

所以，汇报线不是行政细节。指向销售，激励就是拿下眼前这单。这是真工作，却不是 Ganesh 所说的 FDE 工作。指向产品，每次部署都必须留下下一次部署还能继续使用的东西。

护城河在哪里，他先排除了三个候选。模型按月贬值，而且是租来的。人才被每家 AI 实验室争抢，抢的始终是那几百个人，价钱大家都已经知道了。任何一家客户的组织地图也不是，摸一遍几乎不花钱，一下午就能画出一家公司怎样运转的草稿。资产是知道这份草稿哪里错了，而这份认知只能靠一次次被纠正得来。

在 Ganesh 看来，Kepler 的护城河是这样一份认知：某个垂直行业里各家机构实际怎样运作，这份认知是积累起来的、跟得上现状的、经过验证的，并且装在一个能让它保持更新、能证明它正确的平台里。

积累、更新、验证这三个词，在他的解释里各有分量。一次部署只是轶事，“第十次是模式”。机构的运营方式不断漂移，过期的模型垫在 AI 系统底下会悄无声息地出错，摆在分析师面前时从来不会这样。合理的编码与正确的编码，在出事之前看起来一模一样。

Ganesh 认为，竞争者可以雇走工程师、照搬界面、读完这篇文章，却无法跳过那个序列：在客户内部犯错，被纠正，把纠正过的认识写回平台，到下一家时已经知道哪些问题是要害。

三次参与搭建这个职能之后，Ganesh 记住的是那些回来改变了产品的人，而不是给客户交付最多的工程师。雇用 FDE，买到的只有一样东西：判断哪些问题值得解决的权利。那是入场费，不是奖品。