FDE 是什么：把方案和验证合成一件事

传统咨询的交付顺序是：调研、方案、开发、上线。

这个顺序在稳定业务里没问题。在 AI 场景里经常失效：方案写完，业务已经变了；系统上线，需求已经换了。

FDE 把这个顺序倒过来。

一、FDE 的原始场景

FDE（Forward Deployed Engineer，前线部署工程师）这套方法，最早由 Palantir 在情报与国防场景中打磨出来。

场景特点是：问题极其复杂，需求在开始时说不清，而且等不起。

做法是把工程师直接派到客户现场，和业务人员坐在一起，用最短时间做出一个能跑的版本，在实际环境里验证。可行就扩，不可行就换。

这套方法后来被用于制造业、医疗、金融等复杂场景，成为大中型企业 AI 转型的一种范式。

二、和传统咨询的三个区别

**区别一：交付物不同。** 传统咨询交报告，FDE 交能跑的系统。报告可以被搁置，能跑的系统不能。

**区别二：验证时点不同。** 传统咨询在方案评审时验证，FDE 在真实数据上验证。前者验证的是逻辑，后者验证的是可行性。

**区别三：失败成本不同。** 传统咨询失败了，损失的是咨询费和时间；FDE 的失败发生在最小可用版本阶段，损失被控制在 4 到 8 周内。

三、三个角色怎么配合

**Echo：业务策略顾问。** 决定做什么、为什么做。要能听懂一号位的战略意图，也要能判断哪件事值得先做。

**Delta：前线开发工程师。** 把想法跑出来，验证可行。需要同时懂业务和技术，能在现场做决策。

**Dev：工程部署团队。** 把验证过的版本做快、做便宜、做稳定。负责规模化。

三个角色的边界很重要。混在一起，会出现"做出来但没人敢用"或者"能规模化但业务不认"的情况。

四、为什么大组织更需要它

规模越大，纸面方案与真实运行的差距越大。

原因有三：流程长，方案传到执行层已经变形；部门多，接口处的模糊地带最多；历史包袱重，新东西容易和旧系统冲突。

FDE 的作用是把这个差距提前暴露。在小范围、真实环境里跑一遍，比在会议室里推演十遍都准。

五、什么时候不该用

FDE 不适合两类场景。

**第一类，问题已经很清楚。** 比如标准化的报表自动化，直接用成熟工具更快更便宜。

**第二类，组织没有准备好。** FDE 需要业务部门深度参与，需要一号位支持。如果没有，工程师会被当成外包，做出来的东西没人用。

一个判断

AI 转型的失败，多数不是技术失败，是"做出来的东西没人用"。

FDE 的价值不在于技术更强，而在于它把"有没有人用"这个问题，提前到了第一周。

---

*本文观点来自开锐·锐智（iKRC）在 FDE 交付方法上的实践与研究方法。*