一个持续被问的问题

"FDE 不就是高级外包吗？"

这个问题之所以被反复问到，是因为从表面看，FDE 和外包确实有相似之处：都是去客户那边干活，都在解决客户的问题。但如果你深入理解两者的工作方式和激励结构，会发现它们是完全不同的模式。

三个核心分界

分界一：结果责任 vs 工时交付

维度外包FDE
交付物 代码、文档、人月 双方约定的业务结果或结果证据
验收标准 功能完成、测试通过 用户在用、业务指标按约定得到验证
激励 通常按工作包、工时或人力交付 计费方式可以不同，但结果责任必须单独写进合同
风险承担 按合同约定验收、变更和风险责任 对生产结果、边界和风险承担有明确约定

因此，不能仅凭“按人天计费”或“驻场”就给项目贴标签。真正需要审查的是合同是否写清了业务结果、验收证据、生产责任、变更范围和风险接受方式。计费方式可能多样，但没有结果边界的 FDE 宣称很难被验证。

分界二：产品回流 vs 一次性交付

FDE 模式中一个经常被忽略的核心机制是产品回流（Product Feedback Loop）。

在一些公开的 FDE 实践中，客户现场发现的需求、踩过的坑和开发的工具，会被系统性地反馈给产品或核心工程团队，尝试变成通用能力。比如：

  • 某个客户需要的数据格式转换 → 变成平台通用的 Adapter
  • 某个行业的安全合规要求 → 变成产品的内置合规模块
  • 某个客户的 Agent 工作流模式 → 变成可复用的模板

如果合同只要求把代码交付给客户，而没有产品反馈、复盘和资产归属机制，这个回路就很难自然发生。是否存在回路，要看实际流程和证据，不能由公司名称推断。

分界三：资产复用 vs 从零开始

有产品回流和资产治理机制时，FDE 团队才有机会在相近项目中减少重复探索。哪些内容能复用、复用多少、适配成本多高，都需要用第二个场景的变更记录、测试结果和交付时间来验证，不能预先承诺固定比例。

灰色地带：不是所有自称 FDE 的都是 FDE

需要诚实地指出：市场上确实存在"FDE 外包化"的趋势。一些公司打着 FDE 的旗号，做的还是人力派遣的事情。判断一个 FDE 团队是否真的在做 FDE，可以问这几个问题：

  1. 交付合同怎么写？——按人天还是按成果验收？
  2. 有没有产品回流机制？——FDE 在客户现场学到的东西，有没有变成组织能力？
  3. 第二个相近客户的交付效率是否有证据改善？——如果每次都从零开始，应追问资产、测试和反馈机制，而不是直接下结论。
  4. FDE 的绩效怎么评？——按代码行数还是按客户业务指标？

FDEr.ai 的判断

FDE 和外包的区别不应该用“是否驻场”或单一计费方式来判断。驻场只是工作方式，计费只是商业安排。更可靠的分界是：双方是否共同定义结果证据，是否有人对生产采用负责，现场经验是否经过授权、测试和版本管理后沉淀为组织资产。

对于正在评估 AI 落地方式的企业来说，关键不是选择"用 FDE 还是用外包"，而是确保你的合作方有正确的激励结构：

  • 如果只需要补充人手完成确定性任务，外包可能更合适
  • 如果需要在不确定的 AI 场景中探索并交付业务结果，FDE 模式更匹配
  • 如果合作方同时能提供产品能力（工具、模板、平台），那才是 FDE 模式的完整形态

行动建议

  1. 在选择 AI 落地合作方时，先明确你需要的是"人手"还是"结果"
  2. 要求合作方说明验收方式、产品反馈机制、资产归属和复用证据
  3. 不要仅凭“按人天计费”或“驻场”判断模式，先检查生产责任和业务结果是否写进合同