如何组建你的第一支前沿部署工程团队

# 引言

## 前言

本篇 Antimemo 的合著者 Mark 曾是 Palantir 的前沿部署工程师，如今运营着 Forward Deployed Venture Capital，刚刚完成了 4500 万美元的二期基金募集。Mark 从两个不同的角度见证过“前沿部署工程”：最初作为早期实践者之一，后来作为投资人，帮助他的被投公司建立自己的 FDE 战略。如今，和科技界的其他人一样，他看到这个术语渗透进大众意识——往往被当作流行语使用，剥离了其原有的含义和力度。

鉴于 Mark 现在花费大量时间澄清并重新定义“前沿部署工程”的真正含义，而且他创立的基金名字本身就叫这个，我们 Per Aspera 想不出比他更合适的人选来帮助大家回归第一性原理——阐明什么是前沿部署工程、它在实践中究竟如何运作，以及这一战略是否适合你的公司。

让我们把时间倒回 15 年前，从阿富汗坎大哈开始讲起。

## Mark Scianna 的前言

一切始于我们两个人：两名工程师被空降到坎大哈附近的一个军事基地，手里只有来自帕洛阿尔托的简明指令：“去那里，赢下来。有事打电话。”我在阿富汗待了几个月，在涉密网络上安装和配置服务器、构建产品，并乘坐午夜直升机前往巴基斯坦边境附近的作战基地。

2011 年夏天的一个夜晚，我随一支海豹突击队小队执行任务时，读到一位同事发来的博客文章。这篇题为《Why Palantir Makes My Head Hurt》的文章，把 FDE 贬低为不过是“头衔更花哨的顾问”。那一周，我一直在躲避火箭弹袭击、构建数据集成、培训用户、调试棘手的数据库。这种论调让我感觉无比荒诞。就在两个月前，美国成功执行了击毙本·拉登的行动——而这正是 Palantir 旨在支持的那类任务。

在我部署之后的这些年里，Palantir 不断实践并完善着一种艺术：让工程师尽可能贴近问题本身。距离 Palantir 的 Shyam Sankar 给这种实践命名——前沿部署工程（简称 FDE）——已经过去近二十年。天哪，这个名字真是深入人心。
如今，科技界似乎已被 FDE 那诱人的承诺一击即中。夸夸其谈者众多，但谁在真正做事？任何向你兜售“一夜成为 FDE”方案的人都是假先知。这项工作艰难，风险很高，而且并非总是合适的选择。

但如果这就是你打算玩的游戏，这本指南将告诉你如何正确地玩。

## 第 001 节

### 前沿部署工程的“货物崇拜”

FDE 已成为科技行业最热门的工作，而且这一变化来得如此之快，以至于该职位正面临招聘瓶颈。Y Combinator 的招聘板上列出了 100 多个 FDE 职位，而几年前还是零。Agentic AI 公司正在采用这一模式，OpenAI 则表示，一旦你的账单超过每年 1000 万美元，就会为你派驻一名 FDE。微软的 Satya Nadella 对这一概念大加赞赏，Mark Benioff 也是如此，他旗下的 Salesforce 最近开始发布自己的“前沿部署”职位描述。财富 500 强企业和数不清的初创公司纷纷涌入，把头衔贴在团队身上，却没有真正赋予他们权力。

难怪这个词已经被彻底“梗化”了——既是在互联网意义上的，也是在更真实、更根本的模因意义上的：FDE 是一个在传播过程中意义并未完整保留的理念。

具有讽刺意味的是，对前沿部署工程最早的批评竟成了自我实现的预言，并具有了一定的真实性。但由 Palantir 开创并实践的 FDE，既不是披着咨询外衣的东西，也不是穿着风衣的销售。对于从艺术家聚居地被派往字面意义上（或真实）前线工作的 Palantir 人来说，这是一门严谨的学科。工程师深度嵌入客户组织，拥有非同寻常的自主权，并对推动切实的运营成果承担全部责任。

Bob McGrew 曾是 PayPal 的早期工程师、Palantir 的早期高管，最近担任 OpenAI 的首席研究官，他刚刚做客 YC 的播客，分享了许多关于 FDE 的真知灼见，我们将在本文中加以引用。

