✨ 大家好，这是 next play 通讯的免费版，我们在这里分享那些不为人知的机会，帮助你弄清楚人生旅程中的下一步。点击这里加入我们的私密 Slack 社区，点击这里获取价值数千美元的产品折扣。

近期热门帖子：非技术人员的创业技能、61 位愿意与联合创始人见面的人，以及更多。

如果你在科技行业工作，你应该了解一下前沿部署工程（FDE）。 它已迅速成为几乎所有快速增长的 AI 公司都在争抢的热门职位之一……与此同时，却很少有人和公司真正理解这个角色。

FDE 最初由 Palantir（如今是一家市值 2750 亿美元的上市公司）推广开来。所以我觉得采访 Vinoo Ganesh 会是个好主意——他正是 2015 年在 Palantir 设计并搭建了将软件工程师培养成 FDE 的项目的人。

这个项目名为 Project Frontline，其运作方式是将工程师派往国防、情报和企业领域的真实客户部署现场。超过 250 名工程师经历了这个项目。他们现在任职于 OpenAI、xAI、Anduril 以及数十家领先的公司。

我请他整理了他对想要成为（或招聘）FDE 的人的最佳建议，内容包括：

• 为什么 FDE 对初创公司（越来越）重要
• FDE 角色的历史
• 他成为 FDE 的亲身经历
• 为什么你应该考虑成为 FDE
• 为什么你不应该成为 FDE
• 成为 FDE 的行动指南

即使你并不打算立即成为（或招聘）FDE，我认为你也会觉得这篇文章很有启发。其中包含许多适用于初创公司各个岗位的故事和想法，适合那些希望了解客户并深入一线的人。而且我觉得他的故事本身就很有意思。希望对你有帮助！

（顺便说一下，你可以在 LinkedIn 上关注 Vinoo，或关注 kepler.ai 博客获取他的更多想法）

前沿部署工程权威指南

核心要点

前沿部署工程师（FDE）已成为科技行业最有价值的资历，而大多数人并不明白为什么。

如果你看看 OpenAI、xAI、Anthropic、Helsing、Anduril、Scale 或 Palantir 的招聘启事，你会发现他们要找的不只是软件工程师。他们要找的是能够部署、能与客户坐在一起、能让软件在现实世界中真正运转的工程师。

以下是你需要了解的内容：

FDE 是一种以客户成果为己任的软件工程师。不是客户关系，不是客户满意度评分，而是成果：客户试图通过软件实现的实际结果。这个区别听起来微妙，但它改变了一切。售前工程师的职责是帮助达成交易。解决方案架构师设计产品如何融入客户的环境。而 FDE 的职责是确保客户真正取得成功。

关键的洞察在于：你无法通过招聘轻松组建一支真正的 FDE 团队。这种技能组合太稀缺、太特殊，而且高度依赖于大多数工程师从未有过的经历。传统的工程岗位无法培养这种技能，因为它们的设计初衷就是让工程师与客户现实隔绝。你写代码，你发布，你转向下一个工单。你从未感受过客户依赖你工作的分量，从未见过你精心设计的系统遇到杂乱的真实数据时会发生什么，从未需要直视某个人的眼睛，解释为什么他们需要的东西无法运行。

那么，如何招聘前沿部署工程师？答案是：不招聘。而是培养他们。

这正是 Palantir 的关键洞察，而我们花了多年才完全理解它。组建 FDE 团队的唯一方法，是找到有才华的人，让他们经历一场熔炉般的历练，彻底改变他们对构建软件的思考方式。

为什么这一点现在很重要： 三股力量正在让 FDE 模式成为常态而非例外。

首先，AI 正在让部署变得更难，而不是更容易。AI 系统需要微调、提示词工程、评测以及持续的调整。你不可能把一个 LLM 扔过墙就指望客户自己搞定。OpenAI、Anthropic、xAI 以及每一家严肃的 AI 公司都在构建 FDE 式的职能，即使他们不这么称呼它。这里还有一个相关的问题，关乎“工程师”这个身份本身意味着什么：如果 AI 能完成初级工程师过去做的许多工作，那么仍然有价值的工程师，是那些能做 AI 做不到的事情的人——与客户坐在一起，理解他们的真实问题，并对结果负责。

