怎么判断一家 FDE 服务商靠不靠谱：一份买方尽调清单

这篇文章是给采购方用的工具，不是我们的自我推销。 清单里的问题你可以拿去问任何一家候选供应商，包括我们。愿意正面回答这些问题的供应商，通常也更值得合作 —— 因为这些问题里有一半，靠临时编是编不出来的。

一个前提：这个行业目前没有公认的第三方认证，也没有权威的服务商排名。所以判断只能靠提问。下面按五个关卡组织，从“我到底需不需要”到“什么时候该喊停”。

第一关：先问自己（14 个问题里最关键的 5 个）

在评估供应商之前，先确认你要买的东西是清楚的。这一关过不了，后面都是浪费双方时间。

1. 这件事要改善哪个可测量的指标？ 不是“提升效率”，而是“这个环节平均 12 分钟，希望降到 4 分钟以内”。指标说不清，验收必然扯皮。

2. 数据在谁手上，拿得到吗？ 解决这个问题需要的数据存在吗？能取出来吗？质量够支撑判断吗？这是最常见的隐性卡点，也是延期最频繁的原因。

3. 谁是这个系统真正的使用者？他参与过讨论吗？ 如果答案是“IT 部门推动的，业务部门还没参与”，这个项目大概率上线即闲置。

4. 判断错了会有什么后果？ 适合先做的是“判断错了可以人工兜底”的环节。涉及资金、安全、合规的最终决策，现阶段应做辅助而非替代。

5. 我们内部有人能全职投入吗？ 指定业务专家并保证其时间是项目成败的第一变量。做不到就别开始 —— 这一点后面还会出现。

自检结论：如果第 1、2、5 题答不上来，你要的其实不是 FDE，而是先做一次场景梳理。

第二关：判断这件事是否值得派驻（9 个问题里的 4 个）

6. 这个需求是标准件吗？ 如果市面上已有成熟产品能覆盖，买产品更便宜也更快。这一关的作用是劝退 —— 一个从不劝退客户的服务商，要么筛选极严，要么什么单都接。

7. 为什么不能由我们自己团队做？ 诚实的答案通常是“内部没人能全职投入”或“缺少把业务翻译成技术的人”。如果答案是“我们自己也能做，只是没时间”，那你需要的是开发资源。

8. 我们能接受多长的验证周期？ 如果业务上要求三个月见效，而诊断加试点本身就要 1–2 个月，这个预期需要在内部先对齐，而不是压给供应商。

9. 这件事失败了我们能接受吗？ 试点投入打水漂的可能性真实存在。行业里超过 60% 的企业 AI 尝试停在试点阶段。先想清楚失败的可承受度。

第三关：这家供应商是真的在做 FDE 吗（最关键的一关）

这一关问题最多，因为“服务作坊”与真正的 FDE 团队从官网上看几乎一样。

3.1 人员真实性

10. 实际投入这个项目的是谁？他做过什么类似的？ 要问具体的人，不是公司介绍。“项目启动后再定人”是明确的危险信号 —— 说明你可能买到的是售前画的方案，交付另有其人。

11. 过去两周，这个人写过代码吗？ 行业里约三分之一的 FDE 岗位实际上是售前形态。这个问题能快速区分“工程师兼做客户沟通”和“售前换了个头衔”。

12. 如果这个人中途离开项目，怎么办？ 合格答案会包含人员名单进方案、变更提前告知、以及对你方的补偿或退出机制。

3.2 驻场强度与决策权

13. 你们的人在我们现场待多久？做什么？ 如果答案是“每周来开一次会”，那不是 FDE，是顾问。

14. 他有没有决策权，还是每件事都要回去请示？ 前线角色如果没有技术决策权，所有沟通都会变成两轮，效率减半。

3.3 沉淀与复用（这一组最能分辨真伪）

15. 第一个客户和第十个同类客户，分别需要多少工作量？ 判据来自前 Palantir 高管 Bob McGrew：如果第一个客户需要 10 个人月，第十个同类客户仍然需要 10 个人月，这个模式没有跑通。

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

17. 你们劝退过客户吗？举一个例子。 这是测诚实的题。答案应该包含具体场景和判断依据，而不是“我们都会尽力满足客户需求”。

3.4 交接设计（全行业最少被回答的一组）

行业里对这件事最尖锐的描述是：风险不在于用了外部帮助，而在于合作结束时企业变得更没有能力、更依赖外部。 下面五个问题几乎没有人会在方案里主动提，但每一个都决定了你以后能不能自己维护这套系统。

