📂 移动食堂（餐车）项目业务背景资料

版本信息

• 版本号: v1.0
• 状态:
• 最后更新: 2026-01-02
• 变更摘要: 初始版本，梳理战略背景、业务场景与团队分工

一、 战略背景与业务模式

• 战略转型方向：
  • 悠饭平台业务正从**“平台佣金模式”（撮合交易/抽成）向“采购模式”**（统采分销/赚差价）调整。
  • 核心逻辑：由平台制定标准（餐标、SKU），向餐厅采购对应标准的菜品，拥有货权和定价权，批量售卖给客户。
• 项目定位：
  • 移动食堂（餐车）作为新业务，是本次战略转型的验证试点（特区）。
  • 目的：在不影响主营业务（包餐业务）的前提下，通过移动食堂跑通“采购-定价-履约-售卖”的全链路，验证盈利公式、商家盈利公式及客户利益公式。

二、 实际业务场景与流程

• 硬件设备：
  • 移动餐车，配备保温餐台。
  • 餐台承载能力：8个标准1/2份数盆（典型配置：4盆主荤、3盆副菜、1盆青菜）。
  • 结算设备：称重设备（含扫码盒）、加热板（保温用）。
• 用户动线：
  1. 打餐：员工从餐车一侧拿餐盒，自主选菜打餐。
  2. 称重：绕行至另一侧，将打好的餐品放在称重设备上（当前为总重称重）。
  3. 支付：亮出微信/支付宝付款码，扫码支付。
  4. 就餐：打饭（支付后环节），前往工位或会议室。
• 当前数据特征：
  • 支付环节：用户直接使用付款码，未强制绑定身份，导致“不知道用户是谁”。
  • 菜品数据：称重模式下，缺乏单品级消费数据，无法记录具体吃了哪种菜、吃了多少。

三、 业务推进规划（基于2025/12/12前后会议）

1. 核心业务模块拆分

• 供应商管理：处理供应商准入与日常事务。
• 用户端：重点解决“用户识别”与“偏好收集”问题。
• 日常现场运营：负责现场的餐车管理与服务。
• B型应用线：涉及业务系统与AI应用的并行推进。

2. 供给端标准化与菜单构建要求

• 合格菜品定义：需同时满足**“好吃”、“标准化”、“成本核算”**三个要素。
• 菜品储备：建议商家储备 30-50个 合格菜品。
• 成本管理要求：需区分**“估算成本”与“实际测算成本”**，确保具备真实的核算能力。
• 菜单构建逻辑：
  • 基于用户数据（口味偏好、交付结算反馈）进行动态调整。
  • 考虑要素：菜品搭配（荤素/辣度）、分量匹配（人员分布）、区域差异（如广州vs上海）。

3. AI应用与系统建设策略

• 并行开发策略：
  • 业务系统与AI应用并行开发。
  • 验证逻辑：需先用业务数据验证AI模型结果；当AI结果与真实数据一致且稳定后，再将交互入口转向AI。
  • AI底层：现阶段优先搭建模型及AI能力基础。
• 短期目标（用户信息收集体系）：
  • 输出 1.0版本饮食偏好模型：定义核心指标（口味维度、消费频率、评价等）。
  • 触达路径：探索调研系统、产品评价功能、会员系统可行性。
  • 补充手段：考虑在结算端增加**“菜品拍照”**环节，结合AI识别辅助获取用户偏好（配合支付订单识别）。

4. 盈利预测模型要求

• 模型目标：解决当前“无逻辑依据、依赖历史人数简单推算”的问题。
• 预测维度：需综合考虑 用户口味偏好、菜品压秤特性、菜品质量、用餐周期 等多维度因素。
• 架构规划：输出多智能体协同框架，各维度（供应链、用户、质量）配置独立预测模块。

四、 [规划] 智能数据采集方案：AI视觉称重 (AI-Visual Scale)

• 核心逻辑：
  • 硬件改造：在称重台上方架设摄像头（俯拍视角）。
  • 触发机制：重量稳定且检测到支付行为（或生成支付二维码）时，自动抓拍。
  • 数据锚点：
    • User ID：通过支付订单号（Payment Token）生成唯一匿名ID，无需实名即可追踪复购行为。
    • 消费数据：总克重（秤） + 结算金额（支付系统）。
    • 内容数据：餐品照片（及后续AI解析）。
• AI 识别价值链：
  • 一级价值（立刻可用）：留证。客诉处理依据，人工抽检菜品结构。
  • 二级价值（训练后）：菜品识别。识别出“盘子里有红烧肉、青菜、米饭”。
  • 三级价值（高阶模型）：克重反推。
    • 逻辑：已知 Total_Weight，通过 (Area_A * Density_A) + (Area_B * Density_B) 的公式，估算各单品的克重消耗。
    • 用途：虽然无法用于精确结算（因为遮挡问题），但足以支撑供应链备货预测（如：消耗了50kg红烧肉 vs 20kg青菜）。

五、 团队分工与时间节点规划

1. 团队分工

• 赵阳团队：需将精力转向 餐车（移动食堂）项目。
• 其他团队：
  • 12月17日开始转向 包餐产品（主营业务）。
  • 12月25日前完成包餐产品的定制化需求交接。
• 业务组（黄杰团队）：主导菜品标准定义，配合产品落地。
• 产品与业务协同：共同对齐数据指标定义（如“口味偏好”的具体参数），输出统一的指标手册。

2. 近期重点工作

• MVP落地：传统产品先行，细化任务并压缩时间。
• 数据对齐：业务与产品团队需统一“数据指标定义”，避免各做各的。
• 流程固化：12月17日前优先推进用户端与供给端的流程固化。

六、 当前面临的核心痛点与挑战

1. 用户信息断层：支付环节无法识别身份，导致画像缺失。（拟通过方案四解决）
2. 消费数据缺失：无法记录具体菜品和反馈，导致AI预测缺乏基础数据。（拟通过方案四解决）
3. 预测模型黑盒：缺乏逻辑依据，未考虑压秤、口味等实际变量。
4. 跨团队协作：供应链标准化与数据指标定义需要业务与产研紧密配合。

七、 试点对齐补充口径（新增）

1. 业务主链路与角色边界

移动食堂试点主链路为：商拓选品/审核 → 标准菜品库 → 试吃验证 → 合格菜品库 → 菜单结构与定价 → 生产履约 → 现场售卖 → 数据回流。
角色边界为：商拓负责选品与标准化；商家负责按单生产履约；现场履约负责试吃验证与现场秩序；用户运营按片区负责拉新/促活/留存/反馈；平台负责结构定价与数据闭环。

2. 菜品库层级定义

• 标准菜品：平台定义的菜品模板与标准参数，不带商家属性。
• 合格菜品：商家按标准试做并通过验证后可上架，带商家属性。
• 优秀菜品（建议引入）：合格菜品中的高表现分层，用于优先排期与流量倾斜，带商家属性。

3. 用户运营定位

用户运营不按点位配置，按商圈/片区统筹，核心任务为拉新、促活、留存、转化与口味偏好收集。

4. 留痕逻辑

全链路动作留痕用于质量评估与人效核算，作为组织保障的评估依据，不仅限于现场合规留证。

5. 结算口径（已明确）

当前试点为投放重量口径：平台按标准采购与定量，商家按价按量交付，未售损耗由平台承担。

6. “采购-定价-履约-售卖”表述说明

该表述强调的是全链路闭环，并非严格的时间先后顺序。