McGrew 将前沿部署工程师定义为“驻扎在客户现场、填补产品功能与客户需求之间差距的人”。我们将以此作为起点，而“闪光售前工程”则是我们用来指代其他一切……不属于 FDE 的东西。

我们的首要任务是区分什么是前沿部署，什么是闪光售前工程。

Section 002

把工程师尽可能放在离他们要解决的问题最近的地方

“如果让我用一句话概括 FDE，”Mark 说，“那就是 Palantir 真正相信你应该把工程师尽可能放在离问题最近的地方。”

下面，我们将提供一个试金石，帮助你区分 FDE 和闪光售前工程。

001 // 你派的是真正的工程师吗？

FDE 意味着真正的软件工程师嵌入客户组织。不是产品经理、技术顾问，也不是伪装成工程师的销售人员。而是每天打开 IDE、在现场构建定制集成、并在几天到几周内交付成果的人。规则一：如果你的“FDE”在过去几周里没有构建过任何东西，那就不是 FDE。

002 // 这种投入是持续的吗？

你需要深度沉浸、频繁的不适感和持续的存在。短暂的现场访问不算数。规则二：如果你只是周一到周四空降一趟，那不太可能是 FDE。

My first Kandahar deployment lasted three months because we had so much to learn. Even as the product matured and our expertise grew, meaningful deployments took weeks, not days. You need time to understand the customer's workflow, build trust with users, and iterate on solutions based on real feedback.

003 // 工程师是否有权随机应变地开展工作？

这可能是最真实的试金石。FDE 源自军事上的“委托式指挥”（Auftragstaktik）理念：总部设定目标，将战术执行几乎完全下放给一线团队。回想 Mark 接到的命令：去那里，赢下来。接下来怎么做全由他自己决定：迁移哪些数据、培训谁、如何在组织内部扩展等等。日常决策属于 FDE，只有在需要关键的技术支持或出现真正的阻塞问题时，他们才会向总部求助。规则 #3：自主权不容妥协。

004 // 一线是否在反哺产品？

FDE 是一个产品发现闭环，而不是实施服务。一线团队挖掘真实的工作流程，交付能够证明价值的“碎石路”式解决方案，并将可抽象、可加固、可铺设进平台的模式交回总部。做对了，一线工作会提升你的产品杠杆效应；做得敷衍，你只会堆积越来越多的定制化工作。

早期，比例会偏向更多的定制化一线工作。你的 FDE 会从零构建更多东西。反馈循环会显得非线性且不均匀。但是……如果你成功地捕获并抽象出这些模式，后续部署就会变得更轻松、更便宜、更有价值。

以下是这套机制应该如何运作（由 Bob McGrew 提供）：

• 从一个业务成果开始。选定客户排名前五的业务成果之一，并从它出发逆向构建。你交付的是结果，而不是“一次安装”。
• 演示即规格：快速（≤10 天）推进到一个使用真实数据、并能激发用户渴望的现场演示。这能让构建聚焦，暴露出你接下来必须弥合的缝隙，并让所有人就“这就是要做的东西”达成一致。
• 两种角色。Echo 和 Delta 是 Palantir 模式中的阴与阳。Echo 团队是带有叛逆气质的领域内部人士，嵌入客户现场，挖掘真实、高杠杆的问题并维护客户关系；Delta 团队是快速原型工程师，构建和部署速度极快，与 Echo 紧密协作，在几周（而非几个季度）内交付粗糙的 v0 版本。实际上，这些人是独角兽式的人才，通常既有客户服务经验，又有工程背景。
• 修建碎石路：发现并构建通往那个能推动关键指标/解决用户痛点的成果的最小可行路径。快速、有点粗糙，但真实——这会暴露出各种模式（可复用的原语、输入/输出、工作流、功能集、可调参数），你之后可以将它们铺设进平台。
• 了解你的第二用户。你的 FDE 同事是你的第二客户，第一客户是最终用户。FDE #1 留下一些东西，让 FDE #2 能够在其基础上继续构建。#3 进一步打磨，到 FDE #N 时，它已成为默认路径。如果一线工程师不愿意选择你的抽象方案而宁愿做一次性实现，那这个抽象就是错误的抽象。
• 向上一层抽象。产品团队的职责是将某次部署中行之有效的东西泛化为比该站点需求更通用的东西。
• 证明可复用性。先在第二个客户身上验证，再在第二个细分市场验证，最后作为一个通用化的产品推出。
• 晋升为平台：将经过验证的概念融入你的核心产品，让下一次部署更多是配置工作，而非全新代码。

