究竟是FDE还是技术外包？

💡 FDE 这个词现在指着三种完全不一样的工作。分岔口只有一条，你在客户那儿修的东西，有没有沉淀成为可复用的产品。没有，你就是个头衔好听的顾问。​ 最近 FDE 这个词热起来了。 OpenAI、Anthropic、Databricks、Mistral 都在招 Forward Deployed Engineer。Salesforce 去年就把它叫「最热门的岗位」。今年更夸张，Atlassian 挂了个 Principal Forward Deployed Architect，OpenAI 还有 Forward Deployed Security Engineer。 我身边不少工程师在琢磨要不要转。 然后我读到 Vinoo Ganesh 写的一篇文，读完的感受是，这帮人里大多数，想转的其实是咨询，只是他们自己不知道而已。 先说 Vinoo 是谁，他在 Palantir 搞过一个叫 Project Frontline 的轮岗项目，把软件工程师轮岗成 FDE，前后大概 250 人过了这个项目，这批人现在在 OpenAI、Anthropic、xAI、Anduril 带 FDE 团队。之后他去 Citadel 管 business engineering，客户是基金经理，考核只有一条，帮他们赚没赚到 alpha。现在他是 Kepler 的 CEO，卖给对冲基金和投行。 说白了，这个岗位的培训考核上岗，他搭过三遍。 一个词，三种工作 今年 5 月 a16z 搞了个 FDE Fellowship，8 周的 cohort，Vinoo 被提名进去了。前几天他去旧金山参与晚宴，同桌坐着 Snowflake、Anthropic 和几家创业公司的 FDE。 一晚上聊下来他发现一件事儿。 所有人都在说「forward deployed」这两个词，说的却是三份几乎没有交集的工作。 这一头，FDE 是个销售工程师，客户第二次通话的时候被拉进来。 那一头，FDE 是个背着 quota 的销售，区别是会写 Python。 再往下几个座位，FDE 就是个带着笔记本电脑和按合同工作范围计费的技术顾问，被请来做产品做不到的东西。 几天之后，他们的 WhatsApp 群里有人很认真地问：我们的 FDE 团队，应该怎么跟已经驻场的咨询公司划分工作范围？ Vinoo 说这问题问得合理，但按他对 FDE 的理解，这个问题压根就不该存在。 他还补了一句，任何一个讲 FDE 的 YouTube 视频下面，一半评论都是「这不就是重新做了一遍咨询吗？」。 大家以为的 FDE，缺了一个条件 大家现在对 FDE 的理解无非就是一句话：派一个工程师坐进客户那儿，把 AI 落地。 这句话没错。但它缺了一个条件。 缺的条件是，你把客户的问题解决完之后，这些问题信号有没有真正沉淀成可被复用的产品。 沉淀了，你是 FDE。 没沉淀，你是技术顾问+落地外包。 头衔一模一样，工资单可能都一样，干的是两份工作。 Vinoo 那篇文章里我印象最深刻的一句话是：一个 FDE 团队如果只管解决客户的最后一公里，从不把信号带回家，那它就是个头衔更好听的咨询团队。 为什么现在人人都 forward deployed 了？他给的解释挺合理的。 因为低垂的果实摘完了。能靠一款产品、同一套卖法卖给一千家公司的问题，早就被SaaS解决了。剩下的问题全在客户的私有流程里面，藏在那些混乱、没文档、从外面根本推不出来的工作流里。你打十个 discovery call 也猜不出一家公司到底怎么关单。 价值挪到了最后一公里。工作流里那 20% 没有任何产品能预见的部分，决定了另外 80% 到底用不用得起来。 所以人人都得走进企业。 但进去只是一半。进去之后带什么回来，才分出咨询和 FDE。 他自己是如何成为 FDE 的 Vinoo 自己成为 FDE 的过程，说好听点叫成长，说难听点就是被自己需要交付的东西催生出来的。 2013 年他在 Palantir 做一个叫 Phoenix 的事务存储。他说那是他共事过最强的一批工程师设计的，设计极其干净，针对一组明确的客户用例。spec 有，用例有，关于金融机构怎么存数据的资料读了一堆。在他们能控制的每一个环境里，系统的行为都跟规格书一模一样。 然后部署到一家银行。 真实的金融数据里有各种各样的问题，测试数据从来没有遇到过这些问题。有一条记录的时间字段是空的，系统把空值当成了 1970 年 1 月 1 日。保留逻辑于是很尽职地从 1970 年一路算到当天，每十分钟开一个存储桶，算下来大概 230 万个。每个桶都要占一点内存，230 万个加起来，服务器内存直接爆了。想重启？得先找一个 14TB 的内存。 系统从设计好的那一刻，就注定了无法投产使用。 他的归因很有意思。问题出在哪儿？他说，你可能会猜是用户研究没做够。其实并没有。他们有 spec，懂用例，读过资料。他们从来没干过的一件事儿，是站在那家银行的楼里，看着系统跑他们的生产数据。 所以在他们这边，没有任何一个人「理解」设计和日常现实之间的Gap。 关于那家银行的所有认知，全是二手转述的。而在那些人眼里，脏数据太正常了，正常到不值一提。 于是他开始飞来飞去修自己交付的东西。这就是他成为 FDE 的全过程，他说这已经是很慷慨的描述了。 故事到这儿，正常版本应该结束了，教训是「要关注用户」。 但 Phoenix 后来变成了一个平台。Palantir 的 FDE 在上面搭了网络安全、KYC、AML，还有一长串没人事先规划过的用例。产品团队被迫回过头去想，平台该怎么扩才装得下这些东西。 Vinoo 说他当时没看出来，但那个循环就是全部。 FDE 解决客户的问题，为的是换回一样东西，让你看明白下一步该做什么。这个角色的本质是产品团队派出去的信息捕手，用来收集增强系统的信号。 FDE 到底在收什么 Vinoo 给 FDE 的工作下了一个定义，我觉得比市面上所有招聘 JD 都准。 收「名词」和「动词」。 你在一家公司待一周就会发现，同一个概念至少有四个名字。销售说 customer，运营说 client，财务记的是 billing entity，工程写的是 org_id。每两个团队之间都藏着一层翻译，谁改了定义，立马就不知道是什么意思了。 名词，就是这家公司里的人当真的东西。一个头寸，一笔交易，一个交易对手。每个团队手里就那么几个对象，整个运营围着它们转，而且没有一个是按教科书定义的。两家公司在 PPT 上对「头寸」的描述一模一样，代码里完全两码事。 动词，是名词怎么动。一笔交易怎么入账，关账之前什么条件必须成立，晚上十一点谁签例外，那个人休假了又怎么办。 这些东西几乎没有一条写在文档里。它活在六个待得够久、久到自己都注意不到的老员工脑子里，活在某人四年前糊的一张 Excel 里，整个团队现在都默默靠它活着。 这就是它值钱的原因，也是你要不到它的原因。 他讲了一个案例，我觉得是全文最有画面感的。 他之前一家创业公司花了将近一年，想把一个客户从 CSV 迁到 Parquet。客户那边一个数据质量工程师每次都把它拒绝回去。理由每次都在变，「parquet 更差」「不好用」「我觉得没道理」……他们讲省存储，讲省算力，讲管道优化，一条都没打动她。 后来他们派了个 FDE 进去，就干一件事儿，看她怎么干活。 她的流程是这样的。从 S3 把 CSV 拉到一台 Windows 笔记本上，双击打开，肉眼扫一遍行。 这就是数据质量检查。 Parquet 当时没有原生查看器。所以他们提的方案，等于把她手里唯一的质检工具抢走，什么都不还给她。她根本没在刁难人，她在保护那个让她能干活的东西。 他们当晚糊了一个 Parquet viewer。两天后她批了迁移。管道跑一遍的时间从大概 17 小时降到 2 小时。 Vinoo 说，这些话她在任何一场访谈里都不会讲。在她的位置上，理由太显然了，不值一提。 你会发现，那一年的所有论证，全都没有碰到真正的问题。碰到问题只用了一个下午，而且只需要有人去看。 第一层，修完的东西必须变成产品 收到名词动词，只是知道了问题到底是什么。 接下来才是大多数 FDE 团队悄悄跑偏的地方。因为解决眼前的问题有正反馈，看得见摸得着，当周就有人谢你。但真正难的是，分清你在hack还是在沉淀资产。 Vinoo 讲了一个他自己的糗事儿。 有个客户需要一个数据保留任务。他花一个下午拼了一个 groovy 脚本先顶一下，文件名叫 vinoo.groovy。本来的打算是撑不过一周。 一年之后，这个脚本跑在一个近 10 万人的客户那里，他的名字焊在上面。这事儿荒唐到团队开始直接管他叫 vinoo.groovy。 问题是修好了。可是修复从来没变成产品。于是他们花了好几年，维护一个本该立刻死掉的 hack。 他的结论是，你交付的每一条捷径，最后都会变成你的东西。真正的纪律在于分得清，哪些修复该进平台，哪些应该在干完活的那一刻，主动扔掉。 这里他划了一条线，我觉得对想转 FDE 的人特别重要。 让客户满意，是一份真实的、不错的工作。但那是 Solutions Architect 的活，考核他们的也应该是这个。 FDE 在那儿，是为了把一线教会你的东西，变成每一个未来客户默认就能拿到的东西。一次 engagement 做完，客户很爽，可是除了解决问题的临时脚本外，却没沉淀下什么，这就是失败的。 用他的话说：你拿到了宝贵的上下文，却用一种最简陋的方式浪费掉了。 第二层，汇报线定生死 整件事在这儿分岔。 底下没有平台，你就学到一家公司的模型，交付一个完全贴着它长的东西，项目一结束全丢。下一个客户从零开始，再下一个也是。 Vinoo 说，这就是咨询。钱多，人也能干，但它无法形成复利效应。 底下垫一个平台，你梳理过的每一家公司都让下一次部署更快、产品更方便，因为工程师带回来的东西有地方沉淀。 一边在卖工时，一边在攒资产。 他对这场淘金热的判断很直接。里面大多数公司在建前者，然后跟董事会描述后者。 那怎么保证你建的是后者？他给的答案是汇报线。 这个职能挂在销售下面，激励立刻变成关掉眼前这一单。这是份真实的工作，公司里也得有人干，但它跟 FDE 无关。 挂在产品下面，每一次部署都会被要求留下一个东西，让下一次部署能从它开始。 Kepler 从第一天就把 FDE 放在产品下面，那时候他们连能证明这个决定有必要的客户都还没有。他说另一条路是在第十四个月才发现，工程师一直在往错的方向优化。 顺便说一句，他们看信号的方式也挺反直觉。 三家公司要同一个功能，很容易看见，但不值什么钱。三家公司需要一个平台表达不了的东西，才是真正的信号。而这种信号来的时候往往没声音，但一个工程师三次绕开同一个限制的时候，你就会意识到这个问题亟待解决，这就是信号。 第三层，护城河是被纠正的次数 那这个时代的护城河在哪儿？Vinoo 先排除了三样东西。 模型。月月贬值，反正也是从别人那儿租的。 人才。每家 lab 都在抢同一批几百号人，价格早就被发现了。 某一个客户的地图。提取现在几乎免费，谁都能用一个下午草拟一家公司怎么运作。 他说，草稿不是资产。知道草稿哪里错了，才是资产。而这只能来自被纠正过。 所以对他们来说，护城河是对一个垂直领域里的公司到底怎么运作的理解，而且这理解必须是累积的、当下的、经过验证的，装在一个能保持新鲜、能证明它对的平台里。 累积，因为一次部署是试验，第十次才是模式。 这东西买不来。他说竞争对手可以挖你的工程师，抄你的界面，读他这篇文章。他们抄不了的是这个反馈循环。在客户内部犯错，被纠正，把纠正沉淀进平台，然后到下一家的时候已经知道哪几个问题是核心问题。 每转一圈反馈循环，就会收获更多信号，加以沉淀，下一次就会循环更快。这个复利才是你真正拥有的东西。 入场费，不是奖品 Vinoo 看着这个职能被搭起来三次，规律每次都一样。 真正重要的工程师，从来都是回来之后改了产品的那批人。给客户交付最多的那批，反而没那么重要。 招 FDE 只能买到一样东西：识别哪些问题值得解决的权利。 大多数公司连这一步都走不到。而且就算走到了，那也只是入场费，不是奖品。 你要转 FDE，先问自己三个问题 好了，回到我身边那些想转的工程师。 Vinoo 那篇文没直接给求职建议，但顺着他的逻辑，你在接 offer 之前其实只需要问三个问题。 第一，你汇报给谁？销售还是产品。这一条绝对决定了后面所有事儿。 第二，你在客户那儿修的东西，有没有一条路回到主干？谁负责收？收回来之后谁决定进不进平台？如果答案是「看情况」「看谁认识谁」，那就是 Vinoo 讲的 Palantir 早期，全靠关系，没有流程。 第三，公司怎么算你的 KPI？是「客户满意度」，还是「平台因为你改了什么」？ 三个问题答不上来，那就是个顾问岗。 不丢人，钱可能还更多。但你得知道自己在卖工时，别以为自己在攒资产。 注：Project Frontline 校友去向，Vinoo 原文写的是 OpenAI、Anthropic、xAI、Anduril，他的 Maven 课程页没列 Anthropic，另有信源列了 Hex。本文按他原文的版本。文中 Phoenix 事故数字、Parquet 迁移时长、vinoo.groovy 的客户规模都出自他本人自述，没有第二个信源。