技巧精选78°

AI 圈最火的职位 FDE,本质是把客户问题变成平台资产

Forward Deployed Engineer (FDE):AI 圈最火的职位,九成做成了咨询,还有人做成了外包? FDE 的真正价值不只在于替客户解决最后一公里的问题,更重要的是把前线获得的认...

精选理由

VinooGanesh(Kepler CEO)分享的FDE最佳实践,讲的是怎么把客户问题变成平台资产,不是卖小时费,而是建可复用的东西,对做AI产品的很有参考价值。

Forward Deployed Engineer(FDE)是产品团队的延伸,去客户现场解决最后一公里问题的同时,收集企业真实运作的“名词”(核心对象)和“动词”(流程规则)等“活知识”。2013年Palantir Phoenix项目因无人现场验证导致系统崩溃,暴露了这类知识的重要性。FDE的产出必须是能让平台复利的产品,而非仅让客户满意的方案。VinooGanesh给出的最佳实践包括让FDE汇报给产品线而非销售线,用不变量定义平台,以及通过产品杠杆获得试错权。

原文 · shao__meng

Forward Deployed Engineer (FDE):AI 圈最火的职位,九成做成了咨询,还有人做成了外包? FDE 的真正价值不只在于替客户解决最后一公里的问题,更重要的是把前线获得的认...

Forward Deployed Engineer (FDE):AI 圈最火的职位,九成做成了咨询,还有人做成了外包? FDE 的真正价值不只在于替客户解决最后一公里的问题,更重要的是把前线获得的认知回流到平台,让下一次部署更快。 只做前半件事的团队,本质上是“换了个更好听头衔的咨询公司”,甚至是“外包公司”。 @VinooGanesh (Kepler CEO,曾在 Palantir、Citadel 三次从零建立 FDE 团队)通过 @latentspacepod 分享了他的 FDE 最佳实践,一起看看。 latent.space/p/forward-depl… 问题的起源:FDE 一词已被严重污染! Vinoo 在 a16z 的 FDE Fellowship 晚宴上发现,来自 Snowflake、Anthropic 和各类创业公司的 FDE,描述的完全是三份不同的工作:有人是跟第二次销售电话的售前工程师,有人是会写 Python 的带指标销售,有人是补齐产品缺口的驻场顾问——连“专家们”对汇报线和激励方式的认知都不一致。 Vinoo 给出的严格定义:FDE 是产品团队的延伸。去客户现场解决问题是手段,赚回“该往平台里建什么”的洞察才是目的。 一个价值 14TB 内存的事故 2013 年 Palantir 的 Phoenix 项目:一个完全基于二手需求、设计干净的交易存储系统,在银行真实数据面前崩溃——一个空时间戳掉落到 epoch(1970 年 1 月 1 日),导致留存逻辑请求了约 230 万个 keyspace,服务器 OOM,重启需要 14TB 内存。 根因不是代码 bug,是没有人站在客户的楼里,让系统跑过真实生产数据。这次事故让 Vinoo “用内脏而非理智”理解了 FDE 思维——这类知识和流程图上写的是两回事。 工作方法论:收集“名词”和“动词” · 名词:企业视为真实存在的核心对象(一笔持仓、一笔交易、一个交易对手方)。两家公司在 PPT 上对名词的描述可以一模一样,在代码里却完全不同——这正是每家公司独特的本质。 · 动词:名词如何流动——交易怎么入账、关账前必须满足什么条件、深夜 11 点的例外谁签字。 关键在于:这类知识是“活出来的”而非写下来的,存在于六个老员工的脑子里和一张四年历史的表格里。它之所以值钱,恰恰因为“你问不出来”。 Parquet 案例最能说明问题:一家创业公司花近一年无法把客户从 CSV 迁到 Parquet,被一位数据质量工程师反复阻挠,理由不断变化。FDE 蹲在现场观察她工作才发现真相:她在 Windows 笔记本上靠肉眼检查 CSV,而 Parquet 没有查看器——迁移等于没收她唯一的质检工具。团队一夜之间写了个 Parquet 查看器,两天后她批准迁移,流水线运行时间从 17 小时降到 2 小时。这个真实动机在任何访谈中都问不出来。 产出必须是产品,而非客户满意 解决方案架构师让客户满意就算成功;FDE 的标准更高——一个项目结束时,如果只有一个满意的客户、平台没有任何上游改变,这个 FDE 就在他存在的唯一意义上失败了。 反面教材是 Vinoo 自己的 vinoo.groovy:一个下午写的数据留存临时脚本,一年后跑在一个十万人的客户身上。教训被提炼成一句话:“你交付的每一个捷径,都会变成你拥有的东西”——纪律在于刻意判断哪些修复该进平台、哪些该主动废弃。 分叉点:卖小时 vs 建资产 没有平台支撑时,每个项目从零开始——这就是咨询,赚钱但不复利。有平台时,每摸清一家公司,下一次部署就更快。Vinoo 对当前 AI 创业潮的诚实判断很扎心:大多数公司做的是前者,向董事会描述的却是后者。 Kepler 的四条实践 1. FDE 汇报给产品线,不是销售线:这是决定其他一切的结构性选择。汇报销售的 FDE 优化的是“关掉当前这个单”,汇报产品的 FDE 产出的是“下一次部署的起点”。 2. 让不变量定义平台:Kepler 卖给金融机构,数字必须可证明正确,所以 provenance(数据溯源)是平台骨架。它让前线工作可以复利:系统不即兴发挥,误解会以失败而非“看起来合理的错误答案”的形式暴露。 3. 部署揭示的是平台哪里“太窄”,而非客户想要什么功能:三家公司在同一个限制上各自绕路,这才是真信号。 4. 产品杠杆买来试错权:平台能力让部署变便宜,于是可以“一个月错四次”,而不是每个客户每季度押一次昂贵的猜。 护城河在哪(以及不在哪) 不在模型(租来的、在变便宜)、不在人才(价格已被市场发现)、不在对某家客户的了解(“提取几乎免费”)。 护城河是:对某一垂直行业内企业真实运作方式的“积累的、当下的、经过验证的理解”,且装在一个能保持其最新并能证明它的平台里。 Vinoo 对三个定语逐一加压: · Accumulated(积累的):第一次部署是轶事,第十次是模式。 · Current(当下的):业务在漂移,过时的模型在 AI 时代会静默失效。 · Verified(验证过的):貌似合理和真正正确的编码,在出事之前看起来一模一样。 Latent.Space @latentspacepod Before co-founding @kepler_ai_hq , @VinooGanesh led Spark at Palantir and built Project Frontline — a pioneering program for Forward Deployed Engineers. He takes us through the best practices of FDEs. latent.space/p/forward-depl… 🔗 View Quoted Tweet 💬 0 🔄 1 ❤️ 4 👀 544 📊 1 ⚡