FDE（Forward Deployed Engineer）最近在国内火了。
Palantir 原版定义：工程师不坐在总部写通用产品，直接住进客户现场，把技术能力揉进业务流，直到客户真正跑起来。AI 时代这个概念被重新捧起来，因为大模型产品最大的问题就是「demo 很酷，落地很难」，FDE 好像正好能解这道题。
但我想说一句不太好听的：把 FDE 这个词搬到中国市场之前，三个现实矛盾你得先想清楚。 它们不是什么「小问题」——你进场第一个月就会碰到，而且没有标准答案。这篇文章不列清单，就拆这三个。
矛盾一：你要共建，但跟你共建的那个人不欢迎你
FDE 的核心工作方式，说到底是「共建」。
需求不清晰就一起梳理，结果不确定就一起试，价值标准是业务指标的变化而不是功能清单的打勾。这套逻辑在 Palantir 那儿行得通，因为它服务的客户（CIA、BP、Airbus）本身有极强的业务分析能力和内部推进意志，缺的是一个能跟他们在同一个认知层面协作的技术合伙人。
但国内市场的底色不是这样。
过去三十年企业服务的惯例是「我提需求，你写代码，我验收」——这个惯例背后有很硬的结构性原因：
第一，中国大部分企业买的不是「能力」，是「确定性」。 采购流程天然排斥不确定性：需求文档要明确，上线时间要承诺，效果要可预期。你别管最后实际跑成什么样，合同里得写清楚。这种文化不是客户的错——中国 IT 服务市场几十年的外包史（从早期的系统集成到后来的 SaaS 交付）把甲乙方关系训练成了「交付物交换」。甲方愿意为功能付费，不愿意为不确定性付费——而 FDE 的核心价值恰恰是不确定的、过程的、迭代的。
第二，中国企业缺少「业务技术联合体」。 Palantir 式的 FDE 能工作，前提是客户那边有一个对等的业务负责人：他懂自己的业务、有决策权、被授权跟 FDE 一起定义问题。但在中国，你面对的组织是裂开的：业务部门不懂技术也没有决策权，IT 部门懂技术但不了解业务细节，真正有决策权的老板只在关键节点出现。你找不到一个能跟你「共建」的对等伙伴——你得自己同时当技术方和业务分析方。
两层现实一叠加，FDE 就卡在中间了：你按共建的方式进场，客户按交付的逻辑验收。你在乎的是「这个流程真的跑通了吗」，客户在乎的是「需求文档第三条第五项你到底做了没有」。
但这还没到底。更根本的问题是：
你口口声声要跟他「共建」的那个人，可能根本就不欢迎你到来。
我们先把买单链条理清楚。FDE 的买单方是谁？是老板。但老板是实际提需求的人吗？不是。他也不会亲自下场跟你梳理业务流程。他只说一句话：「我要用 AI 改变我的组织」。然后给你指定一个对接人——通常是某个部门负责人或中层管理者。
这个人才是你真正的「共建伙伴」。而你站在他的立场上想一想：你的到来，对他意味着什么？
第一，加活。 他本来只需要写需求文档、管乙方交付，现在要跟你坐在一起梳理流程、定义问题、反复试错。你越认真，他花的时间越多。
第二，风险。 共建完了以后呢？流程自动化了，效率提升了——那他呢？他的岗位还值不值钱？他会不会被替代？你说「我们是来帮你提升效率的」，但在他看来，这句话的潜台词可能是「我们是来让你可以被替代的」。
第三，对比。 没有你的时候，他花预算找乙方交东西就行了——需求明确、流程清晰、验收简单，而且出了问题能推给乙方。你的出现打破了这套他熟悉的规则。你对他是赋能还是威胁？答案往往取决于你看没看到这个人的真实处境。
所以在中国的组织里，「共建」不是一个技术问题，甚至不是一个采购文化问题——它是一个利益问题。你幻想中的共建伙伴，本质上是你的利益相关者，而且优先级是最高的那一个。搞不定他，矛盾一和矛盾二会同时炸。
别试图教育客户改变采购文化。 三十年的惯性你改变不了。能做的是把共建拆成可验收的小周期——两周一个里程碑，每个周期有明确的交付物，用交付物换信任，用信任换下一阶段的共建空间。但在此之前，先回答一个问题：
你那个指定对接人，他有什么理由配合你？
如果你回答不了，后面的事都不用想了。
矛盾二：你以为在赋能，实际在重分蛋糕
FDE 进场时的心态一般是「我来帮你们把 AI 落地」，但在组织内部，你做的每一件事都是权力和利益的再分配。审批自动化动的是审批权，数据打通动的是数据归属权，Agent 替代人工处理动的是岗位价值，项目汇报走直线上报动的是中层的信息差红利。
但这里有一个比「动了谁的蛋糕」更根本的问题：
FDE 作为一个外部角色，你无权重新分配任何东西。
你看到了利益格局的冲突，但你没有任何组织授权去解决它。你不是 CIO，不是 HR VP，不是部门负责人——你是他们请来的工程师。
这就是为什么很多 FDE 项目会死在一种特殊的沉默里：没人公开反对你，但也没人真正配合你。数据接了一个月还在走流程，需求评审永远凑不齐人，验收时突然冒出各种历史遗留问题——这些往往不是技术问题，是你踩到了某个岗位的核心利益，对方选择用不配合让你失败。
面对这个矛盾，FDE 能打的牌就两张：
第一张牌是利益相关者地图。 进场第一周，不要先看代码，先画人。谁发起这个项目？谁签字？谁来用？谁会被替代？谁的数据会被拿走？谁的信息优势会被瓦解？把这些人的利益格局画清楚，你才能判断谁是同盟、谁是中立方、谁是潜在阻力——以及针对每类人该用什么策略。
第二张牌是一把手。 利益格局的重塑不可能由外部工程师完成，只能由组织内部的最高权力推。如果你没有项目决策人的真实背书——不是口头支持，是他在关键时刻会出来替你扛事——那你就不是在推进变革，只是在当一个随时可以被牺牲掉的技术顾问。
两张牌缺一张，矛盾二大概率无解。
矛盾三：你以为你要调模型，实际你连数据在哪都不知道
三个矛盾里最不性感、但最消耗人的一个。
AI 圈讨论 FDE，话题永远在模型选择、Agent 架构、提示工程、评测体系上。硅谷博客描绘的景象：客户有结构化数据躺在数据湖里，API 齐全，权限清晰，你设计推理链路就行。但在中国——包括年营收几十亿的中型企业——你走进现场看到的完全是另一回事：
-
核心业务数据不在一套统一的系统里，而是散落在 Excel、微信群、OA、老的 ERP、以及某个跑了十年的 Access 数据库里。 -
不同部门的系统互相不打通，每个系统有自己的数据格式、自己的账号体系、自己的导出机制——甚至有的系统连 API 都没有，唯一的获取方式是手工导出 CSV。 -
最要命的是，很多你以为理所应当存在的数据，它根本不存在。你想做竞品分析 Agent？竞品数据在哪？在某个市场部同事每天手动刷小红书和抖音攒出来的 Excel 里。你想做供应链优化？供应商的历史交付数据分散在采购部各个人的微信聊天记录里，没有沉淀，没有结构化。
这就是大量中国企业的真实状态：信息化的欠账还没还完，数字化的账本已经翻开，AI 的需求就来了。 很多人没经历过真正的企业业务，以为数据天然可获取、天然结构化。但你在现场面对的往往不是「怎么调优模型」，而是「数据到底存在什么东西里、以什么形式存在、怎么弄出来、弄出来能不能用」。
更讽刺的是，这个问题在技术圈很少被认真讨论。你很难在 Agent 框架的技术博客里看到「业务数据在 Excel 和微信聊天记录里怎么接入」的章节。但真实战场上，一个 FDE 很可能 60% 到 80% 的时间花在数据获取、数据清洗、系统集成上，真正写模型和提示词的时间反而是少数。
在中国做 FDE，你的核心竞争力不只是模型能力，而是数据工程能力：你能不能快速搞清楚一个企业的数据地图？能不能在数据残缺的条件下设计最小可行方案？能不能在不依赖理想数据基础设施的前提下，先让 Agent 跑出一个看得见的价值？
这跟矛盾一是一对：客户要交付确定性，你连数据在哪都不知道。两个矛盾同时出现，项目大概率变成一个漫长的数据治理项目——而你原本是被请来做 AI 的。
应对方式不多，有一条很实用：进场前先做数据摸底，别急着做方案宣讲。 别一上来就告诉客户你用哪个模型、什么架构——先问：这个流程相关的数据都存在哪？我能看吗？你看到的第一个真实数据集长什么样？把数据现实摆到桌面上，把数据工作的周期写进项目计划的第一段。如果客户不接受这个前提，后面的 AI 承诺全是空的。
三个矛盾说完了。它们不是孤立的：
客户要确定性（矛盾一），你却在利益格局上需要共识（矛盾二），而达成共识的前提是数据透明和系统互通（矛盾三），这三件事刚好互相锁死。
在中国的市场环境里，FDE 从来不只是工程师角色。本质上是在干三件事：把零散的系统串起来，在部门之间抹平摩擦，从 Excel 和微信聊天记录里把数据刨出来。三种能力缺一个，你会在对应的矛盾上卡住。缺两个，项目大概率死在中途。
Elliot’s Harness Lab
AI Agent、FDE 与 Vibe Coding 实战笔记
