移动餐车：产品系统背景与现状调研
版本信息
- 版本号: v1.0 (已定稿)
- 状态:
- 最后更新: 2026-01-26
- 文档定位: 本文档旨在全景还原移动餐车项目启动时的 "家底" (Legacy) 与 "战场" (Context)，作为后续系统规划与架构设计的唯一事实依据。
一、 系统现状底座 (Legacy System)
1.1 老团餐系统概况
- 历史: 沉淀 10年+，功能不断堆叠的单体/大系统。
- 核心模块:
- 订餐系统 (线上预订，面向盒饭/预订场景)
- 食堂SaaS系统: (定义修正) 面向"客户自建/租赁食堂"场景。
- 业务流: 客户委托 -> 运营商承包 -> 档口招商。
- 功能: 运营商开通档口，商家独立后台管理菜品/对账。
- 运营管理系统
- 企业后台管理
- 业务基因: B端 (ToB) 基因。核心服务于 "企业食堂/团餐"，侧重于管理、补贴、企业支付。
- C端能力现状: 极其薄弱。用户营销、私域运营、画像分析几乎为零。
1.2 技术决策现状 (Technical Decisions)
- 架构定性: 独立新主权 (Greenfield)。
- 不背历史包袱: C端体系完全从零搭建，只吸取能复用的逻辑经验。
- 数据隔离: 核心业务数据与老团餐隔离。
- 数据互通: 仅同步必要的 商家档案 (Merchant Profile) 等基础数据。
二、 硬件与研发资源现状 (Readiness)
2.1 核心设备与软件
- 称重台: 商米 (Sunmi) 智能称重收银一体机 (已采购)。
- 收银软件 (B端): 自研 (Native Android)。
- 技术栈: 原生 Android (Java/Kotlin) + 商米 SDK。
- 资源: 团队现有 2名 Android 前端 + 2名后端 (具备接口对接能力)。
- 改造策略: 接口替换 (Swap)。保留原生称重/硬件交互逻辑，仅调整前端 UI 并将后端 API 指向新餐车系统。此方案比重写更节省时间。
- 用户端 (C端):
- 选型: 微信小程序 (明确放弃支付宝，专注微信与企微生态)。
- 现状: 老团餐系统由 H5/小程序 组成，新系统将参考其交互，但后端逻辑重写。
2.2 数据与接口就绪度
- 支付连续性 (补贴迁移): 有解 (Migration)。
- 策略: 建立 "老系统用户 <-> 新系统用户" 映射机制。
- 执行:
- 量大: 开发 "一键同步/绑定" 入口，调接口迁移余额。
- 量小: 线下统计，人工录入新系统。
- 菜品数据 (SKU): 无法复用 (Incompatible)。
- 原因: 老系统菜品结构面向"预于入柜/盒饭"，维度与餐车不符。
- 决策: 新系统 SKU 库从零建档。
- 商家档案接口: 待开发 (Pending)。
- 现状: 目前无现成接口。
- 利好: 现有研发人员熟悉老数据库结构，开发新接口无技术门槛。
- C端数据迁移: 不需要 (Greenfield)。
- 策略: 不迁移历史饭卡/余额，C端用户体系从零开始。
三、 业务与运营现状 (Operations Context)
3.1 销售与运营 (Sales & Ops)
- 工具现状: "石器时代"。
- 销售铺点、商家排期、现场排班、损耗记录等，目前全靠 表格 (Excel/在线文档)。
- 结论: 内部效率虽低，但 Q1 阶段可通过人工手段维持运转，优先级排在 C 端体验之后。
3.2 2026 Q1 战略重心 (Must-Win)
- 北极星: C端体验突围 (User Experience)。
- 核心理由: 餐车是零售生意，私域流量 (拉新、复购、留存) 是生死线。现在的 "B端体验" 无法留存 C 端用户。
- 优先级排序:
- C端营销闭环 (积分/券/画像) > P0
- 收银台改造 (识别C端会员) > P0
- 后台管理效率 (排期/验收) > P1 (暂缓)
- 财务自动对账 > P1 (暂缓)