摘要：Palantir 最值得研究的地方，未必是它的软件平台本身，而是它把软件交付这件事重新定义了一遍。FDE 不是一个岗位，而是一整套商业模式的结果。中国 ToB 能学到什么？
Palantir 最值得研究的地方，未必是它的软件平台本身，而是它把软件交付这件事重新定义了一遍。
在很多企业软件公司的逻辑里，产品是核心，交付是附属。软件卖出去之后，实施团队进场，配置系统、打通接口、培训用户、完成验收，这个项目就算结束了。但 Palantir 的前线部署工程师，通常不是这样工作的。
FDE 到客户现场以后，第一件事往往不是打开电脑写代码，也不是拿着标准方案开始部署，而是进入客户真实的业务环境。他可能会待在工厂、仓库、指挥中心或业务部门里，观察一线人员怎么工作，弄清楚数据从哪里来、流程在哪里断、决策为什么失真。等这些问题被摸透之后，他才会开始把技术系统搭起来。
这听起来像是"高级实施"或者"驻场交付"，但本质上不是一回事。
普通交付关注的是：合同里写了什么，我有没有交付完。
FDE 关注的是：客户真正要解决什么问题，我能不能用技术把结果做出来。
这两者之间，差别非常大。
FDE 不是一个岗位，而是一整套商业模式的结果
很多中国 ToB 公司看到 Palantir 的 FDE，容易产生一个误判：既然它能派工程师深度进入客户现场，我们是不是也可以这么做？
表面上看，这似乎不难。中国有大量系统集成商，有成熟的项目经理、实施顾问、解决方案架构师，也不缺能写代码、能沟通的人。只要给足预算，派几个人长期驻场，好像也能做出类似效果。
但真正的问题在于，FDE 不是单独靠招聘解决的。
它背后依赖的是合同结构、客户认知、利润空间、组织能力和人才供给共同形成的一套系统。只学一个岗位名称，而不改变整套交易逻辑，最后大概率只会变成"更贵的驻场外包"。
Palantir 的模式成立，是因为客户愿意为"不确定性"付费。客户承认，在复杂业务场景里，问题一开始并不清楚，方案也不可能提前完全设计好。因此，前期的调研、理解、试错、建模，本身就是服务价值的一部分。
但国内大量 ToB 项目不是这样定价的。
国内客户更习惯购买明确的功能、模块和交付物。合同里会写清楚系统要包含哪些功能、支持哪些流程、完成哪些接口。供应商最终要面对的是验收表，而不是业务结果。
在这种框架下，供应商花时间理解客户业务，很容易变成自己的成本，而不是可以向客户收费的价值。
客户会认为：我已经为软件付钱了，你就应该懂我的业务。你还需要花大量时间来研究，说明你不够专业。
于是，一个非常关键的矛盾出现了：复杂问题需要深入理解，但市场并不愿意为深入理解买单。
中国 ToB 的核心难题，是客户买功能，不买探索
企业软件最难的地方，往往不在软件功能本身，而在业务现场。
同样一个"排产优化"系统，在不同工厂里的难点可能完全不同。有的工厂瓶颈在设备利用率，有的在物料齐套，有的在班组协同，有的在订单频繁变更。表面上都叫排产，背后的业务逻辑可能差得很远。
如果供应商没有足够时间进入现场，只靠几次需求访谈和一份功能清单，很难做出真正有效的系统。
但国内 ToB 市场长期形成了一种惯性：先把需求写成文档，再把文档拆成功能点，然后围绕功能点报价、投标、开发、验收。
这个流程的好处是标准化、可比较、可控。
坏处是它默认"问题已经被定义清楚了"。
可现实恰恰相反。很多企业客户自己也没有完全想明白问题在哪里。他们知道效率低、成本高、数据乱、流程慢，但未必能准确说出根因是什么。这个时候，真正有价值的服务不是简单满足需求，而是帮助客户重新定义需求。
FDE 的价值正在这里。
它不是被动接需求，而是主动进入业务，把模糊问题拆开，把隐性流程显性化，再把业务语言翻译成数据模型和系统能力。
但这类工作在国内合同里经常没有位置。
它既不像软件功能那样容易被列出来，也不像硬件设备那样容易被计价。于是它明明很重要，却常常被视为"售前成本"“实施成本"或者"供应商应该自己消化的成本”。
只要客户不愿意为这部分付费，FDE 模式就很难规模化。
利润结构决定了服务深度
FDE 还有一个非常现实的前提：公司必须养得起这样的人。
一个优秀的 FDE，成本不会低。他既要懂技术，又要懂业务，还要能处理复杂客户关系。更重要的是，他不是远程支持，而是要长时间深度参与客户项目。这意味着一个人一年能覆盖的客户数量有限，边际成本很高。
如果一家公司的项目毛利足够厚，合同周期足够长，客户生命周期价值足够高，那么派一个高水平工程师长期深入现场，是划算的。因为只要项目成功，后续扩展、续约、增购都可能带来可观回报。
但国内很多 ToB 项目并不具备这个条件。
尤其在政府、国企、大型企业采购中，软件项目经常被拆成清晰的招标包。功能要求列出来，供应商分别报价。最终竞争往往高度价格化。大家都知道深度服务重要，但在招投标桌面上，价格经常比服务深度更有决定性。
在这种环境里，厂商为了中标，不得不压低报价。报价一低，利润就薄。利润一薄，就没有空间投入高成本人才。高成本人才进不来，项目质量就受影响。项目质量受影响，客户又更不愿意为服务溢价买单。
这就是一个循环。
很多 ToB 公司不是不想做好服务，而是商业账算不过来。
客户希望供应商像咨询公司一样理解业务，像软件公司一样交付系统，像外包公司一样便宜，还要像结果合伙人一样承担责任。这几个要求放在一起，本身就存在冲突。
一单一结的市场，很难长出长期主义
FDE 的另一个基础，是长期关系。
因为深入业务不会立刻产生全部价值。一个工程师进入客户现场，需要时间理解业务，需要时间建立信任，也需要时间验证方案。真正的效果，往往是在多轮迭代之后才出现。
这就要求供应商和客户之间，不是一次性买卖，而是持续合作。
如果客户未来几年都会使用这套系统，并且愿意围绕系统不断增加场景、扩大范围、提升目标，那么供应商前期投入就有回收可能。FDE 在客户现场积累的知识，不会随着项目验收而归零，而会变成后续合作的资产。
但国内不少 ToB 项目仍然是项目制逻辑。
今年做一个系统，明年有没有预算不知道。这个部门认可你，下一轮采购可能换了负责人。项目验收完成，双方关系就进入停滞。供应商很难确定自己在客户身上的持续投入能不能换来未来收入。
在这种不确定性下，理性的选择就是控制投入，尽快交付，尽快验收，尽快回款。
这与 FDE 所需要的深度陪伴、持续迭代和结果导向，天然不匹配。
所以问题不是中国公司没有长期主义，而是很多时候，合同关系不支持长期主义。
最稀缺的不是工程师，而是复合型人才
即便合同、预算、利润都解决了，FDE 仍然面临一个现实难题：人从哪里来？
真正优秀的 FDE，需要同时具备三类能力。
第一是技术能力。他要能理解数据、系统、模型、平台和工程实现，不能只是会讲方案。
第二是业务能力。他要能进入客户现场，看懂流程背后的逻辑。比如制造业里的物料、设备、工序、班次、异常、质检、交付压力，这些都不是看几页 PPT 就能理解的。
第三是沟通能力。他既要能跟一线员工聊出真实情况，也要能跟中层管理者讨论流程瓶颈，还要能向高层解释技术投入如何转化为经营结果。
这样的人，在任何市场都不多。
在中国，这个问题更明显。优秀工程师往往更愿意去互联网公司、AI 公司、平台型科技企业，工作对象主要是代码、系统和产品，而不是客户现场。真正懂工厂、懂行业、懂流程的人，很多来自业务一线或传统咨询实施体系，但他们未必具备足够的技术抽象能力。
于是两类人经常断开。
懂技术的人不懂现场，懂现场的人不懂系统。
而 FDE 恰恰要站在两者中间，把业务问题翻译成技术问题，再把技术系统变成业务结果。
这不是靠短期培训就能批量制造出来的。
国内所谓"驻场"，常常只是成本转嫁
中国 ToB 市场当然也有大量驻场人员，但很多驻场和 FDE 的含义并不一样。
不少项目里的驻场，更像是客户把不确定性转移给供应商。系统上线后，有问题找驻场；需求变更找驻场；数据不对找驻场；流程卡住也找驻场。驻场人员成了项目里的缓冲垫，负责接住各种临时问题。
这种角色很辛苦，但并不一定拥有真正的决策权、设计权和产品改造权。
FDE 不只是"人在现场"，更重要的是"人有能力改变系统，也有授权推动结果"。
如果一个驻场人员只是被动响应需求，没有平台能力支持，没有组织资源支撑，也不能影响客户的业务流程，那他即便每天坐在客户办公室里，也很难创造 FDE 那种价值。
所以，FDE 的核心不是驻场，而是带着工程能力、业务判断和结果责任进入现场。
这也是它难以被简单复制的原因。
AI 时代，企业服务会越来越需要 FDE 式能力
有意思的是，虽然 FDE 模式在中国很难复制，但它所代表的方向，可能会变得越来越重要。
因为企业软件正在发生变化。
过去，软件本身很值钱。一个系统、一个模块、一套流程工具，都可以成为独立产品。但随着云服务、低代码、开源工具和 AI 能力的发展，很多标准化软件功能会越来越便宜，甚至会被快速商品化。
真正昂贵的东西，会从"软件功能"转向"问题解决"。
企业不缺工具，缺的是有人能判断：到底该解决哪个问题？数据为什么没有用起来？流程为什么跑不通？AI 应该嵌入哪个环节？哪些决策可以自动化，哪些必须由人负责？
这些问题不是单靠一个模型、一个平台、一个 SaaS 产品就能解决的。
它需要有人进入企业内部，把业务、数据、组织和技术放在一起重新梳理。
从这个意义上说，FDE 不是 Palantir 的特殊岗位，而是 AI 时代企业服务的一种预告：未来的软件公司，如果只卖工具，价值会被压低；如果能帮助客户定义问题、改造流程、承担结果，才有机会获得更高议价权。
中国 ToB 要补的课，不只是技术
中国企业软件行业过去很擅长几件事：快速开发、低价竞争、项目交付、功能堆叠、客户响应。这些能力在过去二十年支撑了大量信息化建设，也确实有价值。
但下一阶段，仅仅会做功能可能不够了。
企业客户真正需要的，不只是一个系统，而是经营效率的提升；不只是一个数据平台，而是更好的决策机制；不只是一个 AI 工具，而是可以落地的业务改进。
这要求供应商从"交付软件"转向"共创结果"。
而要做到这一点，客户也必须改变认知。不能一边要求供应商深度理解业务，一边拒绝为这种理解付费；不能一边要求结果，一边只按照功能点采购；不能一边希望长期陪伴，一边把合作关系做成一次性项目。
FDE 在中国难以复制，不是因为中国缺工程师，也不是因为中国企业不努力，而是因为整个市场还没有形成支持它生长的土壤。
客户不愿意支付探索成本，供应商缺少足够利润空间，项目关系又过于短期，复合型人才也不充足。几个因素叠加在一起，就让 FDE 看起来很美，却很难真正落地。
Palantir 给中国 ToB 行业最大的启发，不是"赶紧也设一个 FDE 岗位"，而是提醒我们：企业服务的价值，正在从功能交付转向问题解决。
谁能离客户的问题更近，谁能把技术变成可衡量的业务结果，谁才有机会在下一轮企业软件竞争中获得更高价值。
但这一步，不是改个岗位名称就能完成的。
它需要客户、供应商、合同机制、人才结构和利润模型一起变化。否则，所谓学习 FDE，最后很可能只是把原来的实施工程师换一个更时髦的名字。