# 全周期版本规划与范围分层 - 文档版本：`V1.0` - 基线日期：`2026-03-16` - 适用项目：`TakeoutSaaS` 小程序 C 端 - 文档目标：基于当前已冻结页面职责和当前正式仓库基线，定义小程序从当前阶段到后续成熟阶段的版本路径。 --- ## 1. 这份文档现在解决什么问题 本文件回答 4 个问题： 1. 小程序应该分几期推进。 2. 每一期重点解决什么顾客问题。 3. 每一期应该前置哪些页面和能力。 4. 哪些租户后台能力当前不应该直接前置到 C 端。 这份文档与以下文档配合使用： - `docs/05-页面清单总表.md` - `docs/09-租户后台与C端功能映射总表.md` - `docs/10-全周期研发实施顺序与交付清单.md` - `docs/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-文档导航与实施顺序.md` - `docs/02-信息架构与路由.md` - `docs/03-全局业务规则.md` - `docs/04-核心用户流程.md` - `docs/05-页面清单总表.md` - `docs/06-通用组件清单.md` - `docs/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. 版本依赖关系 1. `V1.0` 没有稳定交易闭环，后续资产和活动没有承接意义。 2. `V1.1` 没有履约和售后，交易体验是不完整的。 3. `V2.0` 没有资产承接，复购和留存没有抓手。 4. `V2.1` 没有活动导流，后台营销能力很难在顾客端转化。 5. `V3.0` 没有服务和精细运营，C 端很难成为长期经营入口。 --- ## 7. 当前推荐落地原则 ### 7.1 按闭环推进，不按页面数量推进 - 优先级取决于是否能形成完整顾客闭环。 ### 7.2 先收口当前已存在页面，再扩新页面 - 当前正式仓库已经有基础页面，不应继续用“未实现很多页面”的思路推进。 ### 7.3 先冻结边界，再扩复杂能力 - 先把当前顾客真正会遇到的页面做稳定。 - 再扩资产、活动、服务等中后期能力。 --- ## 8. 当前结论 当前阶段不是“继续发散页面”，而是： 1. 完成 `V1.0` 当前注册页面和组件的规格收口。 2. 再进入 `V1.1` 的订单履约与售后。 3. 然后依次推进 `V2.0 / V2.1 / V3.0`。 一句话说清楚： 这套小程序的版本路径应该是 `先把交易主闭环做稳，再补订单后链路，再做资产，再做活动，最后做服务与精细运营`。