我们接触到的每一家 AI 公司都在问同一个问题：我们该不该招聘前沿部署工程师？
诚实的答案往往是：不该。至少现在不该，而且可能也不是你想象的那种方式。
OpenAI 最近成立了一家专门的部署公司。Anthropic 正在扩展其服务部门。初创公司在还没弄清楚这个角色到底做什么之前，就已经开始设立"FDE"头衔了。而且在几乎每一场人才讨论中，都会浮现同样的问题：每个人都想要那种处于产品与客户之间、能够在现场进行构建、销售和迭代的人，但没有人能说清楚这与一名优秀的解决方案工程师或昂贵的技术顾问到底有什么区别。
我们最近召集了被投公司的创始人、CTO 和运营负责人，与 Anjor Kanekar 一起召开了一场关于这个问题的研讨。Anjor 曾在 Palantir 担任 FDE 七年，如今是一名帮助企业设计 FDE 组织的顾问。以下是我们的综合观点。
一个以拒绝被定义来定义的角色
首先要理解的是，FDE 这个角色是刻意不被定义的。这既是它的力量所在，也是它令人困惑之处。
Anjor 自己的职业生涯就说明了这一点。七年间，他的工作从 DevOps 式的部署稳定性保障，到与一家大型企业客户共同构建应用，再到领导一个 35 人的团队，然后又以 IC 身份编写后端代码，再到负责政府项目的产品监督。他的头衔呢？始终都是前沿部署工程师。
这不是组织管理上的混乱。这正是这个角色的意义所在。它是一个容器，承载着公司在产品与客户交界处所需要的任何东西。随着产品成熟、市场演变和个人成长，这个形态会不断变化。那些试图把 FDE 固定在一份固定职位描述上的公司，从一开始就误解了这个职能。
唯一保持不变的是反馈回路。FDE 为特定客户构建定制化解决方案，但真正的交付物并不是面向客户的产出，而是反馈回来的产品信号：暴露出的缺口、临时发明的变通方案、以及那些揭示什么应该成为平台能力的模式。Anjor 在最近的一篇文章中很好地阐述了这一点，他设想了如果乐高拥有前沿部署工程师会发生什么：FDE 的职责是为客户交付一条龙，但要把他们为了造出这条龙而不得不发明的那些奇怪积木带回来。如果没有人带着这些积木回到产品团队，那你拥有的就不是 FDE 组织，而只是一个服务团队。
什么时候才真正需要 FDE
Anjor 在我们的研讨中提出了一个能拨开重重迷雾的框架：想想"product-market fit"（产品市场契合）这个短语。如果你还在摸索产品或市场中的任何一方，你可能需要 FDE。如果两者都已确立，你可能就不需要了。
寻找产品。 你的核心产品已经存在，但需要针对每个客户进行大量定制。FDE 负责填补空白、构建定制化解决方案，并将经过验证的信号带回核心团队。在最早的阶段，FDE 本身就是产品：与客户坐在一起，在现场构建，实时塑造产品路线图。我们会议中的一位创始人描述的正是这种情况：一个足够开放的平台，客户需要团队中有人来配置并针对其上的用例进行提示工程。这就是教科书式的 FDE 领域。
寻找市场。 你有一个可用的产品，并希望在现有客户中扩展。一位与银行合作开展反洗钱业务的 FDE，通过驻场并赢得信任，可能会在相邻的工作流程中发现机会。FDE 就是“落地与扩张”的机制。
反向观点： 一旦你的产品开箱即用、市场开始买单，就应该把这个角色拆分为传统的解决方案工程师和解决方案架构师。过了这个阶段还坚持 FDE 模式，公司就会在不知不觉中变成咨询公司。如果产品交付的能力与客户需求之间的差距没有缩小，增加更多 FDE 也无济于事。问题出在别的地方。
激励机制的设计性错位
运营 FDE 组织最困难的地方在于，FDE 与产品团队之间的激励被刻意设计成相互制衡。FDE 追求赢得自己的客户，产品团队追求构建通用的东西。这两种取向相互拉扯，而正是这种不适感孕育出好产品。
这对考核有直接影响。FDE 的绩效绝不应与项目层面的收入挂钩。一旦这样做，FDE 就不再是产品侦察员，而变成了客户经理。他们会专注于从每笔交易中榨取更多价值，而不是识别哪些应该沉淀为平台能力。
Anjor 倡导的一个原则——我们认为更多公司应该采纳——是 FDE 甚至不应该知道自己所负责项目的合同金额。他们的角色是提供产品信号，而非榨取收入。真正重要的指标是公司整体层面的每位前沿部署工程师人均收入：衡量的是产品杠杆效应，而非个人计费。第二个需要追踪的指标是每个客户的 FDE 数量。早期，你可能需要三到五个人负责一个用例。随着产品成熟，这个数字应降至一人负责多个客户。如果这两个数字没有朝正确方向移动（人均 FDE 收入上升、每客户人数下降），说明你的产品没有吸收来自一线的经验教训。
薪酬设计也应遵循这一点。避免对 FDE 采用提成或收入分成结构。将奖励与产生的产品信号、达成的里程碑以及内部贡献挂钩。绩效评估应全面且量身定制。这不是一个适用标准工程职级体系的角色。
招聘：考察应对模糊性的能力，而非算法能力
传统技术面试在 FDE 招聘中越来越不可靠。AI 工具让编程测评的意义大打折扣，而这个角色所要求的技能是标准面试流程无法考察的。
真正重要的是在模糊情境下的批判性思维，尤其是善用 AI 工具的同时，保持对输出何时出错的判断力。正如我们研讨会上一位创始人所说：你不能偷懒，但必须足够聪明地用好这些工具。
会上提出了三种方法：
基于真实场景的面试。 设计一个贴近 FDE 实际工作的角色扮演。Anjor 描述过他为一位客户设计的面试：面试官扮演一位惊慌失措的客户。“我两小时后有个会议，仪表盘显示的数字不对，帮我调试一下。”候选人需要现场进行问题分诊、沟通和解决问题。
工作试用。 对于早期公司来说，没有什么比几天的实际工作更能检验 FDE 的能力了。
评估 AI 增强下的判断力。 2026 年最优秀的 FDE 不是最好的程序员，而是最擅长选择工具、高效提示（prompting）、并知道何时该拒绝输出的人。
一个值得强调的结构性要点：如果你同时招聘 FDE 和核心工程师，可以考虑在两个职能之间设置统一的招聘标准。由同一位招聘负责人或采用一致的评估框架，能确保技术标准保持高水平，并让员工随着公司发展在现场与产品角色之间灵活流动。
定价、知识产权与组织结构
商业模式会按可预测的方式演进。早期你卖的是服务：FDE 的时间就是产品。随着平台成熟，你转向许可费加补贴实施。规模化之后，就是纯 SaaS 加高端服务费率。
知识产权归属是长期存在的难题。最清晰的框架是：支撑 FDE 工作的工具和基础设施是你的知识产权；为特定客户在其之上构建的定制应用则归客户所有。抽象类是你的，实例化是他们的。灰色地带则需要逐案进行合同谈判。早期若处理不当，会埋下痛苦的先例。
在组织架构上，FDE 应隶属于面向客户的部门，与核心产品工程分开。这种分离保留了现场驱动优先级与平台思维之间富有成效的张力。一旦合并，你就会失去让这个职能产生价值的那种反馈回路。
战略岔路口：产品公司还是 AI 驱动的服务公司？
我们研讨会上最具争议性的话题是：随着 AI 工具不断变得更强大，FDE 模式将走向何方。
一位创始人这样描述新的经济逻辑：一个人使用他们的平台，半天之内就能复现过去客户每年要花数万美元软件费才能获得的功能。如果定制交付的单位经济性刚刚下降了一个数量级，你还需要产品化吗？还是说正确的做法是永远交付定制解决方案，按成果而非按许可证定价？
这是一个真正的分岔口。一些公司正积极拥抱它，构建内部工具让自己的员工效率大幅提升，然后以软件的利润率获取服务收入。另一些公司则沿用传统的 FDE 模式，将其作为产品发现职能，最终被吸收进核心产品团队。
正确的答案取决于你的市场、你的雄心，以及你所构建的东西中有多少能够真正泛化。重要的是这个选择必须是自觉的。最糟糕的结果是不知不觉滑向服务业务：一觉醒来发现你的 FDE 在按小时计费，你的路线图变成了一堆客户需求，而你以 SaaS 的估值运营着一家咨询公司。
检验标准
如今大多数招聘 FDE 的公司其实并不需要他们。而对于真正需要的公司来说，这一职能是现有最强大的组织工具之一：一种以部署的速度向客户学习、同时构建能够复利增长的产品的方式。
两个数字能告诉你是否走在正确的轨道上：单个 FDE 创造的收入在上升，每个客户占用的员工数在下降。如果两者都在朝好的方向变化，你正在构建一家以产品为主导、把部署当作加速器的公司。如果它们持平或朝错误的方向发展，你正在构建的是一家以服务为主导的业务——这也可以很有价值，但在招聘、定价和利润率上需要一套截然不同的打法。
运转良好的 FDE 职能能提供一些大型 AI 实验室的部署团队几乎肯定无法提供的东西：对整个项目创始人般的责任感、真实的产品影响力，以及那种能把优秀工程师锻炼成未来创始人的、结构化的模糊性。对于做对了这一点的公司来说，这既是招聘的卖点，也是竞争优势。
本文基于 Northzone 与被投公司创始人及运营者的一次工作研讨，以及 Anjor Kanekar 的文章《If LEGO Had Forward Deployed Engineers》。