最小可行部署

MVD（最小可行部署）：用最小工程投入，在真实环境里验证一次价值的真实发生。

互联网讲 MVP（最小可行产品），验证「要不要做这个产品」；FDE 讲 MVD（最小可行部署），验证「这个方案在这个客户身上能不能产生价值」。一字之差，差在裁判。

读完你能回答：

• MVD（最小可行部署）和 MVP 的区别，为什么「先跑起来」优先
• MVD 的验证周期为什么按「周」而不是按「月」算
• 怎么用早期真实数据去撬动更大范围的采纳

第一条：真实数据，没有例外

用脱敏样例或构造数据做验证，是概念验证坟墓的第一块砖。真实数据里藏着魔鬼：字段含义与文档不符、三成空值、两个互相矛盾的「正确答案」。硬杠只有一条：客户必须带自己的真实业务数据来。在假数据上成立的方案，上线那天会遇到文档里不存在的字段——那时已付了真价钱。

第二条：缩小范围，不减深度

常见错误是把 MVD 理解成「阉割版的大方案」。正确做法是不砍方案的深度，只砍覆盖的面：不追求「覆盖全公司智能客服」，而是「只覆盖退换货工单但做到端到端无人干预」。切口小到价值密度足够高，高到业务部门肉眼可见、主动传播。法律 AI 公司 Harvey 的扩张路径是现成的例子：英国律所 Ashurst 先做覆盖全所的范围试验，跑通之后才宣布全球合作——先在一个切口里做出可信的结果，再横向铺开 ashurst-harvey。

第三条：定死截止时间

MVD 的验证应该以「周」计，不是「月」。Palantir 那套被业内叫作「训练营」的打法是它的极端形态：客户带真实数据进场，FDE 团队驻场，几天之内一起做出能跑、能当场演示的原型。把周期定死的意义不在快，而在强迫诚实取舍：凡不能在这几周里体现价值的部分，都还不是核心价值。一个六个月的「最小验证」，几乎必然重新长成什么都想要的大项目。