其次，国防科技正在爆发。Anduril、Palantir、Shield AI 以及数十家初创公司正在为无法容忍部署失败的军方和政府客户构建软件。这些客户在环境艰苦、约束独特的条件下运作，你无法用一个客服热线来支持他们。你需要身处一线的工程师。

第三，企业买家正变得越来越精明。在经历了数十年的“上架即闲置”软件之后，企业开始要求实施保障。他们希望看到工程师驻场，并知道有人会对部署负责，而不仅仅是对销售负责。能够做到这一点的供应商将会胜出。

我预计，五年之内，每一家严肃的企业软件公司都会设立 FDE 职能。如果你正在考虑把职业押注在哪里，这就是值得押注的趋势。

灰色连帽运动外套

[1] 我的灰色运动夹克

在 Palantir，人人都有一件黑色运动夹克。标准配置。但还有另一种夹克，灰色的，你买不到，也申请不到。

传说中，你的黑夹克是经过多年历练才褪色的——你穿着它经历了足够多的部署和足够艰苦的现场工作，黑色被磨掉了，变成了灰色。当你在实战中证明了自己，领导层才会授予你这件夹克。

Brian Schimpf，如今 Anduril 的 CEO，当年作为 Palantir 的高级工程负责人之一，就负责颁发这些夹克。当我拿到我的那件时，我并没有感到自豪或成就感。我感受到的是它所代表的一切的分量：那些深夜，那些失败的系统，那些在出问题时依赖我的客户。这件夹克不是奖杯。它是一种认可——你经历过某些事情，而这些事情改变了你。

当工程师们问我如何成为 FDE 时，他们想要的是要培养的技能、要考的证书、简历上的关键词。但这不是重点。夹克只是象征。真正重要的是那种蜕变。

想结识志同道合的人？加入 Friends of Next Play Slack 群组。

我的蜕变

如果你想获得关于如何成为 FDE 的具体建议，可以直接跳到文末的“实战手册”。但如果你想理解这种蜕变为何重要、它究竟是什么感觉，请继续往下读。

我加入 Palantir 时在帕洛阿尔托做产品开发。我修 Jira 工单、写代码、建测试、做代码评审、设计系统架构。我参加冲刺规划，按时完成任务。按所有内部指标衡量，我干得不错。

但当我轮岗到一线现场后，我所看到的一切彻底颠覆了我对自己工作的理解。

我们有一个叫 Phoenix 的产品。在它设计所针对的使用场景下，它运行得非常出色。架构干净，代码扎实，测试覆盖良好。我们为它感到骄傲。

然后我亲眼看着它失败。

这个系统依赖一个看似很直接的数据集成：当新数据进来时，我们在 Apache Cassandra 中生成一个 keyspace。我们把它设计成以 10 分钟为增量创建 keyspace，方便自动删除。我们当时觉得这招挺聪明。

然后坏数据进来了。确切地说，是没有数据进来。日期列是空的。我们的系统把它解释为纪元时间：1970 年 1 月 1 日。于是它完全按照设计行事，生成了从 1970 年 1 月 1 日到 2013 年 10 月 7 日之间的每一个 keyspace。

那是 230 万个 keyspace。Cassandra 中每个列族大约需要 5MB。光是启动就需要 14TB 的内存。

系统启动时直接 OOM 了。就像当年 Palantir 常说的那句话：“bad times on boats”（船上的糟糕时刻）。

我坐在那里看着这一切发生，突然意识到一个本应显而易见的事实：我们从未见过这个系统实际要处理的数据。凌晨两点垃圾数据涌入时，我们从不在现场。我们也从不需要直视客户的眼睛，解释为什么他们赖以工作的系统突然没了响应。

