2026年度移动餐车产品系统规划

版本信息

• 版本号: v3.17
• 状态:
• 最后更新: 2026-01-29
• 变更摘要: [v3.17] 优化 Q1 产品人力排布，前置 Q2 核心预研任务（商家/楼栋）至节后空窗期；清理冗余衔接描述。
• 变更摘要 (历史): [v3.16] 修正 Q1 研发时间轴与工作日计算；校准效率提升描述；统一“上线”语义。
• 变更摘要 (历史): [v3.15] 逻辑修复：统一 Q3 指标口径（预测准确率）；规范用户身份 ID 体系（OpenID/User ID）；明确点位-商家排期互斥约束。
• 变更摘要 (历史): [v3.14] Q3 指标调整为“用餐人数预测准确率”；Q4 战略重构为“软硬结合”（增硬件/会员/商家等级，去集采）；新增“硬件创新”独立泳道。
• 变更摘要 (历史): [v3.13] Q2 新增"楼栋信息采录"销售支持模块；菜品治理专项精简范围（仅合格库自动化），红绿灯榜单/自动激励后移至 Q3。
• 变更摘要 (历史): [v3.12] Q4 重新定位为"规模壁垒"，删除定义模糊的"精准营销引擎"，聚焦集采平台为唯一战略壁垒。
• 基准文档: 产品系统背景与现状调研.md

---

〇、全年产品路线图总览

一眼看清全年节奏：Q1 体验突围 → Q2 规模复制 → Q3 数据智能 → Q4 软硬结合 (精细化)

各季度核心战役

阶段	周期	核心战役	关键指标	交付物
Q1	1-3月	体验突围	会员渗透率 > 50% [1]	• C端小程序 • 新收银台 • 拉新两件套
Q2	4-6月	规模复制	人均运营点位 > 5 [3]	• 商家端 (排期/对账) • 运营验收（移动端） • 设备管理 • 楼栋信息采录 • 菜品治理专项
Q3	7-9月	数据智能	用餐人数预测准确率 > 90% [2]	• 个人口味建模 • 点位画像与客流预测 • 销量预测与智能排菜
Q4	10-12月	软硬结合	千台目标达成	• ** 商家等级体系** • 积分会员体系 • 智能餐车 v2.0 (AIoT)

[1] 产品提供扫码引导工具，最终指标由运营现场推广达成。
[2] 基于支付 User ID 的精准预判。该指标主要受历史数据与日历特征（周末/节假日）影响，属于产品技术团队核心可控的算法能力指标。
[3] 系统赋能人效的及格线。当前纯人工模式人效约 1.2 点位/人，目标 >5 代表系统替代人工监管带来的超 4 倍效率提升。

---

一、 核心战略与打法

1.1 现状定性

• 底座: 拥有 原生安卓收银端源码；老团餐系统可提供商家基础数据与支付通道。
• 挑战: 当前是用 "B端管饭堂" 的逻辑硬扛 "C端做零售" 的业务，导致无画像、无留存、无营销。
• 策略: 独立新主权 + 接口互通。C端完全从零搭建（微信小程序），B端收银台采用 "界面适配+接口切换" 方案复用原生代码。
• 资源盘点:
  • 研发团队：现有 "2后端 + 2安卓前端 + 1测试" 的配置（可灵活调配）。
  • 产品设计：现有 "2名产品经理 + 1名UI设计师(共享)" 负责文档与视觉。

1.2 核心指标定义

会员渗透率 = 小程序支付笔数 / 总支付笔数

定义：每10个用户付款，有多少是通过小程序完成、系统可识别身份的。

说明：会员渗透率关注的是"识别用户身份"。

当前基线: 0% (无数据)

量化假设 (Q1 试点验证)：

• 试点场景：以公司内部员工餐厅为首个验证点位
• 目标人群：公司员工约 50 人，日均午餐人次约 30
• Q1 末目标：会员渗透率 ≥ 50%（即日均 15+ 笔小程序支付）
• 验证节点：灰度期（3.24-3.31）每日统计渗透率，验证目标可达性

---

二、 Q1 详细执行计划

目标: 3月31日前，聚焦 "C端交易闭环 + 基础拉新"。不求大而全（暂缓积分/企业认证），只求 "能卖货、能发券、能裂变"。

