MVP 最小版本应该做多少功能？

MVP 可以小，但不能靠以后一定重写来成立

工程上的 MVP 不是把十个页面各做一半，而是选择一条有业务价值的纵向切片，从入口、权限、规则、数据库一直跑到结果。比如库存项目的第一版可以只做一种入库和一种出库，但这两条流程必须能留下操作人、批次和库存流水，也必须能在失败时回滚。用户拿到的是范围有限的系统，而不是只有正常路径能演示的原型。

先确定要验证的假设，再决定保留哪些能力

如果要验证“扫码能否减少错发”，第一版就必须记录扫码结果、人工修正和错发原因；如果只做了漂亮的扫码页面，却没有可对比的数据，这个版本无法回答业务问题。我们会把假设写成可观察指标，并在数据模型里预留最少的事件记录，让迭代依据来自真实使用而不是会议印象。

架构跑道只为确定会发生的变化留空间

MVP 不需要提前拆微服务，但需要避免把关键规则写死在页面和 SQL 里。账号、权限、状态流转、审计时间等基础结构从第一版就应正确；低概率的复杂配置、多租户和国际化可以暂缓。所谓架构跑道，是让已知的第二阶段不必推翻第一阶段，而不是为所有想象中的未来增加抽象。

用功能开关和数据迁移控制试运行风险

真实业务试运行时，新旧流程常常需要并存。功能开关可以只向一组用户开放新链路，数据库变更使用向前兼容的迁移，异常时关闭入口而不删除数据。对于库存、订单这类系统，还要准备对账脚本：每天比较旧表格与新系统的关键数量，找到差异后再逐步扩大使用范围。

验收标准要覆盖失败，不只覆盖成功

我们会为最小链路准备一组真实但脱敏的数据，包含正常、重复、缺失和越权输入。验收除了“能提交”，还包括重复请求不会产生两条记录、无权限用户拿不到数据、接口失败后状态可恢复、关键操作能在日志中追踪。小版本把这些底线守住，后续扩展才不会一直偿还技术债。

MVP 的技术设计，要为下一阶段保留哪些接口

先稳定核心对象，不急着拆微服务

第一版可以是结构清晰的单体应用，但客户、订单、任务、库存等核心对象要有独立标识、明确状态和归属关系。可变规则放入配置或策略，不散落在页面条件判断里。这样验证成功后可以扩充角色与流程；如果一开始连数据含义都没定，提前拆成多个服务只会增加联调与部署成本。

从第一天记录验证假设所需的事件

MVP 不是只看注册量。应围绕假设定义事件：用户从哪里进入、是否完成关键步骤、在哪个状态退出、人工介入了几次、一次处理耗时多久。事件带匿名访客或业务用户标识、来源、时间和业务对象，口径写进文档。没有这些基础数据，上线后仍只能靠访谈猜测第一版是否有效。

迁移、审计和导出不能等到“正式版”再补

数据库变更要使用 migration，关键记录保留 created_at、updated_at 和 operator_id，业务数据提供可控导出，备份能够恢复。它们不需要做成复杂平台，却决定试点数据能否继续使用。若验证期全部数据存在临时表或浏览器本地，进入下一阶段往往只能推倒重来。

质量底线与扩展能力要分开

第一版可以暂不做多语言、复杂报表和极端并发，但登录安全、权限隔离、输入校验、错误提示、备份和关键流程测试不能省。对预计变化的功能使用 feature flag，逐步向试点用户开放。MVP 缩减的是验证范围，不是把数据安全和可恢复性也当成以后再说。