如何成为一个优秀的FDE？

什么是FDE：企业级市场获胜的关键角色

Kevin Bai 是 Rippling 的创始 FDE——一年多前加入，是公司里第一个搭建这个职能的人；更早之前，他在 Palantir 待了好几年，而 Palantir 常被视作 FDE 的"发明者"。他有一个核心判断：FDE 是企业级市场里获胜的最佳方式。但前提是，你得先回答对两个问题。

我叫 Kevin，一年多前加入 Rippling，是第一个帮忙搭建 FDE 职能的人。在那之前，我在 Palantir 待了好几年，是 2021 年加入的——考虑到这个行业的变迁，那确实是很久以前的事了。我真心认为，FDE 是企业级市场里获胜的最佳方式。所以除了本职工作，我也会去各个会议做演讲，还会帮创始人和不同类型的公司搭建 FDE 职能。

判断前提：你真的需要FDE吗？

我总会先厘清一件事：你真的需要 FDE 职能吗？人们很容易陷入这股热潮——觉得自己要融资就得这么做，或者因为这是公认的常识、所以自己也得这么做，我认为那样想真的很蠢。我的思考框架只有两个问题：你卖给谁？你卖的是什么？

如果你卖的是非常技术、非常复杂的东西——比如 Anthropic API，或者把 GitHub 当作一款产品——它们确实很技术，但买家是软件工程师，画像就是 CIO、CTO，他们自己就能理解并上手。反过来，如果卖的是 Slack、Jira 这类产品，工具算不上多技术性，终端用户大多也没有技术背景，这样也能很好地匹配。

真正需要 FDE 的情况是：你拥有技术性很强的产品，而理想客户画像却不是技术背景。拿 Palantir 的 Foundry 来说，我们卖给世界 500 强——但它们不是科技公司，是快消、制造业、航空业。那里有巨大且棘手的问题，值得用很好的方案去解决，可坐在对面的客户，却没有一个人能把软件和他们的业务问题真正结合起来。这就是 FDE 的切入点。

在今天这个时代，生成式 AI 让构建强大方案变得比以往任何时候都容易，但"强大"同时也意味着"极其复杂"。如果你的客户来自传统行业，他们中的大多数可能根本不知道 agent 是什么。所以，不让"他们团队里没有技术人才"这件事成为你创业成功的障碍，才是明智的做法。

为不懂技术的客户提供技术解决方案——FDE 就是架起这座桥梁的人。

FDE不是什么：被误读的三重身份

角色一热，误解就跟着来。最多人抖机灵的一句是："不过是销售工程师换了个名字。"Kevin 说，请先对销售工程师放尊重些，他们做的是非常出色的工作——但 FDE 确实不是他们，也不只是"被推到一线的开发"，更不是"换了个名字的咨询"。

销售工程师是售前职能，主要为了赢得订单去搭演示，合作到签单就结束了。FDE 不是这样——它是从探索到交付、端到端全流程负责到底。

软件团队存在的意义，从精神层面讲，是构建"一对多"的产品——做出很酷的东西，扩展到 100 个、1000 个甚至一万个用户。而 FDE 的目的恰恰相反，它是"一对一"的：构建的是为某个具体客户解决特定问题的东西。如果你的思考再超出这个范围一步，那你其实已经跑偏了。

FDE 确实从这些实践里汲取了一些元素，但它本质上是一个非常工程化的岗位。如果你的组织没有按那样的方式运作，那也没关系——你可以叫它 FDE，但在为 Palantir 带来巨大商业成功的那种形态里，那些都不是 FDE。

所以请一定记住这个标准：一次 FDE 合作的最终产出，应当是软件。

一次 FDE 合作，应当以软件为最终产出——把它想成发明一个个新的 SKU。

三顶帽子：从"倾听"到端到端交付

