MVP
MVP（最小可行产品）是能让目标用户完成一件核心任务、并让团队验证关键假设的最小产品版本。它解决的是投入大量开发前不确定用户是否需要的问题，比如先做可上传文件并获得摘要的 AI 工具，观察用户会不会持续使用。
你可能会说：「我想先做一个能给真实用户用的最小版本，看看他们到底需不需要这个功能。」
读之前建议先了解
动手看看文件摘要工具的最小版本
悬停、按住或用 Tab 聚焦上传入口，体验按钮反馈；再切换功能和结果预演。这里不实际上传，摘要是模拟内容。
两项核心功能都开启时，用户能拿到摘要，这才具备验证需求的条件。预演成功不等于需求成立，还要观察真实用户是否再次使用。
要点一个 MVP 怎么帮助我们做决定？
- 1
先找出最需要验证的假设
假设你想做会议纪要工具，最不确定的可能不是能否生成文字，而是用户是否愿意上传录音来获取待办事项。先把这个问题说清楚，我们才知道第一版该围绕什么来做。
- 2
保留完成核心任务的闭环
如果要验证用户是否愿意用生成的待办事项跟进工作，用户至少得能上传录音、看到结果并取走待办。头像设置和主题切换可以以后再做；缺了核心环节，用户就无法真正试用。
- 3
提前约定怎样判断结果
上线前，我们可以约定看多少目标用户完成了流程、是否再次使用，以及他们卡在哪里。这样做的好处是，试用结束后能决定继续投入、调整方向，还是停止，而不只是说一句“反馈不错”。
容易混淆的地方
MVP 和可点击原型的区别在于：原型主要让人看懂并试走流程，MVP 则要让目标用户实际完成核心任务，从使用中验证假设。它也不等于“功能少的正式版”：少做功能只是控制投入，关键仍是能否学到足以影响下一步决策的东西。对于保留的核心流程，基本可靠性不能省掉。
什么时候用
适合用
- 你准备做 AI 合同摘要工具，但不确定法务是否会用它初筛条款，可以先交付可上传、查看和复制摘要的版本。
- 团队想做面向小店的预约系统，却不确定店主是否愿意在线管理时段，可以先让少量店主实际接单。
- 你有几个产品方向，但开发资源有限，可以分别明确关键假设，先用 MVP 验证其中最值得投入的方向。
不适合用
- 只是想比较两种页面布局是否容易看懂，不需要先做 MVP；用可点击原型请目标用户完成任务更省力。
- 现有系统的导出按钮报错，用户需求和修复目标都明确；直接修复并做回归测试，比另起一个 MVP 合适。
- 要按已确定的合同要求交付一套完整后台，范围和验收条件都已明确；按交付计划实施，而不是用 MVP 代替约定功能。
练一练选一个答案，看看解释
你想做一个帮自由职业者整理客户需求的 AI 工具，最不确定的是他们会不会把真实聊天记录交给工具处理。第一步选哪种做法？
让 AI 帮你做复制给 AI Agent 直接用
请和我一起规划这个产品的 MVP。先问清目标用户、核心任务和最不确定的假设，再列出完成任务必需的功能、暂缓的功能，以及邀请真实用户试用后要观察的行为。先讨论范围和验证方式，不要直接写完整产品。