2010年左右，Eric Ries的《精益创业》风靡全球。

我们那时做MVP（最小可行性产品）的套路非常简单：砍功能。

先把核心流程跑通，哪怕后台全是手动配置，哪怕界面丑一点，只要用户愿意用，就证明路子对了。

那时候的MVP，验证的是“需求”。 逻辑是确定性的：代码写了，功能就在那里。用户点一下，它就动一下。

但在AI时代，这套逻辑失效了。

太多AI创业团队，做了一个看起来很炫的MVP：对接了OpenAI的API，套了个壳，Demo演示时惊艳全场。

但一推向市场，用户立刻弃之如敝履。

为什么？

因为AI是概率性的，是有语境依赖的。

传统MVP验证的是“这东西能不能跑”，AI MVP需要验证的是“这东西有多聪明，以及它会不会犯傻”。

如果在AI项目的初期，你只盯着“功能是否上线”，而忽略了“智能是否可用”，那你做的不是MVP，而是“最低级废弃品”（Minimum Viable Junk）。

一、 警惕“演示效应”：Demo不等于产品

AI产品最擅长的是“欺骗”。

你在Demo里问它三个精心准备过的问题，它对答如流，逻辑严密。

你会觉得：“哇，这就成了！” 但真正的用户不会只问这三个问题。他们会问各种刁钻的、边缘的、甚至是带有恶意的攻击性问题。

AI MVP的第一个坑，就是“过拟合”于Demo。

真正的MVP，必须包含“真实世界的噪音测试”。

不要在内部自嗨，要把原型扔给一小撮真实的种子用户。

只有当面对他们那些乱七八糟的输入时，你的AI没有出现“幻觉”或“胡言乱语”，这个MVP才算立住了。

二、 “绿野仙踪”式MVP：先验证逻辑，再上AI

对于AI初创项目，我有一个反直觉的建议：最快验证MVP的方法，往往是不用AI。 在《精益创业》里，这叫“绿野仙踪法”：屏幕背后其实是一个人，而不是一台电脑。

在AI项目里，这意味着：在接入大模型之前，先用“人肉智能”跑通流程。

场景： 你想做一个法律合同自动审查的AI。

• 错误做法： 一上来就调通GPT-4，写各种Prompt，试图让它直接出结果。

• 正确做法： 找几个法律系实习生。用户上传合同 -> 实习生人工审查 -> 系统把实习生批注的结果展示给用户。
  如果用户觉得实习生批注得不行，那说明你的逻辑没想清楚，或者你的数据（合同模板）不够全。
  这时候上AI也是白搭。
  如果用户觉得实习生批注得准，那恭喜你，商业闭环验证成功。
  接下来你要做的，就是用AI去慢慢替换掉这些昂贵的实习生。

MVP验证的是“这个问题是否可以被智能解决”，而不是“AI能否解决这个问题”。

三、 圈定“有限域”：不要试图做全知全能

传统软件我们追求“功能大而全”。

但在AI MVP阶段，“克制”比“全”更重要。

因为AI的智力水平（即便是最强的大模型）也是有边界的。

如果你的MVP试图回答全人类的所有问题，那它99%的时间都在胡扯。

正确的AI MVP策略： 做一个“专家Agent”，而不是一个“万能聊天机器人”。

• Bad MVP： “我能帮你处理任何税务问题。”（范围太广，幻觉爆炸）

• Good MVP： “我只针对美国加州的独立承包商，填写1099表格。”（范围极窄，精度极高） 只要在这个狭窄的领域里，AI的表现超越了人类，或者给用户带来了极致的效率，MVP就成功了。先做深，别做宽。

四、 评估指标的重构：引入“人类反馈”

传统MVP看什么数据？DAU（日活）、留存率、转化率。

AI MVP当然也要看这些，但必须增加一个新的核心指标：反馈质量。

在MVP阶段，你的产品旁边必须加一个简单的“点赞/点踩”按钮，或者简单的文本反馈框。

这不仅仅是为了收集意见，这是为了“验证智能”。

• 如果用户只点“踩”，说明AI在胡说八道，模型不可用。

• 如果用户经常修改AI生成的结果，说明Prompt（提示词）设计有问题。 在AI时代，数据清洗和反馈闭环是产品的一部分。如果你的MVP里没有设计收集用户反馈数据的机制，那你就是在盲人摸象。

五、 结语：从“功能思维”转向“信任思维”

回望这二十年的开发历程，我们一直在做“确定性交付”的MVP。

而AI时代的MVP，本质上是在建立“信任”。

用户愿意把工作交给AI，不是因为它有按钮，而是因为它准、稳、懂行。

作为技术管理者，在AI项目立项之初，就要降低对“功能数量”的期待，转而死磕那几个核心场景下的“准确率”和“可靠性”。

哪怕只有一个功能，只要它能比人干得好，它就是一个伟大的MVP。

当你验证了这个MVP确实有用户愿意买单，接下来的问题就变成了：这块业务，我到底该放在别人的云上跑，还是自己买显卡建机房？

下一篇预告： 第十九篇 私有化部署 vs 公有API：数据安全与成本的平衡术