这不是一次性的经历。在其他项目上我又看到了同样的情况。我们会构建出优雅而技术精妙的东西，交付到现场，然后看着它以我们从未预料到的方式与现实碰撞。模式总是一样的：我们在不了解情况的情况下构建，为错误的目标优化，解决不存在的问题，却忽视真正存在的问题。我们构建的东西与用户实际需要的东西之间的差距不是小差距，而是一道鸿沟。

在第一次经历之后，我不断回到现场：纽约、新加坡、阿富汗、以色列、阿联酋、多伦多、旧金山、孟买，还有一些我不能透露名字的政府部署项目。我在 SCIF（敏感信息设施）里花了大量时间处理跨多个网络的数据集成。我的笔记本电脑有一次在中东的车里过热，差点熔化。

每一次现场经历都让我对构建软件与部署软件之间的距离有了新的认识，让我明白当你的代码遭遇现实时会发生什么，明白在理论上解决问题与为一个此时此刻就需要它正常运转的真实的人解决问题之间的区别。

多年来，我在软件工程和前沿部署工作之间来回切换，在构建与部署之间往返。每次回到产品开发，我的构建方式都不一样了。我会提出不同的问题，预见不同的失败。我以一种以前不可能有的方式，真正理解了这些软件究竟是做什么用的。

这种往复改变了我。我也开始相信，它同样能改变别人。

为什么这种模式有效

商业逻辑

商业逻辑很简单：真正被采用的软件，其价值远远超过被束之高阁的软件。

大多数企业软件未能创造价值，不是因为技术上不行，而是因为它们从未被正确地部署、配置、采用并集成到客户的工作流程中。这个行业肮脏的秘密是，很大比例的企业软件采购最终沦为搁置软件。客户买了，尝试实施，遇到阻力，然后放弃。

采用 FDE 模式的公司没有这个问题。他们的软件得到使用，因为有工程师在现场确保它被使用。问题得到实时解决，配置根据实际工作流程进行调整，边缘情况在成为阻碍之前就被处理掉。

这就形成了一个飞轮：部署的软件产生反馈，反馈改进产品，更好的产品更容易部署，更容易的部署带来更多客户，更多客户意味着更多反馈。

Palantir 仅从其前 20 大客户就获得了超过 11 亿美元的年收入。这并不是因为他们的软件比竞争对手好一点点，而是因为 Palantir 的工程师以一种传统企业软件供应商根本不会采用的方式对客户成果负责。

公司想要 FDE 的另一个原因是，他们是产品洞察的最佳来源。直接与客户合作的工程师能看到那些只读调研数据的产品经理永远看不到的东西。他们了解实际的工作流程、真实的约束条件、真正的痛点。Palantir 最好的产品创意，都来自那些在现场待了足够久、明白该构建什么的 FDE。

我参与过的一个部署项目每天运行着五十多条数据管道，监控它们简直是一场噩梦。几位亲身经历过这种痛苦的工程师构建了一个管道监控工具，随后被部署到多个站点。他们构建它不是因为产品经理的要求，而是因为他们自己切身感受过这个问题。

这就是 FDE 的优势：凭经验构建，而不是凭规格说明构建的工程师。

是一种纠偏，而非一种潮流

长期以来，软件行业一直在为规模化构建进行优化，同时把部署的复杂性推给客户，并让工程与其本应解决的业务问题脱节。当时的主流模式很简单：把东西扔过墙去，让客户自己想办法，再雇系统集成商来收拾烂摊子。

在软件简单、客户有耐心的时代，这种模式行得通，但如今这两点都不复存在了。

现在胜出的公司，是那些掌控构建与部署完整闭环的公司。他们不会把工作甩给系统集成商，也不会把实施失败归咎于客户。他们派工程师深入现场，对成果负责，而不仅仅是对产出负责。

Palantir 二十年前就想明白了这一点，并因此饱受批评。批评之声从未停歇：“这不可扩展。”“这不过是咨询顾问。”“这不是一家真正的软件公司。”如今，所有人都在试图复制这一模式。

问题在于，你无法靠招人来打造一个 FDE 组织。

