最小可行产品（MVP）是指一个产品版本，它只包含足够让早期用户使用的功能，这些用户随后可以为未来的产品开发提供反馈。
\n\n今天，我想重点讨论在发布 AI 应用时，MVP 应该是什么样的。要做到这一点，我们只需要理解以下四点。
\n\n帕累托法则，也就是大家熟知的 80/20 法则，依然适用，但方式可能和你想的不一样。
\n\n我经常用一个类比来帮助理解这个概念：你需要一个工具帮你从 A 点到达 B 点。最终愿景可能是拥有一辆汽车。然而，MVP 不是没有轮子或引擎的底盘。相反，它可能更像一块滑板。你发布产品后，会发现它需要刹车或转向功能。于是你发布了滑板车。之后，你发现滑板车需要更大的杠杆作用，于是你装上更大的轮子，变成了一辆自行车。受限于人类体能，你开始考虑加装电机，于是延伸出轻便摩托车、电动自行车和摩托车。然后有一天，你发布了汽车。
\n\n当我们说某件事完成了 80% 或准备好了 80% 时，通常是在机器学习的语境下。在这种语境下，每个组件都是确定性的，这意味着 80% 相当于 10 个功能中有 8 个已经完成。一旦剩下的 2 个功能准备就绪，我们就可以发布产品。然而，如果我们想遵循 80/20 法则，也许可以只带着 80% 的功能发布产品，然后再补充剩下的 20%，就像一辆没有收音机或空调的汽车。然而，80% 的含义可能千差万别，这个定义未必适用于由 AI 驱动的应用。
\n\n![\"Anscombe's](\"/assets/images/anscombes_quartet.png\")
\n\n上图是安斯库姆四重奏（Anscombe's quartet）的一个例子。它由四组数据集组成，这些数据的简单描述性统计量几乎完全相同，但分布和外观却截然不同。这是一个经典的解释，说明为什么汇总统计可能会产生误导。
\n\n请看下面的例子：
\n\n| Query_id | \nscore | \n
|---|---|
| 1 | \n0.9 | \n
| 2 | \n0.8 | \n
| 3 | \n0.9 | \n
| 4 | \n0.9 | \n
| 5 | \n0.0 | \n
| 6 | \n0.0 | \n
平均分是 0.58。然而，如果我们按细分场景来分析这些查询，可能会发现我们对绝大多数查询都处理得非常好！
\n\n\n\n\n承认你不擅长什么
\n坦诚面对自己的不足是与用户建立信任的好方法。如果你能准确识别出某些情况表现会很差，并有把握地拒绝处理它们，那么你或许就可以发布一款优秀的产品，同时让用户了解应用的局限性。
\n
深入了解系统的局限性，并能够超越汇总统计去自信地把握系统的特征，这一点非常重要。因为并非所有系统都是等同的。概率系统的表现可能与前面的例子大相径庭。请看下面的数据集：
\n\n| Query_id | \nScore | \n
|---|---|
| 1 | \n.59 | \n
| 2 | \n.58 | \n
| 3 | \n.59 | \n
| 4 | \n.57 | \n
这样的系统平均分同样是 0.58，但要拒绝任何一部分请求就没那么容易了……
\n\n假设有一个 RAG 应用，其中很大一部分查询都与时间线有关。如果我们的搜索引擎不支持这种时间约束，那么我们很可能无法很好地处理这类查询。
\n\n| Query_id | \nScore | \nQuery Type | \n
|---|---|---|
| 1 | \n0.9 | \ntext search | \n
| 2 | \n0.8 | \ntext search | \n
| 3 | \n0.9 | \nnews search | \n
| 4 | \n0.9 | \nnews search | \n
| 5 | \n0.0 | \ntimeline | \n
| 6 | \n0.0 | \ntimeline | \n
如果我们急着发布，可以简单地构建一个分类模型，用来检测这些问题是否属于时间线问题，并抛出警告。与其不断试图推动算法做得更好，不如通过改变产品设计的方式来教育用户。
\n\n\n\n\n检测细分场景
\n检测这些细分场景可以通过多种方式实现。我们可以构建一个分类器，或者使用语言模型来对它们进行分类。此外，我们还可以利用聚类算法对嵌入向量进行处理，以识别出常见的群组，并分析每个群组的平均得分。唯一的目标就是找出那些能够增进我们对特定子群体行为理解的细分场景。
\n
你能做的最糟糕的事情之一，就是花几个月时间开发一个只能稍微提升效率的功能，却忽视了用户群中某个更重要的细分群体。
\n\n通过重新设计应用并认识到它的局限性，我们可以通过识别哪些类型的任务可以拒绝，从而在特定条件下提升表现。如果我们能将这些细分数据放入某种系统内可观测性（In-System Observability）工具中，就可以安全地监控有多大比例的问题被拒绝，并优先安排工作以最大化覆盖范围。
\n\n在与初创公司合作时，我注意到一个危险的现象：我们常常以为 AI 什么都能做……于是，我们就想做一个大而全的应用，却很少思考我们到底想实现什么。
\n\n在我看来，这些公司中的大多数应该试着聚焦在一两个重要领域，并找到一个合适的细分赛道。如果你的应用在一两件事上做得很好，你不可能找不到一两百个用户来测试你的应用并快速获得反馈。相反，如果你的应用什么都做不好，那就很难让人记住，也无法提供具有重复使用价值的东西。你可能会获得一些病毒式传播，但很快你就会失去用户的信任，发现自己陷入了试图降低流失率的困境。
\n\n在项目前期，使用 GPT-4 进行预测的能力以及获得反馈的时间都非常重要。如果我们能快速获得反馈，就能快速迭代。如果我们能快速迭代，就能打造出更好的产品。
\n\nAI 应用的最小可行产品（MVP）并不像发布一个具备 80% 功能的产品那么简单。相反，它需要深入理解你能服务好的用户细分场景，并有能力让用户了解那些你服务不好的场景。通过理解系统的局限性并聚焦细分赛道，你可以打造出一款令人印象深刻、具备重复使用价值的产品。这将让你能够快速获得反馈、快速迭代，最终通过识别你的「强项」来打造出更好的产品。
", "source_hash": "sha256:145f757651a7540ac4d35b4afde9a79f337936029ace5840b1ff7b5d56b0fce6", "model": "moonshotai/kimi-k2.6", "generated_at": "2026-08-07T05:38:33.881531+00:00" }