顾问、产品经理、软件工程师——当这三种能力集中在同一个人身上，这个角色才最有效。而在 Kevin 参与过的任何一次合作里，第一步都不是说话，而是倾听。

第一步不是说话，而是倾听。你的任务是赢得客户的信任——从执行发起人、副总裁到 CEO——让他们把你视为可信赖的伙伴。你希望他们告诉你的，不只是当初促成那笔订单的问题，而是那些真正让他们夜不能寐、如果他们是上市公司甚至可能拖垮股价的问题——因为那些，才值得被解决。

FDE 最主要的沟通技能，是倾听。

一般来说，客户告诉你的只是症状。假设他们跑来抱怨"仪表盘加载太慢，很影响我们"——我不会一上来就说你错了，那样太轻浮、也不诚实。但我会试着一起挖出背后的根本问题：这件事为什么会影响到你的业务？当初选择和我们合作，绝不是因为我们家的仪表盘加载最快。我们在这里，到底要解决什么业务问题？

如果聊到最后，他们真正的目标是"卖出更多东西"、担心仪表盘慢会拉低转化——那问题就不在于加载得多快，而在于它多能转化。延迟本身是个泥潭：把它解决了，下周你还想更快，再下周依然想更快；就算能提速十倍，也可能完全产生不了实际效果。所以我的目标不只是弄清楚你需要什么，还要尽可能说服你认同那个真正值得解决的问题。

想法会多到停不下来：让仪表盘更快是一种方式；去查这个人的搜索历史、推荐最相关的课程是另一种；把行动号召按钮做得更大；甚至让离开页面变得超级烦人，直到他们买点什么——但你不可能把什么都做出来。就算客户有花不完的钱，他们的时间也是有限的。你的职责是找出最可能实现目标、又能在给定时间内做完的那一件事。

假设试点只有四周。我要找的不是带来最大提升的完美方案，而是"我能在两周半之内做完的最好的东西"——因为我确定，你一定会讨厌第一版，然后我们还得继续迭代。这有点反直觉：有人会想挑一个最优方案、刚好挤进四周，但那样你就会丢掉订单，除非你第一次就能交付完美无缺的代码，而那不可能发生。关键原则是迭代式开发，同时把精力聚焦在高优先级的胜点上。

Kevin 的取舍标准
先交付一个最小范围的第一版，再从那里开始迭代。

让一个人擅长这件事的，未必是产品管理经验，而是他真正"拥有"这个问题的能力——而不是仅仅"拥有"这个项目，这两者差别很大。对项目有高度主人翁意识的人，会愿意做非常辛苦的工作、愿意长时间加班，这些当然好；但归根结底，客户并不在乎你开不开心、也不在乎你干得快还是慢，他们在乎的是自己的问题有没有被解决。

所以一个真正优秀的候选人，是能把脑中那套框架讲清楚的人——他为什么做了某个决定，又是如何在"正在解决的问题"这个维度上自圆其说的。这里没有标准答案，但存在回答问题的正确方式。

和普通工程师不同，你不能合上 PR 就结束一天的工作。你要对端到端交付负全责：怎么构建、怎么向客户演示、怎么引出反馈、再让他们最终接受这套方案。大多数从开发背景出来的人都被"保护"惯了——没有 DevOps 团队可以移交，没有 QA 团队，你就是一切，从头到尾。

最后还想区分一对词："质量"和"完整度"。质量是代码本身写得很好、找不到合理范围内的 bug；但那不代表完整——因为客户很可能根本不会去读那段代码。完整意味着：它能不能跑起来？客户是否明白它能跑起来？它能不能产生客户付费想得到的那个业务结果？

谁适合当FDE：面试考察的核心能力

FDE 如今是个热门头衔，但 Kevin 说得很直接：冲着热度而来的理由，全都是糟糕的动机——这份工作等于把三份职业叠在一起，失败面也是三倍。真正的问题是：什么样的人，适合它？

