S1-C01
商家端 V1 是否定位为轻量运营后台?
建议结论:是。V1 不做完整 ERP,先服务真实营业动作。
- 它负责订单处理、制作看板、茶礼处理、商品维护、基础配置和异常处理。
- 店长能看到今日待办,现场员工能快速处理已支付订单。
- 后续可以扩展权限、数据统计和更复杂经营能力。
确认后范围更清楚,S2/S3/S4 可以按模块推进。
如果不确认后台容易膨胀成 ERP,拖慢上线。
原文:第 3、4、11 章
S1-C02
是否不做商家端人工点单 / 收银台?
建议结论:是。用户扫码,自助下单并完成支付,商家端只处理已支付订单。
- 不做员工替用户点单,不做前台收银。
- 不做报手机号扣会员余额。
- 不做好友卡截图或口头核销。
确认后订单和资金链路更简单,更适合 MVP。
如果不确认会引入收银、权限、对账、误扣等复杂问题。
原文:第 4.2、7.1、7.5 章
S1-C03
是否采用“角色权限 + 工作模式”?
已确认方向:是。后台角色不能写死,V1 支持角色配置和页面级功能权限;暂不做数据权限和按钮级权限。
- 角色里可以勾选功能权限,第一版先做到页面级别。
- 暂不做数据权限,例如“只能看自己订单”或“只能看某门店数据”。
- 暂不做按钮级权限,例如某个页面里的“退款”“删除”“导出”按钮是否可操作。
- 工作模式用于组织页面体验,不替代角色权限。
确认后后台有权限底座,又不会被复杂权限拖慢第一版。
如果做得更深数据权限、按钮级权限和审批流会显著增加设计和开发量。
原文:第 4.1、5 章;后续需单独权限 PRD 细化
S1-C04
P0 是否包含 6 个必做模块?
建议结论:是。基础配置、商品、点单订单、制作看板、茶礼订单、商家端首页进入 P0。
- 基础配置避免用户端写死茶场信息。
- 商品、点单订单、制作看板决定能否现场营业。
- 茶礼订单和商家端首页支撑茶礼闭环与日常管理。
确认后V1 主干完整,能覆盖点单和茶礼。
如果不确认后续排期会反复摇摆,容易漏主链路。
原文:第 6.1 章
S1-C05
P1 是否包含会员、好友卡、经营数据?
已确认:是。它们属于 V1 范围内,但开发顺序放在后面;经营数据优先级建议放在会员 / 好友卡之后,先做基础看板,不做复杂 BI。
- 会员与充值管理用于查询、充值记录、消费记录、退款流水。
- 好友卡管理用于列表、详情、流水、关联订单和异常查询。
- 经营数据先做基础看板,不做复杂 BI。
确认后不会遗漏会员好友卡,但不抢 P0 资源。
如果不确认可能过早做复杂会员系统,影响上线节奏。
原文:第 6.2、7.5 章
S1-C06
第一开发模块是否为基础配置?
建议结论:是。先做基础配置,再做商品和订单。
- 茶场名称、地址、电话、营业时间、停止接单、首页轮播图都应从后台配置。
- 这能避免用户端页面写死信息。
- 也为订阅消息、物流 API 等后续配置留入口。
确认后可以直接进入 S2-T001 基础配置 PRD。
如果不确认用户端和后台会反复临时写死信息。
原文:第 7.4、8 章
S1-C07
资金相关模块是否坚持先技术文档后开发?
建议结论:必须坚持。支付、退款、余额、好友卡流水不能直接边想边写代码。
- 真实支付和退款涉及密钥、回调、对账和资金安全。
- 好友卡和会员余额都需要流水可追溯。
- staging 默认 mock 支付,prod 才进入真实支付链路。
确认后资金安全底线清楚,后续开发更稳。
如果不确认容易产生资金错账、退款漏洞和不可追溯问题。
原文:第 8、10 章;S0 技术决策