大多数源自一线的发现——也许 90%——都无法在初次接触（例如某个客户现场或用户画像）之外存活下来。但那些成功突破的，都是从摩擦的熔炉中凝结而成的来之不易的洞见。这些部落知识、用户洞察、行为模式、功能和需求被反馈回母舰，在那里被迅速捕获、精心提炼，并最终融入支撑 Palantir 内部和外部工具的技术之中。

如果运转良好，形成一个健康的循环，随着软件取代那些弥合产品能力与客户需求之间差距的工程师，每位 FDE 的收入将会上升。当运转不佳时，你的经济数据会暴露一切。

于是，我们终于有了规则 #4：如果各项信号没有向好趋势，而坏味道持续存在——每位 FDE 的收入停滞不前，定制工作不断累积——那你可能正在经营一家服务外包公司。

规模化地做不可规模化的事

因此，Palantir 真正的优势并不严格在于前沿部署工程师，而在于捕捉罕见而深刻的客户洞察，并将其抽象进自己的核心技术栈。正如 McGrew 所说，Palantir 破解了“规模化地做不可规模化的事”这道算术题。

Palantir 前沿部署架构师 Chad Wahlquist 表示，FDE“在一线、在客户需要的时候，构建客户需要的产品”。“FDE 在一线体验客户痛点并将其转化为产品的反馈循环，让我们能够更快地迭代并构建正确的产品。”

大多数人错过了这一点，没有发现那些定义“什么应该存在”的模式、框架和权衡空间。

请记住：这个过程是痛苦的。在 McGrew 最近做客 YC 播客时，我们数到“痛苦”一词被提及了八次。如果你掌握了这个循环，就能实现幂律级的成果。但这很痛苦，也很难做到。你很容易滑向客户支持或咨询业务，这会稀释战略并让你的成本结构膨胀。

这就引出了下一个问题：FDE 的成本是多少？

第 003 节

不容情面的经济学

FDE 改变你的招聘对象、成本结构、团队组织方式、开发节奏和产品开发。这是一种高方差策略：高投入、高风险、高潜在回报。

Palantir 前首席财务官 Colin Anderson 对这笔账直言不讳。他最近在 TBPN 上表示，试图在小额合同上推行 FDE 的公司是在“把股权当柴烧”。“一名世界级工程师加上其股权稀释，是一笔昂贵的开支……你必须是一个资本配置者，才能追求这种模式。”

FDE 需要一种稀缺人才。

顶尖的、高能动性的工程师，既能写代码，又能察言观色，某种程度上还能做销售。仅凭工程能力，这些人完全可以轻松进入 Google 或 Meta。但他们不是挂着更漂亮头衔的 IC 或 SE，而必须身兼数职。他们需要产品直觉、创造力，以及面向客户的敏锐度。这是一种难以招到、成本高昂的全栈技能组合。因此，你应当预期更长的招聘周期和更高的薪酬。

认清你的资金消耗与单位经济模型。

七位数的 ACV 合同通常能够支撑 FDE 模式；八位数或九位数显然更没问题。但更小的合同，比如 2 万到 10 万美元区间，除非明确视为通向更大合同的研发投入，否则算不过账来。把 FDE 硬塞进小额交易 = 用现金消耗或股权稀释来补贴交付。

FDE 的天然筛选条件

• 大型企业交易。你要寻找的是 ≥100 万美元的交易，或是有明确路径达到该规模的真正战略试点。

• 显著的学习需求。你面对的是无法远程发现的未知因素。有些问题或认知必须在现场才能获得，因此你必须亲赴现场学习。如果工作流程、数据现状和约束条件都不透明，而短暂的实地走访或断断续续的对话无法揭示你所需要的真相，那么你可能已具备充分条件。
• 复杂的、任务关键型问题。国防、航空航天、关键基础设施、能源、重型工业自动化……共同点是什么？它们都是可靠性、精确性和性能属于基本门槛的领域，而且通常都非常适合 FDE 模式。定制化不是可选项，而是必需品，保守主义主导一切。你需要有人能够帮助弥合新旧方式之间的鸿沟。

