MVD最小可交付：不做大而全，只做最痛的那一点

💀 为什么第一个项目最容易失败

FDE的第一个项目，失败率极高。不是因为技术不行，而是因为"贪大求全"——客户想一步到位做个大而全的系统，FDE为了签单什么都答应，结果项目周期拖得很长、成本超支、效果达不到预期、客户不满意，最后项目烂尾。

一个真实的失败案例：深圳某货代公司想做AI客服，一开始跟FDE说"我们要做全时段AI客服，覆盖所有问题，全自动，不需要人工"。FDE觉得这个需求合理，就按这个范围做了。结果：知识库梳理花了2个月（因为客户的知识太散），模型调优花了1个月（因为复杂问题AI处理不好），上线后效果很差（复杂问题答错率高，客户投诉），最后客户说"这AI还不如不用"，项目黄了。

失败的根本原因：第一个项目就想做"大而全"，范围太大、不确定性太多、周期太长、风险太高。第一个项目的目标不是"做一个完美的系统"，而是"快速验证价值、建立客户信任、积累实战经验"。MVD就是为这个目标设计的。

🎯 MVD是什么：最小可交付

MVD（Minimum Viable Delivery，最小可交付）的定义：用最小的范围、最短的时间、最低的成本，交付一个能解决客户最痛问题的可用系统，验证AI方案的价值，建立客户信任，为后续迭代打下基础。

MVD有三个关键词：

关键词一：最小。范围要最小——只做最痛的那一个问题，其他都不做。时间要最短——2-4周交付，不是2-4个月。成本要最低——用最简单的技术方案，不搞复杂架构，能跑通就行。"最小"不是"简陋"，是"刚好够用"。

关键词二：可交付。MVD不是PPT、不是原型、不是demo，是一个真正能在客户环境中运行、能解决实际问题、客户能真正用起来的系统。可交付意味着：有真实数据、有真实用户、有真实效果。"可交付"不是"看起来能用"，是"真的能用"。

关键词三：验证价值。MVD的核心目标不是"做完一个功能"，而是"验证AI方案能不能解决客户的问题、能解决到什么程度、客户愿不愿意为这个价值付钱"。验证价值意味着：有明确的成功指标（比如"响应时间从32小时降到5分钟"）、有before/after的对比数据、有客户的真实反馈。"验证价值"不是"客户说挺好"，是"数据证明有效"。

MVD和MVP（Minimum Viable Product，最小可行产品）的区别：MVP是互联网产品的概念，强调"最小功能集验证用户需求"；MVD是FDE项目的概念，强调"最小交付范围验证业务价值"。MVP更偏向产品功能，MVD更偏向项目交付和业务效果。对FDE来说，MVD比MVP更实用——因为FDE做的是项目，不是产品。

✅ MVD的三个判断标准

怎么判断你选的MVD切口对不对？看三个标准：

标准一：痛点够痛。这个问题是不是客户真正痛的？痛到愿意付钱、愿意投入资源、愿意配合你做？如果客户只是"觉得这个问题也可以解决一下"，那不够痛，不要选。要选客户天天在抱怨、老板天天在催、一线员工天天在吐槽的问题。痛点够痛，客户才有动力配合你，项目成功了客户才会认。

标准二：切口够小。这个问题的范围是不是足够小？小到2-4周能交付、小到技术方案简单可控、小到不确定性少。如果切口太大（比如"做一个全功能AI客服"），那不是MVD，是大项目。要把大问题拆成小问题，选其中最小的那个。比如"AI客服"可以拆成：夜间客服、售后退换货客服、物流查询客服、售前咨询客服……选其中一个最小的。

标准三：效果可量化。这个问题的解决效果能不能用数据衡量？有没有明确的before基线？能不能算出after的预期效果？如果效果不可量化（比如"提升客户体验"），那项目做完了客户说"没感觉"，你就百口莫辩。要选效果能量化的问题，比如"响应时间从X降到Y""人工成本从X降到Y""错误率从X降到Y"。效果可量化，项目成功才有据可依，客户才会认。

三个标准都满足的问题，才是好的MVD切口。如果只满足两个，那需要再想想——要么痛点不够（客户不配合），要么切口太大（做不完），要么效果不可量化（客户不认）。

⚠️ MVD的常见误区

做MVD时，常见的五个误区：

误区一：MVD=简陋版。很多人以为MVD就是"做个简陋版，能用就行"。错了。MVD是"最小范围的完整版"——范围小，但在这个小范围内，功能要完整、体验要流畅、效果要达标。比如做夜间AI客服，范围只做夜间（小），但夜间的问题要能完整处理、回答要准确、用户体验要好。简陋版客户用两天就不想用了，完整版客户才会真正用起来。

误区二：MVD=技术原型。很多人以为MVD就是"做个技术原型，给客户看看效果"。错了。MVD是"可交付的系统"——要部署到客户环境、要用真实数据、要让真实用户用起来。原型只能"看起来能用"，MVD要"真的能用"。原型做完了客户说"挺好"然后就没下文了，MVD做完了客户天天在用，效果数据摆在那里，后续续约和扩展自然就来了。

误区三：MVD范围可以慢慢加。很多人做MVD时，客户说"再加一个小功能吧"，FDE觉得"就一个小功能，加吧"，结果一加再加，最后MVD变成了大项目。记住：MVD的范围一旦确定，就不能再加。客户要加功能，可以，放到二期。MVD的核心是"快速交付验证价值"，范围蔓延会直接毁掉这个目标。

误区四：MVD不需要考虑后续扩展。很多人做MVD时，只考虑当前的小范围，完全不考虑后续怎么扩展。结果MVD做完了，验证了价值，但架构太简陋，后续扩展要推倒重来。正确的做法是：MVD范围要小，但架构要留好扩展接口（参考F2-5的"留接口"方法）。这样后续扩展时，只需要加模块，不需要推倒重来。

误区五：MVD做完就结束了。很多人以为MVD做完了，项目就结束了。错了。MVD只是开始——MVD验证了价值，接下来要做的是：基于MVD的效果数据，跟客户谈二期扩展；基于MVD的经验，优化你的方法论；基于MVD的案例，打造你的标杆项目。MVD是"第一个项目"，不是"唯一的项目"。