--- title: "MVP 已死？请构建最小可信产品" canonical: https://wavect.io/zh/blog/minimum-credible-product/ language: zh description: "AI 降低了原型成本，却没有降低产品判断的难度。传统 MVP 为何正在失效，以及应该用什么取代它：最小可信产品。" image: "https://wavect.io/img/blog/headers/header_minimum-credible-product.png" --- [**返回**](/zh/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/zh/team/kevin-riedl/) [Kevin Riedl](/zh/team/kevin-riedl/) https://linkedin.com/in/wsdt 10 分钟 阅读 · 2026 年 6 月 28 日 [**下一篇**](/zh/blog/ai-coding-agents-context-not-intelligence/) # MVP 已死。请构建最小可信产品。 要点速览 作为验证式学习方法，MVP 并没有死。真正失效的是那种用“它只是 MVP”为粗糙和不完整开脱的产品。AI 降低了基础软件产出的成本，却提高了用户、投资人和企业买家的可信门槛。更好的目标是最小可信产品：用一条完整、可靠的路径解决一个真正痛苦的问题，并为下一项业务决策产生证据。它在范围上最小，而不是在用心程度上打折：一个明确用户、一个值得回来或付费的理由、在失败会使实验失真之处具备生产级基础、能支持决策的分析，以及一份明确的不做清单。本文中的 MCP 指 Minimum Credible Product，而不是 Model Context Protocol。 **MVP 真的死了吗？**用它来学习的方法没有死，拿它当借口的做法死了。AI 让原型开发变得容易得多，因此用户、投资人和买家不再自动把粗糙理解为“团队跑得快”。他们越来越可能得出另一个判断：这个团队没有测试、没有取舍，也没有把唯一重要的路径做完整。 我们提出一个更合适的目标：最小可信产品（Minimum Credible Product）。它是在不要求用户原谅可避免故障的前提下，能够验证最危险业务假设的最小版本。它的功能比许多 MVP 更少，但保留下来的那条路径从头到尾都能工作，并足以赢得下一项决策所需的信任。 这不代表要打磨每个角落，也不代表要为想象中的百万用户提前设计。它只意味着一句老话已经不够用了：“这只是 MVP。” ## 最小可行产品发生了什么变化？ 最初的 MVP 从来不等于糟糕的软件。Eric Ries 将它描述为 [能够快速启动学习过程的最简单版本](https://www.ericries.co/) ：在投入大量资源之前，先用真实用户验证核心业务假设。 这个逻辑仍然成立。变化的是实验必须达到的可信门槛。 当软件很昂贵时，肉眼可见的粗糙往往代表真实约束。一个简单界面加人工流程可以说明：团队把稀缺的工程时间花在最重要的假设上。今天，一个精美界面、API、数据库结构、测试和部署可以在几天内出现。同样的粗糙因此传达出不同信号：如果最便宜、最显眼的一层都没有完成，那么用户看不见的部分又会怎样？ AI 改变了早期软件的社会契约： - **用户期望核心路径完整。** 可选产品太多，他们不会因为同情而替团队调试 onboarding。 - **投资人期望演示经得住基本追问。** 一个生成式仪表盘本身不再能证明技术进展。 - **企业买家提高了可信门槛。** 权限、数据处理、审计、集成和所有权会在试点讨论中出现，而不是试点之后。 - **创始人期望小团队交付更多。** 这种期望是否公平并不重要，它已经改变了早期产品必须传达的信号。 代码产出的成本下降了。被认真对待的成本上升了。 ## 原型、MVP 与最小可信产品有什么区别？ 它们不是三种精致程度，而是在回答三个不同问题。 | 产物 | 回答的问题 | 面向谁 | 质量门槛 | 下一步 | | --- | --- | --- | --- | --- | | **原型** | 这种交互或技术思路能否成立？ | 团队、少量访谈对象、演示观众 | 快乐路径可能足够；只要明确披露，就可以使用假数据和人工步骤 | 丢弃、学习，或用它界定真正产品的范围 | | **传统 MVP** | 早期用户会不会接受这个价值主张？ | 愿意容忍粗糙之处的早期采用者 | 可用到足以产生验证式学习 | 根据行为迭代、转向或停止 | | **最小可信产品** | 正确的用户是否足够信任它，从而做出下一项有意义的承诺？ | 真实客户、试点买家、投资人或内部负责人 | 一条完整路径；任何会使信号失真的环节都达到生产级 | 赢得试点、付款、续约、投资，或下一阶段所需的证据 | 原型证明“可以做”。MVP 尝试证明“有人要”。最小可信产品证明产品拥有足够的价值和信任，值得下一项承诺。 如果下一项承诺是加速器申请，可以使用 [Y Combinator 申请技术准备清单](/zh/blog/yc-application-technical-readiness-checklist/) 整理演示、指标、创始团队责任和进展证据，同时避免过度建设。 ## AI 会写代码，是否意味着软件工程已死？ 不会。AI 压缩的是软件生产中的部分工作。它没有消除这些决定：什么应该存在、系统应该如何失败、什么证据足以支持上线。 关于生产力的证据也没有社交媒体那么戏剧化。GitHub 报告称，在一项受控编程任务中，Copilot 用户完成任务的速度 [最高提升了 55%](https://github.blog/news-insights/research/does-github-copilot-improve-code-quality-heres-what-the-data-says/) 。在完全不同的场景中，METR 2025 年的研究发现，经验丰富的开源开发者在自己熟悉的成熟代码库中使用当时的 AI 工具，反而花了更长时间。METR 的 [2026 年后续研究](https://metr.org/blog/2026-02-24-uplift-update/) 看到了新一代智能体带来帮助的迹象，同时也说明了为什么干净地衡量这种帮助变得更困难。 这些结果并不矛盾，它们衡量的是不同工作。当目标、上下文和验证方式都明确时，AI 很擅长生成边界清楚的产出。真实产品工作却充满缺失的上下文、冲突的目标、没有写下来的限制，以及无法塞进编程基准测试的后果。 Google Cloud 的 DORA 研究给出了更有价值的组织层结论： [AI 会放大它周围的系统](https://dora.dev/dora-report-2025) 。强团队把更快的产出转化成更好的交付。薄弱的产品纪律则把同样的产出转化成更多不稳定，以及更多没人需要的软件。 ![Kevin Riedl](/img/team/kevin.webp) "一个构建错误产品的 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 生成应用的生产就绪清单](/zh/blog/vibe-code-production-readiness-checklist/) 完成技术检查。对于 AI 特有的验收标准、评测集和上线门槛，请使用 [AI MVP 范围模板](/zh/blog/ai-mvp-scope-template/) 。 ## 如何界定最小可信产品的范围？ 从决策开始，而不是从功能列表开始。一份有用的范围能用普通语言回答六个问题： 1. **风险最高的假设是什么？** 需求、付费意愿、重复使用、技术可行性、信任还是采购？选择一个主要风险。 2. **谁的行为能解决这个问题？** 明确最小的、可接触的用户群体；他们既有这个问题，也有采取行动的权力。 3. **最小的完整闭环是什么？** 定义用户从哪里进入、得到什么结果，以及接下来应该做什么。 4. **什么失败会让测试失效？** 如果权限错误、错误答案、慢响应或破损交接会让拒绝原因变得模糊，它就属于可信底线。 5. **哪个可观察事件会改变下一项决策？** 十个付费试点、40% 的每周重复使用、进入正式采购，或其他上线前就约定好的门槛。 6. **明确拒绝构建什么？** 把功能墓地放在范围旁边。AI 让功能复活变得危险地便宜。 顺序很重要。如果团队先问“本周能生成什么”，得到的是一份产出清单。如果先问业务风险，团队才能判断什么产出值得存在。 ## 什么时候仍然应该只用原型？ 如果受众清楚知道这是实验，而且问题不需要真实信任，就使用原型。用于五次客户访谈的可点击流程、技术探索、假门测试或内部演示都可以粗糙，因为此时没有人依赖它。 不要因为演示顺利，就悄悄把原型变成生产系统。一旦真实资金、客户数据、运营依赖或品牌信任进入闭环，这个产物的任务就变了。我们的 [从 Lovable 或 Cursor 原型走向生产](/zh/blog/lovable-cursor-prototype-to-production/) 指南解释了这次转变背后的工程工作。 ## 创始人应该向开发伙伴提出什么要求？ “我们能做”只是入场券。更困难的问题更有价值： - 这个东西真的应该构建吗？ - 这个版本要解决哪一项业务风险？ - 在定制软件之前，最便宜的诚实测试是什么？ - 哪一部分从第一天起就需要生产级工程？ - 哪些环节可以继续人工完成，直到用户证明它值得自动化？ - 什么证据会让我们停止、继续或增加投资？ 探索、产品领导、 [定制软件开发](/zh/services/software-development/) 、AI 集成和 QA 互相关联，却不是同一项工作。把它们压成一句泛泛的“帮我做个 MVP”，往往会得到一个很快的原型和一个很慢的业务。 严肃的合作伙伴应该先缩小范围，再扩大报价。他们必须解释哪些捷径是有意为之、哪些风险被阻断，以及第一版要证明什么。这也是我们 [开发 MVP](/zh/services/mvp-development/) 时采用的标准：软件不仅要能演示，还要能够上线和销售。 ## 常见问题 ### MVP 真的死了吗？ 作为验证式学习方法，MVP 没有死。正在失效的是那种用“它只是 MVP”为粗糙和不完整开脱的产品。AI 降低了可见软件产出的成本，也提高了买家的期望。替代方案不是更大的首版，而是更小、但拥有一条完整可信路径的产品。 ### 什么是最小可信产品？ 最小可信产品，是用一条完整、可靠的路径解决一个痛苦问题，并为下一项业务决策产生证据的最小产品。它在范围上最小，而不是在用心程度上打折。可信门槛由那些会让实验变得不安全或结果不可信的失败决定。 ### MVP 与最小可信产品有什么区别？ MVP 询问早期用户是否接受价值主张。最小可信产品询问正确的用户是否足够信任产品，从而付款、回来、批准试点或投资。它通常功能更少，但保留下来的核心路径拥有更高质量门槛。 ### 这里的 MCP 是指 Model Context Protocol 吗？ 不是。本文中的 MCP 指 Minimum Credible Product，是一个产品战略概念。Model Context Protocol 是连接 AI 应用、工具和数据的技术标准。两者共享缩写只是巧合。 ### 最小可信产品与 Minimum Lovable Product 相同吗？ 不同。Minimum Lovable Product 强调愉悦感和情感吸引力；最小可信产品强调信任和支持决策的证据。消费产品可能两者都需要。受监管的 B2B 试点通常在需要惊喜感之前，就先需要可信度。 ### vibe-coded 原型能变成最小可信产品吗？ 可以，前提是生成代码值得保留，而且团队补齐缺失的产品与工程工作：清晰范围、服务端权限、数据保护、故障处理、QA、可观测性、支持决策的分析，以及可维护的交接。有时加固更便宜，有时窄范围重写更合理。 ### 最小可信产品要花多少钱？ 不存在有意义的统一价格，因为可信门槛取决于风险、数据、集成和目标买家。低风险内部流程与受监管、面向客户的 AI 产品是完全不同的项目。可以先参考我们发布的 AI MVP 成本区间，再对那条完整核心路径做具体范围界定。 ## 最终思考 AI 没有杀死软件工程。它杀死的是基础软件产出的稀缺性。因此，判断、范围、信任和证据变得更有价值，而不是更不重要。 MVP 中有用的部分会留下：在过度投资之前先学习。真正消失的是这种想法：因为团队还处在早期，用户就应该原谅一个破损的核心体验。少做功能，把重要路径做完整，衡量最初要解决的业务风险。这就是最小可信产品。在人人都能交付更多的世界里，知道什么不该交付，才是优势。 ## 你可能也喜欢.. [**AI 生成应用的生产就绪清单** 真实用户接触 AI 生成应用之前应完成的十项检查，并按最常造成问题的顺序排列。](/zh/blog/vibe-code-production-readiness-checklist/) [**在奥地利开发 AI MVP 要花多少钱？** 按 AI 产品类型给出的 2026 年真实成本区间，以及推高或降低成本的因素。](/zh/blog/ai-mvp-cost-austria-2026/) MVP 验证 ## 继续浏览此集群 [从核心文章开始**如何验证 DACH B2B SaaS 想法**](/zh/blog/validate-b2b-saas-idea-dach/) - [Y Combinator 申请技术准备清单：该做什么，不该做什么](/zh/blog/yc-application-technical-readiness-checklist/) - [如何验证 DACH B2B SaaS 想法](/zh/blog/validate-b2b-saas-idea-dach/) - [付费试点、PoC 与设计合作伙伴：哪个能验证需求？](/zh/blog/paid-pilot-vs-poc-vs-design-partner/) - [融资前 AI MVP 的技术尽职调查](/zh/blog/technical-due-diligence-ai-mvp/) 只收重要内容 ## 关注与你相关的内容 每当我们发布新文章，你会收到一封简短邮件。你可以关注整个博客，也可以只选感兴趣的主题。 [**返回**](/zh/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/zh/team/kevin-riedl/) [Kevin Riedl](/zh/team/kevin-riedl/) https://linkedin.com/in/wsdt 10 分钟 阅读 · 2026 年 6 月 28 日 [**下一篇**](/zh/blog/ai-coding-agents-context-not-intelligence/) 邮件订阅新文章 × × 通过邮件获取新文章 我们发布时给你一封简短邮件。免费，不做跟踪。 ## Structured Data ```json { "@context": "https://schema.org", "@graph": [ { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ], "employee": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "founder": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "legalRepresentative": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "name": "Wavect GmbH", "subjectOf": { "@id": "https://wavect.io/verified-claims.json#dataset", "@type": "Dataset", "creator": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "description": "A machine-readable registry of quantitative and qualitative claims published by Wavect, with review dates, localized page appearances and public third-party citations where available.", "inLanguage": "en", "isAccessibleForFree": true, "license": "https://creativecommons.org/licenses/by/4.0/", "name": "Wavect verified publication claims", "url": "https://wavect.io/verified-claims.json" }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "sameAs": [ "https://www.wikidata.org/wiki/Q139796367", "https://www.linkedin.com/in/jocr77/", "https://github.com/jo-chris" ], "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/#website", "@type": "WebSite", "inLanguage": [ "en", "de", "es", "zh" ], "name": "Wavect", "potentialAction": { "@type": "SearchAction", "query-input": "required name=search_term_string", "target": { "@type": "EntryPoint", "urlTemplate": "https://wavect.io/search/?q={search_term_string}" } }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/zh/blog/minimum-credible-product/#webpage", "@type": "WebPage", "dateModified": "2026-07-07", "inLanguage": "zh", "isPartOf": { "@id": "https://wavect.io/#website", "@type": "WebSite" }, "lastReviewed": "2026-07-07", "url": "https://wavect.io/zh/blog/minimum-credible-product/" } ] } ``` ```json { "@context": "https://schema.org", "@type": "BlogPosting", "abstract": "作为验证式学习方法，MVP 并没有死。真正失效的是那种用“它只是 MVP”为粗糙和不完整开脱的产品。AI 降低了基础软件产出的成本，却提高了用户、投资人和企业买家的可信门槛。更好的目标是最小可信产品：用一条完整、可靠的路径解决一个真正痛苦的问题，并为下一项业务决策产生证据。它在范围上最小，而不是在用心程度上打折：一个明确用户、一个值得回来或付费的理由、在失败会使实验失真之处具备生产级基础、能支持决策的分析，以及一份明确的不做清单。本文中的 MCP 指 Minimum Credible Product，而不是 Model Context Protocol。", "articleBody": " 博客概览/产品与 MVP/MVP 验证 MVP 已死。请构建最小可信产品。 要点速览 作为验证式学习方法，MVP 并没有死。真正失效的是那种用“它只是 MVP”为粗糙和不完整开脱的产品。AI 降低了基础软件产出的成本，却提高了用户、投资人和企业买家的可信门槛。更好的目标是最小可信产品：用一条完整、可靠的路径解决一个真正痛苦的问题，并为下一项业务决策产生证据。它在范围上最小，而不是在用心程度上打折：一个明确用户、一个值得回来或付费的理由、在失败会使实验失真之处具备生产级基础、能支持决策的分析，以及一份明确的不做清单。本文中的 MCP 指 Minimum Credible Product，而不是 Model Context Protocol。 MVP 真的死了吗？用它来学习的方法没有死，拿它当借口的做法死了。AI 让原型开发变得容易得多，因此用户、投资人和买家不再自动把粗糙理解为“团队跑得快”。他们越来越可能得出另一个判断：这个团队没有测试、没有取舍，也没有把唯一重要的路径做完整。 我们提出一个更合适的目标：最小可信产品（Minimum Credible Product）。它是在不要求用户原谅可避免故障的前提下，能够验证最危险业务假设的最小版本。它的功能比许多 MVP 更少，但保留下来的那条路径从头到尾都能工作，并足以赢得下一项决策所需的信任。 这不代表要打磨每个角落，也不代表要为想象中的百万用户提前设计。它只意味着一句老话已经不够用了：“这只是 MVP。” 最小可行产品发生了什么变化？ 最初的 MVP 从来不等于糟糕的软件。Eric Ries 将它描述为能够快速启动学习过程的最简单版本：在投入大量资源之前，先用真实用户验证核心业务假设。 这个逻辑仍然成立。变化的是实验必须达到的可信门槛。 当软件很昂贵时，肉眼可见的粗糙往往代表真实约束。一个简单界面加人工流程可以说明：团队把稀缺的工程时间花在最重要的假设上。今天，一个精美界面、API、数据库结构、测试和部署可以在几天内出现。同样的粗糙因此传达出不同信号：如果最便宜、最显眼的一层都没有完成，那么用户看不见的部分又会怎样？ AI 改变了早期软件的社会契约： 用户期望核心路径完整。可选产品太多，他们不会因为同情而替团队调试 onboarding。 投资人期望演示经得住基本追问。一个生成式仪表盘本身不再能证明技术进展。 企业买家提高了可信门槛。权限、数据处理、审计、集成和所有权会在试点讨论中出现，而不是试点之后。 创始人期望小团队交付更多。这种期望是否公平并不重要，它已经改变了早期产品必须传达的信号。 代码产出的成本下降了。被认真对待的成本上升了。 原型、MVP 与最小可信产品有什么区别？ 它们不是三种精致程度，而是在回答三个不同问题。 产物 回答的问题 面向谁 质量门槛 下一步 原型 这种交互或技术思路能否成立？ 团队、少量访谈对象、演示观众 快乐路径可能足够；只要明确披露，就可以使用假数据和人工步骤 丢弃、学习，或用它界定真正产品的范围 传统 MVP 早期用户会不会接受这个价值主张？ 愿意容忍粗糙之处的早期采用者 可用到足以产生验证式学习 根据行为迭代、转向或停止 最小可信产品 正确的用户是否足够信任它，从而做出下一项有意义的承诺？ 真实客户、试点买家、投资人或内部负责人 一条完整路径；任何会使信号失真的环节都达到生产级 赢得试点、付款、续约、投资，或下一阶段所需的证据 原型证明“可以做”。MVP 尝试证明“有人要”。最小可信产品证明产品拥有足够的价值和信任，值得下一项承诺。 如果下一项承诺是加速器申请，可以使用Y Combinator 申请技术准备清单整理演示、指标、创始团队责任和进展证据，同时避免过度建设。 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 系统连接工具和数据的技术协议。 最小可信产品由七部分组成： 一个真正痛苦的问题。如果范围描述需要反复使用“以及”，可能是三个产品假装成一个 MVP。 一个具体用户。不是“中小企业”“团队”或“知识工作者”。要明确人物、场景，以及让问题变得紧迫的触发点。 一个值得回来或付费的理由。产品必须创造可重复的结果，而不只是五分钟的新鲜感。 一条完整生产路径。核心流程覆盖输入、处理、输出、错误和恢复。漂亮界面下面如果是不可靠的流程，它仍然只是原型。 与风险匹配的信任底线。只要失败会让测试失去意义或造成危险，认证、权限、隐私、QA 和人工批准就必须存在。 证据，而不是虚荣指标。衡量真正回答业务问题的行为：任务完成、重复使用、付费转化、节省时间或批准率。 明确的不做清单。可信不等于功能多。把不交付的内容写下来，避免更快的代码生成偷偷把范围带回来。 最小可信产品是否意味着过度建设？ 不。过度建设是在证据要求之前添加能力。可信化则持续删除能力，直到剩下的路径可以产生可靠信号。最小可信产品完全可以使用人工操作、托管模型、简单架构和单一集成。它只是不把不安全或不完整的工作藏在 MVP 标签后面。 现在就做 等信号出现再做 真实客户数据的服务端访问控制 第一个客户根本不需要的复杂角色系统 核心路径的错误处理 目标用户真实工作之外的边界情况 与假设直接相关的分析 通用数据仓库和虚荣仪表盘 失败会造成后果时的回滚或人工后备 自动化每一种例外 能够支撑下一批客户的架构 在前十个用户之前就为百万用户设计基础设施 实用规则很简单：构建能够保护实验有效性的保障。推迟那些只是在保护想象中未来的机器。 一个最小可信 AI 产品是什么样？ 假设团队正在构建一个从公司文档中回答问题的 B2B 助手。 原型上传一个 PDF，在干净的聊天界面里返回一条令人信服的答案。它证明这种交互可以成立。 薄弱的 AI MVP 连接共享文档文件夹，加入登录，然后上线。它看起来已经完成，但每个用户都可以检索每份文档；答案没有来源；失败静默发生；也没人衡量答案质量。这种产品的使用数据被污染了：如果用户离开，团队无法判断他们是在拒绝这个想法，还是只是不信任实现。 最小可信产品只服务一个部门，只连接一个文档源。它尊重源系统权限，为每个答案引用原文，在证据不足时拒答或升级，记录质量和成本，并提供清楚的纠错路径。它做得更少，但学习价值更高。 确切的可信门槛取决于风险。一个起草内部社交媒体文案的私有工具，与一个推荐医疗行动、转移资金或暴露客户记录的软件，需要完全不同的标准。可信度取决于场景，不是一份固定清单。 当真实用户和数据即将进入系统时，可以使用AI 生成应用的生产就绪清单完成技术检查。对于 AI 特有的验收标准、评测集和上线门槛，请使用AI MVP 范围模板。 如何界定最小可信产品的范围？ 从决策开始，而不是从功能列表开始。一份有用的范围能用普通语言回答六个问题： 风险最高的假设是什么？需求、付费意愿、重复使用、技术可行性、信任还是采购？选择一个主要风险。 谁的行为能解决这个问题？明确最小的、可接触的用户群体；他们既有这个问题，也有采取行动的权力。 最小的完整闭环是什么？定义用户从哪里进入、得到什么结果，以及接下来应该做什么。 什么失败会让测试失效？如果权限错误、错误答案、慢响应或破损交接会让拒绝原因变得模糊，它就属于可信底线。 哪个可观察事件会改变下一项决策？十个付费试点、40% 的每周重复使用、进入正式采购，或其他上线前就约定好的门槛。 明确拒绝构建什么？把功能墓地放在范围旁边。AI 让功能复活变得危险地便宜。 顺序很重要。如果团队先问“本周能生成什么”，得到的是一份产出清单。如果先问业务风险，团队才能判断什么产出值得存在。 什么时候仍然应该只用原型？ 如果受众清楚知道这是实验，而且问题不需要真实信任，就使用原型。用于五次客户访谈的可点击流程、技术探索、假门测试或内部演示都可以粗糙，因为此时没有人依赖它。 不要因为演示顺利，就悄悄把原型变成生产系统。一旦真实资金、客户数据、运营依赖或品牌信任进入闭环，这个产物的任务就变了。我们的从 Lovable 或 Cursor 原型走向生产指南解释了这次转变背后的工程工作。 创始人应该向开发伙伴提出什么要求？ “我们能做”只是入场券。更困难的问题更有价值： 这个东西真的应该构建吗？ 这个版本要解决哪一项业务风险？ 在定制软件之前，最便宜的诚实测试是什么？ 哪一部分从第一天起就需要生产级工程？ 哪些环节可以继续人工完成，直到用户证明它值得自动化？ 什么证据会让我们停止、继续或增加投资？ 探索、产品领导、定制软件开发、AI 集成和 QA 互相关联，却不是同一项工作。把它们压成一句泛泛的“帮我做个 MVP”，往往会得到一个很快的原型和一个很慢的业务。 严肃的合作伙伴应该先缩小范围，再扩大报价。他们必须解释哪些捷径是有意为之、哪些风险被阻断，以及第一版要证明什么。这也是我们开发 MVP时采用的标准：软件不仅要能演示，还要能够上线和销售。 常见问题 MVP 真的死了吗？ 作为验证式学习方法，MVP 没有死。正在失效的是那种用“它只是 MVP”为粗糙和不完整开脱的产品。AI 降低了可见软件产出的成本，也提高了买家的期望。替代方案不是更大的首版，而是更小、但拥有一条完整可信路径的产品。 什么是最小可信产品？ 最小可信产品，是用一条完整、可靠的路径解决一个痛苦问题，并为下一项业务决策产生证据的最小产品。它在范围上最小，而不是在用心程度上打折。可信门槛由那些会让实验变得不安全或结果不可信的失败决定。 MVP 与最小可信产品有什么区别？ MVP 询问早期用户是否接受价值主张。最小可信产品询问正确的用户是否足够信任产品，从而付款、回来、批准试点或投资。它通常功能更少，但保留下来的核心路径拥有更高质量门槛。 这里的 MCP 是指 Model Context Protocol 吗？ 不是。本文", "articleSection": "产品管理", "author": { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/" }, "dateModified": "2026-07-07", "datePublished": "2026-06-28", "description": "作为验证式学习方法，MVP 并没有死。真正失效的是那种用“它只是 MVP”为粗糙和不完整开脱的产品。AI 降低了基础软件产出的成本，却提高了用户、投资人和企业买家的可信门槛。更好的目标是最小可信产品：用一条完整、可靠的路径解决一个真正痛苦的问题，并为下一项业务决策产生证据。它在范围上最小，而不是在用心程度上打折：一个明确用户、一个值得回来或付费的理由、在失败会使实验失真之处具备生产级基础、能支持决策的分析，以及一份明确的不做清单。本文中的 MCP 指 Minimum Credible Product，而不是 Model Context Protocol。", "headline": "MVP 已死。请构建最小可信产品。", "image": "https://wavect.io/img/blog/headers/header_minimum-credible-product.svg", "inLanguage": "zh", "keywords": "最小可信产品, MVP, AI 软件开发, 产品战略", "mainEntityOfPage": { "@id": "https://wavect.io/zh/blog/minimum-credible-product/", "@type": "WebPage" }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/zh/blog/minimum-credible-product/", "wordCount": 346 } ``` ```json { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "item": "https://wavect.io/zh/", "name": "首页", "position": 1 }, { "@type": "ListItem", "item": "https://wavect.io/zh/blog/overview/", "name": "博客概览", "position": 2 }, { "@type": "ListItem", "item": "https://wavect.io/zh/blog/topics/product-mvp/", "name": "产品与 MVP", "position": 3 }, { "@type": "ListItem", "item": "https://wavect.io/zh/blog/clusters/mvp-validation/", "name": "MVP 验证", "position": 4 }, { "@type": "ListItem", "item": "https://wavect.io/zh/blog/minimum-credible-product/", "name": "MVP 已死？请构建最小可信产品 | ", "position": 5 } ] } ``` ```json { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "作为验证式学习方法，MVP 没有死。正在失效的是那种用“它只是 MVP”为粗糙和不完整开脱的产品。AI 降低了可见软件产出的成本，也提高了买家的期望。替代方案不是更大的首版，而是更小、但拥有一条完整可信路径的产品。" }, "name": "MVP 真的死了吗？" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "最小可信产品，是用一条完整、可靠的路径解决一个痛苦问题，并为下一项业务决策产生证据的最小产品。它在范围上最小，而不是在用心程度上打折。可信门槛由那些会让实验变得不安全或结果不可信的失败决定。" }, "name": "什么是最小可信产品？" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "MVP 询问早期用户是否接受价值主张。最小可信产品询问正确的用户是否足够信任产品，从而付款、回来、批准试点或投资。它通常功能更少，但保留下来的核心路径拥有更高质量门槛。" }, "name": "MVP 与最小可信产品有什么区别？" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "不是。本文中的 MCP 指 Minimum Credible Product，是一个产品战略概念。Model Context Protocol 是连接 AI 应用、工具和数据的技术标准。两者共享缩写只是巧合。" }, "name": "这里的 MCP 是指 Model Context Protocol 吗？" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "不同。Minimum Lovable Product 强调愉悦感和情感吸引力；最小可信产品强调信任和支持决策的证据。消费产品可能两者都需要。受监管的 B2B 试点通常在需要惊喜感之前，就先需要可信度。" }, "name": "最小可信产品与 Minimum Lovable Product 相同吗？" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "可以，前提是生成代码值得保留，而且团队补齐缺失的产品与工程工作：清晰范围、服务端权限、数据保护、故障处理、QA、可观测性、支持决策的分析，以及可维护的交接。有时加固更便宜，有时窄范围重写更合理。" }, "name": "vibe-coded 原型能变成最小可信产品吗？" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "不存在有意义的统一价格，因为可信门槛取决于风险、数据、集成和目标买家。低风险内部流程与受监管、面向客户的 AI 产品是完全不同的项目。可以先参考我们发布的 AI MVP 成本区间，再对那条完整核心路径做具体范围界定。" }, "name": "最小可信产品要花多少钱？" } ] } ```