打造 Frontline：将其规模化的计划

要真正理解 FDE，你需要了解 Frontline。

当时，Palantir 有两个互不了解的组织。产品开发部（PD）负责构建软件，而业务开发部（BD，其中包括前沿部署工程师）负责把软件推向客户。这两个团队在文化和运营上彼此割裂，而这种割裂正在造成实实在在的损害。

PD 认为 BD 缺乏技术严谨性。BD 认为 PD 缺乏紧迫感。部署产品非常痛苦，有时需要数天甚至数周。一线的工程师被各种总部工程师从未见过的问题淹没，而总部的工程师却在开发解决错误问题的功能，因为他们从未体会过使用他们软件的人的痛苦。

理解一个人最好的方式是设身处地。我们决定把这句话变成现实。

Project Frontline 正是源于这一洞察。软件工程师在正式开始产品开发工作之前，会先到一线进行一轮前沿部署轮岗。他们会看到软件实际是如何被使用的，体会部署的痛苦，切身感受我们构建的产品与客户需求之间的差距。然后他们会回来，以不同的方式构建产品。

我有机会与 Palantir 的高级领导层一起领导 Frontline 项目：Matt Steckman、John Garrod、Bill Ward、Lynne Lu 和 Randy Shultz。Palantir 现任首席技术官 Shyam Sankar 也直接参与其中，在我们摸索哪些做法有效、哪些无效时，他会参加我们的进展汇报会议。这不是一个附带项目，而是一项战略优先事项。

我们很快意识到，仅仅把工程师扔到一线是不够的。他们需要支持和结构。每位 Frontline 轮岗者都会有一位经历过这一过程的导师，指导他们完成从构建软件到部署软件的转变所带来的迷茫。还有负责人会经常跟进，不仅是为了追踪进度，更是为了尽早发现问题。我们在整个轮岗过程中建立了反馈机制，这样当有人遇到困难时，我们能及早发现；当某些做法行不通时，我们能迅速听到反馈。

我们在过程中也犯了错误。六个月的轮岗周期本应只是一个指导性安排，但资源压力有时会把轮岗拉长到一年，工程师们会感到被困住。现有的 FDE 与轮岗者之间存在摩擦，还有文化冲突和工作风格的差异。

我们还发现了一个关键问题：轮岗往往与工程师最终要构建的产品没有关联。有人会花六个月部署一个自己再也不会接触的软件。他们学到了宝贵的东西，但这种关联是抽象的。于是我们开始让轮岗与未来的产品工作对齐。如果有人要构建管道监控工具，我们就把他们派到管道监控是痛点的部署现场。

他们先成为用户，再成为构建者。

这带来了变革性的效果。当工程师亲身体验了自己日后要解决的问题的痛苦时，某种东西被点燃了。他们带着情感和热情去构建，深刻理解用户真正的需求。你能从产品中感受到这一点。这些软件不仅在技术上出色，更是由那些在乎的人、那些亲身经历过的人、那些真正理解的人设计出来的。

随着时间推移，这个项目不断扩展。超过 250 名工程师在 Frontline 轮岗，它不再是一项实验，而是成为了工作的常态。

证明在于那些经历过这个项目的人后来的发展。Frontline 的毕业生如今在 OpenAI、xAI、Helsing、Anduril、Hex 以及数十家其他公司从事重要的事业。曾共同领导 Frontline 的 Bill Ward 创办了 Northslope Technologies，提供 FDE 即服务。Jesse Rickard 创办了 Fourth Age，做着类似的事情。我们构建的模式如今正在整个行业被复制。

什么样的人能在这方面出类拔萃

我观察过数百名工程师经历 FDE 的磨砺。有些人变得出类拔萃，有些人则被淘汰。以下是优秀者与常人的区别。