2.1 Q1 核心交付物列表

模块	功能点	交付标准	备注
基础设施	• 项目初始化 • 代码仓库/集成发布环境搭建	跑通基础流程	技术内部管理
基础交易	• 打菜-称重-显码-支付 • 订单列表/详情 • 微信支付接入	跑通「打菜-称重-显码-手机扫码支付-设备播报」全流程	核心交易闭环
营销地基	• 优惠券中台 (配置/发放/核销) • 领券中心 (前端)	支持 "满减券" 与 "立减券" 的全生命周期流转	替代复杂的积分体系
拉新工具	• 新人首单立减 (自动计算) • 邀请有礼 (老带新送券)	新用户首单自动抵扣； 老用户每邀请1人得1张券	暂不做 "连续用餐奖励"
数据 最小可行性产品	• 数据导出 (Excel) • 包含：用户明细/拉新关系/订单表	运营可一键导出 Excel 进行透视分析	不做在线数据看板

2.2 Q1 产品计划

本计划保障 Q1 核心产出，Q1 后半段（2 月下旬起）可衔接 Q2 功能需求设计。

序号	任务名称	核心范围	负责人	开始	结束	备注
1	数据模型与规则定义	核心实体字段规划	陈旻	1-29	1-29	已完成
2	小食堂小程序 PRD	扫码支付、优惠券、拉新两件套等全量 PRD	陈旻	1-30	2-7	Q1 核心 C 端
3	餐车收银扫码 APP PRD	称重 SDK 集成、收银显码/扫码、退款流程	杨昭原	1-30	2-4	Q1 核心 B 端
4	运营后台 v1.0 PRD	基础档案、订单/优惠券查询、发券管理	杨昭原	2-5	2-26	节后主力开发支持
5	智能餐车硬件预研	可折叠结构调研、视觉采集与算法方案	杨昭原	2-26	3-24	并行启动硬件探索线
6	商家端与菜品治理 PRD	菜单、排期、采购单提报、合格库审批流	陈旻	2-24	3-14	Q2 核心预研前置
7	销售采录系统 PRD	楼栋/商圈资产采集、销售陌拜过程管理	陈旻	3-17	3-28	Q2 核心预研前置

2.3 详细时间轴

• 规划周 (1.27-2.02): [产品] 需求调研、竞品分析、方案定稿。
• 设计周 (2.03-2.14): [产品] 原型设计、UI 出图；[技术] 方案预研、基建准备。注意：预留节前 1-2 天弹性缓冲（应对提前请假）。
• 春节 (2.15-2.23): 全员休假 (2月24日正式开工)。
• 研发冲刺 (2.24-3.25): [研发] 约23个工作日（基于大小周制度核算），完成核心功能开发与联调。
• 验收/灰度 (3.24-3.31): [运营] 配合单点灰度验证，收集真实反馈。

2.4 关键架构决策

• 身份模型: "点位为主，客户为辅"。
  • 核心策略: 鉴于 99% 场景在微信生态，Q1-Q4 聚焦通过微信 OpenID 构建会员体系。
  • 扩展性: 暂不接入支付宝，但架构设计需预留多渠道账号映射能力 (One ID)，为未来扩展做储备。
• 营销逻辑: Q1 仅通过 满减券/立减券 单点工具进行拉新与促活，保持机制简单直接。

2.5 基础数据初始化 (Q1 策略)

原则：新老系统解耦，仅做"基础信息"的单向一次性导入。

商家数据

• 数据来源：从老团餐系统导出商家信息。
• 导入字段：商家基本信息、简称、工商注册名称、经营资质等。
• 菜品管理：Q1 阶段由运营人员在管理后台代录入标准菜品；Q2 将上线"商家排期门户"，由商家自行提报。

点位基础建设

• 点位档案：建立点位主数据（点位ID、名称、地址、容纳餐车数、所属区域）。
• 点位-商家关联：支持一个点位挂载多个商家档口。
  • 约束: 同一餐段 (午/晚) 仅允许一个商家排期生效。确保断网或静态码模式下，系统能唯一确定收款方。
• 点位二维码：生成点位专属扫码入口，用户扫码即进入对应点位的选餐页面。

2.6 断网静态收款码应急

