什么样的项目不适合

也诚实地说不适合的情形：

• 需求已经写得非常清楚——买几套现成 SaaS 就能解决，找 FDE 是杀鸡用牛刀
• 只需要纯 UI 外包——设计稿到代码的转化，找专业前端外包更合适
• 业务环境不能开放——安全合规不允许外部驻场，或者业务方没时间参与，FDE 模式没法落地
• 预算是"给一次钱、拿一次货"——FDE 是持续合作的模型，不适合一锤子买卖

更深的三种"看似适合、其实错配"

有些项目表面上有需求、有预算、有场景，但底层机制装不下 FDE，硬塞进去只会两败俱伤：

1. 没有产品底座
交付方手里没有一个平台/产品底座，从零开始现写。这种情况下所谓的 FDE 会退化成纯定制外包——客户付了 FDE 的价，拿到的是外包的东西。辨别方式：问一句"你们平台的边界是什么？哪些能力是底座、哪些是每次现场定制？"——答不上来的，业务本质就不是 FDE。

2. FDE 被当成人天来卖
计费按工时、KPI 按驻场天数、越驻越久越赚钱——这种商业模式跟 FDE 的机制完全相反。FDE 的正向激励是**"越快让客户团队独立、越快回流经验到产品"，按人天计费会把这个方向反过来。有一条圈内评论说得挺犀利——"有人把 FDE 当品牌跳板，有人说是挂着酷头衔的咨询，两种都对，关键看公司让不让现场学习回流产品。"**

3. FDE 向销售线汇报
组织结构上，FDE 应该汇报给产品或工程线，让"回流"这件事有制度保障。如果 FDE 汇报给销售，最后会沦为售前人力池——每个项目做完就散、经验不进产品线、下一次进新客户还是从零开始，等于养了一支很贵的售前技术支持团队。

一条最直接的判断

McGrew 的说法是——产品开箱即用的领域不需要 FDE，那堵墙没那么高，一个咨询顾问 + 一个交付经理就够了。FDE 是给"墙很高、demo 与生产之间落差巨大"的场景准备的。用错场景既浪费预算，也委屈这个岗位。