FDE 和外包到底有什么区别？一条分界线讲清楚

一句话回答：外包卖的是人力和功能，FDE 卖的是判断力和可复用的方法。 分界线不在是否有人驻场 —— 驻场只是一种工作形式 —— 而在项目结束、人撤走之后，客户手里留下了什么。

这个区别听起来抽象，但在采购决策里它直接对应三件具体的事：你付的钱买到了什么、项目风险由谁承担、以及第二个类似项目你要不要再花一遍钱。

三层判断标准

第一层：项目结束后留下了什么

这是行业里目前最通用的一条分界线：

项目结束时留下的东西	这叫什么
只给客户一个能跑的系统，知识随人离开	外包
带回了经验，但下一个客户用不上，一切从头再来	项目制交付
把去掉客户信息的行业经验，沉淀成可复用的组件、连接器与模板	FDE
沉淀后显著降低下一个同类客户的交付成本	可规模化的 FDE

关键在第三行那句“去掉客户信息”。可复用的是行业通用的方法与组件，不是你的具体业务规则、数据或系统细节。这个边界必须在合同里写清楚 —— 口头承诺“我们不会用你的数据”没有意义。

第二层：用工作量验证，而不是用说法验证

一条来自前 Palantir 高管 Bob McGrew 的量化原则：

如果第一个客户需要 10 个人月，第十个同类客户仍然需要 10 个人月，说明这个模式没有跑通。

这条判据的价值在于它无法含糊回答。你可以直接问任何一家候选供应商：你们做的第一个同类客户和第十个，分别需要多少工作量？如果两个数字差不多，说明这家公司没有沉淀能力，你付的钱里没有方法，只有时间。

另一条常被引用的红线：单个客户占用的交付人力如果长期超过总量的 30–40%，业务实际上已经退化成高端人力外包。（F-Prime 的口径）

第三层：看它卖的是什么计价单位

这一层最容易被忽略，但最直白：

• 按人天/人月计价 → 卖的是时间。这种模式下，供应商的利益与“项目更快结束”是相反的。
• 按功能清单计价 → 卖的是实现。需求必须已经清晰，否则清单本身会成为争议来源。
• 按阶段范围计价 → 卖的是结果。范围清楚、验收标准前置、每阶段可停。
• 按业务指标计价 → 卖的是效果。理论上最理想，但指标定义极难，实践中容易扯皮。

一个诚实的补充：这四种模式没有绝对优劣。需求完全标准化、边界清晰的项目，按人天采购人力反而是最经济的。问题不在于哪种模式更高级，而在于供应商有没有告诉你他在卖什么。

采购方可以直接用的提问清单

下面七个问题，问任何一家候选供应商都能用。它们的设计思路是：答案必须具体到无法临时编造。

1. “第一个客户和第十个同类客户，分别需要多少工作量？” 问的是沉淀能力。含糊的回答通常是“每个客户情况不同”——这句话本身没错，但用它回避一个数量级判断，说明对方没有积累。

2. “项目结束时，除了系统，你们会留下什么？” 好的答案会具体到组件、连接器、模板、评测集这类可复用产物。如果答案是“完整的文档”，注意：文档是交付的一部分，不是沉淀。

3. “举一个你们劝退客户的例子。” 从来没有劝退过客户的供应商，要么筛选极严（那是好事），要么什么单都接。

4. “验收标准由谁定、什么时候定下来？” 如果验收要到交付时才讨论，这个项目大概率会以扯皮收场。行业里对这件事的描述很直白：客户一句“这里再改一下”“效果还没达到预期”，验收就得继续往后推。

5. “实际投入这个项目的是谁？他们做过什么类似的？” 要问清具体的人，而不是公司的整体介绍。FDE 的交付质量高度依赖个人。另外，“项目启动后再定人”是一个危险信号 —— 这说明你可能买到的是售前团队画的方案，交付团队另有其人。

6. “数据怎么用？会不会进入你们给别的客户做的方案里？” 这个问题问的是沉淀的边界。合格的答案必须能落到合同条款上：数据访问范围、以什么身份访问、如何留痕、哪些数据不得离开你的环境、项目结束后如何处理。

7. “上线之后谁负责？出问题多久响应？” 大量 AI 项目死在上线后三个月：模型漂移、数据分布变化、业务规则调整，然后没人管。没有明确维护责任人的交付是不完整的。

什么情况下你其实只需要外包

这是本文最想讲清楚的一点：FDE 不是更高级的外包，它只是适合不同的问题。

以下情况找传统外包或直接买产品更划算：

• 需求已经标准化。 你知道要什么、市面上有成熟产品能覆盖 —— 买产品比自己开发便宜也更快。
• 需求已经完全清晰。 你能写出一份开发人员照着就能做的需求文档，那你要的是开发资源，不是 FDE。
• 要的是长期稳定的执行人力。 例如日常功能迭代、维护、测试。这类工作按人天采购是最经济的方式。
• 内部有能判断该做什么的人。 如果团队里已经有人能清晰回答“做什么、做到什么程度算完成、谁验收”，FDE 的核心价值（场景判断）就不稀缺了。

反过来，FDE 真正值钱的地方是需求本身模糊的时候。一位一线从业者的说法很准确：客户如果能准确说清楚自己想要什么，他可能也不会来找 FDE。

一个容易忽略的风险

最后提醒一件在中国市场特别常见的事：供应商承诺得越漂亮，越要警惕。

行业里“AI 落地”项目最典型的失败模式，是技术指标做得很好但业务不买单：演示环境跑得通、真实数据上不准；或者效率指标上去了，利润没有变化。有从业者描述过这种落差：部门一个月多产出上千份文档，在老板眼里只是多烧了一笔算力费用。

判断方法其实很简单 —— 要求供应商把承诺写成可测量、可复现、能写进验收标准的东西。凡是只能写成形容词的承诺（“显著提升效率”“大幅降低成本”），在验收环节都会变成争议。

---

分界线讲完了，剩下的问题是你自己的场景落在哪一侧。可以继续看《FDE 是什么？前沿部署工程师完整指南》与《企业什么时候真的需要一个 FDE》，或者直接联系我们做一次诊断 —— 如果结论是你只需要外包，我们会直接说。