设计原则：极端断网或设备故障时，以"保障交易闭环"为最高优先级，确保订单数据完整（含点位、商家、用户、金额）。

• 点位收款码：
  • 运营后台「点位配置」中可下载点位专属静态收款码。
  • 用户扫点位码 → 跳转小程序 → 系统自动查询该点位当前 餐段生效 的商家。
  • 约束：若当前时段无排期商家，则提示无法下单；确保静态码也能路由到正确商家。
• 用户输入金额：
  • 现场运营人员口头报价，用户在小程序内手动输入金额并确认。
  • 支付完成后生成完整订单（含点位、商家、用户、金额），支持优惠券核销与拉新活动。
• 物理码备份：
  • 建议将点位收款码打印贴于餐车，作为设备故障时的兜底方案。

2.7 运营后台基础模块 (Q1 范围)

说明：以下模块为系统运行的必要基础，Q1 需完成基础增删改查能力。

• 用户管理：基于 OpenID 的会员列表查询、基础标签。
• 点位管理：点位档案维护、点位-商家关联配置。
• 商家管理：商家信息维护、菜品代录入。
• 订单管理：订单列表查询、订单详情、退款处理。

2.8 拉新两件套 (C端通用)

设计理念：Q1 优先解决 B端向C端转变的首要卡点——如何让用户愿意扫码。采用简单直接的券机制，用最小成本验证拉新效果。

功能	机制	门槛	预期效果
① 新人首单立减	系统自动判别首单，结账立减 3 元	满 15 元可用	降低首单门槛，提升转化率
② 邀请有礼	老带新双方各得 5 元满减券	新人消费后发放	裂变拉新，低成本获客

2.9 周级排期（节后 5 周攻坚）

说明：产品设计在节前完成；研发主力在节后 (2.24) 启动。

2.10 阶段拆解 (按周执行)

阶段一：节前技术深度前置 (W1-W3: 1.27 - 2.14)

原则：逻辑前置，契约先行。年后直接进入「填空式」开发。

• 基建体系：自动化部署流水线调优，生产/测试环境服务器隔离与配置。
• 架构设计：基于「独立新主权」原则完成数据库逻辑建模 (ER图)，定义核心业务实体表。
• 支付对接：完成微信支付（V3版本）及服务商模式的账户权限调研，跑通本地测试环境的模拟支付。
• 硬件预研：针对「商米称重一体机」安卓原生 SDK 进行接口封装预研，确保年后能直接调用重量数据。
• 接口契约：根据 PRD 预定义前后端交互的开放接口契约，支持年后前端开发基于模拟数据先行。
• 产品交付：2.14 前产出全量 PRD 与 UI 稿 (含领券页、下单页)。

春节休假 (2.15 - 2.23)

• 安排: 全员休假 (2月24日正式复工)。

阶段二：核心攻坚 (W4-W5: 2.24 - 3.08)

重点：跑通交易主链路。

• 后端：实现用户识别、结算引擎、主数据接口。
• 前端：小程序点餐页集成，收银设备 SDK 对接，后台管理门户基础界面。
• 里程碑：收银台能显示扫码支付二维码，小程序能扫码下单。

阶段三：拉新与数据闭环 (3.09 - 3.23)

重点：实现营销与数据闭环。

• 营销：优惠券引擎（发、算、核），邀请裂变逻辑实现。
• 数据：订单流水聚合与 Excel 导出功能。
• 里程碑：拉新两件套上线，运营能导出数据。

阶段四：验证交付 (W8: 3.24 - 3.31)

重点：真实环境「实弹演习」。

• 动作：全链路联调压测，单点灰度部署。
• 交付：确认数据准确，签署 Q1 验收单。

---

三、 Q2 - Q4 演进蓝图

Q2: 效率与合规（规模复制）

主题: "把自己从表格里解放出来"

• 4月: 商家端
  • 痛点: 商家还在用微信报菜名。
  • 功能: 商家端上线 "排期提报"、"每日采购单"。
• 5月: 楼栋信息采录 (销售资产沉淀)
  • 痛点: 销售扫完楼，信息记在备忘录/脑子里，离职即带走；公司不知道哪栋楼跑过了。
  • 功能: 销售小程序录入片区、商圈、楼栋、入驻企业基础信息，沉淀公司级楼栋数据库。
  • 后续扩展 (Q3): 潜客管理、拜访记录、签约漏斗。
