源自Palantir的FDE（前线部署工程师），AI to B的银弹？

"前线部署工程师"（Forward Deployed Engineer）这个概念最近在硅谷AI创业圈高频出现。最早玩转这套模式的Palantir和OpenAI，随着AI概念不断发酵，现在估值加起来大几千亿美金。

Palantir是当前ToB AI的明星公司，由硅谷教父彼得·蒂尔、内森·盖特林等人共同创办，最初的目标是帮助政府机构处理复杂的数据分析任务，特别是在反恐和国家安全方面。随着时间的推移，Palantir 逐渐扩展其服务，向商业客户提供解决方案，尤其是在金融、医疗、制造等领域。最大特点就是基于自研的平台给客户交付定制化的解决方案，这一点与追求标准产品或是追逐基座模型热点的公司来讲是个异类。

很多人对此进行研究，希望能够学到一二，但多数人理解错了。近日，YC邀请了这一模式的发明者，PayPal、Palantir 核心员工，OpenAI 原首席研究官 Bob McGrew来解密什么是FDE。

不是工程师驻场开发就叫FDE，真正的精髓在于"产品化咨询"。他在最新访谈里拆解了关键三点：

1. 工程师要同时懂技术栈和客户业务逻辑，能当场把需求翻译成代码
2. 解决方案必须能快速抽象成产品功能，否则就是定制化外包
3. 团队要配置"三栖人才"：20%销售+30%产品+50%工程

最反直觉的发现？采用FDE模式的AI公司，前18个月ARR增速平均比同行快3倍，但客户成功团队规模只有1/3。

相对于传统ToB的解决方案架构师，交付的是PPT，而FDE交付的是可迭代的产品模块。 但这个事情落到国内，不是大家不想，实际情况就是项目的不稳定，提前投入耗不起，另外，一个更本质问题就是人才质量和人力成本的不可调和矛盾，但凡处理不好，最终都将会变成一场难以自拔的“焦油坑”。

机缘巧合，笔者自我感觉不论过去还是现在都在朝这样的方向探索，做过平台开发，做过销售及方案，也在做交付实施，如何将它们融合在一起变成一个适应新趋势的角色，感兴趣的朋友可以一起讨论学习。

附访谈要点摘录：

1. FDE = “规模化地做那些不能规模化的事情 (do things that don’t scale—at scale)”。 目标不是减少每个客户的定制化；而是在增加成果价值 (outcome value) 和合同规模的同时，保持定制化的稳定。
2. 你的第二用户是 FDE。 构建产品原型 (product primitives) 和工具，每个季度都要能增加 FDE 的影响力；如果现场团队不喜欢你的抽象概念，那你就做错了。
3. 在需求之上进行更高层次的提炼。 永远不要将特定场景的工作流 (workflow) 产品化；应该提取可复用的概念（本体/原型 ontology/primitives），并在交付前经过多个线上客户的验证。
4. 卖结果 (outcomes)，而不是卖安装 (installs)。 早期的交易可以进行风险加权（例如“有效再付款”）；随着成果的扩大，合同必须阶梯式上升——做到复杂、灵活，但要与价值对齐。
5. 要么进入高管层 (Executive) 的前五大优先事项，要么就失败。 如果你的切入点 (wedge) 不在 CEO 的优先列表上，那么 IT 或流程的惯性就会占上风。来自高管层的支持是一项技术依赖 (technical dependency)，而不仅仅是销售上的客套。
6. 以演示驱动 (Demo-driven) ≠ 廉价的戏剧表演。 一个好的演示 (demo) 是一种驱动力：每一个新功能都必须在一个可信的、能创造客户渴望而不仅仅是同意的端到端工作流 (workflow) 中赢得一席之地。
7. 痛苦就是信号。 重写、粗糙的原型 (prototypes) 以及现场和产品之间的摩擦是学习的特征，而不是需要被“流程化”解决的错误 (bugs)。如果过程毫无痛苦，你可能并没有在探索新事物。
8. 衡量两件正确的事情： (a) 交付的成果价值 (Outcome value)（即使你还无法完全捕捉到它），以及 (b) 产品杠杆 (Product leverage)（在所有客户中，单位价值对应的现场投入应该下降）。
9. 小心“赞助商的局部最优解 (sponsor local maxima)”。 中层领导的要求往往是为了优化便利性，而不是影响力。要重新锚定于企业层面的成果 (outcomes)；否则你就会偏离到做服务上去了。
10. 为什么这套方法现在对 AI 适用： 对于 agents 来说，没有现成的产品 (no incumbent product)，且产品的采用速度落后于技术能力——因此，探索发现必须在客户内部反复进行，而平台化则紧随其后。
11. 雇佣叛逆者，而不是“原住民”。 “回声”角色需要那些认为现有方式不足的领域内部人士；而“变革”角色则是能够“吃苦”的快速原型开发者 (rapid prototypers)，而不是着眼长远的工匠。
12. 登陆 (Land) → 扩张 (expand) → 抽象 (abstract)。 用一个有说服力的成果赢得胜利，利用邻近优势发现更大的相关问题，然后将这种模式整合回平台。重复此过程。