优秀的 FDE 对客户的世界有着不懈的好奇心。 良好的 FDE 解决交给他们的问题，但优秀的 FDE 对客户的业务理解足够深入，能够发现客户已经放弃或尚未明确表达的问题。换句话说，正如我上面所说，他们在成为建设者之前先成为用户。有一次我在客户现场待了一周，注意到每天早上，一位分析师都要花 45 分钟从三个不同的系统手动下载数据并在 Excel 中合并，然后才能开始她的实际工作。她这样做已经两年了，从未想过问是否可以自动化。她只是把它当作工作的一部分接受了。一个良好的 FDE 会构建她所要求的东西。而我构建了一条自动完成她早晨例程的流水线，在她到达时已经放在她的收件箱里。这就是区别。

优秀的 FDE 会根据情况调整自己的工程方式。 他们知道什么时候该构建一个健壮的系统，什么时候该写一个能用的脚本。这里有一个失败的故事：在我 FDE 职业生涯早期，一位客户要求提供一种记录去重的方法。我花了两个星期构建了一个优雅的、可配置的去重引擎，带有模糊匹配、置信度评分和审核界面。而他们实际需要的只是一条运行一次的 SQL 查询，用于清理一次特定的数据导入。他们再也没有用过那个引擎。我过度设计了 10 倍。相反的失败同样令人痛苦：我曾经草草拼凑了一个“临时”数据删除脚本，结果它在生产环境中运行了十八个月（vinoo.groovy，我的许多 Palantir 老同事至今仍这样称呼我）。

优秀的 FDE 能面向不同受众进行沟通。 他们既能向不关心细节的高管解释复杂系统，也能与需要确切了解系统如何运作的技术同行深入探讨。有一次会议上，我需要解释为什么一次数据迁移需要三个月而不是三周。我对 CTO 说：“这些数据积累了 15 年的边缘案例，如果不谨慎处理，会破坏下游报表。仓促行事会危及季度董事会报告。”我对工程负责人说：“12 张表中共有 847 个列，存在未记录的相互依赖关系，而且现有 ETL 中有隐式类型转换，我们必须保留它们，否则会出现静默的数据损坏。”同一个问题，不同的语言。

优秀的 FDE 在系统出问题时保持冷静。 而问题总会出现。我记得有一次部署中，客户的 CEO 正在向他们的董事会演示我们的产品，结果产品崩溃了。我的电话响了。我没有慌乱，而是引导客户的 IT 人员重启了服务（我知道这会奏效，因为那周早些时候我已经诊断出了根本原因），四分钟后演示恢复运行。CEO 从始至终都不知道电话那头有位工程师。你如何应对危机，和你能否修复问题同样重要。

优秀的 FDE 在没有职权的情况下对结果负责。 这是最难掌握的技能。有一次，我需要某个产品团队优先修复一个阻碍大客户的 bug。我对那个团队没有任何职权。没有效果的说法是：“能不能请你们优先处理这个 bug？”有效的说法是：“这位客户每年贡献 400 万美元收入，六周后就要续约。他们已经告诉他们的高管支持者，这个 bug 是他们最大的抱怨。如果我们不修复它，就有失去续约的风险，如果有帮助的话，我可以安排你与客户通话，直接听取他们的意见。”两天内我就拿到了修复。

优秀的 FDE 知道何时该提出异议。 他们不会客户要什么就做什么。有一次，一位客户要求我们开发一个需要占用三个月工程时间的定制功能。我没有直接答应或拒绝，而是花了两天时间弄清楚他们为什么想要它。结果发现，他们想解决的问题其实通过我们现有产品的一次配置更改就能解决。我向他们演示了如何操作，他们对这个方案比定制功能更加满意。提出异议不是说不，而是理解真正的需求并找到正确的解决方案。

Palantir 新加坡 FDE 团队正在排查一次服务中断（照片由 Satej Soman 提供）

为什么你可能不想要这份工作

我在这篇文章中一直在解释 FDE 为什么有价值。现在让我告诉你，它为什么可能不适合你。

如果你需要深度专注的时间，这条路不适合你。FDE 的工作是由打断驱动的，客户随时可能出现紧急情况，部署也会遇到意想不到的问题。你的日程表会像我上面描述的那一周一样：混乱、碎片化、不断变化。

