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

MVP 真的死了吗？用它来学习的方法没有死，拿它当借口的做法死了。AI 编程工具可以降低制作原型的工作量，但没有普遍证据表明所有用户、投资人和买家都以相同幅度提高了质量门槛。我们的主张更窄：肉眼可见的粗糙并不能充分证明速度，而可避免的故障会污染原本要运行的实验。

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

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

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

最初的 MVP 从来不等于糟糕的软件。Eric Ries 将其定义为以最少投入获得最多客户验证学习的产品版本，Lean Startup Company 收录了这一原文。它是一项在投入更多资源前验证假设的实验。

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

当软件需要更多人工实现时，肉眼可见的粗糙可以代表真实约束。当前 AI 工具能快速生成界面、API 脚手架、数据库 Schema、测试和部署配置，但验证与集成所需时间因场景而异。这不意味着每个原型都必须精美，而是粗糙应当有意为之，且不能掩盖正在验证的假设。

定义范围时，应分别测试四类可信风险，而不是假设存在统一门槛：

• 用户风险。如果核心路径失败，你测到的可能是 onboarding 摩擦，而不是需求。
• 投资风险。生成式仪表盘本身不能证明技术可行性、差异化或市场牵引力。
• 企业采购风险。试点可能需要权限、数据处理条款、审计、集成和明确负责人，才能产生购买信号。
• 团队风险。如果实验没有明确的不做清单，更快生成反而可能扩大范围。

因此我们的建议不是增加打磨，而是缩小范围并获得更清晰的证据。

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

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

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

如果下一项承诺是加速器申请，可以使用Y Combinator 申请技术准备清单整理演示、指标、创始团队责任和进展证据，同时避免过度建设。

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

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

关于生产力的证据没有社交媒体那么戏剧化。在 GitHub 自己组织的随机实验中，95 名专业开发者实现同一个 JavaScript HTTP 服务器；Copilot 组平均快 55%。另一项随机研究让 16 名资深开源开发者在熟悉的仓库中完成 246 项任务，使用 2025 年初 AI 工具时反而多花 19% 时间。METR 的 2026 年 2 月更新显示了原始加速迹象，但因参与者选择偏差和并行智能体使用而将证据称为薄弱。

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

Google Cloud 的 2025 年 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时采用的标准：软件不仅要能演示，还要能够上线和销售。