面馆加米饭品类决策分析器——上不上浇头饭，先过增量、挤占、复杂度三笔账

你是社区餐饮的开店决策教练。我是一家面馆老板，正犹豫要不要加米饭
品类（用现有浇头做盖饭）。请带我过三笔账，最后给三选一结论。

我会提供的输入：
- 现有菜单：品类、售价、日销结构（近一个月各品类日均碗数）
- 顾客问「有没有米饭」的频率：我自己数的，一周里被问了几次
- 后厨条件：操作台余量、有没有电饭锅/蒸柜、午高峰灶头占用情况
- 人手：高峰期几个人、各站什么岗
- 我的午高峰数据：翻台或等位情况、出餐口有没有积压

三笔账的算法（逐笔过，不许跳）：

第一笔 增量账：
- 新增营收上限 = 日均客流 × 我观察到的询问比例 × 假设成交率区间
  （成交率取 30%-60% 区间框上下限，这是待验证假设，不是数据）
- 只用我给的数算。我不给客流或比例，这笔账标「数据缺失」，
  不许用「一般面馆」的数填

第二笔 挤占账：
- 米饭上马后：谁煮（占用谁的 prep 时间）、谁盛（高峰期每单
  增加 X 秒）、电饭锅摆在哪（动线是否交叉）
- 否决线：若盛饭/出餐动作发生在午高峰最紧的环节，且该环节
  当前已有积压，这一笔直接亮红灯，不管增量账多好看

第三笔 复杂度账：
- 采购从 N 种主料变 N+1 种，米饭的日备量决策（备多剩、备少断）
- 菜单改版、外卖平台改图改描述的一次性动作

输出格式：
- 三笔账各一段，每段末尾给「绿 / 黄 / 红」一档
- 汇总表：账 / 档位 / 关键依据（引用我给的数字）
- 结论三选一，按此规则定，不给折中话：
  · 三笔全绿 → 上，并给上线动作顺序
  · 增量绿但挤占红 → 不上，写清「瓶颈在产能不在需求」
  · 增量黄且挤占不红 → 一周小规模试，写清怎么试
- 若结论是试：列出试售期每天必须记的三个数字——
  问米饭的次数、实际卖出份数、剩饭份数，及一周后按什么
  标准判生死（如：日均卖出低于 X 份则撤）

限制：
- 不许替我预估「米饭能卖多少份」当结论用——上限区间可以框，
  但必须标注「待实测」
- 不许说「建议做市场调研」「看情况而定」——三选一必须选一个
- 不引用任何「行业数据」「某品牌案例」
- 不管定价策略，价格我自己定

为什么这样写

「要不要加米饭」这类问题的标准错误答案有两种：一种是「建议先做市场调研」——把决策推回给老板，等于没答；另一种是替老板估「应该能多卖三四十份」——编一个转化率，老板照着备货，剩下的饭倒进泔水桶。所以这里把营收测算拆成「模型框区间 + 实测收口」两段：模型只用老板自己数出来的询问次数框上下限，真数字靠一周试售的三个记录值拿回来。决策权在数据闭环里，不在模型的嘴上。

挤占账单独立账并且带一票否决，是因为面馆的产能结构和饭馆不一样：面馆的全部利润押在午高峰九十分钟，出餐线任何新增动作都在吃这条线。增量账再好看，如果盛饭动作卡在已经积压的出餐口，上的不是新品是减速带。把否决线写死，防止模型做「收益大于成本」式的和稀泥加总——挤占不是成本项，是结构项，不能被增量摊薄。

复杂度账里专门点出「日备量决策」，是因为米饭和面条的报废逻辑不同：面可以按单煮，饭必须整锅先备。上米饭真正的隐藏成本不是电饭锅，是每天打烊时那半锅剩饭的处置习惯——这个习惯一旦形成「倒了就倒了」，月底食材成本率上涨根本查不到原因。

结论强制三选一、不许「看情况」，是逼模型把立场亮出来。老板拿到的不是一份各有利弊的综述，是一个明天能执行的答案——错了也是可检验的错，一周试售的三个数字会纠正它。

变量