如果模糊性会让你瘫痪，请远离。FDE 时刻都在信息不完整的情况下工作。需求不清晰，优先级不断变化，你必须在不知道决定是否正确的情况下做出决策。

如果你想在某个技术专业领域深耕，请另寻他路。FDE 出于 necessity 必须是通才。你会学到很多方面的很多东西，但不会成为其中任何一个领域的世界级专家。如果你的目标是成为分布式系统或机器学习领域世界顶尖的人，纯产品工程是更好的路径。

如果你把客户的挫折感当成针对自己，你会精疲力竭。客户会感到沮丧，并把不是你的错的事情归咎于你。

如果你不能设定边界，你会把自己累死。FDE 的工作会膨胀到填满所有可用时间。我见过有才华的人因为不会说“不”而精疲力竭。

这些不是缺点；只是让 FDE 不适合他们的特质。对于具备这些特质的人来说，还有很多优秀的工程岗位。

正在招聘？我们很乐意向你介绍优秀的候选人。邮箱：hi@nextplay.so。

行动手册

自己制造一线接触机会

阅读本文的大多数人所在的公司并没有 Frontline 项目。没有人会把这种经历送到你手上，所以你必须自己创造。以下是具体做法。

第 1-2 周：参加客户通话。 今天就给你的 PM 或客户成功负责人发邮件，内容就用这段原话：“我想更好地了解我们的客户，以便构建更健壮的功能。接下来几周我能旁听 2-3 次客户通话吗？我会静音，只是观察。”几乎没有人会拒绝。在通话中，不要记录功能需求。要记录这些事情：这个人的一天是什么样的？通话前他们在做什么？通话后会做什么？他们似乎对什么感到沮丧，却没有明确抱怨？他们在使用哪些变通方法？

第 3-4 周：跟随支持或实施团队。 找到公司里负责客户升级问题处理或实施的人。请求跟随他们三天。如果你是远程办公，请求被加入他们的 Slack 频道，并在问题出现时和他们一起开视频通话。观察问题是如何被诊断的。注意客户说的问题和实际存在的问题之间的差距。留意产品的哪些部分最容易让人困惑。

第 2 个月：接手一次升级处理。 当客户问题出现时，主动请缨端到端地负责它。不只是修复 bug，还要与客户沟通、了解影响、通报时间线、部署修复方案，并确认问题已解决。这是完整的闭环。这会让人不自在，但你会从这一次经历中学到比几个月常规开发工作更多的东西。

第 3 个月：拜访客户现场（或进行深度远程会议）。 如果你的公司有可以拜访的客户，主动申请参加现场拜访。如果没有，询问能否与客户进行一次 2 小时的屏幕共享会议，观察他们如何用产品完成实际工作——不是演示，不是培训，而是他们真实的工作。在观察过程中，找出一个你能在一天内修复的小痛点。然后在本周结束前修复并上线，并告诉客户你做到了。这比任何其他方式都更能建立信任和好感。

第 4-6 个月：建立你的反馈闭环。 到这时你应该有足够的背景信息来发现规律了。创建一份简单的文档，标题为“我从客户那里学到的东西”，并每周更新。与你的产品团队分享。包含具体的引述、具体的工作流程、具体的痛点。这份文档会让你变得不可或缺，也会为你日后参加 FDE 面试做好准备——届时你需要展现对客户的同理心。

培养六项特质

好奇心本质上关乎同理心。当你强迫自己走出代码库、进入客户环境时，它就会得到培养。下次参加客户电话会议或现场拜访时，不要只听功能需求。试着理解客户的一天：他们在打开你的软件之前在做什么，之后又在做什么？还有哪三件与你的产品无关、却让他们夜不能寐的事情？

校准感来自双向的犯错。你需要两方面的伤疤。刻意变换你的方法：在下一个项目中，尝试用最简单的方案解决问题；再下一个项目中，尝试把它构建得规范完善。留意当前的情况实际上需要哪种方法。

