本文是「学习方法与效率」系列第 5 篇，20 个问题讲透 MVP，覆盖最小闭环、假设验证、范围控制和上线决策。可按目录跳读。
Q1. 什么是 MVP？
MVP 是最小可行产品，用最小成本验证最关键的假设，而不是做一个功能残缺的版本。它的目标是学习，不是交付完整产品。
MVP 要回答一个问题：这个需求值不值得继续投入。验证成功就迭代，失败就停下来，避免把预算砸在错误方向上。
项目里 MVP 可以是一个假页面、一个手工流程或一个只支持单场景的脚本。形式不重要，能验证假设才重要。MVP 的关键是学习速度，用最短时间拿到真实反馈，验证完明确继续还是停止。产出不是代码，是验证结论和下一步决策。
Q2. MVP 要验证什么？
MVP 要验证最危险、最不确定的假设，比如用户是否愿意用、价值是否成立、技术是否可行、成本是否可接受。
不要验证已经确定的事情，也不要把所有假设都塞进一个 MVP。一次验证一个核心问题，结论才清晰。
项目里 AI 客服的 MVP 先验证回答准确率和用户是否愿意用，而不是先做多轮对话和复杂权限。假设要按风险排序，先验证一旦错了会让项目失败的假设。最危险的通常是用户是否需要、技术是否可行、成本是否可接受。验证假设要写清成功标准和失败标准。
Q3. 怎么定义最小可行范围？
先列必须验证的假设，再倒推需要的最小功能。只保留能产生验证信号的部分，其他都砍掉。
范围要能在一到两周内完成，能拿到真实反馈。做不完就继续砍，不要拉长周期。
项目里推荐 MVP 只做单场景、单渠道、固定候选集，先看点击率，再决定是否扩召回和排序。范围要围绕验证信号，不要围绕功能完整，能手工、能 mock、能单场景就不要做全量。范围要能在一到两周内跑完，做不完就继续砍。范围要写到能验收的程度，不能只说做个简单版。
Q4. 怎么选择要做的和不要做的？
按假设重要性和实现成本排序。高重要性、低成本的先做；高重要性、高成本的想办法用假数据或人工替代。
低重要性、低成本的可以顺手做；低重要性、高成本的直接不做。不要因为“以后可能用”就加进来。
项目里我会把功能分成验证必需、体验增强和未来扩展，MVP 只做第一类。边界写清楚，避免范围蔓延。判断标准是验证价值除以成本，不是功能多少，高成本部分想办法替代。要写清边界，防止范围蔓延。要区分验证必需和体验增强，MVP 只做前者。
Q5. 怎么快速搭原型？
优先用现成工具、低代码、脚本和假数据。能手工就手工，能 mock 就 mock，不要一开始搭完整架构。
原型只做关键路径，异常和边界先简化。要能跑通端到端，让用户看到真实交互。
项目里 AI 原型可以直接调模型 API 加一个简单页面，先验证效果，再考虑工程化。原型要能端到端跑通，让用户看到真实交互，技术栈选最熟的，不要在学习工具上浪费时间。要能演示，也要能收集反馈。原型要有 demo 脚本，能重复演示，不依赖临时环境。
Q6. 怎么用假数据和假接口验证？
假数据要贴近真实分布，覆盖正常、边界和异常。假接口要返回真实结构，让前端和业务能走通流程。
假数据要标注清楚，避免被当成真实结果。验证完成后要替换成真实数据，不能把假数据带进生产。
项目里推荐原型会先用离线样本跑排序，再接入真实商品接口。假数据用于验证交互，真实数据用于验证效果。假数据要覆盖真实分布，假接口要返回真实字段和错误码。要标注假数据，验证完替换成真实数据。假数据要和真实数据对账，确认分布没有偏。
Q7. 怎么设计原型实验？
先定假设、指标、样本和观察周期。实验组和对照组要可比，变量要单一。
指标要能回答假设，比如点击率、完成率、准确率、留存。样本太小或周期太短，结论都不可信。
项目里 AI 问答 MVP 会选一批真实问题，比较人工答案和模型答案的采纳率，再决定是否继续。实验要控制变量，一次只改一个因素，样本要随机可比，周期要覆盖业务周期。要设基线、指标和阈值，防止偏差。实验结论要能复现，记录样本、时间和环境，写报告。
Q8. 怎么衡量 MVP 成功？
成功标准要提前定，分验证性指标和 guardrail 指标。验证性指标回答假设是否成立，guardrail 防止副作用。
比如推荐 MVP 看点击率，但也要看多样性和投诉率。只涨点击、伤体验，不算成功。
项目里会设一个最低可接受阈值，达到就继续，达不到就复盘是假设错、方案错还是执行错。成功标准要分必须达到和希望达到，guardrail 要防止为了指标伤害体验。阈值、样本和周期要提前定。指标要能归因，知道是哪个改动带来的变化。
Q9. 怎么控制原型的技术债？
原型代码要隔离，不要直接进主分支。能复用的抽象再抽，不能复用的先写死。
原型要有明确的废弃计划，验证完要么重写，要么补齐测试、监控和安全。
项目里原型放在独立目录或独立服务，标注 experimental，禁止直接上线。原型代码要隔离，验证完要么重写，要么补齐工程能力，并明确废弃计划。要标注 experimental，禁止承载核心流量，要有 owner、监控和下线机制，能快速下线，不能成为隐形依赖。
Q10. 原型转生产要补什么？
要补架构、测试、监控、告警、权限、灰度、回滚和文档。原型只验证了效果，生产还要验证稳定性和成本。
数据要从假数据换成真实数据，接口要加超时、重试和限流。安全要从一开始就补，不能等上线。
项目里原型转生产会做一次完整设计评审，列出差距和补齐计划。不能把原型直接当生产系统。架构、测试、监控、告警、权限、灰度、回滚和文档都要补。要评审、压测、演练，确认稳定性和成本。补齐计划要有优先级和时间，不能一次全做。
Q11. 怎么避免原型变成永久方案？
原型要有生命周期和 owner，到期必须决策：转正、重写或下线。没有决策就默认下线。
原型代码要标注 experimental，禁止承载核心流量。监控要能看到原型的调用量和错误。
项目里每季度清理一次原型，避免僵尸服务堆积。原型不是免费资产，维护也要成本。原型要有生命周期和决策点，到期必须转正、重写或下线。要有 owner、监控和文档，避免变成僵尸服务。下线要通知使用方，做好迁移。
Q12. 怎么和业务对齐 MVP 预期？
提前说清 MVP 只验证什么、不覆盖什么、可能的结论是什么。不要让业务以为 MVP 就是最终产品。
要给业务一个时间盒和决策点，验证完一起看数据，决定继续、调整还是停止。
项目里 MVP 启动会写一页说明：目标、范围、指标、时间和不做什么。业务签字后再开工。预期要写清验证什么、不验证什么、可能的结论，定期同步。要设决策点、留时间盒，验证完能停止或调整。业务确认后要签字，避免事后不认账。
Q13. 怎么在 MVP 中保证安全底线？
MVP 可以简化功能，但不能简化安全。权限、脱敏、审计、限流和输入校验要有最低版本。
涉及资金、医疗和个人信息时，安全底线不能妥协。先用小范围、白名单和人工审核控制风险。
项目里医疗 MVP 只对内部医生开放，PHI 脱敏，输出有人工复核。验证效果不等于可以放开合规。要白名单、小范围、人工审核和日志告警。安全评审要前置，不能等原型跑通再补，记录和审计也要有。安全底线要有清单，逐项确认后才放开范围。
Q14. 怎么处理 MVP 的性能问题？
MVP 先验证效果，性能可以暂时妥协，但要知道上限和瓶颈。用限流、排队和缓存防止拖垮系统。
不要用 MVP 承载大流量，也不要因为性能差就否定需求。先区分是方案问题还是实现问题。
项目里 AI 原型会限制并发和输入长度，先看效果，再压测和优化。性能优化放在验证之后。MVP 可以接受较差性能，但要知道上限和瓶颈，用限流、排队和缓存防止拖垮系统。要监控和压测，区分方案问题还是实现问题。性能问题要记录，作为转生产的设计输入。
Q15. 怎么用 MVP 做技术选型？
用 MVP 验证候选技术能否满足关键约束，比如延迟、成本、准确率和集成难度。不要只做 Demo，要跑真实场景。
选型 MVP 要设对比基线，至少两个候选，同一批数据、同一套指标。结论要能解释差异。
项目里向量库选型会用同一批文档和查询跑召回率、延迟和成本，再决定用哪个。选型 MVP 要同一批数据、同一套指标对比候选，不要只做 Demo。要压测、算成本、看维护和退出方案。选型结论要写成 ADR，记录为什么选它。
Q16. 怎么用 MVP 验证 AI 效果？
先定评测集和指标，再跑 baseline 和候选方案。评测集要覆盖正常、边界、无答案和对抗问题。
AI 效果要看准确率、忠实性、拒答率和成本，不能只看一个漂亮案例。要人工抽检，避免 LLM-as-judge 偏差。
项目里 RAG MVP 会先用 100 条真实问题跑召回和答案质量，再决定是否扩知识库和上 Agent。评测集要覆盖正常、边界、无答案和对抗，指标包括准确率、忠实性、拒答率和成本。要跑 baseline，做人工抽检，避免只看一个漂亮案例。
Q17. 怎么管理 MVP 的时间盒？
时间盒是硬约束，到点必须出结论，哪怕结论是“继续调研”。时间盒内只做验证必需的事。
如果做不完，砍范围而不是延长时间。延长时间通常意味着范围没控制好。
项目里 MVP 设一到两周，第一周搭链路，第二周跑真实用户。到点开评审会，决定下一步。时间盒内只做验证必需的事，做不完砍范围，不要延长。要设里程碑、每日同步，到点复盘决策。时间盒到点必须决策，不能无限期调研。日常同步只报阻塞和风险，不报流水账。
Q18. 怎么复盘 MVP？
复盘看假设是否成立、指标是否达到、成本是否符合预期、过程中哪里卡住。结论要明确：继续、调整还是停止。
要区分验证失败和执行失败。假设错是好事，及时止损；执行错要改方法，不要轻易否定方向。
项目里 MVP 复盘会记录数据、用户反馈和决策理由，沉淀成下次的检查清单。结论要明确继续、调整还是停止，不能只写效果不错。要区分假设错和执行错，更新检查清单。复盘结论要进清单，下次直接复用。复盘要写清下一步负责人和时间，不能停在结论。
Q19. 怎么从 MVP 演进到产品？
MVP 验证成功后，再补工程能力：架构、性能、安全、监控、权限和运营。不要一次全补，按优先级迭代。
要保留 MVP 学到的用户反馈和指标基线，作为产品迭代的参照。产品化不是把原型放大，是重新设计稳定性。
项目里 MVP 转产品会先做架构评审和容量规划，再分阶段上线，避免一次性重构。要保留用户反馈和指标基线，作为产品迭代的参照。要架构评审、容量规划，再分阶段上线。先保核心，再扩规模。
Q20. 项目里怎么实践 MVP？
项目里先找最危险的假设，用最小范围验证。能手工就手工，能假数据就假数据，先拿到信号。
LingShu 的 RAG 和 Agent、SuGuangMall 的推荐和秒杀都可以先做窄场景 MVP，再扩功能和流量。
MVP 不是偷懒，是控制风险。花小钱验证方向，比花大钱做错方向更专业。项目里先找最危险的假设，用最小范围验证，设时间盒和决策点，沉淀可复用的检查清单。结论要沉淀成模板，把假设、指标和决策点记录下来，减少下次试错。