11 KiB
11 KiB
全周期版本规划与范围分层
- 文档版本：
V1.0 - 基线日期：
2026-03-16 - 适用项目：
TakeoutSaaS小程序 C 端 - 文档目标：基于当前已冻结页面职责和当前正式仓库基线，定义小程序从当前阶段到后续成熟阶段的版本路径。
1. 这份文档现在解决什么问题
本文件回答 4 个问题：
- 小程序应该分几期推进。
- 每一期重点解决什么顾客问题。
- 每一期应该前置哪些页面和能力。
- 哪些租户后台能力当前不应该直接前置到 C 端。
这份文档与以下文档配合使用：
docs/05-页面清单总表.mddocs/09-租户后台与C端功能映射总表.mddocs/10-全周期研发实施顺序与交付清单.mddocs/11-V1.0页面开发执行清单与验收标准.md
2. 全周期总览
| 阶段 | 版本建议 | 阶段定位 | 核心目标 | 当前重点 |
|---|---|---|---|---|
G0 |
原型收口期 | 文档、规格、边界冻结 | 把页面职责、路由、规则和映射关系定清楚 | 已基本完成 |
G1 |
V1.0 交易闭环收口版 |
收口当前已注册页面和组件 | 让顾客稳定完成选店、点餐、结算、支付、查单 | 当前主阶段 |
G2 |
V1.1 履约与售后版 |
补齐支付后的服务链路 | 让顾客看懂订单进展、申请退款、完成评价 | 下一阶段 |
G3 |
V2.0 我的与资产版 |
建立长期留存资产承接 | 让顾客查看并使用会员、积分、储值、次卡 | 中期阶段 |
G4 |
V2.1 活动导购版 |
把活动能力前置成导流页面 | 让活动真正导流到商品、购物车和结算 | 中后期阶段 |
G5 |
V3.0 服务与精细运营版 |
进入服务化和精细化经营 | 让顾客获得消息、帮助和更长期的经营体验 | 长期阶段 |
3. 各阶段详细范围
3.1 G0 原型收口期
阶段目标
- 收口页面地图、业务规则、页面规格、组件清单和后台映射关系。
- 统一哪些能力要前置到 C 端，哪些能力不前置。
核心交付
docs/01-文档导航与实施顺序.mddocs/02-信息架构与路由.mddocs/03-全局业务规则.mddocs/04-核心用户流程.mddocs/05-页面清单总表.mddocs/06-通用组件清单.mddocs/07-页面规格/docs/08-11规划和执行文档docs/12-租户管理员功能重构梳理/
完成标准
- 页面职责和版本边界已经明确。
- 设计、开发、测试对“先做什么、后做什么”没有歧义。
3.2 G1 V1.0 交易闭环收口版
阶段定位
当前正式仓库已经有 10 个页面路由和 2 个关键抽屉组件，不再是“从零起页”的阶段。
这一期的重点是把当前已存在页面和组件，对齐到新的冻结规格，形成稳定交易闭环。
重点解决的问题
- 顾客能不能进入正确门店和正确场景。
- 顾客能不能稳定完成加购、结算和支付。
- 顾客支付后能不能找到订单和下一步操作。
版本范围
必须收口的页面与组件
P01门店选择页P18堂食扫码确认页P02地址管理页T02点餐页C01商品详情抽屉C02购物车抽屉P03结算确认页P04支付成功页T03订单页P05订单详情页T01首页T04我的页
核心能力
- 门店和场景上下文前置。
- 渠道和场景驱动的菜单浏览。
- 简单商品直接加购，复杂商品走规格或组合选择。
- 购物车编辑与结算入口。
- 结算页中手动资产与自动优惠分开展示。
- 支付成功页、订单页、订单详情页形成结果承接闭环。
- 首页与我的页形成聚合和导流能力。
当前必须守住的边界
- 首页是导流页，不是固定八宫格活动页，不是资产目录页。
- 点餐页类目和商品必须跟随场景、渠道和门店能力。
- 结算页手动资产当前只确认：
- 优惠券
- 余额
- 次卡
- 自动优惠当前只确认结果展示：
- 满减
- 新客优惠
- 会员折扣
- 免配送费
积分抵扣当前不作为已冻结结算能力。- 当前支付方式页面表达只冻结：
- 微信支付
- 余额支付
- 订单页和详情页使用顾客语言，不使用商家后台看板语言。
本阶段不做
- 退款、评价的完整页面闭环。
- 领券中心、秒杀、限时折扣等独立活动页。
- 会员、积分、储值、次卡等完整资产页。
- 完整消息中心和帮助中心能力。
成功标准
- 顾客可稳定完成
选店 -> 点餐 -> 结算 -> 支付 -> 查单。 - 外卖 / 自提 / 堂食 3 种场景完成基础差异表达。
- 当前仓库注册页面与冻结规格基本对齐。
3.3 G2 V1.1 履约与售后版
阶段定位
在交易闭环稳定后，补齐支付后的订单进展、售后和评价体验。
版本范围
- 回补
T03订单页 - 回补
P05订单详情页 P06退款申请页P07退款详情页P08评价页
核心能力
- 顾客视角订单状态表达。
- 更完整的履约时间轴。
- 最小退款申请和退款结果查询。
- 最小评价提交闭环。
- 再来一单等回流动作。
当前必须守住的边界
- 不把商家后台履约动作直接搬到顾客端。
催单 / 骑手轨迹 / 取餐码不提前写成所有版本固定必做按钮。- 评价页先做最小闭环，不叠加复杂运营玩法。
成功标准
- 顾客知道订单走到哪一步。
- 顾客知道售后在哪里、结果怎么看。
- 支付后体验不再只停在订单列表的最小展示层。
3.4 G3 V2.0 我的与资产版
阶段定位
从“完成一次交易”升级到“形成复购和留存承接”。
版本范围
- 回补
T04我的页完整版 P12会员中心页P13积分商城页P14储值充值页P15次卡页
核心能力
- 我的页承接身份、资产、服务和复购入口。
- 展示会员等级、权益说明和成长信息。
- 展示积分余额、兑换内容和兑换记录。
- 展示余额、充值方案和充值结果。
- 展示次卡说明、购买结果和使用结果。
当前必须守住的边界
- 我的页是聚合页，不是资产真源页。
- 不把不稳定数量字段写成强依赖。
- 不把积分商城反向扩成结算页积分抵扣主入口。
成功标准
- 顾客能理解自己拥有哪些资产。
- 资产页能回流到交易链路，而不是只做静态展示。
- 我的页形成稳定的身份和复购聚合中心。
3.5 G4 V2.1 活动导购版
阶段定位
让后台营销能力在顾客端形成真正的活动导流页，而不是孤立展示。
版本范围
- 回补首页动态活动区
- 回补点餐页活动摘要和活动价表达
- 回补结算页自动优惠命中说明
P09领券中心页P10秒杀活动页P11限时折扣活动页
核心能力
- 券模板聚合和领取导流。
- 秒杀会场和倒计时表达。
- 限时折扣会场和活动商品承接。
- 首页、点餐页、结算页形成活动结果闭环。
当前必须守住的边界
- 当前值得独立页面承接的活动只冻结为：
- 领券中心
- 秒杀活动
- 限时折扣活动
- 满减和新客优惠主要在结果区表达，不先扩成重页面。
- 活动页不能绕开标准交易主链路。
成功标准
- 顾客能在活动页完成导流，不是停留在静态会场。
- 商家配置的活动能真实影响加购、结算和支付。
3.6 G5 V3.0 服务与精细运营版
阶段定位
在交易、售后、资产和活动都稳定后，进入服务化和精细化经营阶段。
版本范围
P16消息中心页P17帮助中心页- 回补我的页服务区
- 回补首页和我的页的个性化推荐模块
- 预留未来扩展入口：
- 发票
- 客服
- 投诉建议
- 个性化券包
核心能力
- 订单消息、营销消息、系统通知的页面职责承接。
- FAQ、售后帮助、服务兜底入口。
- 基于顾客历史和标签的推荐与经营模块。
当前必须守住的边界
消息中心页当前是职责页，不默认等于成熟的完整 inbox。帮助中心页当前是服务兜底页，不默认等于成熟的 FAQ CMS 或客服系统。发票当前更适合作为未来从订单详情页扩出的能力，不在前几期抢主线。
成功标准
- 小程序不只是下单工具，也能承担服务和长期经营入口。
- 顾客在 C 端能找到消息、帮助和个性化服务承接。
4. 全周期能力分层
| 能力域 | 主要内容 | 主要版本 |
|---|---|---|
| 交易域 | 选店、场景切换、点餐、购物车、结算、支付、查单 | V1.0 |
| 履约售后域 | 订单进展、退款、评价、结果说明 | V1.1 |
| 资产域 | 会员、积分、储值、次卡、我的聚合 | V2.0 |
| 增长域 | 领券、秒杀、限时折扣、活动导流 | V2.1 |
| 服务域 | 消息、帮助、服务入口、个性化承接 | V3.0 |
5. 明确不前置到 C 端的后台能力
以下能力当前属于租户后台的经营支撑能力，不应该直接推导成顾客端页面：
- CRM、顾客分析、客户分群
- 财务概览、结算、报表、成本分析
- 商家经营看板、驾驶舱、数据总览
- 后台消息触达中心本身
- 后台 FAQ CMS、本地客服系统本身
这些能力的关系是：
- 可以支撑 C 端页面展示结果。
- 但不直接等于 C 端要做一个同名页面。
6. 版本依赖关系
V1.0没有稳定交易闭环，后续资产和活动没有承接意义。V1.1没有履约和售后，交易体验是不完整的。V2.0没有资产承接，复购和留存没有抓手。V2.1没有活动导流，后台营销能力很难在顾客端转化。V3.0没有服务和精细运营，C 端很难成为长期经营入口。
7. 当前推荐落地原则
7.1 按闭环推进，不按页面数量推进
- 优先级取决于是否能形成完整顾客闭环。
7.2 先收口当前已存在页面，再扩新页面
- 当前正式仓库已经有基础页面，不应继续用“未实现很多页面”的思路推进。
7.3 先冻结边界，再扩复杂能力
- 先把当前顾客真正会遇到的页面做稳定。
- 再扩资产、活动、服务等中后期能力。
8. 当前结论
当前阶段不是“继续发散页面”，而是：
- 完成
V1.0当前注册页面和组件的规格收口。 - 再进入
V1.1的订单履约与售后。 - 然后依次推进
V2.0 / V2.1 / V3.0。
一句话说清楚：
这套小程序的版本路径应该是 先把交易主闭环做稳，再补订单后链路，再做资产，再做活动，最后做服务与精细运营。