1.4 三个陷阱

概念：FDE 最容易踩的三个坑

知道了 FDE 是什么，还得知道什么"不是 FDE"。以下三个陷阱是最常见的"伪 FDE"模式，每个都看起来像 FDE，但实质上没有完成"学习沉淀"这个核心动作。

陷阱描述：团队贴了 FDE 标签，人也派到客户现场了，但工作方式还是传统的"需求调研 → 系统配置 → 交付走人"，没有任何沉淀动作。

识别信号：

本质原因：把 FDE 理解成了"位置"（在前线），而不是"机制"（在前线学习并沉淀）。人在前线，但工作模式没变。

陷阱描述：FDE 到客户现场做了调研，把需求"传"给后方的开发团队，后方团队做完再"传"回来给客户验收。FDE 变成了"传话筒"。

为什么是陷阱：

传话式 FDE 的问题在于"信息损耗"。就像玩传话游戏，第一个人说"帮我买杯咖啡，要少冰"，传到第五个人变成了"他要个杯子"。在 AI 项目里，这种损耗尤其严重：

本质原因：把 FDE 理解成了"前端销售 + 后端开发"的分工模式，但 FDE 的核心价值是"判断和执行在同一处完成"——在客户现场直接做判断、直接出方案，而不是传话。

**⚠️ 风险提示：**不是说 FDE 不能有后方团队支持。后方团队可以做 Delta 的重活（开发、集成），但 Echo（判断）必须在现场完成。判断和执行可以分工，但不能中间隔一个"传话层"。

陷阱描述：管理层用传统项目交付的指标考核 FDE——交付周期、客户满意度、Bug 率——但完全没有考核"沉淀了多少能力"。

为什么是陷阱：

考核决定行为。如果考核只看"做得多快"，FDE 自然会牺牲沉淀时间来赶交付——反正沉淀没人考核，干嘛花时间做？结果就是：每个项目都按时交付，客户也满意，但平台能力原地踏步，一年做了 20 个项目，平台还是那个平台。

正确的考核维度应该包含：

本质原因：管理层仍然把 FDE 当"交付团队"考核，没有认识到 FDE 的核心产出除了"客户系统"，还有"平台能力增量"。