沟通是需要锻炼的肌肉。把它想象成传话游戏：每经过一个人，信息就会失真。FDE 的作用就是短路这条链条。练习为非技术利益相关者撰写一页纸的技术项目摘要。如果你不能用一页纸、不带行话地解释你构建了什么以及它为什么重要，那说明你理解得还不够透彻。

保持冷静靠的是准备和重复，而不是性格。主动把自己置于高压情境中：主动加入值班轮换、接手升级处理、在生产环境宕机时加入作战室。到第十次时，你脑海中就会有一套应对手册。

在没有职权的情况下对结果负责，这种能力是在你把自己置于需要向不向你汇报的人寻求帮助的情境中培养出来的。学会提出请求时解释“为什么”，而不仅仅是“做什么”。

有效地说不依赖于可信度。把可信度想象成可以花费或失去的积分。早期要谨慎选择 battles。关键在于，每次提出反对意见时都要附带替代方案，而不只是说“不行”。

你在技术上真正应该掌握的东西

FDE 是通才，但这并不意味着你可以在所有方面都浅尝辄止。以下是你需要的具体技术知识。

XY 问题。 客户会向你索要 Y，而他们真正需要的是解决 X 的方案。练习方法：在急于给出解决方案之前，先问“你想达成什么目标？”

SQL。 JOIN、带 HAVING 的 GROUP BY、窗口函数、CTE、子查询。目标：不借助 Google 就能写出“找出每个类别中第二高值”的查询。数据是客观的，数据分析是你的命脉。

命令行和 Linux。 文件系统导航、读取日志（grep、awk、tail -f）、理解进程（ps、top、kill）、基础网络（curl、netstat、ping、traceroute）。知道“out of inodes”是什么意思。资源：OverTheWire Bandit。

容器。 Docker 是做什么的、容器与虚拟机的区别、日志存放在哪里。从高层次理解 Kubernetes 是做什么的。资源：Docker 入门指南。

网络。 DNS、HTTP 状态码、TLS/SSL 基础、能 ping 通但无法连接时的调试。资源：Julia Evans 的 zines。

Python 脚本。 读取 CSV、转换数据、写入某处。调用 API、处理分页。连接数据库。要快。资源：《Automate the Boring Stuff with Python》。

数据质量。 时区不匹配、编码问题、意外的空值会发生什么。我讲过的 Cassandra 的故事？那就是一个数据质量问题。

求职：面试官实际会问什么

FDE 面试非常侧重行为问题，因为这份工作考验的是判断力，而不仅仅是技术能力。

“讲一次你不得不与难缠客户打交道的经历。” 差的回答：“客户不讲理，但我保持冷静，最终他们改变了态度。”好的回答：“客户很沮丧，因为我们的产品弄丢了他们的数据。他们很生气，说实话，他们有理由生气。我首先承认是我们搞砸了，而不是找借口。然后我详细解释了发生了什么、我们正在如何恢复数据，以及我们正在采取哪些措施确保这种情况不再发生。我还把我的手机号码给了他们，告诉他们如果再出任何问题可以直接打给我。这花了两个星期，但最终他们续签了合同。”

“讲一次你与客户请求意见不一致的经历。” 差的回答：“客户想要一个不合理的东西，所以我解释了为什么他们错了。” 好的回答：“客户想让我们定制一个仪表盘，那需要占用一个月的工程时间。我没有直接拒绝，而是请他们详细说明具体会怎么使用它。结果发现他们其实只是需要为每周例会回答一个特定问题。我向他们展示了如何用我们现有产品加一个 10 分钟的 SQL 查询来得到答案。他们反而对这个方案更满意，因为当天就能拿到结果，而不用等一个月。”

“讲一次生产环境出故障的经历。” 差的回答：“我们的服务宕机了，我把它修好了。” 好的回答：“我值班时，主 API 开始返回 500 错误。首先，我查看监控以了解影响范围：30% 的请求受影响，不是全部。这说明问题很可能不是新代码引起的。错误日志显示数据库连接超时。数据库 CPU 占用率达到 100%。慢查询日志显示，当天早上上线的一个功能对 5000 万行数据做了全表扫描。我禁用了该功能，恢复了 API，然后和团队一起添加了索引。整个过程花了 45 分钟。第二天我们为大表查询实施了查询评审机制。”

