在AI落地的复杂场景中，FDE（现场工程师）的价值远超传统认知。本文深刻剖析了FDE存在的本质原因——不是解决已被表达的需求，而是挖掘那些无法言明的真实需求。通过Palantir等经典案例，揭示了从'碎石路'到'高速公路'的规模化方法论，并指出AI时代更需要这种直面混沌的能力。文章将颠覆你对技术产品交付模式的固有认知。

一、一个反直觉的结论

先给出这篇文章的核心论点：

FDE存在的原因不是因为”客户的需求可以被现场工程师解决”，而是因为”客户的需求在大多数情况下无法被清晰表达”。

这个结论是反直觉的。如果我们相信技术产品应该”一通百通”——写一套代码、卖一万个客户——那FDE的存在本身就是一种效率悖论。为什么要把最贵的工程师派到现场，去做看似一次性的定制工作？

要回答这个问题，我们需要回到原点。

二、第一性原理追问：FDE到底解决什么根本矛盾？

让我们做一个思想实验。

假设你是2003年的Palantir，你的客户是美国情报机构。对方有一个极其复杂的问题——在海量加密通信中发现恐怖分子的活动模式。你去问他们：”你们有什么需求？”

对方答不上来。不是他们不想配合，而是他们自己也不清楚”需求”长什么样。他们只有一种模糊的、直觉式的感知——”我们需要更高效地发现威胁”，但无法把这个感知翻译成结构化的产品需求文档。

这就是FDE这个角色要解决的根本矛盾：

尖端领域的核心问题，往往无法在问题被充分理解之前被清晰定义。而要理解问题，你必须先踏入问题现场。

传统软件开发的流程是：需求定义 → 方案设计 → 编码实现 → 测试交付。这条流水线的前提是——需求可以在开发之前被充分定义。

但在AI落地的场景中，这个前提被打破了：

• 客户不知道AI能做什么、不能做什么
• 客户的数据和流程对产品团队是黑盒
• 客户甚至不知道自己以为的需求和真实需求的差距有多大

于是，一个先有逻辑颠倒发生了：你不能先定义再执行，你必须先执行才能定义。

FDE就是那个被派去执行、以便让定义成为可能的人。

三、重新理解”规模化”：不被规模化的表面，去规模化的是过程

现在我们来触碰”规模化”这个概念的本质。

传统认知中，”规模化”指的是同一套产品交付给越来越多的客户，边际成本趋近于零。这是SaaS的叙事，也是绝大多数人理解的规模化。

但FDE模式揭示了一个更深层的真理：

世界上最有价值的东西，往往是从那些看似”不能规模化”的事情中长出来的。

Peter Thiel有一句被反复引用的话：“We need scalably do things that can’t be scaled.”（我们需要规模化地做那些无法规模化的事。）

这句话听起来像是悖论，实际拆解一下，它包含三个层次：

第一层：识别”不能规模化的事”

哪些事不能规模化？

• 帮第一个客户想清楚他要什么（模糊需求 → 明确方案）
• 在客户的真实环境中打通第一个数据接口
• 用客户的语言解释AI的ROI
• 解决第一个”文档里没写但实际发生”的问题

这些事都无法被自动化、无法被标准化、无法被产品化。每做一次，都是从零开始。

第二层：设计规模化的方式

既然这些事本身无法被规模化，那什么可以被规模化？

是”做这些事的方法论”可以被规模化。

Palantir的Echo-Delta模式就是对这个问题的回答：

Delta团队（现场工程师）负责做那些”不能规模化”的事——驻场、摸索、迭代

Echo团队（产品团队）负责从Delta的经验中提取可复用的模式，沉淀为平台能力（Ontology）

Delta做的是”碎石路”——在沼泽地里先铺出一条能走的路，不管它有多粗糙。 Echo做的是”修高速公路”——把碎石路的经验抽象、泛化，铺成能服务更多客户的标准基础设施。

规模化的不是”每次铺碎石路”这个动作，而是”从碎石路到高速公路”这个转化机制。

第三层：飞轮效应

一旦这个机制建立起来，就会产生复利：

• 第1个客户：碎石路铺了3个月，高速修了2个月 = 5个月
• 第5个客户：碎石路铺了2周（因为有了经验库），高速几乎不用修（因为已有模块可用）= 2周
• 第50个客户：碎石路铺了3天，高速公路都是现成的 = 3天

Palantir的利润率能做到80%，不是因为它的收费有多高，而是因为它把”铺碎石路”的成本系统性降低了。

