PS：
AI 工程落地干货直播，欢迎点击预约，直播见。
一个 Palantir 老兵的两个灵魂拷问：你卖给谁？你卖的是什么？
AI 大模型正在重新定义软件的范式，这句话我讲了两年多。但真正走到企业落地环节，最扎心的现象只有一个：Demo 惊艳，POC 冒烟，上生产拉胯。很多人把锅甩给模型能力、甩给算力、甩给数据质量。我的判断不一样：这三样都在飞速变好，真正的瓶颈是「翻译层」缺失：没有人能把客户嘴里那句含混的业务抱怨，翻译成一个 Agent 能解、并且值得解的技术问题。硅谷给这个「翻译层」起了个岗位名，叫 FDE（Forward Deployed Engineer，前置部署工程师）。发明者被公认是 Palantir。最近这个词在国内技术圈、创投圈也开始刷屏。但我必须先泼一盆冷水：现在大多数人聊的 FDE，都是一个被严重误读的 FDE。这篇文章，我把 Rippling 首位 FDE、Palantir 老兵 Kevin Bai 的一线实践，拆到底层逻辑上，讲清楚四件事：- 什么样的公司该上、什么样的公司根本不该上 FDE（一个四象限，自己对号入座）
- FDE 到底是什么，以及它不是什么（三个最常见的误读）
PS：
FDE 更多案例深入免费学习去这里：
1.打开 AITutor 新一代 AI 原生学习伙伴：www.aiaitutor.com 2.在首页输入"FDE” 就能看到更详细更丰富案例。3.包含了图文、视频、播客、闪卡、代码、测验等9种学习模态。
01 先泼冷水：两个灵魂拷问，决定你该不该上 FDE
Kevin 说，每当创始人跑来问他「我们要不要建 FDE 团队」，他从来不接这个问题，而是先反问回去：因为绝大多数人问这个问题的动机，是：「大家都在做」「投资人喜欢听」「这是公认的常识」。他的原话很不客气：因为这些理由去建 FDE，真的很蠢。第一，你卖给谁？第二，你卖的是什么？
| | |
|---|
| 标准 SaaS 打法<br>（Slack、Jira、飞书） | |
| ⭐ FDE 的唯一主场（Palantir Foundry、企业级 Agent 平台） | |
右下角：产品很技术，但买家也很技术。比如 Anthropic 的 API，比如把 GitHub 当产品卖。东西是复杂，但对面坐着的是软件工程师，画像是 CTO、CIO，人家自己就能读文档、自己就能跑起来。你派 FDE 过去，是浪费。左上角：产品不复杂，用户也不懂技术。Slack、Jira 这类，工具本身谈不上多技术，终端用户大多没有技术背景，双方天然匹配。你派 FDE 过去，还是浪费。左下角：这才是 FDE 存在的唯一理由：产品技术性极强，而理想客户画像（ICP）完全不是技术背景。Palantir 的 Foundry 就是典型：卖给世界 500 强，但这些客户不是科技公司，是快消、制造、航空。那里有巨大且棘手的问题，值得用最好的方案去解，可是坐在你对面的，没有一个人能把「软件」和「他们的业务问题」这两件事对接起来。一句话总结：为不懂技术的客户，提供技术解决方案，FDE 就是架起这座桥的人。
这个框架本身不新，但生成式 AI 把这个矩阵彻底扭曲了。过去，「产品极其复杂」是少数派。现在呢？大模型让构建强大方案变得前所未有地容易，但「强大」的同义词就是「极其复杂」：多 Agent 编排、RAG 链路、工具调用、Context 工程、评测体系、护栏与回滚……而你的客户是谁？如果是传统行业，他们中的大多数，连 Agent 是什么都还没搞清楚。也就是说：左下角这个象限，正在以肉眼可见的速度膨胀。在 AI 应用落地这条赛道上，FDE 不是「要不要建」的问题，而是「你建不建，客户那道鸿沟都在那里」的问题。别让「客户团队里没有技术人才」这件事，成为你创业成功的天花板。但请注意，先做完上面那道对号入座题。你如果在右下角还硬上 FDE，那不叫战略，那叫烧钱。02 一句话定义 FDE：面向客户的软件工程师
FDE = Customer Facing Software Engineer（面向客户的软件工程师）
顾问（Consultant）+ 产品经理（PM）+ 软件工程师（Engineer）有些公司会把这三顶帽子拆给两个人、三个人戴。但作为一个职能，FDE 就是这三种能力的集合体。角色一热，误读就跟着来。最常见的三句抖机灵，我们一句句拆。误读一：「FDE 不就是售前解决方案工程师换了个马甲？」请先对售前工程师放尊重些，他们做的是非常出色的工作。但两者的边界非常清楚：售前是「售前」职能，核心目标是搭 Demo、赢下订单，合作到签单那一刻就结束了。FDE 是「端到端」职能，从需求探索一路负责到最终交付，签单只是开始。这是最本质的一条差异，我认为值得每个技术管理者背下来：软件团队存在的精神内核，是构建「一对多」的产品：做出很酷的东西，扩展到 100 个、1000 个、10000 个用户。
而 FDE 的目的恰恰相反，它是「一对一」的：构建的是为某一个具体客户、解决某一个特定问题的东西。
你的思考只要超出这个范围一步，就已经跑偏了。
这句话说给谁听？说给所有习惯了「先抽象、再复用、要做平台」的架构师听，也包括我自己。在 FDE 的场景里，过早抽象是原罪。FDE 确实从咨询实践里汲取了不少元素，但它的本质是一个极其工程化的岗位。Kevin 给了一条铁律，我认为这是全文最硬的一条标准：一次 FDE 合作的最终产出，必须是软件。
把每一次交付，想象成在发明一个新的 SKU。
如果你的组织跑出来的最终产出是一份 PPT、一份方案书、一堆人天，那么你可以管它叫 FDE，但那不是在 Palantir 创造出巨大商业成功的那个 FDE。03 第一顶帽子｜顾问：最重要的沟通技能是「听」
我在很多场架构分享里都强调过一个思维模型：业务需求至简抽象分析。说白了就是：能不能从「我要一匹更快的马」里，听出「我要更快地到达」。他说：任何一次 FDE 合作，第一步都不是说话，而是倾听。你的第一任务，是赢得从执行发起人、到 VP、到 CEO 的信任，让他们把你当成可信赖的伙伴。你希望他们告诉你的，不是当初促成那笔订单的那个问题，而是那些真正让他们夜不能寐、如果是上市公司甚至可能拖垮股价的问题。客户跑过来抱怨：「你们的仪表盘加载太慢了，严重影响我们。」Kevin 的反应：我不会一上来说「你错了」，那样太轻浮也不诚实。但我会带着他一起往下挖：第一层｜症状：仪表盘慢。第二层｜影响：这件事为什么会影响到你的业务？第三层｜目标：当初选择和我们合作，绝不是因为我们家仪表盘加载最快。我们坐在这里，到底要解决的是什么业务问题？挖到最后，真正的目标浮出水面：他们想卖出更多东西，担心仪表盘慢会拉低转化。问题的关键根本不是「加载得多快」，而是「它多能转化」。
延迟本身是个泥潭。你把它解决了，下周他还想更快，再下周依然想更快；就算提速十倍，也可能完全产生不了实际效果。
所以 FDE 的目标是双重的：不仅要弄清楚你需要什么，还要尽可能说服你认同那个真正值得解决的问题。- 症状层：你观察到的现象是什么？（听，不打断，不辩解）
- 影响层：这个现象具体怎么伤害了你的业务？能不能量化？
- 目标层：如果这件事彻底不存在了，你的哪个业务指标会变好？变好多少？
⚠️AI 项目里的高发陷阱：客户说「我们的 AI 客服回答不准」，这是症状。往下挖你会发现，可能是知识库三年没更新、可能是转人工链路断了、也可能是根本没人定义过「准」的标准。上来就调模型、换向量库，你会掉进和「延迟」一模一样的那个泥潭。04 第二顶帽子｜产品经理：4 周的试点，我只做 2.5 周的事
Kevin 说，方向一旦明确，想法会多到停不下来：让仪表盘更快是一种；去查用户的搜索历史、推荐最相关的课程是另一种；把 CTA 按钮做大；甚至让离开页面变得超级烦人，逼着他们买点什么……但你不可能全做。就算客户有花不完的钱，他们的时间也是有限的。FDE 的职责是：找出那件「最可能实现目标、又能在给定时间内做完」的事。假设试点周期是 4 周。
我要找的，不是那个带来最大提升的完美方案，而是「我能在两周半之内做完的最好的东西」。
因为我百分之百确定：你一定会讨厌第一版，然后我们还得继续迭代。
有人会想挑一个最优方案、时间刚好挤满 4 周。那样你就会丢掉这个订单。除非你第一次就能交付完美无缺的代码，而那不可能发生。
核心原则：迭代式开发 + 火力集中在高优先级的胜点上。交付范围 ≈ 试点周期 × 60%，剩下 40% 全部留给「客户讨厌第一版」之后的迭代。
在 AI Agent 项目里，这条法则的重要性要再乘以三为什么？因为传统软件的第一版，客户至少知道自己要什么，验收是确定的。不是因为你做得烂，是因为客户在看到第一版之前，根本不知道 Agent 能做到什么程度、边界在哪里、什么时候该让它自主、什么时候必须人工兜底。第一版的真正价值，不是交付功能，是把「双方对 Agent 能力边界的认知」对齐。你把 4 周排满，就等于把这个最关键的认知对齐环节，排到了合同截止之后。比「产品经验」更重要的是：拥有问题，而不是拥有项目Kevin 说，让一个人擅长这件事的，未必是产品管理经验，而是：他真正「拥有」这个问题的能力，而不仅仅是「拥有」这个项目。这两者差别巨大。
对项目有强主人翁意识的人，愿意做很辛苦的活、愿意长时间加班，这当然好。但归根结底，客户不在乎你开不开心，也不在乎你干得快还是慢，他们只在乎自己的问题有没有被解决。05 第三顶帽子｜工程师：「质量」不等于「完整」
到了动手环节，FDE 和普通研发的差距，才真正拉开。和普通工程师不同，你不能合上 PR 就结束一天的工作。
你要对端到端负全责：怎么构建、怎么向客户演示、怎么引出反馈、怎么让他们最终接受这套方案。大多数从研发背景出来的人，都被「保护」惯了：没有 DevOps 团队可以移交，没有 QA 团队。你就是一切，从头到尾。
全文我最推荐分享给团队的一组概念：质量 vs 完整度质量高 ≠ 完整。因为客户很可能根本不会去读你那段代码。因为 Agent 最危险的失败模式，从来不是宕机，而是一本正经地给出错误答案，而没有任何人察觉。可解释、可观测、可回滚、有护栏，这些在 Agent 交付里不是加分项，是「完整度」的基本盘。06 谁适合当 FDE？以及面试到底考什么
冲着热度而来的理由，全都是糟糕的动机。
这份工作等于把三份职业叠在一起，你失败的面，也是普通工作的三倍。
FDE 的形态极像 Design Partner（设计伙伴）式的合作：你不知道自己要建什么，客户也不知道自己要买什么。你到场、和他们交谈、然后把东西做出来，哪怕一开始大家都不确定究竟需不需要它。YC、a16z 反复教的就是同一件事：去和客户聊，然后把东西做出来。后两类人，其实基本上已经在做这件事了，只不过头衔不叫 FDE 而已。说到底，这份工作是为那些真心渴望「一份工作干三个工种」的人准备的。工程面：考 Ownership 和 Completeness我让你写一个「两数相加」的函数。
如果你只是把它写出来，却没告诉我：「不能传字符串进来，这个函数只接受整数」，那么客户一旦传了字符串，就会觉得你的应用坏了、你的平台不行。
所谓完整性，就是真正理解问题的全貌：它能被怎么用，又可能被怎么误用。好消息是，这些基本功对普通软件工程面试同样有用。太多人写代码时，脑子里根本没有测试用例这根弦。面试里很难展示「我很会倾听」，但不难展示你如何出场、如何跟客户合作，因为你的面试官很可能就是你未来的客户，你正在向他们推销你自己。咨询行业有个词叫 Executive Presence（高管气场）：你在高层领导面前的表现有多好。Kevin 引了他导师的一句话，我准备贴在工位上：Fail to prepare, prepare to fail.（不做准备，就准备失败。）
每个人在工作中都要跟人打交道。直接去问你的同事：我沟通得怎么样？你会不会说我讲得清楚、能把复杂的东西讲简单？
如果他们没这么说，那就接着问：我怎样才能做得更好。
主动索取反馈，同样是被低估的能力。
动作一：写。产品 sense 和清晰写作有大量共通之处。做出一些决定，然后把它们写下来，说清楚为什么做这件事而不是那件；再找一个对你的处境毫无背景、对你的决定毫无了解的人，看他能不能只凭你写下的思路理解你。动作二：看。判断力没法在一周内练出来，但你可以花时间研究真正优秀的产品，理解它们是怎么做出来的。最优秀的那批人，无论在科技、艺术还是销售领域，都会花大量时间去看别人把什么事做得特别好，然后向他们学习。你得先知道「优秀」长什么样，才能把它用到自己的问题上。
- [ ] 我能讲清楚我做某个决定的框架，而不只是结论吗？
- [ ] 我最近一次交付，除了代码，还交付了使用说明和失败边界吗？
- [ ] 我能把一个复杂技术方案，用业务语言讲给非技术高管听吗？
- [ ] 我在最近一个项目里，拥有的是问题，还是只是任务？
- [ ] 我能说出我做过的东西，带来了什么可量化的业务结果吗？
07 阶梯与未来：把自己当成一家公司的 CEO
Palantir 成立 20 多年，FDE 从公司创立第一天就存在，因为他们意识到，在非常复杂、且最终买家和用户都不具备技术背景的环境里，这是交付真正有效软件的最好方式。只要这种形态的问题还在，FDE 这个角色就还会在。他也承认：某些 FDE 岗位会被吸收、某些用 FDE 的公司会失败，因为有太多公司做着各种事情然后管它叫 FDE，没法仅凭一个名字去评判整个职能。如果你做的事情是：直接跟客户合作、倾听他们想要什么、拿出一份他们认可的方案、然后把东西做出来交给他们，我看不出这怎么会失败。
每一款伟大的产品，都是这样做出来的。
在 Palantir，FDE 是一个「终点职级」（Terminal Title）：你入职第一天是 FDE，第十年还是 FDE。负责整个商业业务、管着上亿美元盘子的商务负责人，头衔就是 FDE。这非常符合 Palantir 的精神：这个头衔之上，不应该再有别的。（当然，现在也有公司设 Senior FDE、Staff FDE，那也完全 OK。）跟着资深同事做客户问题中的一小块 → 独立负责一个客户 → 负责所有客户 → 一个行业 → 一个领域 → 一个地区而 Palantir 教给他们的心智模型，是全文最提气的一句：给你一家公司，你就是这家公司的 CEO。
你只有一个客户，唯一能创造营收的方式，就是尽最大可能让这个客户成功。
如果你做得好，也许我们会再给你几个客户。
08 三点补充思考
前面都是 Kevin 的实践。这一节是我自己的判断，供你参考、也欢迎拍砖。第一，FDE 看起来「反规模化」，但它是规模化的前置条件很多创始人抗拒 FDE，理由是「这不就是定制吗？不 Scale 啊」。我认为这是把顺序搞反了。回看那条铁律：「一次 FDE 合作的最终产出，是软件，是在发明一个新 SKU」。一对一交付 → 沉淀可复用的组件/模板/SKU → 下一个客户交付周期缩短 → 边际成本下降 → 某些 SKU 长成标准产品不 Scale 的是「人天」，能 Scale 的是「沉淀」。如果你的 FDE 团队干了两年，交付效率没有任何提升、没有沉淀出任何可复用资产，那你建的不是 FDE，是一个内部外包队。坑一：把 FDE 挂在销售线下，考核签单额。结果 FDE 变成了高级售前，交付质量无人负责。坑二：把 FDE 挂在交付线下，考核项目回款和人天利用率。结果 FDE 变成了外包，沉淀归零。坑三：FDE 和产品团队之间没有回流通道。FDE 在一线趟出来的所有认知，全部烂在项目里，产品还在闭门造车。我的建议：FDE 的考核，应该同时看「客户业务结果」和「资产沉淀率」这两个指标，并且必须有一条制度化的通道，把 FDE 的一线洞察回流进产品路线图。第三，对个人：FDE 恰恰是 AI 时代最难被替代的岗位之一现在很多工程师焦虑：Coding 被 AI 吃掉了怎么办？我的判断是：AI 吃掉的是「把明确的问题变成代码」这一段，而 FDE 的核心价值，恰恰在这一段的两头。前面那头：从客户含混的抱怨里，把真问题挖出来、并说服客户认同它。这依赖信任，而信任目前无法被外包给模型。后面那头：为交付结果负全责，在没有 QA、没有 DevOps 的情况下，判断什么叫「够完整了」。这依赖判断力和担当，同样很难外包。当写代码的成本趋近于零，稀缺的就不再是「会写」，而是「知道该写什么、以及敢为写出来的东西负责」。09 写在最后
Kevin 最后说了一段很诚实的话，我原样搬过来，因为它比任何鸡汤都有用：FDE 是一份很特别的工作，但它也只是另一份工作，不是那个能解决你所有问题的万灵药。
我可以向你保证，包括 Palantir 在内的许多好公司里，有大量 FDE 过得非常痛苦。
它是一门职业，就像软件、产品、招聘是职业一样。选择你认为自己擅长的事，然后找到一个能把这一切融合起来的角色。
FDE 不是又一个热门头衔，而是一种「把问题真正解决到客户身上」的能力组合，它要求一个人既肯倾听、又能交付。如果这个「一份工作干三个工种」的角色让你动心，那就先做 Kevin 建议的那件最小的事：送个福利：
新一代 AI 原生学习伙伴 AITutor「www.aiaitutor.com」，重构学习方式，AI 驱动个性化精准成长，体系化学习+真实案例，塑造 AI 实战能力。快来免费体验吧。
PS：
AI 工程落地干货直播，欢迎点击预约，直播见。
—8—
加我微信
扫码加我👇欢迎探讨和合作👇。
加星标★，不错过每一次更新！
⬇戳”阅读原文“，立即体验 AITutor
