# 全周期研发实施顺序与交付清单 - 文档版本：`V1.0` - 适用项目：`TakeoutSaaS` 小程序 C 端 - 文档目标：给设计、前端、接口、测试一个统一的落地顺序，避免“页面很多但阶段混乱、边界失控” --- ## 1. 文档目的 本文件回答 4 个问题： 1. 全周期应该按什么实施顺序推进 2. 每一阶段需要产出什么交付物 3. 每一阶段达到什么标准，才算可以进入下一阶段 4. 如何让实现顺序和当前已经冻结的页面职责保持一致 --- ## 2. 推荐实施总节奏 | 阶段 | 名称 | 主要目标 | 核心交付 | | --- | --- | --- | --- | | `S0` | 范围收口 | 定边界、定版本、定母版文档 | `08 / 09 / 10` 规划文档、页面优先级 | | `S1` | 信息架构与设计基线 | 定路由、定组件、定状态与场景差异 | 路由、低保真、状态矩阵、组件清单 | | `S2` | 交易主链路开发 | 跑通选店、点餐、结算、支付主闭环 | 首页、门店、点餐、抽屉、结算、支付成功 | | `S3` | 履约与售后开发 | 补齐订单后半段体验 | 订单页、订单详情、退款、评价 | | `S4` | 我的与资产开发 | 形成身份、资产、复购聚合闭环 | 我的、会员、积分、储值、次卡 | | `S5` | 活动导购开发 | 把活动导流能力前置到顾客端 | 领券、秒杀、限时折扣、首页活动位 | | `S6` | 服务与预留补位 | 补齐服务兜底和预留职责页 | 帮助中心、消息中心职责页、服务入口 | | `S7` | 联调验收与上线准备 | 全局走查、联调和上线准备 | 联调清单、验收清单、演示脚本 | --- ## 3. 各阶段实施顺序 ## 3.1 `S0` 范围收口 ### 目标 - 把“本期做什么、不做什么、先做什么”收口 ### 必做事项 1. 确认版本分期：`V1.0 / V1.1 / V2.0 / V2.1 / V3.0` 2. 确认页面优先级：`P0 / P1 / P2` 3. 确认三场景：`delivery / pickup / dine_in` 4. 确认后台到前台的功能映射层级： - 直接承接 - 间接支撑 - 未来扩展 - 明确不前置 ### 必交付物 - `docs/08-全周期版本规划与范围分层.md` - `docs/09-租户后台与C端功能映射总表.md` - `docs/10-全周期研发实施顺序与交付清单.md` - 页面优先级结论 ### 完成标准 - 团队已明确“本期不做什么” - 不再有人按后台菜单数量直接推导前台页面数量 --- ## 3.2 `S1` 信息架构与设计基线 ### 目标 - 让后续页面开发不再反复讨论结构边界 ### 必做事项 1. 确认 `4` 个 Tab 与全部二级页、抽屉、弹层路由 2. 确认页面模板：Tab 页、二级页、抽屉、弹层 3. 确认全局状态矩阵： - 默认态 - 空态 - 加载态 - 错误态 - 禁用态 4. 确认三场景差异矩阵：外卖 / 自提 / 堂食 5. 确认页面职责边界： - 聚合页 - 导购页 - 结果页 - 预留职责页 ### 必交付物 - 路由与页面层级总表 - 页面低保真骨架 - 全局设计基线 - 页面状态矩阵 - 场景差异矩阵 - 通用组件清单 ### 完成标准 - 任意页面都能用统一模板快速搭出骨架 - 新页面设计不会再脱离现有模式和边界 --- ## 3.3 `S2` 交易主链路开发 ### 目标 - 先跑通“当前门店上下文建立 → 点餐 → 结算 → 支付成功” ### 开发顺序 1. `T01 首页` 2. `P01 门店选择页` 3. `P02 地址管理页` 4. `P18 堂食扫码确认页` 5. `T02 点餐页` 6. `C01 商品详情抽屉` 7. `C02 购物车抽屉` 8. `P03 结算确认页` 9. `P04 支付成功页` ### 必交付物 - 路由可跳转的交易主闭环 - 当前门店 / 当前场景上下文闭环 - 商品与购物车 mock 或服务层数据 - 金额试算与结算结果占位逻辑 - 三场景基础差异展示 ### 验收重点 - 能否在正确门店和场景下进入点餐 - 能否看清费用来源、优惠结果和实付金额 - 能否从支付成功页进入正确后续动作 ### 当前阶段必须守住的边界 - `P03` 手动资产当前只确认： - 优惠券 - 余额 - 次卡 - `积分抵扣` 当前不作为已冻结结算能力 - `C05` 支付方式当前只收敛为： - 微信支付 - 余额支付 --- ## 3.4 `S3` 履约与售后开发 ### 目标 - 补齐支付之后的订单、履约、售后和评价体验 ### 开发顺序 1. `T03 订单页` 2. `P05 订单详情页` 3. `P06 退款申请页` 4. `P07 退款详情页` 5. `P08 评价页` ### 必交付物 - 顾客视角订单状态分组 - 履约时间轴与场景信息区 - 最小退款申请与退款结果页 - 最小评价闭环 - 再来一单入口 ### 验收重点 - 顾客是否能快速看懂“这单现在到哪一步了” - 售后入口和售后结果是否清楚 - 评价页是否保持最小闭环，不夹带复杂运营玩法 ### 当前阶段必须守住的边界 - 不把商家看板四列直接搬到订单页 - 不把商家动作直接前置给顾客 - 不把 `催单 / 骑手轨迹 / 取餐码` 写成固定必做按钮 --- ## 3.5 `S4` 我的与资产开发 ### 目标 - 把“我的”做成身份、资产、服务、复购的聚合页 ### 开发顺序 1. `T04 我的页` 2. `P12 会员中心页` 3. `P13 积分商城页` 4. `P14 储值充值页` 5. `P15 次卡页` ### 必交付物 - 我的页身份头部卡、资产摘要、订单快捷入口、服务入口、复购区 - 会员权益表达 - 积分余额、兑换内容与兑换记录 - 储值余额、充值方案与充值记录 - 次卡模板说明与使用结果记录 ### 验收重点 - `T04` 是否仍然是聚合页，而不是资产真源 - 资产页是否能回流到交易链路，而不只是静态展示 - 次卡和储值是否按当前证据边界表达，没有写成过满系统 ### 当前阶段必须守住的边界 - 不把 `优惠券数量 / 次卡数量 / 未读消息数` 写死成首页强依赖 - 不把积分商城反向扩成订单积分抵扣总入口 - 不把消息中心当成已经成型的完整收件箱 --- ## 3.6 `S5` 活动导购开发 ### 目标 - 把活动能力前置为“导购页 + 导流结果”，而不是活动孤岛 ### 开发顺序 1. 回补 `T01` 首页动态活动区 2. 回补 `T02` 点餐页活动摘要和活动价表达 3. `P09 领券中心页` 4. `P10 秒杀活动页` 5. `P11 限时折扣活动页` 6. 回补 `P03` 结算页自动优惠命中说明 ### 必交付物 - 首页动态活动位 - 点餐页活动条与活动价商品表达 - 券模板聚合页 - 秒杀活动会场 - 限时折扣活动会场 - 活动导流回商品和结算的链路说明 ### 验收重点 - 活动是否真正导流进商品、购物车和结算 - `P09` 是否保持“券模板导购页”定位 - `P10` 和 `P11` 是否明确分开，不再用一套活动页糊过去 ### 当前阶段必须守住的边界 - 满减和新客活动主要做规则结果展示，不做重页面 - 首页活动位必须动态化，不做固定八宫格 - 活动页不能绕开标准交易主链路 --- ## 3.7 `S6` 服务与预留补位 ### 目标 - 补齐服务兜底能力和当前只保留职责的预留页 ### 开发顺序 1. `P17 帮助中心页` 2. `P16 消息中心页` 3. 回补 `T04` 服务入口与说明文案 4. 预留未来发票、客服等扩展入口位 ### 必交付物 - 帮助中心页 - 消息中心职责页 - 服务入口表达 - 未来扩展入口位规划 ### 验收重点 - 顾客是否能找到基础帮助和服务兜底入口 - 是否没有把后台发送中心、FAQ CMS、客服系统直接假定为已完整存在 ### 当前阶段必须守住的边界 - `P16` 当前只保留页面职责，不冻结完整消息 inbox - `P17` 当前是服务兜底页，不冻结后台 FAQ / 客服动态能力 --- ## 3.8 `S7` 联调验收与上线准备 ### 目标 - 把前面阶段串成一套真正可演示、可交付、可联调的版本 ### 必做事项 1. 检查所有页面路由跳转 2. 检查所有主 CTA 是否闭环 3. 检查三场景差异是否完整 4. 检查金额、优惠、状态文案是否一致 5. 检查登录拦截与回跳逻辑 6. 检查空态、错误态、禁用态 7. 检查导购页是否都正确回流到交易主链路 8. 整理演示脚本、验收清单、联调顺序 ### 必交付物 - 联调清单 - 验收清单 - 演示路径脚本 - 版本发布说明 ### 完成标准 - 业务、设计、开发、测试都能按同一套路径演示 - 新接手的 AI 或工程师可以快速理解全局结构和边界 --- ## 4. 推荐交付物清单 | 阶段 | 必交付物 | | --- | --- | | `S0` | 分期文档、映射文档、实施文档 | | `S1` | 低保真、状态矩阵、场景矩阵、组件清单 | | `S2` | 交易主链路页面、mock 数据、跳转脚本 | | `S3` | 履约售后页面、状态时间轴、订单操作脚本 | | `S4` | 我的页与资产页、资产回流脚本 | | `S5` | 活动页、活动入口、活动承接脚本 | | `S6` | 服务页、预留职责页、服务入口规划 | | `S7` | 联调文档、验收清单、演示说明 | --- ## 5. 如果是个人或 AI 独立推进，建议这样执行 ### 模式 A：先文档后代码 1. 先补齐文档、边界和低保真 2. 再实现可点击原型或页面骨架 3. 最后把原型骨架转成真实小程序代码 ### 模式 B：边文档边代码 1. 每完成一个页面规格，就同步搭建页面骨架 2. 每完成一个阶段，就统一走查路由、状态和边界 3. 不要跨阶段抢做复杂资产、复杂营销或分析页 ### 模式 C：只做 MVP 1. 只做 `S0 + S1 + S2 + S3` 2. 上线后再根据业务反馈扩展 `S4-S7` --- ## 6. 阶段切换门槛 ### 从 `S1` 进入 `S2` 前 - 页面结构、路由、组件模板已稳定 ### 从 `S2` 进入 `S3` 前 - 主交易闭环可完整演示 ### 从 `S3` 进入 `S4` 前 - 订单与售后体验清晰，没有主流程断点 ### 从 `S4` 进入 `S5` 前 - 资产页已能回流到交易链路 ### 从 `S5` 进入 `S6` 前 - 活动页不是孤岛，已能导流到交易闭环 ### 从 `S6` 进入 `S7` 前 - 页面、服务、活动、资产已基本成套 --- ## 7. 实施时最容易踩的坑 1. 一开始就想把所有资产、活动、服务一起做完。 2. 先画很多视觉稿，却没有先收口状态和流程。 3. 把后台字段原样搬到前台，没有翻译成顾客语言。 4. 把后台发送中心、财务驾驶舱、分析页直接当成前台设计来源。 5. 只做页面，不做关键跳转与交互闭环。 --- ## 8. 最终建议 这套项目最稳的推进方式不是“按页面零散推进”，而是： 1. 先按版本收口 2. 再按闭环推进 3. 然后按阶段交付 4. 最后统一联调与上线准备 只有这样，租户后台到 C 端小程序的关系才会清晰，整个项目也不会越做越散。