• 4-6月: 硬件创新专项 (探索期)
  • 可折叠车体: 完成手板打样，验证物理结构与收纳便利性。
  • 视觉采集: 在早期点位安装双摄（打菜/托盘），人工标注数据，验证"视觉识别"的可行性。
• 5月: 运营验收（移动端）
  • 痛点: 验收标准靠嘴说。
  • 功能: 收银端增加 "验收模式" (拍照/称重录入)，不验收不开餐。
• 6月: 自动对账
  • 痛点: 线下与商家对账数据分散，经营分析表格处理低效。
  • 功能: 将线下对账数据搬到线上，每日生成标准账单，支持多维度 (商家/点位) 拆分，提升经营分析效率。
• 6月: 设备管理
  • 痛点: 6月点位破百，资产规模超500件，人工台账管理失效，资产去向不明。
  • 功能: 实现称重一体机、扫码盒子、摄像头及餐车本体的入库、绑定 (人-车-点) 与盘点，通过车身实体码管控无联网设备。
• 4-6月: 菜品治理专项
  • 痛点: 规模化后，无法靠人工筛选好菜，好坏一个样，商家缺乏提升品质的动力。
  • 范围: 合格库自动化 — 商家在【商家端】认领标准菜品、提交打样、查看审批流，实现准入标准化。
  • 后续扩展 (Q3): 红绿灯榜单、自动激励逻辑。

Q3: 数据与风控（智能化）

主题: "用算法对抗人性"

• 7月: 个人口味建模
  • 逻辑: 数据原子化。基于 Q1-Q2 积累的消费流水，为每个 User ID 贴上结构化标签（口味、单价敏感度、用餐时段）。
• 8月: 点位画像与客流预测
  • 逻辑: 从个体到群体。将点位内的固定人员标签进行指数加权聚合，并结合日历特征（节假日/天气）产出未来一周客流预测。
• 8-9月: 销量预测与智能排菜
  • 功能: 基于客流预测结果，自动建议备货量，并微调周菜单比例（优先排高毛利且符合当地“群体偏好”的组合）。
• 9月: 商家履约分体系
  • 功能: 迟到/投诉/质量异常自动扣分，得分直接影响商家在 Q4 的等级权益。
• 7-9月: 硬件创新专项 (研发期)
  • 视觉算法: 基于 Q2 数据训练"打菜热度"与"盘中餐识别"模型，跑通数据闭环。
  • 小批量试制: 试产 50 台 v2.0 样车，进行实地灰度测试。

Q4: 软硬结合（精细化运营）

主题: "硬件量产落地，软件精细运营"

• 10-12月 (核心战役):
  • 商家等级成长体系:
    • 功能: 基于履约分实现 S/A/B 分级管理。S级商家享优先派单、费率优惠；C级商家限制接单。以机制优胜劣汰。
  • 积分商城与会员等级:
    • 功能: 消费返积分、积分换券/周边；建立 V1-V3 会员权益（如新品尝鲜、免排队），提升复购率与粘性。
  • 智能餐车 v2.0 (AIoT 量产):
    • 功能: 可折叠车身规模化列装；双摄视觉算法正式合入业务流（为口味模型提供更精准的输入数据）。
    • 价值: 真正实现"物理空间降本"与"数据资产增值"，构建千台规模下的硬件壁垒。

---

四、 附录

4.1 术语对照表

术语	定义
会员渗透率	小程序支付笔数 / 总支付笔数。衡量系统识别用户身份的能力 (Q1-KR 指标)

| 拉新两件套 | 新人首单立减 + 邀请有礼（Q1 不做连续用餐奖励） |

4.2 与其他文档关系

本文档章节	关联文档	关系说明
现状定性	产品系统背景与现状调研.md	基准文档，详见家底与资源现状
会员渗透率目标	年度千台餐车里程碑规划.md	里程碑文档同步使用此指标
毛利率基准	采购定价逻辑与测算模型.md	组合毛利率 40.5% 计算详见

---

总结: Q1 的核心不再是 "收银重构"，而是 "接口切换 + 拉新两件套"。我们用最小的研发成本 (换接口)，换取最大的业务价值 (会员渗透与复购)。