企业采购如何选择 FDE 团队 / 服务商

选择 FDE 服务商的评估维度、避坑指南、报价与验收建议，附带面试/评估问题清单。

一句话：看落地能力，而不是看 PPT

“FDE 服务商”不是统一认证类别，市场上可能是软件公司、咨询团队、系统集成商或独立顾问。无论名称如何，都要同时核验书面方案、工程能力和已交付结果：

能不能在约定周期内，把真实业务问题变成可评测、可运行、可维护的系统。

所以评估的核心不是“方案多漂亮”，而是“落地能力多强”。

五个评估维度

维度	看什么	为什么重要
案例	是否有同行业或同场景的落地案例	FDE 强调业务理解，同场景经验能大幅降低沟通成本
方法	是否有清晰的需求分析、MVP、迭代流程	好的 FDE 团队不会一上来就做大系统
团队	是否同时具备业务理解力和技术交付力	纯技术团队容易脱离业务，纯咨询团队容易落不了地
交付	是只给方案，还是给可运行的工具 + 培训	FDE 的交付物应该是能上线、能试用的
售后	是否提供持续优化和内部转移能力	工具上线后需要迭代，企业最终也要能自己维护

评估时可以问的 10 个问题

关于业务能力

你们做过哪些和我们行业类似的 AI 落地项目？
项目最初要解决的业务痛点是什么？最后怎么衡量的效果？
在项目过程中，你们怎么和业务部门沟通的？

关于落地能力

一个典型的 FDE 项目周期是多长？第一周会交付什么？
如果业务需求发生变化，你们怎么调整？
你们怎么保证 AI 输出的结果是可用的、可控的？

关于交付与售后

项目结束后，企业会得到什么？代码？文档？培训？
如果后续要我们自己维护，你们会提供什么支持？
项目失败或效果不好的情况你们遇到过吗？怎么处理？

关于安全合规

我们的数据会怎么处理？会不会用于训练外部模型？

避坑指南

坑一：只看 AI 技术参数，不看业务结果

有些服务商喜欢讲用了什么大模型、参数多少、推理速度多快。

但企业真正关心的是：

能不能解决我的问题
能省多少时间
能降低多少错误
员工愿不愿意用

建议：先做有代表性的付费小范围验证，周期根据数据、集成和风险确定；用预先约定的质量、采用和工程证据评估结果。

坑二：项目范围一开始就太大

“我们要做一个全公司统一的 AI 平台”——这种项目往往死得很快。

建议：从一个部门、一个具体场景开始。验证价值后，再考虑扩展。

坑三：合同里没有数据归属和保密条款

FDE 项目通常需要接触企业内部数据、流程、文档。

建议：合同里明确：

数据归属
知识产权归属
保密义务
是否允许用于模型训练
项目结束后数据如何销毁或移交

坑四：没有验收标准就开工

FDE 项目容易因为“感觉不够好”而无限拖延。

建议：在开工前明确：

要交付什么功能
要达到什么效果指标
试用期多长
多少人参与试用
什么叫“验收通过”

坑五：没有内部Owner

如果企业自己没有一个人负责对接、推广、收集反馈，项目很容易烂尾。

建议：每个 FDE 项目都要指定一个内部 Owner，最好是业务部门的人，而不是 IT 部门单方面推进。

报价模式参考

模式	适合场景	注意点
按项目固定价	需求相对明确的小项目	范围变更需额外约定
按阶段付费	MVP + 迭代扩展	每阶段有明确交付物和验收标准
按月驻场	长期陪伴型企业	需要明确月度产出
效果对赌	效果能量化的场景	指标定义要清晰、可验证

建议：第一次合作优先选“按阶段付费”，先验证服务商能力。

验收标准清单

一个 FDE 项目通过验收，至少应该满足：

工具能跑通真实业务流程
关键用户接受过培训，能独立使用
数据安全和权限已配置
有明确的使用文档
能量化展示效果数据
有后续迭代计划或维护方案

一个小建议：先做 PoC

PoC（Proof of Concept，概念验证）是降低首次合作不确定性的一种方式，但不是所有项目都必须采用，也不能替代安全、合同和生产能力评估。

方式：

选 1-2 个具体场景
根据复杂度、依赖和风险约定验证周期
付一笔小额 PoC 费用
看交付物、看业务反馈、看团队配合度

通过 PoC 可以观察团队理解问题、处理反馈和交付证据的方式；长期运行能力仍要通过架构、代码、评测、运维和客户参考继续核验。

采购前可直接下载供应商 RFP 核对清单。