好的，作为一名在科技行业摸爬滚打多年的老手，今天我们来聊聊最近圈子里一个特别有意思的趋势——“前沿部署工程师”，也就是FDE。这个角色今年在AI初创公司里火得不行，甚至被a16z称为“科技行业最热门的工作”。它融合了软件工程、销售和平台工程的活儿，随着AI解决方案的落地需求激增，相关的招聘从年初就开始猛涨。而且，对FDE有需求的，远不止AI初创公司。 今天我们就来深入拆解一下这个角色，重点看看这几个方面： 1. FDE到底是个什么角色？简单说，就是一种在客户团队和核心产品工程团队之间来回切换的软件工程师。这活儿可不轻松，得有两把刷子才行。 2. 这个角色怎么来的？直到2016年，Palantir的FDE（当时叫“Deltas”）数量都比普通软件工程师多。可以说，没有哪家公司比这家神秘的科技公司更能定义这个角色了。 3. OpenAI的FDE团队。ChatGPT的母公司今年早些时候设立了这一职位，和我们熟悉的解决方案架构师（SA）有区别。 4. Ramp的实践。金融科技公司Ramp在9个月前组建了FDE团队，目前大约有15人，分成几个小组，遵循四项核心运营原则来工作。 5. 为什么现在这么火？整合大语言模型和AI产品，简直就是为FDE量身定做的场景。而Palantir的商业成功，也离不开FDE的贡献。 6. FDE和解决方案工程师（SE）、智能体工程师（AE）的区别。虽然有点像，但FDE通常需要对核心产品做出更多贡献。 7. FDE的职业发展。怎么招人？薪资待遇如何？未来晋升路径又是什么？ ## 到底什么是前沿部署工程师？ FDE的招聘广告通常会列出几个关键特征： * **扎实的软件工程基础。** 几乎所有公司都要求有深厚的软件工程功底和实际项目经验来证明能力。Ramp的高级FDE职位更倾向于5年以上经验，但也会招一些优秀的应届毕业生。Palantir甚至招过只有一年工作经验的毕业生。而像医疗健康初创公司Commure和工业AI公司Matta，则更看重从零到一构建和交付项目的实际经验。 * **与销售团队配合拿下客户。** 很多初创公司会利用FDE来赢得客户。当客户犹豫产品是否好用、能否集成时，销售团队就会派出一名FDE，帮助客户搞定整合。Ramp的招聘广告里写得很清楚：“与销售和市场团队紧密合作，达成关键交易，激活客户，并随着时间推移扩大Ramp提供的价值。” * **嵌入客户团队。** 就像OpenAI的招聘广告说的：“作为FDE，你会嵌入到客户团队中，了解他们的业务领域，和他们一起开发解决方案，解决那些通常定义不清、不断变化的实际问题。” 这意味着，出差去客户现场和他们并肩工作是家常便饭。Palantir预计FDE大约25%的时间在客户现场，而医疗AI公司Commure估计这个比例高达50%。 * **为公司核心产品做贡献，并与核心产品工程团队深度协作。** Ramp的描述很到位：“推动核心产品的工程路线图，做出重要的优先级和范围决策，决定我们是构建定制化方案，还是加速推进现有的大项目。我们采用一种嵌入式模式，FDE会嵌入到核心产品工程团队中，在最相关的技术领域发展专业能力。” * **帮助客户成功。** 这个角色的核心，就是在公司产品的基础上进行二次开发，确保客户成功。机器人初创公司Gecko Robotics的表述很有代表性：“我们寻找最具影响力的难题，花大量时间与客户在一起，理解问题的本质，我们提出新方法，直到产生实际影响，否则绝不放弃。” 有些公司倾向于把这个角色看作技术顾问，比如AI智能体管理平台Lindy，希望FDE能帮助客户构建和维护无代码工作流，同时担任技术顾问。但显然，当顾问和既服务客户又参与产品开发的工程师之间，界限是模糊的。 每家公司对FDE的定义都不同，毕竟这个角色相对较新，大家都会根据自己的情况来定义。有些公司更强调FDE在销售漏斗中的作用，有些更看重协助客户，还有些则聚焦于对核心产品的贡献。看起来，这个角色被寄予了厚望。比如，Salesforce对高级FDE的期望清单是这样的： 1. 亲自动手推动切实成果 2. 构建变革性AI解决方案 3. 设计定制化AI智能体解决方案 4. 负责整个数据配置与集成生命周期 5. 主动消除技术障碍 6. 推动Agentforce创新 7. 成为值得信赖的战略合作伙伴 8. 进行深入的技术调试和根本原因分析 9. 主导快速原型开发与迭代 10. 实施并推行最佳实践 这份清单内容不少，看起来和资深软件工程师的隐性期望很像。我个人比较喜欢Palantir的定义，它几乎涵盖了上面所有内容：**“FDE的职责和初创公司的CTO类似：你在小团队里工作，负责高风险项目的端到端执行。”** 与FDE高度相似的角色可能有不同的名字，比如“智能体工程师”、“解决方案架构师”、“销售工程师”和“技术交付工程师”。区别在于，FDE既与客户合作，也对公司销售的产品做出贡献。 可以这样理解FDE的角色模型——注意，如果公司不让FDE参与产品开发，那么“平台工程师”这部分可能就没那么重要了： ## 起源：Palantir的“Delta”部队 “前沿部署软件工程师”这个角色，最早是由数据挖掘巨头Palantir在2010年代初创造的，他们称之为“Delta”。Palantir成立于2003年，服务对象主要是执法部门、军方等政府机构，以及私营公司。他们处理的数据通常非常敏感、具有专有性。 直到大约2016年，Palantir的FDE人数都超过了“普通”软件工程师。那一年，他们推出了一个名为Palantir Foundry的产品，这是一个面向商业和民用政府部门的集成数据平台。从那时起，越来越多的FDE回到了软件工程师岗位，专注于开发Foundry，把在前线积累的经验带回核心产品。 即使到今天，也没有哪家公司雇佣的FDE比Palantir更多，也没有哪家初创公司对这个角色的影响力能与之相比。Palantir对FDE角色的解释非常详细： > “Deltas（前线部署软件工程师）将我们的软件平台部署给客户。Deltas属于业务发展部门，任务是为客户实现技术成果。作为直接支持一个客户的团队成员，Delta专注于技术驱动的价值创造：部署和定制Palantir平台以解决关键业务问题。他们以对客户目标的影响来衡量成功。例如，我们与希望减少生产线上缺陷产品数量的制造商合作。为了在该指标上取得进展，Delta使用Palantir产品、多种语言、开源工具、行业标准的构建工具，以及自身的创造力来设计解决方案。 > > 你可以把Dev的关注点看作‘一项能力，多个客户’，而Delta的关注点是‘一个客户，多种能力’。” FDE有时会被误认为是顾问，但区别在于，顾问提供一次性建议，而FDE通常与客户长期合作。如前所述，FDE也对核心产品做出贡献。当客户需要某项能力而平台缺失时，FDE可以动手进行开发，为Palantir的产品添加功能和改进。 两位在Palantir的FDE分享了他们在2019年的典型一天： * **Dyon（阿布扎比）：** “大多数时候，我每周花几天在客户现场工作，其中一部分时间用于与技术或业务相关方开会，其余时间则用于监控、调试、部署或为客户配置软件。回到办公室后，我会花时间编写小的代码更改、审查pull request，以及研究/规划客户解决方案。剩余时间用于通过邮件或视频会议与内部支持和产品开发团队，以及位于多个远程办公室的下属沟通。” * **G.M.（圣保罗）：** “我的‘日常’每个月都在变，这是这个角色很酷的地方！有些周，我大部分时间像典型软件工程师一样开发和审查代码。其他周，则花大量时间与客户一起规划项目未来，或与用户合作确保功能满足需求。” 总体来看，Palantir的FDE典型一周包括： 1. **客户的项目工作：** 主要关注点。 2. **改进Palantir的平台/系统：** 当平台阻碍功能构建时，FDE会配置新的数据模型、贡献稳定性改进，或提交平台修复。 3. **处理内部任务：** 内部沟通、邮件、会议、站会等。 这听起来像是把两个独立的工作（类似顾问+平台工程师）合并成了一个！这正是该角色的难点所在。一位Palantir的FDE表示，能说“不”是做好这份工作的关键：“我通常通过问自己‘这个讨论是否必须以会议形式进行，是否必须我在场？’来限制开会时间。公司里大多数人都这么做，使得我参加的每场会议最终都能有效利用时间。” Palantir经常与我认为属于“传统”类型的政府机构和公司合作。我怀疑，如果没有FDE这样的角色，这些较为传统的业务将很难把Palantir的系统整合进自己的系统。初创公司灵活敏捷，开发者乐于尝试，不介意把解决方案“拼凑”起来。但大型企业往往相反，完成任务的障碍往往不是技术挑战，而是官僚主义和“不是我职责范围”的心态。 通过派遣有授权的工程师，其任务是以能够为客户创造价值的方式整合Palantir的软件，Palantir一举两得：他们不需要担心内部官僚主义，因为他们对此毫不知情；同时派出具有“创业思维”的开发人员进行整合，心态是“我如何能让它运作起来”，而不是“有哪些原因会导致它无法运作”。与Palantir签约的公司看到的软件整合进度，比自己完成要快得多。 ## 前沿实践：OpenAI的FDE团队 Colin Jarvis是OpenAI前沿部署工程（FDE）的负责人。他最初在2022年以解决方案架构师身份加入，后来成为解决方案架构负责人。今年年初，他提出了设立FDE团队的商业案例，以提供更具针对性的服务。团队最初只有两名FDE，如今公司里已经有超过10人，分布在纽约、旧金山、都柏林、伦敦、东京、新加坡等8个城市。 OpenAI仍然保留了“解决方案架构师”（SA）的角色。SA和FDE都帮助解决客户在使用大语言模型（LLM）时遇到的复杂问题。但FDE更加亲力亲为，通常比传统SA处理更多不确定性。SA更偏向咨询角色：他们很少在客户的基础设施上编写代码，通常使用匿名化或离线数据构建最小可行产品（MVP）或概念验证（PoC）。而FDE直接在客户的基础设施上编写代码，使用客户的工具，也需要处理更多不确定性。 FDE还帮助推进产品路线图。举个例子，OpenAI与一家语音客户合作进行呼叫中心自动化，FDE为语音模型创建了评估（evals）。最初，模型的表现不足以让客户承诺部署。于是，FDE团队带着数据回到OpenAI的研究部门，针对语音使用场景改进模型性能，最终使该客户成为首个在生产环境中部署该先进解决方案的用户。OpenAI的实时API（Realtime API）也因此得到了改进。最终，这是一个双赢的结果：客户通过FDE更快获得了更先进的能力，而OpenAI则通过真实案例测试了改进，并为所有客户提升了产品。 Colin解释了他们的FDE团队如何看待工作的并行维度： 客户项目通常分为三个阶段： * **早期范围界定（阶段#1）：** 与客户现场共处几天，梳理流程，识别最大价值领域，使用合成数据进行原型设计，在白板上构思想法并排序。 * **验证（阶段#2）：** FDE驻场客户现场，回答“我们界定的范围是否是能为客户做的最有价值的事情？”如果是，就验证标准达成一致。构建验证标准通常包括：使用用户输入和标注构建评估、扩展标注流程、构建功能并在评估中优化、提交最终报告。 * **交付（阶段#3）：** 在客户现场，了解问题细节，获取数据，构建解决方案，专注于能产生端到端解决方案的“最小单元”。 Colin说，在交付前进行验证并不常见，但这样做是有充分理由的：“FDE在大量模糊性中工作，客户在范围界定中描述的内容往往与地面的数据/系统现实不匹配。我们希望偏向于快速行动，证明任何无法逾越的障碍，然后根据任何不可克服的限制调整范围，做我们能做的最有用的事情。” 有个有趣的例子：在美国爱荷华州，一名FDE与John Deere合作开展了一个项目。这家有200年历史的农业基础设施企业，希望将“个性化农民干预措施”规模化。此前，客户通过手动打电话给农民，提供如何最好地利用农业设备的提示和建议。但客户希望农民能获得个性化洞察，以最大化利用他们最新的杂草控制技术，该技术减少了喷洒在作物上的杀虫剂量，节省了大量成本。作为项目的一部分，Colin和一名FDE亲自前往爱荷华州，直接与农民合作。 项目时间很紧：John Deere希望新功能能在下一个种植季节前准备好，那时作物种植完成，有效的喷洒至关重要。团队在这个紧张的时间框架内完成了集成，项目被认为是成功的。 除了客户项目，FDE也与OpenAI内部团队分享知识：与研究团队定期的知识分享会议、与产品负责人和产品经理的进度汇报、内部Slack频道的“FDE现场笔记”，以及每季度一次的训练营，把所有成员聚集在一起。值得一提的是，FDE团队还是OpenAI Agents SDK的重要贡献者。 ## 金融科技领域的实践：Ramp的FDE Leo Mehr在金融科技初创公司Ramp负责前沿部署工程。他回忆了创建这个职能的过程： 【后续内容将基于原文继续，这里保持结构完整】