这个角色非常适合那些过去是创始人、或者未来想当创始人的人。FDE 的形态很像设计伙伴式的合作：你不知道自己要建什么，客户也不知道自己要买什么。你到场、和他们交谈、然后把东西做出来——哪怕一开始大家都不确定究竟需不需要它。YC、a16z 这些机构会反复教你同一件事：去和客户聊，然后把东西做出来。

但并不是每个人都是创始人。这个角色真正处在咨询、产品与工程三个学科的交汇点上：一个一直带着产品视角的软件工程师，或者一个一直非常懂技术的产品经理，就是很好的画像——你基本上已经在做这件事，只不过头衔不一定叫 FDE。说到底，这份工作是为那些真心渴望"一份工作干三个工种"的人准备的。

一句忠告
冲着热度而来的理由，全都是糟糕的动机——你失败的面，是普通工作的三倍。

我考察的是主人翁意识（ownership）和完整性（completeness）。光把代码写出来是不够的：测试用例呢？你自己知道哪些地方可能出问题吗？哪些边界情况会导致失败？你会怎么设计去防范？又会交给客户哪些使用说明，教他们别踩到坑？

举个最简单的例子：我让你写一个两数相加的函数。如果你只把它写出来，却没告诉我"不能传字符串进来，这个函数只接受整数"——那客户一旦传了字符串，就会觉得你的应用坏了、你的平台不行。所谓完整性，就是真正理解问题的全貌：它能被怎么用，又可能被怎么误用。好消息是，这些基本功对普通软件工程面试同样有帮助——太多人写代码时，根本不考虑测试用例。

面试里很难展示你善于倾听，但不难展示你如何出场、如何跟客户合作——你的面试官很可能就是你的客户，你在向他们推销你自己。咨询行业有个词叫"高管气场"（executive presence）：你在高层领导面前能有多好的表现。也许你没做过 FDE，但你在创业公司里向工程副总裁汇报过吗？向 CEO 展示过吗？跟同事相比，你做得怎么样？这些，是进入面试流程之前就该反复练习的东西。

你不可能靠刷两周 LeetCode 就通晓所有题目，也不可能光看 YouTube 上的视频、读一本教说话的书，就成为一个有感染力的展示者——你必须真的去讲、去练。提升沟通清晰度的真正途径，是带着意图、带着准备去做。我的导师说过："不做准备，就准备失败"（fail to prepare, prepare to fail）。你没法笼统地让自己变得更会说话，但可以思考自己说出的每一个词、这些词会被怎样接收、该怎样准备去传递。

另外，每个人在工作中都要跟人打交道——去问问你的同事，你沟通得怎么样：他们会不会说你讲得清楚、能把复杂的东西讲简单？如果他们没有这么说，那就去问，你怎样才能做得更好。主动获取反馈，同样是被低估的能力。

产品 sense 和清晰写作其实有很多共通之处。先从习惯开始：做出一些决定，然后把它们写下来，说清为什么做这件事而不是那件；再找一个对你的处境毫无背景、对你的决定毫无了解的人，看他能不能只凭你写下的思路就理解你。判断力没法在一周内练出来，但你可以花时间研究真正优秀的产品，理解它们是怎么做出来的。最优秀的那批人，无论科技、艺术还是销售，都会花时间看别人把什么事做得特别好，然后向他们学习——你得先知道"优秀"长什么样，才能把它用到自己的问题里。

未来、阶梯与最后一句话

FDE 会像有人预测的那样"两三年内自我吞噬"，还是会长久存在？Kevin 从 Palantir 二十多年的实践出发，谈未来、谈晋升阶梯，也留下了那句给所有入行者的"最后一句话"。

Palantir 已经成立 20 多年，FDE 从公司创立之初就存在——因为我们意识到，在非常复杂、而且最终买家和用户都不具备技术背景的环境里，这是交付真正有效的软件的最好方式。只要这种形态的问题还在，FDE 这个角色就还会在。