当以下三个条件同时成立时，全面推行 FDE 才是合理的：你面向能够承受极高价格的市场；你承认自己并不完全了解产品，并将与用户一起自下而上地探索它；你的平台为可扩展性而构建，并对什么留在边缘、什么迁移到核心有清晰的纪律。

Palantir 专注于美国政府（USG）、国家机构、航空航天与国防以及财富 500 强企业，这绝非巧合。这一客户群体支付意愿高，能够承受前沿部署的重量。

第 004 节

为什么大多数公司无法承受这一点

撇开单位经济模型不谈，FDE 需要一种罕见的契合——复杂性、规模与文化的完美融合。

FDE 颠覆了组织架构。权力与信任不再集中于总部路线图和 PM 委员会，而是被推向边缘。Palantir 的内部信条变成了“对一线团队的绝对尊重”。

Few companies are willing to fully subordinate their roadmap to field teams…this is an anathema to most cultures, where leadership creates top-down roadmaps and plans.

Barry McCardel, cofounder/CEO of Hex and ex-Palantir deployment strategist

呕吐反射：大多数组织根本无法忍受这种模式。普通的公司、机构或官僚体系想要定期汇报、每一项技术决策都要审批、可预测的路线图以及严格的预算控制。FDE 不提供这些舒适待遇。

一线团队可能会做出总部永远不会做的决策。他们会犯错，而且早期、频繁地犯错。而这正是关键所在！

底线检验：如果你无法容忍模糊性，无法接受一开始很丑陋、后来才变好的代码，或者每个 v0 都需要产品经理签字，或者失败会受到惩罚而不是被研究总结，那就不要做 FDE。

你无法在不忍受最初的痛苦和混乱的情况下，获得 FDE 的复利式回报。如果你想要确定性，可以采用更传统的服务模式。如果你想要探索发现，就把权力下放到一线，并学会管理混乱。

第 005 节

出发吧，前沿部署工程师

好了，你已经掌握了背景信息——也许比你预想的还要多。

现在来回答你们都在思考的问题：FDE 适合我的公司吗？

两个字的标准答案当然令人抓狂：看情况。取决于你的商业模式、时间跨度、市场以及对痛苦的承受能力。FDE 既可以是护城河的构建者，也可能是利润的杀手。它可以孕育一家价值数百亿美元的企业，也可能掏空你的资产负债表。

归根结底，在决定 FDE 是否适合你时，你应该考虑以下几点。

1. Upfront Cost vs. Later Payoff: The rule of thumb is to not forward deploy for <$1M ACV deals (unless it is an investment, which credibly leads to $1M+ outcome). The teams that make FDE work (Palantir, Anduril, etc.) were well-capitalized and/or selling largely from the incorporation womb. If your board demands SaaS-like margins in 24 months, the invest now, harvest later approach may be difficult to justify. You, the founder, must judge: can we invest heavily to unlock a possibly huge market 5+ years out? If yes, then FDE may be right for you as a go big/go home bet with power-law upside. (Case in point: $PLTR).

2. Retention and Talent Development: You need to be a hell of a recruiter. While you’ll be hard-pressed to get any good public data on this, the anecdata is clear: attrition must be managed. It’s a doubled-edge sword: the field attracts ambitious builders who want to make an immediate impact. They run hot. Even on the right mission, churn is real, whether from burnout, spinning out to found a startup, or moving into leadership. Design for that reality. FDE mints founders, so treat it as a leadership pipeline, not a forever seat. Run defined tours, keep a bench, and write the succession plan before you need it. If you cannot recruit, develop, and backfill at a brisk cadence, you can’t sustain FDE.

3. Headcount Ratios: Plan for a forward-heavy mix. Palantir carried a disproportionately large share of engineers in forward roles relative to pure product roles (which is unusual vis-a-vis most software companies). If FDE is core to your model, expect something similar. You may want to plan for roughly a 1:1–1:2 ratio of forward engineers to core engineers. The optimal ratio depends on situational factors, like stage. Early is lopsided and may look like 1:0 for a stretch (all hands on deck with customers). As the product hardens, you might leverage a smaller, more agile FDE team feeding a larger platform group. A forward function lives in COGS (even if it’s actually R&D) and compresses gross margin while discovery is heavy. If you cannot budget for a persistently higher services headcount, it will be difficult to employ the FDE model.
4. Investor Relations: VCs and institutional investors like traditional SaaS in part because it optimizes for a very low headcount to keep margins high. FDE calls for you to fund a larger, in-house, services-like team because you treat it as R&D. This will show up in the P&L: gross margins compress while deployment is heavy, then trend up only as field patterns are productized. Set and manage expectations early on, with yourself, prospective investors, future controllers, your board, and the market. State plainly that the forward-heavy mix is a deliberate R&D investment, and show how you’re trading near-term margin drag for a differentiated product development strategy. Practice your story, practice it some more, and perfect it. If you need to spell it out for stakeholders, start with this and turn it into your own:

