MVP 已死。请构建最小可信产品。

MVP 真的死了吗？用它来学习的方法没有死，拿它当借口的做法死了。AI 让原型开发变得容易得多，因此用户、投资人和买家不再自动把粗糙理解为“团队跑得快”。他们越来越可能得出另一个判断：这个团队没有测试、没有取舍，也没有把唯一重要的路径做完整。

我们提出一个更合适的目标：最小可信产品（Minimum Credible Product）。它是在不要求用户原谅可避免故障的前提下，能够验证最危险业务假设的最小版本。它的功能比许多 MVP 更少，但保留下来的那条路径从头到尾都能工作，并足以赢得下一项决策所需的信任。

这不代表要打磨每个角落，也不代表要为想象中的百万用户提前设计。它只意味着一句老话已经不够用了：“这只是 MVP。”

最小可行产品发生了什么变化？

最初的 MVP 从来不等于糟糕的软件。Eric Ries 将它描述为能够快速启动学习过程的最简单版本：在投入大量资源之前，先用真实用户验证核心业务假设。

这个逻辑仍然成立。变化的是实验必须达到的可信门槛。

当软件很昂贵时，肉眼可见的粗糙往往代表真实约束。一个简单界面加人工流程可以说明：团队把稀缺的工程时间花在最重要的假设上。今天，一个精美界面、API、数据库结构、测试和部署可以在几天内出现。同样的粗糙因此传达出不同信号：如果最便宜、最显眼的一层都没有完成，那么用户看不见的部分又会怎样？

AI 改变了早期软件的社会契约：

• 用户期望核心路径完整。可选产品太多，他们不会因为同情而替团队调试 onboarding。
• 投资人期望演示经得住基本追问。一个生成式仪表盘本身不再能证明技术进展。
• 企业买家提高了可信门槛。权限、数据处理、审计、集成和所有权会在试点讨论中出现，而不是试点之后。
• 创始人期望小团队交付更多。这种期望是否公平并不重要，它已经改变了早期产品必须传达的信号。

代码产出的成本下降了。被认真对待的成本上升了。

原型、MVP 与最小可信产品有什么区别？

它们不是三种精致程度，而是在回答三个不同问题。

原型证明“可以做”。MVP 尝试证明“有人要”。最小可信产品证明产品拥有足够的价值和信任，值得下一项承诺。

AI 会写代码，是否意味着软件工程已死？

不会。AI 压缩的是软件生产中的部分工作。它没有消除这些决定：什么应该存在、系统应该如何失败、什么证据足以支持上线。

关于生产力的证据也没有社交媒体那么戏剧化。GitHub 报告称，在一项受控编程任务中，Copilot 用户完成任务的速度最高提升了 55%。在完全不同的场景中，METR 2025 年的研究发现，经验丰富的开源开发者在自己熟悉的成熟代码库中使用当时的 AI 工具，反而花了更长时间。METR 的 2026 年后续研究看到了新一代智能体带来帮助的迹象，同时也说明了为什么干净地衡量这种帮助变得更困难。

这些结果并不矛盾，它们衡量的是不同工作。当目标、上下文和验证方式都明确时，AI 很擅长生成边界清楚的产出。真实产品工作却充满缺失的上下文、冲突的目标、没有写下来的限制，以及无法塞进编程基准测试的后果。

Google Cloud 的 DORA 研究给出了更有价值的组织层结论：AI 会放大它周围的系统。强团队把更快的产出转化成更好的交付。薄弱的产品纪律则把同样的产出转化成更多不稳定，以及更多没人需要的软件。

"一个构建错误产品的 100 倍工程师，并没有多 100 倍的价值。他只是以 100 倍的速度制造债务。"

工程从来不只是打字。真正稀缺的工作越来越集中在判断：

• 哪个功能根本不应该存在？
• 哪个边界情况会摧毁信任，而不只是造成一点不便？
• 哪个捷径可以撤销，哪个捷径会迫使团队重写？
• 哪个用户问题痛到足以让人现在付费？
• 哪个指标能把真实学习与演示时的掌声区分开？
• AI 输出在哪些环节必须经过人工审查，才能避免真实后果？

AI 可以协助回答这些问题，但不会承担错误答案带来的后果。

什么是最小可信产品？

最小可信产品，是用一条完整、可靠的路径解决一个痛苦问题，并为下一项业务决策产生证据的最小产品。它在范围上最小，而不是在用心程度上打折。它的质量门槛取决于：什么会让实验结果变得不可信。

我们把 Minimum Credible Product 当作一个实用工作术语，而不是已经确立的行业标准。本文中的 MCP 指 Minimum Credible Product，不是 Model Context Protocol。缩写碰撞确实不太方便，但两者很容易区分：前者是产品战略概念，后者是让 AI 系统连接工具和数据的技术协议。

最小可信产品由七部分组成：

