Consider applying for YC's Winter 2027 batch! Applications are open till November 2.Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact
Hacker Newsnew | past | comments | ask | show | jobs | submit login
什么是前沿部署工程师？为什么他们如此抢手？(2025) (pragmaticengineer.com)
106 points by saisrirampur 3 months ago | hide | past | favorite | 98 comments
我记得当年去 Palantir 面试的时候，正是他们把这个职位捧红的时候（大概十年前）。我想应聘的是 SDE，但招聘人员一直劝我去他们的“前沿部署工程师”岗位。听完他们的介绍后，我心想……哦，所以你是想让我当销售顾问？他们对此反应不太好，我猜是因为 Palantir 当时正竭力向世界证明自己是一家科技独角兽，而不是一家包装光鲜的咨询公司。
FDE 其实是两个现有职位的合体：解决方案架构师和工程师。在过去，销售会在技术销售人员和解决方案架构师的协助下拿下客户，解决方案架构师会为解决方案制定一份高层次的规格说明。这份规格说明会在售后阶段细化完善，然后交给工程师去开发。如今，FDE 往往身兼两职。Palantir 与纯咨询公司的区别在于，Palantir 拥有一个核心软件平台，并针对每个客户进行定制。其商业模式更类似于 IBM 或 SAP 的产品。
这是*理想中*的区别。和所有这些新术语一样，它很快就被挪用了，结果大多数使用这个头衔的公司对待它的方式与旧头衔并无二致。
是啊，我读着读着就纳闷，这到底有什么新鲜的。科技公司不是一直都有这个角色吗？我想，前沿部署工程师听起来更像一个工程岗位，而销售顾问听起来则像是你是销售员而不是工程师，所以在我看来这多半是为了让这个职位对工程师更有吸引力的公关手段。这招在我身上确实奏效了，因为我喜欢和利益相关方交流并找出我能解决的问题，而我不喜欢销售。我更愿意以前沿部署工程师的身份去应聘。
我认为 FDE 是售后环节的角色。基本上就是销售已经完成，而作为客户的公司没有足够的专业能力来用好所购买的东西。
如果你是销售，你能拿到（希望是丰厚的）销售提成。如果你是前沿部署，那你就会被“部署”到前线（远离舒适的总部办公室）。
这是奥威尔式的说法，意思是……你的薪酬不会和我们基础工程师一样，而且当我们想摆脱你的时候，我们就把你派到我们的西伯利亚客户那里，因为你是前沿部署工程师，哈哈。不过我还是愿意相信我错了，这是一份好工作。
这是一份薪水不错的工作，但对你的未来职业发展来说可能是毒药，就像 SRE 或 QA 岗位一样，因为你从此被定型了。
这个职位以前叫“售前工程师”，但 Palantir 想要一个听起来更有军事色彩的名字。可惜其他公司也捡起了这个恶心的叫法并开始使用。
售前工程师负责售前工作，而 FDE 既负责售前也负责售后。FDE 在客户实施过程中的参与度也高得多，通常实际干活的就是他们，尤其是在政府官僚机构或僵化的大公司里，因为那里根本没人知道怎么把事情办成。
售前工程师也做售后工作。通常，如果他们要做大量实际工作，那就会被直接称为“顾问”。
“以前”？你是说“售前工程师”这个称呼已经不存在了吗？
他们以前叫“售前工程师”。现在仍然叫，但他们以前确实也这么叫过。
Palantir 以前是这么叫的，现在不这么叫了。
我知道我的看法与主流相悖，但我认为这个职位真的很酷。被自己的公司授权披上专家的外衣，又被客户期待提供能让团队“脱困”的建议，前沿部署工程师正处在证明自己有多大本事的绝佳位置。尤其是在国防这类领域，客户方都是极度规避风险的团队。这是少数几个让我有点羡慕的职业之一，尽管其职业倦怠率可能相当高。
我同意这个理念很酷，但据我从大多数公司担任该职位的人那里听到的，这基本上就是换个名字的解决方案架构师角色。有趣的是，Pragmatic Engineer（所链接文章的作者）在上述文章发布约一年后写了一篇后续，他报告的情况也是如此。 https://blog.pragmaticengineer.com/the-pulse-forward-deploye...
看了前沿部署工程师的官方职位描述，我甚至不确定它与解决方案架构师在名义上到底有什么区别。一个典型的 FDE 和一个典型的 SA 之间的名义差异，会比 SA 角色在不同公司之间的差异更大吗？
所需的技能组合不同。在我工作过的地方，SA 基本上都是纯粹的销售人员。他们必要时可以顶替 AE 的工作，会使用 Salesforce，懂得如何判断客户账户的状态等等。他们在技术上相对有限，因此通常被部署去销售已经“完成”的产品，大部分时间是把客户映射到已知的、行之有效的模式上，并识别这些模式。FDE 则不同，他们被部署去销售和集成某种意义上尚未完成的产品。例如，Palantir 销售的是一种相当底层的通用产品，需要定制化的技术工作才能与客户完成集成。这种集成工作更接近普通的工程工作，可能需要编写大量代码，也需要技术上的创造力。FDE 如今日益流行的原因在于，AI 公司尚未找到一种能够在众多客户之间通用的高层产品形态，因为市场还不成熟，客户可能也不知道自己想要什么。因此，需要大量的工程工作，把一个较为底层的产品（例如某种 AI Agent）拿过来，研究如何用它为某个特定客户创造价值。
根据我最初听到的描述来看，是的，我认为是这样。在我工作过的大多数地方，SA（解决方案架构师）通常只是把系统中现有的组件连接起来以满足客户需求。他们可能会写代码，但往往只是用来连接系统中两个部分的胶水代码，或者转换一些数据之类的。他们并不真正为底层产品做贡献，只是使用产品加上一些定制代码来满足特定客户的需求。而 FDE 应该更接近产品或平台团队的普通软件工程师，他们的目标是解决特定客户的问题，但应该更注重大局，并利用他们的经验积累来打造更好的产品。他们同样使用现有系统解决问题、写大量胶水代码，但他们还应该有空间为底层产品做贡献，让它对所有客户都更好。我能想到的最简单的例子是：客户说他们需要一种方法，把自己的大量数据转换成 CSV，然后每周五发送到某个指定的电子邮箱。比较传统的 SA 思维方式可能是写一个 Python 脚本，用 cron 定时运行，连接客户的数据库拉取数据，转换成 CSV，然后发到那个指定的邮箱。即使 SA 明知这不是最佳做法，这也是他们手头被给定的工具。而 FDE 应该有空间和能力去找 PM 和他们的工程团队沟通，直接在产品内构建一个自助式工具来完成这件事（前提是大家都认同这对产品有利）。不过再说一次，据我所知，大多数公司的大多数 FDE 其实只是换了个名字的 SA。
我认为是的。我在一家（相对）较小的公司工作。我自然地从项目工程师成长为高级工程师/负责人/领域专家（包括为我的行业开创技术），再到 SA。我还在公司待了很多年，所以我积累了行业人脉，并被视为重量级人物。与客户的信任关系加上技术能力 = 销售和咨询。同样，由于公司规模的原因，我可以让我的角色保持流动性（而且是好的那种流动性），但随你怎么称呼，我既做工程，也做销售，还做咨询。
它就是 SA，只不过太多地方开始把 SA 用作销售岗位，所以现在我们有了 FDE 这个角色……而它也开始被销售污染了。
看起来答案是否定的。在公司之间该角色的普通差异范围内，它们是一样的。
如果你听麦肯锡（McKinsey）推销顾问这份工作，它听起来也会像是世界上最酷的工作。
我在 33 岁左右基本就是这样干了几年。我是一家数十亿美元“数字化转型”项目中薪资最高的 IC（独立贡献者）。我用 5 种以上的语言写代码，做硬件改造，拥有所有系统的读写权限，为了自己的“臭鼬工厂”项目爬梯子部署硬件。整个经历太疯狂了，真的是匪夷所思。回看那段时期的工作产出，连我自己都震惊。我非常享受那段时光。坚持绝不管理任何人的立场也让我远离了政治漩涡。我喝酒，但我懂行。我可能拥有比任何人在同规模公司里都更大的自由度和权限——他们甚至出钱让我获得了一定程度的 DHS（国土安全部）许可，可以在护照管控区不受限制地活动，简直离谱。公司设这种岗位到底好不好？我不知道。在创办过几家公司、也在大公司工作过之后，那是我觉得最有趣的一段经历。推动实质进展，把烂摊子理顺，降低复杂度，在以前毫无问责的地方建立问责。我离开是因为他们想让我搬过去。我每周一飞过去、每周五飞回来，但我不想换城市，而且我有一个想启动的创业项目。我花了 3 个月旅行，然后花 2 个月为我的第四家创业公司写代码。几乎不存在什么普适规则，我的工作为他们省下了天文数字般的成本，还创造了更多收益，但这些方法之所以有意义，只是因为要把他们从自己造成的、完全无人问责的僵局中解救出来。如果你小时候读过詹姆斯·邦德的小说，里面有一段内心独白解释他为什么如此高调——他的整个行事方式就是让自己显眼，在不透明的局面中搅动出变化。当你的工作开始让人们对结果负责时，你必须做到无懈可击，而且在积累起足够的业绩记录之前，这会在你背上画出一个靶子。这段经历让我更了解自己，最终，全身心投入这个角色并沉浸其中的过程，帮助我弄清了自己真正看重什么。
如果我竭尽全力做到这一点，我会想当老板，而不是当冤大头。真正的问题是：他们究竟如何奖励在这个角色中表现出色的人？他们真的能识别谁在创造价值，还是只看投机取巧的指标和出身背景？这些对期望值（EV）计算至关重要。
作为一个自封的“黑客游客”，我获得了一种信任和尊重——在那些很少见到外来者的文化里，人们相信我不会把自己或同事搞砸。有几次，如果情况没有改变，我在入职第一个月内就威胁要辞职；有一次我走进门，转身就走了出去。还有一次我自己掏钱买机票去面试，之后两个月没回家探亲（在那儿工作了六个月）。薪水还行，但不算出色。每段工作时长在三到九个月之间。（我从 1984 年起就是持照经营的独立从业者。）
这份工作确实是通往产品管理的跳板——而且它是会随大语言模型一起真正成长的角色。一个能使用 Fable 的迷你产品经理可以解决大量客户需求。编辑：看到这条评论被踩我并不意外；我理解 HN 上很多人并不真正理解产品管理，或者不重视它。从工程走向产品管理的路径，确实可以从更贴近客户开始——花更多时间去理解他们的需求。这一点在大语言模型时代发生很大变化的原因是，售前工程师/前沿部署工程师用 Claude Code 解决客户需求的速度远超他们自己动手，这意味着这些反馈循环可以成为客户实验与理解的速成课。Teresa Torres 写了一本关于持续探索的精彩著作，我在团队中使用它（https://www.producttalk.org/continuous-discovery-habits/），书中三分之一的内容讲的是尽可能每周与客户交流。一个既面向客户又能写代码的人，相比从学术背景进入产品领域的人，拥有巨大优势。MBA 的案例研究对战略很有帮助，但它们通常是固定时间点的内容。获得那种敏捷的反馈来打磨你的产品直觉，才是变强的最难之处。
到那时，如果产品经理只是在做定制化的东西，那 PM（甚至整个咨询公司）的附加价值是什么？客户自己用 Fable 能解决其中多少需求？或者供应商的支持人员不用上报给 PM 就能解决？在这种公司里——没有宏大的统一愿景，只是响应客户请求——PM 几乎就是一个纯文书工作的角色，当你可以让大语言模型总结所有这些沟通和“分析”时，这个角色看起来就没那么必要了。
我编辑了评论以便更清楚地表达我的观点，因为我觉得很多人不知道 PM 是做什么的。如果你的 PM 没有在制定清晰的战略，那你的 PM 可能经验不足和/或负荷过重。听起来你可能有过这样的经历。我认为一个优秀的 PM 需要三大技能：客户探索、战略规划和团队对齐。后两者更容易通过学术途径学习，而这类角色正是学习第一项技能的理想环境。
在这种情况下，PM 的职责是基于从客户那里收集的信息，提炼出某种可跨客户推广的高层次战略，其中包括功能需求，但远不止于此。
优秀的 PM 不仅仅是个人贡献者，他们还是与之合作的工程师的力量倍增器。
如果 Fable 能解决客户的需求，那为什么还需要 PM？
你觉得 PM 是做什么的？
你觉得工程师是做什么的？
你问了为什么需要 PM。我想先了解你认为 PM 是做什么的，这样才能帮你回答这个问题。
有迫切需求，比如用 AI 回答 HN 上的问题来给自己做宣传。
我发表的任何评论都不使用 AI。
LLM 和这个其实没什么关系，只是 LLM 对几乎所有（技术）岗位都有用而已。
你为什么这么说？
好吧，先坦白说明：我在一家数据库公司领导一个前沿部署工程师团队。这个岗位通常意味着我们的工程师会长期驻扎在客户现场，他们的工作基本上是 DevOps、软件工程，再加上一些比较传统的解决方案架构工作，也就是这篇文章所描述的内容。他们使用 LLM 的方式和普通工程师差不多。这是一个工程岗位，而不是产品/项目管理岗位。我不认为这个岗位有什么特别之处，会被以不同于其他工程岗位的方式彻底改变。归根结底，他们的价值在于他们既嵌入在客户内部，也嵌入在我们公司内部，是我们在客户那里的耳目。他们的目的不是做销售演示，而是让我们的软件真正满足客户的需求、正常运转。
好的，我们的理解一致。我想说的是，让 FDE 能够使用强大的前沿模型来大幅修改代码以满足客户需求，会让他们的工作重心从工程转向客户探索和策略，大大改变他们时间分配的比例。这会让反馈循环更紧密，让他们能更快地进行实验。
我不明白你为什么被踩。在东亚，“SI（系统集成）”常被人瞧不起，但 SI 经常被提到的一个优势就是理解客户的业务，也就是领域知识。诚然，在一个以跳槽和职业积累为基础的行业里，SI 受到很多批评。但从创业公司的角度来看，它往往被正面评价为具有强大的业务洞察力。所以我认为你的观点是成立的。事实上，从我在 HN 上观察到的情况来看，大多数人似乎执着于“编程纯粹性”，而不是“产品周期”。当你做以产品为中心或以交付为导向的开发时，不可避免地会有你不理解的黑盒、你无法控制的环节，而且产品管理的核心不是“完美”，而是能否从客户那里快速获得反馈并迭代。但在论坛上，大多数人似乎默认一切都应该理想地完美。我同意你的观点。因为如果你真正深入一线而不是只跟服务打交道，你就能清楚地看到领域建模实际上是多么不完美。如果业务足够大，你可以用资本力量重塑领域来适配你的服务，但正如你所知，大多数时候到了现场，你面对的是不完美的领域、大多数客户其实并不清楚自己的需求，以及实现能力之间的冲突。实际上，我觉得你的帖子层次更高。别太在意那些踩。
我想大家踩我是因为某些 LLM 训练数据喜欢我的风格吧。;) 谢谢！确实层次更高。我现在完全不担心产品管理这个职业了，因为软件工程师要把自己的思维提升到业务层面，会比产品经理用 LLM 构建高质量软件难得多。
什么是 mini-PM？是 Apple 提供的什么职位吗？
在半导体行业，这个职位叫做现场应用工程师（Field Application Engineer）。他们做的是实实在在的工作，而不只是做幻灯片，因为你的芯片出厂时附带的驱动程序，往往是在你还没能从客户工程师那里获得足够时间之前（这通常只有在量产之后才会发生，但你需要软件在量产之前就证明芯片能正常工作）几个月甚至几年前就设计好的。所以正是这些人负责适配工作，他们的反馈很有价值，因为他们是真正建立对客户理解的人。不过，在我以前的公司，他们并没有主软件仓库的提交权限。他们不得不随身带着一堆补丁，这些补丁再被逐步清理和整合。由于我没有直接和他们共事，我不知道这更多是反映了他们的问题，还是管理内部开发的人的问题。这个职位适合与典型软件工程师不同性格的人。如果你作为开发者感到无聊，它可能适合你。不过，把不适合的人硬塞进这个职位是毫无意义的。
我的理解是，Palantir 使用了这个术语，并把由前沿部署工程师组成的团队称为"Delta Force"，是为了让这种以咨询和服务为主的软件采用周期对美国军方客户来说更容易理解。
不是。他们用音标字母来区分商务拓展（BD）团队中的多种不同专业方向，包括 alpha、bravo、delta 和 echo。我在 2008 到 2016 年在那里工作的 8 年里，从没听过"Delta Force"这个说法。
这是有用的背景信息，但既然你说"delta"在十多年前就在使用，而且你在此之后没有第一手了解，那么如此笃定地断言人们后来没有开始口语化地加上"force"一词，似乎至少有点武断。
是啊，我的错。"force"那部分可能是我记错了。不过我正在读 Karp 的授权传记《The Philosopher in the Valley》，里面确实提到这些名称的选择是为了让军方容易理解，大概是这样的意思。
在东亚，有一种叫"SI"（系统集成）的岗位，但很少被认可为正经的职业经历。在西方似乎不是这样。这个岗位难以获得职业认可的原因是，每家公司使用的技术栈都不同，所以你需要了解很多不同的技术，却很难在任何一项上深入。而那些公司专有的技术在换工作时也帮不上忙，所以你实际上被当作最底层的员工。这也是我的谋生方式。事实上，大多数硬件制造商出于"稳定性"的原因固守老旧技术，但那种经验也很少被认可为有价值的职业资本。
我做过一些我认为属于这类工作的事情，在客户现场做本地化部署。当我看到那些 FDE 职位居然全都要求在旧金山坐班时，我觉得很好笑。在我看来，"前沿部署"的全部意义就在于真的被部署到前线。
如果公司既不给你配防弹衣，也不给你买绑架赎金保险，那 FDE 这个称呼似乎就不太对劲。（把"工程师"这个头衔用在非注册专业工程师身上……倒是个值得辩论的话题）
客户也在旧金山吗？
我也做过这种工作，只是没有挂正式的 FDE 头衔。我从来没有那么强烈地想过一了百了。我感觉自己就像一群巨婴的家教，被困在《土拨鼠之日》式的循环里。合同结束时，我如释重负地长舒了一口气。
我想做的主要区分是：你的 FDE 塑造你的产品战略，应当被视为研发（R&D）。在确保客户部署成功之后（顺便说一句，是不惜一切代价，哪怕意味着在产品之外构建新系统），关键的下一步是在接触现实之后，与产品经理和核心软件工程师一起推动产品改进。在 SaaS 时代，这是 Palantir 提出的一个相当激进的想法。如果你只做第一步，那你基本上就只是解决方案工程师/麦肯锡；如果你只做第二步而没有从客户那里学到东西反馈到产品中，你就无法为其他所有客户改进你的平台。痛点成为护城河。这一梯队的企业给 FDE 的薪酬远高于服务型公司是有原因的，因为你是在寻找集工程+产品+面向客户于一身的人（我认识的人五年前作为应届毕业 FDE 就能拿到 20 万美元以上，而实验室里同类岗位轻松拿到 50 万美元以上）。话虽如此，这个角色这些年来已经演变了很多，取决于具体公司，它可能与解决方案工程师、售前工程师，甚至开发者关系毫无区别。
我在另一条评论里写过类似的内容。你所描述的是一份艰难的工作，需要投入和通过跨多个学科的工作客观地证明自己的能力。我把那段话复制到这里：“真正的问题是，他们究竟如何奖励在这个角色中表现出色的人，他们是否真的识别出谁在交付成果，还是只看投机取巧的指标和出身背景。”我大学毕业后在一家技术咨询公司工作过，大部分属于第一类，但我的小团队经常做第二步。然而，更大的公司层级从未对此加以推广，因为激励机制不存在。我很想做这样的工作，因为我既极客又有魅力，还有见识。了解我自己以及我会多么投入，低于 25 万美元我绝不会接受。
别忘了提一下你有多谦虚和谦逊。
谦虚和谦逊？那他们得付我 40 万美元！！
Palantir 也是那种每一次合作都多少或完全是定制化的企业。这与更典型的 SaaS 模式有很大不同——后者专注于提供一个平台，让客户用一套更通用的工具在其上构建。我很好奇这种 FDE 方向是否会导致更多的产品和平台复杂性，从而更难拆解。
在 Palantir 开创的经典 FDE 模式中，一个主要特点是你把从某个客户那里学到的经验整合回自己的内部产品中，这样以后服务类似客户时成本更低。随着 AI 编程 Agent 的出现，FDE 现在遍地开花。一是因为有了 AI，他们能做更多的事，因此可以要求更高的薪水。二是因为 AI 确实大大加速了整个定制化解决方案的实施过程。然而，据我所知，那种“把经验整合回内部平台”的事情实际上根本没有发生。所以这多少有点像一场闹剧。
大家都厌倦了给系统管理员换名字，于是转而去找一个新的职位来改名。
从实际工作内容来看，我一直算是一名前沿部署工程师，如果正确理解这个头衔，它和“黑客旅行家”这个绰号很相符。我去过 Prudhoe Bay，去过一些我不便在此点名的地方；去过工厂；去过一些本质上就是工厂、但从外表可能看不出来的地方。我做过一些奇怪的远程合同工作，比如在医院网络中搜寻医疗设备（它们有点像 SCADA，但没有 Purdue 模型）。我在客户的技术团队和供应商/服务商的技术人员之间充当桥梁……前提是供应商有技术人员。其他时候更像是寻宝游戏之类的（有时确实有真正的坏人），而我的作用是在更广泛的行业知识和现场技术团队之间架起桥梁。我不断收到湾区招聘人员关于旧金山都会区“前沿部署工程师”职位的联系。那不是实验室之一，没有机械或电气工程师，没有什么东西会逃脱、起火或爆炸，库存也没有重兵把守。这就是胡扯；是个骗局，好让你察觉不到自己被要求在加州建立税务关联。我已经厌倦了坐飞机（不过如果你真的需要我跳伞或索降进场，我虽然年纪有点大了，但我们可以谈谈），但我很乐意开车去大太平洋西北地区的任何地方（距离 Puget Sound 都会区不超过两天车程）。
我们家里也有售前工程师。
这些职位在某些地方可能被称为“现场应用工程师”。
前沿部署金融交易赋能工程师
>FDE 有时会被误认为是顾问，但顾问和 FDE 的区别在于，前者只做一次性的建议，而 FDE 通常与客户长期合作。……听起来就像顾问嘛！而且，就算“长期合作”是个重要区别，FDE 这个词本身也是不久前才流行起来的！！！ https://trends.google.com/trends/explore?date=all&geo=US&q=f... 那你怎么能断言 FDE 是与客户长期合作的
这个区别其实很大程度上取决于具体情况。FDE 在国防承包商领域早已存在，Palantir 借用了这个术语，并大幅拓宽了其含义。随后它传播到了整个软件/科技行业。在国防领域，FDE 历史上是指那些真正被前沿部署到硬件部署所在的其他国家的工程师，以便提供现场的硬件和软件支持。他们的头衔要么就叫 FDE，要么是 Engineer (forward deployed)、field engineer，或其他大致能表达这个意思的称呼。你会部署某个平台，并派去一两名工程师和几名技术人员。根据平台或部署规模的不同，这些工程师要么是普通工程师被前沿部署几个月到一年左右，要么是为该特定部署/站点专门聘请一名 FDE。据我观察，随着互联网通信的改善，可以进行实际的远程调试和实时视频会议，这种情况变得少多了，但传统意义上的 FDE 职位偶尔还是能看到。不过，后来 Palantir 和大型科技公司出现了，基本上把它变成了一个美化的顾问和/或系统集成商角色。
有趣的是，我在很多大型科技公司（包括 FAANG）工作过或与之合作过，其中一些团队里资历最深的人竟是外部顾问。
> FDE 通常与客户长期合作。在这个每个月都大规模裁员的年代，谈“长期”听起来像个残酷的笑话。
我认为主要区别在于，FDE 在项目结束后需要推动产品战略反哺平台（这不是一件简单的事）。你通常会看到 FDE 驱动型公司的产品是“组装”驱动的，并且深入到集成层面，因为他们会找出最优的基础组件，通过组装来解决新的客户问题。
> 即使“长期”是一个重要的区别，FDE 这个术语本身也是不久前才流行起来的！！！[] 那你怎么能断言 FDE 与客户长期合作呢？ 这很简单；即使这个职位两个月前才出现，你也可能已经签了一份五年的服务合同。
> 这很简单；即使这个职位两个月前才出现，你也可能已经签了一份五年的服务合同 合同是否要求在整个期间都让同一个人“前沿部署”在客户那里？如果不是，那么仅凭合同就断言我们知道他们会长期留在那里就太想当然了；如果是……那这份工作保障也太惊人了！
我一直听到的说法是“现场应用工程师”，指供应商派来集成其产品的顾问。
在汽车行业，合同要求派驻现场工程师（基本上就是 FDE）的情况并不少见。
我以前工作过的一家咨询公司开始这样称呼他们的工程师。所有工程师都这么叫。他们就是喜欢跟风。
什么都在跟风……说实话有点让人沮丧……
科技行业正在从利润率的天堂变成最糟糕的境地。资本支出超高（像制造业一样），而且每增加一个客户还需要增加人手（像咨询业一样）。
以前叫售前工程师。也叫客户工程师。也叫现场工程师。还有：解决方案架构师。换汤不换药。老轮子又开始转了。
在这个 AI 时代，我们还需要一个名为“反向稳定工程师”的新角色，其职责与 FDE 恰好相反。这个角色的核心是防御现代 AI 生成的垃圾代码更新、零停机集成、确定性自动化等等。将大语言模型与遗留系统融合将是他们的看家本领。
“客户驻场工程师”或“驻场工程师”是描述这个职位的两种有用的非军事化说法。
简单来说，这类人既精通整个产品的使用和集成，又能帮助公司的客户把产品无缝集成到他们的技术栈中。我们已经看到这种趋势的兴起，尤其是 OpenAI 的工程师在 Nvidia 园区里设办公时间等等。
这听起来像是身兼数职太多，我觉得这不是对人才的最佳使用方式。
这和 Facebook 的生产工程师职位或 Google 的 SRE 职位类似吗？
不，这就是售前工程师/现场工程师的角色，只是借用了军事术语，因为营销需要。
有一些技能重叠，但仅此而已。我非常惊讶地发现，我以为的一个站点可靠性工程师职位实际上是“前沿部署”岗位。我开始把它称为“售前补救工程”（哈哈），或者现实点说，就是别人负责谈判的咨询工作，享受更少的自由和更低的报酬，还要干更多的活。简而言之：别人想让你这么以为，但事实并非如此。我认为 FDE 对员工来说是一种倒退。重点不再是管理你自己的方向/服务，而是应付客户。
上世纪 90 年代末，我们自称“突击队”。
这和 GTM（市场推广）工程师是一回事吗？
随着构建变得越来越容易，纯软件工程师的价值在下降。我觉得在这种环境下，要想脱颖而出，要么成为专业领域的工程师，要么成为 FDE。
因为这些软件平台太烂了，你需要专门的支持人员……而且，你们裁掉了所有正式员工，就为了买得起高管们在一场荒淫无度的狂欢之夜后拍板购买的闪亮平台。
这是个付费墙文章，可见部分又臭又长，然后在讲到有意思的地方之前就撞上了订阅墙。唉。
这不过是“现场工程师”换了个更有军事色彩的名字，好吸引最糟糕的“兄弟”型人群。这个岗位自 60 年代起就在计算行业存在了，很可能更早。
简而言之：一个被美化的合同工角色，负责把雇主的 API 与企业客户做集成。喜欢和麦肯锡风格的产品经理共事，被许诺丰厚的利润率却一分都拿不到？那这工作太适合你了！
(2025)
这个头衔真让人翻白眼。除非 FDE 在核心产品团队里有真正的话语权，否则他们不过是被美化的现场工程师/技术顾问罢了。
我看到那些评论时也是这么想的，但在现场工程师和软件顾问社区，以及售前工程师社区和解决方案工程师社区里，人们对实际工作内容缺乏共鸣，因为前沿部署工程师被期望做的事情差异足够大；另一方面，招聘这类岗位的公司自己也在摸索。这个角色基本上是嵌入在销售团队“舰队”中的一名工程师，为销售增加可信度，同时也承认不再需要完整的软件工程团队，而且这些公司在客户组织中往往有一定话语权。一个专门为 AI 自动化软件服务、借助 AI 辅助的现场工程师，其工作内容可能与 FDE 完全重叠。FDE 特指这一类工作，而非其他任何软件工作，语言的存在就是为了传达共同的概念，而这个术语正好做到了这一点。
大多数公司会设立 FDE 岗位，却不理解 FDE 组织的价值——即推动产品战略并发挥研发部门的作用。
给一个毫无实际工程内容的网站起这样的名字，真是个有趣的选择。
我见过的每家公司实现的技术栈几乎一模一样，只有些许小差异。问题在于这些实现往往质量不高，而且通常落后几个月甚至几年。我已经在多个地方见过这种情况，包括几家财富 250 强公司。坦白说，这是浪费时间。构建成本高昂，后续维护成本高昂，而且往往等做完就已经过时了，因为技术早已向前发展。另外，尽管我喜欢代码，个人也更倾向于用代码构建东西，但很多内部创新之所以发生，是因为最终用户能够使用 Agent 工具。然而，从一开始看，OpenAI 和 Anthropic 的 FDE 方案似乎都严重依赖代码驱动。也许我理解有误。在我看来，更好的做法是部署一个更具可定制性、横跨不同技术栈且对用户友好的 harness。不过我这么说有失偏颇，因为这就是我们在做的事情，所以这条评论你怎么看随你。