MVP 做到什么程度能交付：把必须有、可推迟和不做写清

MVP 是最小闭环，不是功能残缺版

判断标准是目标用户能否完成一个核心任务并得到价值，同时系统能处理必要的失败和安全边界。动画、复杂后台和低频角色可以推迟，核心校验和数据保护不能省。

必须有

完成主流程必需的页面、数据、权限、错误和人工操作。

通过标准：缺一项用户就无法闭环或产生不可接受风险

把涉及的文件、目录、版本、命令和实际输出写进记录；代码变化同时保留 diff 与测试结果。

可推迟

能提升速度、外观或规模，但可由手工流程暂时代替。

通过标准：有明确触发条件和后续成本

确认“可推迟”已经有可回查结果，再进入“明确不做”；依据仍然来自猜测时，把缺口单列并停在当前步骤。

明确不做

与当前用户或验证目标无关的角色、平台、自动化和集成。

通过标准：写入范围外，避免开发中被重新加入

确认“明确不做”已经有可回查结果，再进入“质量底线”；依据仍然来自猜测时，把缺口单列并停在当前步骤。

质量底线

关键测试、备份、日志、隐私、可访问性和回滚。

通过标准：即使是 MVP 也不制造不可恢复问题

确认“质量底线”已经有可回查结果，再进入“验收场景”；依据仍然来自猜测时，把缺口单列并停在当前步骤。

验收场景

真实用户从入口到结果的步骤、数据和可见证据。

通过标准：不靠开发者口头解释才能完成

需要修改时先限定文件和行为范围，无法说明回滚方式或影响面的动作先不执行。 完成后把证据归入“MVP 范围与验收表”。

每个范围项都要能回答“为什么现在做”

把价值、风险、依赖和验证方式写进表。截止前出现新需求时先判断替换哪一项，不无限增加“必须有”。