关于一些毫不 fancy 的 FDE

Forward Deployed Engineer，剥掉英文缩写的光环之后，是一个所有咨询公司最熟悉的古老角色的叙事变体：被派往现场的技术劳工。咨询公司称之为「交付」，软件公司称之为「部署」，本质是同一件事：携带技术，前往他人的领地，按照他人的需求，改造他人的系统。所处的位置是工具的工具。

从至今为止的 AI 发展路线看，AI 和其他技术的应用与商业化路径没有太大不同；同理的，FDE 这个角色在公司里的位置，跟 1970 年代 IBM 工程师的位置惊人地相似。IBM 是卖硬件 + 定制咨询的公司，工程师们被派往化工厂、制药厂、银行，给每一家客户编写定制程序，触碰着最具体的业务现实——每一张订单怎么流转，每一笔账怎么入库。受限于硬件 + 定制咨询的商业模式（这里我认为是结构性的），IBM 没有看到纯软件的盈利机会。但企业 SaaS 做得极好的 SAP，其创始人均出自 IBM——他们在给一家化工厂做订单处理系统的时候发现，每家企业的财务流程其实大同小异，可以做成标准化软件包。IBM 拒绝了这个提案，原因不予揣测。类似的事情还发生过一次：IBM 研究员 Edgar Codd 发表了论文《大型共享数据银行的关系模型》，提出了关系型数据库的概念，IBM 内部做了研发但认为没有商业价值。Larry Ellison 读完同一篇论文后创立了 Software Development Laboratories，也就是后来的 Oracle——第一个使用 SQL 的商用关系型数据库。

SAP 和 Oracle 的故事本质上是同一件事：工程师在 service 中发现通用结构，抽象成产品，独立出来。从结果来看，新技术带来的工程师们在行业里的位置有三种：一是寄生但独立——看到通用需求，抽象成产品，出来自己做，SAP 和 Oracle 都是这条路；二是创造新品类——Google、PayPal 等，可遇不可求；三是纯寄生——就是 service，给人做定制，卖人天，本质上是高级外包。

一个通识是，FDE 中绝大多数人将停留在第三种，买卖时间的处境。关键转折点是：在做 service 的过程中，能不能找到一个「通用结构」——一个跨客户、跨场景都成立的共性需求，把它抽象成产品。但这里有一个更深的问题，受限于场景复杂度的飙升，当前 AI 均从垂类入手，假设成功为律所 build 了一个效率提升 5 倍的 Agent 产品，真实利润会翻倍吗？显然不会，受制于供需关系，同样的团队能处理 5 倍的案件量。但是一个城市里的法律服务总需求在短期内是相对固定的——不会因为有了 AI 就突然多出 5 倍的人要打官司。所以这家律所的增长只能来自抢其他律所的客户。

对于这批相对成功的 FDE 们，接下来又是一个分岔路口：是用资本市场的高 PE 倍数套利，还是老老实实赚行业的钱，亦或是继续追求一个「新品类」？

碎碎念结束，talk is cheap，在任何阶段创造真正价值的都是做一件具体的事。