18. 运行监控与日志归谁？ 如果你看不到系统在调用什么、失败在哪、效果有没有衰减，我们一走，你对系统的可见性就一起走了。

19. 效果评测套件（评测数据 + 判定标准 + 脚本）交给我们吗？ 没有它，你无法判断某次改动是变好还是变坏，也无法在模型升级后确认系统还准不准。

20. 集成逻辑与配置以什么形式交付？ 如果字段映射和异常处理只存在于某个只有你们能改的配置文件里，我们实际上没有拿到这个系统。

21. 有没有运行手册和决策记录？ 包括常见故障怎么处理、哪些参数不能随便改、当初为什么这么设计。没有决策记录，下一个接手的人会重复已经踩过的坑。

22. 这套系统每月的运行成本是多少，什么情况下会突然变贵？ 行业里有一条被反复引用的成本事实：部署大概占总成本的 20%，另外 80% 是让系统在模型升级、数据漂移和边缘情况中持续运行。多数方案只给第一部分定价，然后把后面当成理所当然。

实用判断法：问一句“你们离开之后，我们自己能改哪些、不能改哪些”。如果答案里有很多“这个得找我们”，那不是技术限制，是商业设计。

3.5 角色错配

23. 你们会不会建议我们不做？什么情况下会建议？ 没有这个机制的供应商，会在发现方向不对时继续做下去 —— 因为停下来对他是损失。

24. 你们同时在做几个项目？ 如果一个人同时挂在五个项目上，他在你现场的时间和质量都可推算。

第四关：合同怎么签（12 个问题里的 6 个）

25. 验收标准谁定、什么时候定下来？ 必须开工前书面确认。行业里最高频的抱怨就是“客户一句’这里再改一下’，验收就得继续往后推”。

26. 半途发现关键假设不成立，怎么结算？ 按阶段结算、允许中途停止的供应商，说明对自己的判断有信心；要求全额预付或按人天清算的，风险在你这边。

27. 范围蔓延怎么处理？ 合格的答案是“变更记录为下一期输入，不吸收进本期”。范围蔓延是试点失败的首要原因。

28. 数据访问范围、访问身份、审计留痕怎么约定？ 要能落到合同条款上：谁能看什么、以什么身份看、日志保留多久、你是否可以随时调取。

29. 我们承担的是固定总价还是工程量？ 固定总价不一定更安全 —— 有审计结论指出，固定总价会激励供应商把评测套件做薄，因为省下的评测工作量直接变成他的利润，而效果风险留给了你。

30. 上线之后谁负责？出问题多久响应？ 大量 AI 项目死在上线后三个月。没有明确维护责任人与响应时限的交付是不完整的。

第五关：什么时候该喊停（红旗信号）

出现以下任意一条，建议暂停而不是继续投入：

1. 人员迟迟不确定，或反复更换对接人
2. 只谈能力不谈边界 —— 从不说明自己做不到什么
3. 拒绝写验收标准，或一直往后推“等做完再定”
4. 数据边界说不清，或明确表示要用你的数据训练模型
5. 演示很好但拿不出在真实数据上的评测方法
6. 所有问题都由同一个人回答，且他明显不是实际交付的人
7. 交接设计问题被回避，或答案是“这些你不需要关心”
8. 承诺的指标只有形容词（“显著提升”“大幅降低”），没有可测量的定义

一页纸总结：决策表

关卡	核心问题	不合格的处理
一、自检	指标、数据、使用者、兜底、内部投入	先做场景梳理，不找供应商
二、是否值得派驻	是否标准件、为何不自建、周期、失败可承受度	买产品，或先补内部能力
三、供应商真伪	人员、驻场强度、决策权、沉淀、交接设计	换一家，或缩小到单场景试点
四、合同	验收标准、结算方式、范围变更、数据条款、维护责任	不签，先把条款谈清
五、红旗	见上 8 条	立即暂停并复盘

最后一句实话：这份清单最大的价值不是帮你选到最好的供应商，而是帮你排除掉不合格的。 在这个还没有公认标准的行业里，能排除掉一半候选，判断质量就已经大幅提升了。

---

如果你正在评估几家供应商，可以先用第一关的五个问题自检一遍。如果结论是“我们需要先想清楚要做什么”，那正是我们做诊断的场景；如果你只是想找人对一下判断，直接联系我们也可以。相关的判断依据还可以看《FDE 和外包到底有什么区别》与《企业什么时候真的需要一个 FDE》。