四、元认知视角：FDE的三层思维

如果把”铺碎石路”看作一种能力，那么这种能力本身也有层级。我从低到高排一个框架，你可以对照看看自己处在哪一层：

第一层：执行者思维（Doer）

• 被分配到客户现场，按需完成任务
• 关注”怎么做”——代码怎么写、接口怎么调、模型怎么部署
• 这是初级FDE或在传统驻场模式下工作的人
  

  第二层：设计者思维（Designer）

• 能够从客户需求中抽象出可复用的模式
• 关注”什么值得沉淀”——哪些问题是通用的、哪些是一次性的
• 这个层级的FDE开始具备”碎石路 → 高速公路”的意识

第三层：系统建设者思维（System Builder）

• 不仅会铺碎石路，还会设计”铺碎石路的方法论”
• 关注”如何让更多人学会铺碎石路”——知识体系、SOP、培训机制、量化评估
• 这是资深FDE和FDE团队Leader的思维层次

更高一层：元思维（Meta-Thinker）

• 理解”碎石路-高速公路”这个模式本身的价值，并且能判断什么时候该铺路、什么时候该修高速
• 关注”这个客户的潜在地基是否值得投资”——战略判断

大多数关于FDE的讨论只停留在第一层（执行者），少数能触及第二层（设计者），但真正让FDE模式产生巨大商业价值的，是第三层和元思维。

如果你只是会驻场写代码，你是工程师。如果你能在驻场中提炼出产品需求、反馈给产品团队、驱动产品演进，你才是FDE。

五、反面案例：为什么国内FDE容易沦为”驻场开发”？

理解了上面的框架之后，就能清楚地看到国内FDE实践的普遍问题。

很多国内企业对FDE的理解是：”找个工程师去客户那边坐班，出问题了现场解决。”

这本质上是在雇佣第一层思维的人，然后期望他产出第三层思维的结果。

问题出在三个环节：

第一，没有反馈闭环。工程师在客户现场发现了通用需求，但没有渠道、没有机制把它反哺给产品团队。驻场就是驻场，做完就完了。

第二，没有抽象能力。企业缺乏Palantir Ontology那样的底层抽象平台。即使FDE发现了可以沉淀的东西，也没有”高速公路”可以修——每次都是重新铺一条路。

第三，激励机制错位。干得好的FDE被”升职调回”的原因不是因为他干得好要奖励，而是因为”驻场太苦了调回来”——这导致最有经验的人离开了最需要他的一线。

这不是某一家公司的问题，是整个生态的土壤问题。但这并不意味着FDE模式在中国行不通——只是意味着需要更清醒地认识到：“碎石路”阶段会远比预期更长，而且这个阶段本身就是价值。

六、AI时代为什么放大了这个逻辑？

最后回到AI，解释一下为什么FDE在2026年突然爆发——因为这股风潮的底层逻辑和我们前面讲的”碎石路”逻辑完全吻合。

AI模型的特性决定了它比任何软件都更需要”现场调试”。

传统SaaS产品：你部署一套CRM，配置好了就能用，差异主要体现在UI和流程上。

AI产品（尤其是大型语言模型）：同一个模型的输出在不同企业的数据上可能是天壤之别。RAG的检索策略要调、Prompt要根据业务场景改、Agent的工具有赖于企业的现有系统——每一次部署都是一次”从零开始的探索”。

这不是Bug，这是Feature。

这意味着AI时代天然需要更多的”碎石路”——更多的现场探索、更多的模糊需求拆解、更多的试错和迭代。每一个部署都是一次”不能规模化”的事。

而谁能把”做这些不能规模化的事的方法论”变得可规模化，谁就在下一波AI落地竞争中占据制高点。

这就是FDE模式在AI时代的真正价值。

七、写在最后

最后，我想留一个问题给正在读这篇文章的你：

如果你的公司明天要招聘一个FDE，你希望他/她带着”第一层思维”来，还是”第三层思维”来？

大多数公司的答案会是”第三层”。但现实是，很多公司连给FDE发挥第三层思维的组织机制都没有。

一个真正有价值的FDE，不是因为他能写代码，而是因为他能把你公司的产品，从一个只能服务”一个客户”的定制解决方案，变成能服务”一类客户”的标准化产品。

这中间需要的，不过是从一条碎石路开始的勇气。

而这个世界上最贵的路，往往正是那些还没被任何人走过的路。