APP首期范围的界定，不是把功能清单简单删减，而是确定产品在首次上线时必须完成的业务闭环。范围定义错误，后续即使页面数量不多，也可能因角色、权限、接口和异常流程不断扩张，导致预算与周期失控。
先定义首期必须验证的业务闭环
首期范围应回答一个核心问题：目标用户能否完成最关键的任务，管理人员能否完成必要的运营和处理工作。需求梳理时，建议先明确服务对象、用户类型、核心任务、管理内容，以及是否涉及支付、交易、第三方接口和后台管理。
功能可以按优先级分为三类：首期必须上线的功能、能够提升效率但可以后置的功能、需要经过业务验证后再增加的功能。首期不是功能越少越好，而是只保留支撑核心流程正常运行的部分。若一个功能无法影响首期业务闭环，且不涉及基础权限、数据或接口，就应优先放入后续版本。
按流程而不是按页面划定边界
页面数量不能直接代表开发工作量。一个订单页面背后，可能包含创建、状态流转、支付、退款、权限控制和数据查询等逻辑。因此，范围评估必须从真实操作路径出发。
原型确认时，应完整检查每种角色能做什么、每个页面从哪里进入、操作完成后如何跳转、异常时如何提示、哪些数据需要保存和查询。注册、下单、支付、审核、退款等核心环节，只要存在未定义的状态或责任人，就不适合直接进入开发阶段。
把“包含”和“暂不包含”同时写清楚
首期范围文件或报价单，应明确包含哪些端、哪些角色、哪些功能、哪些接口，以及是否包含原型设计、UI设计、测试、上架和后台系统。同时，也要列出明确不包含的内容，并说明后续需求如何确认费用和延期时间。
接口文档、角色权限和核心业务规则应在开发前完成确认。每次变更都应记录变更事项、影响功能、增加费用、延期时间和确认人员。这样界定出的首期范围，既能支撑业务验证，也能避免“顺便增加一点”逐步演变为整套流程重做。