1. 一个真正痛苦的问题。如果范围描述需要反复使用“以及”，可能是三个产品假装成一个 MVP。
2. 一个具体用户。不是“中小企业”“团队”或“知识工作者”。要明确人物、场景，以及让问题变得紧迫的触发点。
3. 一个值得回来或付费的理由。产品必须创造可重复的结果，而不只是五分钟的新鲜感。
4. 一条完整生产路径。核心流程覆盖输入、处理、输出、错误和恢复。漂亮界面下面如果是不可靠的流程，它仍然只是原型。
5. 与风险匹配的信任底线。只要失败会让测试失去意义或造成危险，认证、权限、隐私、QA 和人工批准就必须存在。
6. 证据，而不是虚荣指标。衡量真正回答业务问题的行为：任务完成、重复使用、付费转化、节省时间或批准率。
7. 明确的不做清单。可信不等于功能多。把不交付的内容写下来，避免更快的代码生成偷偷把范围带回来。

最小可信产品是否意味着过度建设？

不。过度建设是在证据要求之前添加能力。可信化则持续删除能力，直到剩下的路径可以产生可靠信号。最小可信产品完全可以使用人工操作、托管模型、简单架构和单一集成。它只是不把不安全或不完整的工作藏在 MVP 标签后面。

实用规则很简单：构建能够保护实验有效性的保障。推迟那些只是在保护想象中未来的机器。

一个最小可信 AI 产品是什么样？

假设团队正在构建一个从公司文档中回答问题的 B2B 助手。

原型上传一个 PDF，在干净的聊天界面里返回一条令人信服的答案。它证明这种交互可以成立。

薄弱的 AI MVP 连接共享文档文件夹，加入登录，然后上线。它看起来已经完成，但每个用户都可以检索每份文档；答案没有来源；失败静默发生；也没人衡量答案质量。这种产品的使用数据被污染了：如果用户离开，团队无法判断他们是在拒绝这个想法，还是只是不信任实现。

最小可信产品只服务一个部门，只连接一个文档源。它尊重源系统权限，为每个答案引用原文，在证据不足时拒答或升级，记录质量和成本，并提供清楚的纠错路径。它做得更少，但学习价值更高。

确切的可信门槛取决于风险。一个起草内部社交媒体文案的私有工具，与一个推荐医疗行动、转移资金或暴露客户记录的软件，需要完全不同的标准。可信度取决于场景，不是一份固定清单。

当真实用户和数据即将进入系统时，可以使用AI 生成应用的生产就绪清单完成技术检查。对于 AI 特有的验收标准、评测集和上线门槛，请使用AI MVP 范围模板。

如何界定最小可信产品的范围？

从决策开始，而不是从功能列表开始。一份有用的范围能用普通语言回答六个问题：

1. 风险最高的假设是什么？需求、付费意愿、重复使用、技术可行性、信任还是采购？选择一个主要风险。
2. 谁的行为能解决这个问题？明确最小的、可接触的用户群体；他们既有这个问题，也有采取行动的权力。
3. 最小的完整闭环是什么？定义用户从哪里进入、得到什么结果，以及接下来应该做什么。
4. 什么失败会让测试失效？如果权限错误、错误答案、慢响应或破损交接会让拒绝原因变得模糊，它就属于可信底线。
5. 哪个可观察事件会改变下一项决策？十个付费试点、40% 的每周重复使用、进入正式采购，或其他上线前就约定好的门槛。
6. 明确拒绝构建什么？把功能墓地放在范围旁边。AI 让功能复活变得危险地便宜。

顺序很重要。如果团队先问“本周能生成什么”，得到的是一份产出清单。如果先问业务风险，团队才能判断什么产出值得存在。

什么时候仍然应该只用原型？

如果受众清楚知道这是实验，而且问题不需要真实信任，就使用原型。用于五次客户访谈的可点击流程、技术探索、假门测试或内部演示都可以粗糙，因为此时没有人依赖它。

不要因为演示顺利，就悄悄把原型变成生产系统。一旦真实资金、客户数据、运营依赖或品牌信任进入闭环，这个产物的任务就变了。我们的从 Lovable 或 Cursor 原型走向生产指南解释了这次转变背后的工程工作。

创始人应该向开发伙伴提出什么要求？

“我们能做”只是入场券。更困难的问题更有价值：

• 这个东西真的应该构建吗？
• 这个版本要解决哪一项业务风险？
• 在定制软件之前，最便宜的诚实测试是什么？
• 哪一部分从第一天起就需要生产级工程？
• 哪些环节可以继续人工完成，直到用户证明它值得自动化？
• 什么证据会让我们停止、继续或增加投资？

探索、产品领导、软件开发、AI 集成和 QA 互相关联，却不是同一项工作。把它们压成一句泛泛的“帮我做个 MVP”，往往会得到一个很快的原型和一个很慢的业务。

严肃的合作伙伴应该先缩小范围，再扩大报价。他们必须解释哪些捷径是有意为之、哪些风险被阻断，以及第一版要证明什么。这也是我们开发 MVP时采用的标准：软件不仅要能演示，还要能够上线和销售。