为什么 FDE 最后很容易做成外包
FDE 不是岗位名，而是一种交付模式；它最后之所以常常做成外包，是因为合同、KPI 和组织机制这三样东西，还停留在「卖人头」的默认设置里。
上篇我聊了一个问题：FDE 真正该较真的，是项目结束留下了什么。写完有读者反问：既然大家都知道要留下能力，为什么最后做着做着还是变成外包？
这是个好问题。我们在自己复盘过的项目里也反复看到：名字换成了 FDE，做法还是驻场外包。问题不在人不够聪明，而在三个默认机制没改。
一个常见的结局：系统留下了，能力没留下
腾讯研究院 2026 年 8 月那份《FDE模式行业观察与实践》里有一个判断，我印象很深：只留给客户一个系统，是外包；带回经验却无法复用，是项目制；把现场经验转化为 Skill、模板、测试集或产品能力，才是 FDE。
这个区分很准。但我在前线看到的情况是：很多项目连「项目制」都算不上，就是换了名字的驻场外包。
典型的流程是这样：客户签了一个 AI 落地项目，供应商派两三个人长期驻场。他们确实比客户更懂 AI，也确实把系统接进去了。验收时功能清单都打勾，业务方也觉得「挺好用」。但一段时间后，人一撤，客户发现自己手里只有一套系统文档，遇到新问题还得再找人。
更麻烦的是，供应商那边也没有变得更聪明。第二个同类客户进场，交付团队还是从零开始踩一遍坑。第一个项目吃过的亏，第二个项目照吃不误。
这就是外包的标志性结果：双方都在为「人头时间」付费，而不是为「可复用的能力」付费。
三个默认机制，把 FDE 拉回外包
为什么名字改了，结局没变？国内 ToB 团队很容易把 FDE 套回过去十几年的旧框架，因为三个默认机制没动。
第一，合同还是按人头计费。
外包和 FDE 的分界线，首先写在合同里。外包的典型计费方式是「人天/人月」；FDE 的计费方式应该更接近「阶段交付、按结果验收」。
但很多企业不敢按结果签，因为结果太难定义。于是合同退回安全模式：派几个人，驻几个月，按人头付钱。人一签合同，行为就被锁死了——团队只会关心「我有没有按要求到场」，不会关心「这次能不能把经验带回去复用」。
范冰在《前线部署工程师》（开源版 v1.0.6，2026 年 8 月）里把这个点讲得很直接：国内第一批打出 FDE 旗号的服务商，划清过外包和 FDE 的边界——驻场按工时算钱，FDE 按阶段交付、按结果验收。但落到真实采购里，按人头签仍然是主流。
第二，KPI 只验收功能上线，不验收能力沉淀。
很多项目的验收标准，到「系统上线、功能可用」就结束了。有没有沉淀出可复用的 Skill？有没有把行业接口、测试方法、失败案例带回来？这些不在验收范围里。
结果是前线团队天然倾向「做完就走」。写文档、抽模板、反哺产品，这些事情当期看不到回报，也没人考核。不做，项目照样验收。
腾讯研究院那份报告里有一句话：FDE 中的「部署」，关键不是安装系统，而是把模型、数据、流程、权限、组织责任和业务指标部署成可持续运行的结果。如果 KPI 里只写「安装完成」，它自然就会退化为外包。
第三，前线人员没有回流通道。
这是最隐蔽的一点。很多公司不是不想沉淀，而是不知道怎么让前线经验流回组织。
前线工程师天天在客户现场，最懂痛点。但回到公司，没有固定的机制让他把经验变成产品能力：没有 Skill 模板库，没有失败案例归档流程，也没有人专门负责把现场发现变成下一个版本的输入。于是经验锁在个人脑子里，人一跳槽，知识跟着走。
报告里把这种现象叫「现场做得越深，对个人经验的依赖越重；规模越大，利润越薄」。传统系统集成靠堆人解决问题，堆到最后就是人力生意。FDE 如果不能把现场经验沉淀成平台能力，本质上也是在走这条老路。
一个历史对照：定制化为什么是 SaaS 的天敌
范冰在那本小书里写到一个老问题，我觉得对理解 FDE 很有用：中国企业软件行业早就在沟里躺了十几年——大公司要定制，厂商做一单赔一单，交付完代码离场作废，最后集体沦为「甲方的外包公司」。
这个循环很多人都熟悉：客户提差异化需求，销售为了签单全部答应，交付团队进场后才发现定制成本远高于报价。项目做完，厂商没赚到钱，客户也没得到持续迭代的能力。下一轮客户再来，一切从头开始。
FDE 的出现，本是为了打破这个循环。它的核心假设是：AI 降低了原型开发、流程编排和系统适配的成本，让「深度贴合客户业务」这件事变得经济可行；同时，前线经验可以被沉淀为可复用的 Skill 和本体层，让下一次交付成本下降。
但如果合同、KPI 和组织机制不改，这个假设就不成立。低成本原型 + 高成本驻场，最后只是让客户用更低的门槛拿到一个更贵的「定制外包」。
我们在前线用的防外包检查清单
在我们自己复盘过的企业 AI 落地项目里，判断一个项目是不是正在滑向外包，一般用下面这五条快速自检：
| 检查项 | 外包信号 | FDE 信号 | | --- | --- | --- | | 计费方式 | 人天/人月 | 阶段交付 + 结果验收 | | 验收标准 | 功能上线即可 | 必须沉淀 Skill/模板/测试集 | | 知识回流 | 无固定机制 | 有案例入库和 Skill 迭代流程 | | 同类项目成本 | 第十个和第一个差不多 | 第十个明显比第一个便宜/快 | | 客户自助能力 | 长期依赖驻场 | 能培训客户团队独立运维 |五条里面只要有两条以上偏左，这个项目就很可能正在变成外包。
说到底，FDE 改的是账簿
Palantir 第 13 号员工 Shyam Sankar 当年改了这个账簿：在软件行业的账本里，为单个客户做定制叫服务，是利润率的敌人；他把它翻了过来——现场定制不是成本，而是产品发现。
这句话说透了 FDE 和外包的本质区别。外包的账簿里，驻场定制是成本，要尽量压缩；FDE 的账簿里，前线实践是投资，要从中提炼出能服务下一个客户的能力。
两个账簿对应两种完全不同的行为。成本视角下，团队会尽量减少在前线花的功夫；投资视角下，团队会主动花时间去抽象共性、沉淀模板、反哺产品。
所以，判断一个团队是不是真在做 FDE，不用看它的岗位名称，也不用看它有没有派人驻场，要看它怎么算账。
适用边界
FDE 不是万能药。它最适合业务复杂、流程有共性、且值得长期深耕的场景。一次性的小尝试、没有复用可能的纯定制项目，硬套 FDE 框架反而会增加交付负担。
另外，改合同、改 KPI、改组织机制，通常比换一个岗位名更难。如果你正在推动这件事，建议先从一条小切口开始：找一个有复用潜力的场景，把计费方式从人天改成阶段验收，把「沉淀一个 Skill」写进验收标准。
下一篇，我聊一个更具体的问题：Echo 与 Delta：AI 落地团队为什么不能只靠全能选手。