技术问题侧重于调试和实际编码：

• “你会如何调试一个响应缓慢的 API 端点？”（按步骤讲解：监控、日志、性能分析、数据库查询、外部依赖）
• “写一个脚本来处理这些数据。”（脏数据问题。处理边界情况。用 Python。）
• “假设我不懂技术，向我解释 X。”（DNS、数据库索引、限流。不要用行话。）

你的前 90 天

第 1-30 天：学习。 吸收背景信息。认识每个人。阅读所有文档。旁听每一通电话。建立一份术语表。每天写下你学到的三件事。先别急着创造价值。最常见的失败模式是工程师还没了解环境就带着满腔观点冲进来。

第 31-60 天：找到你的第一个胜利。 一件你能完全负责的小事。一个自动化手工工作的脚本。一个一直困扰客户的 bug 修复。一个取代电子表格的仪表盘。要有清晰的前后对比。交付它。告诉别人。

第 61-90 天：开始形成自己的观点。 现在你有了背景信息和可信度。去接触更难的问题。提出解决方案。保持谦逊——三个月过去，你仍然是新手。但你是带着背景信息的新手。

需要避免的陷阱：

• 过度设计。我曾见过一位新入职的 FDE 花了三周时间，为一个只需要 bash 脚本就能解决的问题构建“健壮、可扩展”的方案。而客户只关心周五之前拿到答案。
• 退缩到代码里。当会议气氛紧张时，你的本能是躲到笔记本电脑后面。别这样。保持专注在场。
• 过度承诺。少承诺，多兑现。周二完成却说“周三交付”，胜过周三完成却说“周一交付”。
• 解决错误的问题。“你想达成什么目标？”是 FDE 工具箱中最重要的问题。

职业发展路径

第一年：学习。 吸收背景知识，建立人际关系，培养判断力。处理单个客户的问题。成功的标志：客户信任你，团队依赖你提供洞察，你交付的东西产生了真正的影响。

第二至三年：领导。 负责更大的客户关系或带领小团队。做出优先级决策。指导新晋 FDE。成功的标志：扭转了陷入困境的客户关系，影响了产品路线图，人们在不知所措时会来找你。

第四年及以后：放大影响力。 走深度路线（领域专家）或走广度路线（领导 FDE 组织、产品领导岗位、创业）。许多 FDE 成为创始人，因为他们兼具技术能力和客户理解力。其他人成为产品领导者。有些人留任资深 FDE，处理最复杂的部署。

前沿部署工程的校友已成为 AI 公司的创始人、上市公司的产品负责人以及国防承包商的工程领导者。FDE 的技能组合在几乎所有技术领导岗位上都稀缺而宝贵。

资源

正在招聘 FDE 的公司： Palantir、Anduril、OpenAI、Anthropic、Scale AI、Helsing、Hex、Databricks、Weights & Biases

与 FDE 相关的领域： FDE 即服务公司、国防科技初创公司、需要复杂部署的垂直 SaaS、拥有企业客户的 AI 公司

推荐阅读：

• Palantir 的 S-1 招股书（部署方法论部分）
• Shyam Sankar 的博客 - https://www.shyamsankar.com/
• Rob Fitzpatrick 所著《The Mom Test》- https://www.momtestbook.com/
• Julia Evans 的博客和 zine - https://jvns.ca/

前进之路

那件灰色运动外套只是一个象征。它所代表的东西更为深刻：当你不再闭门造车地开发软件，而是开始为真实世界中有真实问题的人们构建软件时，所发生的那种转变。

无论你是否在 Palantir 工作，这种转变对你都是可以实现的。它要求你深入一线，感受部署的痛苦，理解客户真正的需求。它要求你经历某种能改变你的事情。

一线才是真正的教育发生的地方。其他一切都只是准备。