我们现在有意在前沿部署工程上投入更多，这会在短期内压低利润率，从而让我们能把一线的成功转化为可复用的产品开发洞察，加速部署、提升增购，并随时间推移提高利润率。

把“为什么”讲明白，展示相关指标，如果有帮助，就把这篇文章发给那位疲惫的投资者。

5. Define, Live, and Die by your KPIs: The metric set to watch: conversion, expansion, and time-to-value. FDE, done right, helps you land bigger deals and expand them faster (the logic being that by delivering value quickly, you grow a pilot to a $1M+ deal in a way pure sales could not). Palantir often started small with projects that turned into huge contracts (e.g., Project Maven) after value was proven on the ground. The beauty is that your FDEs are your key lever for account expansion. Once embedded, the engineer finds more problems to solve and essentially creates their own upsell opportunity by delivering results. If you’re seriously considering going down this road, have a good handle on pilot conversion rate, expansion revenue, and time to value for customers under an FDE model vs. normal. With a successful FDE strategy, you’d expect shorter time to first value and high expansion multiples on initial deals.

6. You have to be customer-obsessed, and your customer has to be obsessed: The point of FDE is stickier, higher-value outcomes. That is its raison d’être. While harder to quantify, things like customer retention/churn or NPS score can reflect this. Palantir’s retention on core accounts and strategic programs speaks to this point. And quantitatively, Palantir’s improving margins showed progress: as the software matured, the company could reduce how many engineers were sitting with a given client. But, a word of caution…if a customer’s environment changes or if you step back, will they maintain success? Over a 5–10 year span, a well-executed FDE model should see decreasing marginal cost per customer (as more of the solution is out-of-the-box) while maintaining/improving outcomes. If instead you still need just as many custom engineers for the Nth customer as you did for the first, the model isn’t scaling.

结论

向前，奔赴前沿

这一切对硬件领域意味着什么？硬件正是 Per Aspera 的执着所在，也是你们许多人每天从事的工作。

前沿从来都属于那些离问题最近的人。从让大型机保持运转的现场工程师，到系好安全带驾驶未经验证机器的宇航员，进步都来自那些选择沉浸而非抽象的人。FDE 在最佳状态下正是这种本能：把人才、判断力和意志力放到风险最高的地方。这种本能比任何名字都重要，它正是最难的问题得以解决的方式。

FDE 是一种关于如何构建的选择。做得好，探索就会成为一种节奏——落地、扩展、抽象——产品开始承担重量。但它并不适合大多数团队。它需要资本、耐心和极高的痛苦承受力。

如果你身处硬件行业，并且一直在做看起来和感觉上都像 FDE 的事情，这份反备忘录应该能让你掌握更精准的语言、更清晰的指标和更明确的运营模式。如果你是这一领域的新手，希望这能帮助你判断这场竞技是否适合你。我们已经为你提供了正确的核算方法，让你不必通过 FAFO（瞎搞乱试）来付出惨痛代价、艰难地领悟误用这一模式的真实成本。

决定你要玩哪一场游戏，然后全力以赴。

两个行动号召

• 如果你在做这类工作，并且拥有证明自己的伤疤和实绩，我们想听听你的故事。把你的经验教训、险些失败的教训和悄然累积的胜利发给 Per Aspera 团队。如果你还没有注册 Per Aspera，赶紧报名！
• 如果你是一位创始人，希望找到一位能帮助你建立真正前沿部署职能的投资人，请联系 Forward Deployed VC 的 Mark Scianna。他亲身坐过这个位置，现在投资于那些能够承受痛苦的团队。如果你打算玩这场游戏，请带上愿意和你一起坐到离问题最近处的人，并且坚持待在那里，直到那该死的东西真正跑通为止！