移动餐车事业部业务理解记录（供AI使用）

版本信息

• 版本号: v1.1
• 状态:
• 最后更新: 2026-01-27
• 变更摘要: 项目定位由“试点”升级为事业部正式项目，更新 AI 使用口径

目的：统一业务理解与边界条件，避免后续AI在流程与优先级判断上偏离实际。

1. 项目定位与业务模式（已确认）

• 项目已从“移动餐车/移动食堂”试点升级为事业部正式项目，围绕 2026 年目标推进“采购模式”的全链路闭环。
• 说明：早期阶段以试点形式验证关键假设与闭环路径，本文件保留并延续该阶段沉淀的核心口径。
• 采购模式核心逻辑：平台制定菜品标准与采购价，向商家采购合格菜品并获得货权与定价权，自负盈亏。
• 结算口径：以采购订单为准；投放重量仅用于实物验收校验，售出重量用于平台收入核算。
• 风险转移点：现场验收签字后，货权与售卖风险由商家转移至平台。

来源：业务背景信息.md、移动餐车试点核心业务规则书.md

2. 线下实际运营约束（来自现场补充）

• 商家在自己店面配餐、出餐，并负责配送到点位。
• 到场时间：开餐前约20-30分钟。
• 现场只有保温暖菜板，无二次加热/简单处理能力。
• 每餐段每车固定8盆菜（8个1/2份数盆），全部为热菜。
• 单一商家供货为主，无备用供应商。
• 平台人员负责验收签收与售卖运营。

来源：用户补充

3. 主链路与关键握手（已确认）

主链路为：
商拓选品/审核 → 标准菜品库 → 试吃验证 → 合格菜品库 → 菜单结构与定价 → 采购订单 → 生产履约 → 现场售卖 → 数据回流 → 排期优化（晋升/淘汰）

核心链路编号（规则书 L01–L13）：

• L03 选品标准化：平台锁定菜品卡与采购价上限
• L04 菜品准入：商家打样通过试吃后入库
• L05 菜单生产：基于结构与成本模型生成采购订单
• L06 履约验收：现场签字即风险转移
• L07 用户运营：画像/复购数据采集
• L08 餐后损耗：余量与可售率回流
• L10 数据闭环：排期与采购量优化
• L12/L13 晋升/淘汰：数据驱动排期权调整

来源：移动餐车试点核心业务规则书.md

4. 角色边界（已确认）

• 平台：定义标准菜品与采购价、制定菜单结构、承担售卖风险与用户体验责任
• 商家：按采购订单生产并交付合格菜品
• 现场运营：验收签字、售卖管理、用户体验
• 用户运营：拉新/促活/留存/反馈收集（偏好与复购）

来源：业务背景信息.md

5. 关键指标口径（必须一致）

• 可售率：用户真正能打走的有效产出比例，直接影响真实成本
• 售罄率：剔除结构性损耗后的真实动销指标
• 损耗率：1 - (售出重量 / 投放重量)
• 采购订单：平台与商家的结算上限与契约

来源：移动餐车试点核心业务规则书.md

6. 当前核心目标（来自业务诉求）

• 口碑/复购优先，认为这是衡量用户是否被吸引的第一指标。

来源：用户补充

7. 现实矛盾与关键摩擦（基于现状）

• 到场验收只能“发现问题”，无法“补救问题”（无二次加工、无备用供应）。
• 商家自检激励弱：份量小、动力不足，难以落地。
• 如果“不能缺菜”被当成硬要求，则口碑/复购目标会被牺牲。

来源：用户补充 + 业务约束

8. 因采购模式导出的优先级理解（结论）

• 采购模式下，平台必须通过标准化采购与供应商准入去控制质量，而不能依赖商家自检。
• 现场验收是最后一道红线闸口，但不是质量改善的主手段。
• 口碑/复购的可控杠杆在上游标准与供应商淘汰机制，其次是菜单结构与风险分级。

来源：对话总结（可复核）

9. 待确认问题

• 是否允许“菜品不足/提前售罄”来换取口碑底线？
• 是否能严格执行“试供不达标即停供”的供应商准入淘汰规则？