App 第一版该砍什么？用三问法守住 MVP 的工程底线
创业团队做 App，第一版最常见的冲突不是不会开发，而是每个功能都"以后可能有用"。会员、积分、邀请、排行榜、站内信、数据大屏和 AI 推荐不断进入清单，真正要验证的问题却越来越模糊。
MVP 不是功能残缺的 Demo。它应该让一个明确用户完成一件真实的事，并产生可观察结果。范围可以小，交付责任不能断。
先把第一版写成一个等式
第一版可以用下面的方式约束：
一个明确用户 × 一个核心场景 × 一条完整闭环 + 一个验证信号 + 最低上线条件
以预约 App 为例，闭环不是"有一个预约按钮"，而是：看到服务、选择时间、提交、商家确认、用户收到结果，并能在必要时取消或改期。
页面少没有问题；流程走到一半没有结果，才是问题。
MVP 必须保留四层能力
第一层是核心闭环。用户能从触发点走到明确结果，主流程和关键异常都有人负责。
第二层是验证信号。至少定义一个能支持或推翻价值假设的事件，例如完成核心任务、再次使用、提交有效订单。打开次数不一定等于价值。
第三层是人工兜底。早期低频运营可以人工处理，但必须有后台入口、责任人、状态记录和结果通知。没有兜底的"自动化以后再做"，往往会变成无人处理的异常。
第四层是上线底线。隐私政策、必要权限、账号或数据删除、关键日志、备份恢复、应用审核和备案不能以 MVP 为由砍掉。
用三问法筛掉伪需求
面对每个候选功能，依次问：
- 删掉它，核心用户还能完成核心任务吗？
- 没有它，还能得到这轮最关键的验证证据吗？
- 没有它，产品还能安全、合规、可恢复地上线运行吗？
任一答案为"不能"，保留最小实现。三个答案都是"能"，通常延后。
筛选结果只进入三个篮子：
| 结论 | 判断标准 | 示例 |
|---|---|---|
| 现在做 | 支撑闭环、证据或上线底线 | 核心操作、结果反馈、简化后台、隐私入口 |
| 以后做 | 有价值假设，但不影响第一轮验证 | 会员等级、自动化运营、复杂报表 |
| 不做 | 说不清服务谁，也说不清验证什么 | 为了显得完整而增加的功能 |
工程上最容易误砍的部分
有些能力不显眼，却决定第一版能不能真实运行：
- 失败状态和重复提交保护；
- 最低限度的后台与操作日志；
- 用户数据的最小收集和访问控制；
- 隐私、权限、账号及数据删除路径；
- 关键数据备份和恢复方法；
- 开发者主体、备案和审核材料。
Apple App Review Guidelines要求应用信息准确、后台服务可用，并对隐私政策、账号删除等提出明确要求；Google Play也要求允许创建账号的 App 提供账号及关联数据删除路径。面向中国境内提供互联网信息服务时，还要把 APP 备案放进排期。
这些不是发布前一周补两页文案就能解决的事项，它们会反向影响账号、数据模型、页面入口和运营责任。
用一页范围表开始，而不是先画几十张页面
立项前先回答十个问题：核心用户是谁、何时打开、必须完成什么、结果是什么、验证信号是什么、哪些现在做、哪些以后做、哪些不做、人工怎样兜底、上线底线有哪些。
如果核心用户、核心任务和验证信号还写不出来，就不该按页面数量报价。此时缺的不是更多原型，而是产品判断。
MVP 的工程价值，是用较小成本得到下一步决策所需的真实证据。它不是少做测试、少做安全，也不是把异常留给上线后的用户。真正合格的第一版，是范围克制，但闭环、证据和责任完整。