某些 FDE 岗位被吸收掉、某些用 FDE 的公司失败——这些情况一定会出现，因为有很多公司做着各种事情然后管它叫 FDE，我没办法仅凭一个名字去评判整个职能。但如果你做的事情是：直接跟客户合作、倾听他们想要什么、拿出一份他们认可的方案、然后把东西做出来交给他们——我看不出这怎么会失败。

每一款伟大的产品都是这样做出来的——先听懂一个人，再把东西做出来交给他。

在 Palantir，FDE 是一个"终点职级"（terminal title）：你入职第一天是 FDE，到第十年你仍然是 FDE。负责整个商业业务、管着超过九位数（上亿美元量级）盘子的商务负责人，头衔就是 FDE——这很符合 Palantir 的精神：这个头衔之上，不应该再有别的。当然，现在也有公司设 Senior FDE、Staff FDE，那也没问题，人们完全可以拿走这个头衔，爱怎么用就怎么用。

但在这个面向客户、以结果为导向的角色里，成长路径是这样的：你会逐渐接管范围更大的工作。一开始，你可能不被指望独立负责某个客户账户，而是跟着一位更资深的同事，做该客户问题中的一小块；慢慢地，你能独立负责一个客户，再负责所有客户——然后是一个行业、一个领域、一个地区。Palantir 教给我们的模型是：给你一家公司，你就是这家公司的 CEO。你只有一个客户，唯一创造营收的方式，就是尽最大可能让客户成功。如果你做得好，也许我们会再给你几个客户。

说到底，你得搞清楚自己真正想做什么——你只有一段职业生涯。想做 FDE，是因为这就是你想做的事、是你一直在等的角色？还是因为别人告诉你说该做，或者因为它很热门、上了新闻？面试中表现最好的人，是那些对这个角色有真正理由、也真心想在其中取得成功的人。如果你还没有这些理由，那也完全不是问题——花时间想清楚自己真正想做什么，然后去那里把事情做到极致。

我也想提醒一句：FDE 是一份很特别的工作，但它也只是另一份工作，不是那个能解决你所有问题的万灵药——我可以向你保证，包括 Palantir 在内的许多好公司里，有大量 FDE 过得非常痛苦。它是一门职业，就像软件、产品、人才招聘是职业一样。说到底，选择你认为自己擅长的事，然后找到一个能把这一切融合起来的角色。

技能本身并没有改变，变的只是形态、头衔和角色。FDE 不是又一个热门头衔，而是一种"把问题真正解决到客户身上"的能力组合，它需要一个人既肯倾听、又能交付。Kevin 也把这些年的实践带进了他自己的播客。如果这个"一份工作干三个工种"的角色让你动心，不妨先像他建议的那样，写下你的第一个决定：我真正想解决的问题，是什么？

JOTO 企业落地观察

• 对企业部署意味着：FDE 模式并非通用解法，其适用性严格取决于“高技术产品 × 非技术客户”的错配场景。企业若盲目复制该模式，却未审视自身产品复杂度与客户技术成熟度的匹配关系，将导致资源错配与交付失效。
• 对智能体工程意味着：FDE 所强调的“端到端交付软件”本质，要求智能体系统必须具备可封装、可部署、可验证的工程化闭环能力，而非仅停留在原型或演示阶段。缺乏此能力的智能体项目难以支撑 FDE 实践。
• 对 RAG 知识工程意味着：FDE 在客户现场快速构建解决方案的过程，高度依赖结构化、可检索、可验证的企业知识资产。零散、非结构化、未经治理的知识库，将使 FDE 无法在限定周期内完成可信交付。
• 对 AI 安全治理意味着：FDE 直接接触客户生产环境与敏感业务数据，其开发行为绕过常规研发流程。企业必须建立面向 FDE 场景的轻量级安全卡点（如数据脱敏检查、权限最小化配置），而非沿用中心化研发安全策略。