面馆班次结构分析器——排班跟着单量曲线和熬汤钟点走，午峰拆半小时看，平铺班改错峰班

你是面馆的排班分析师。请分析我们班次结构和单量曲线的
匹配度，输出一份逐人的改班草案。

我会提供的输入：
- 近四周 POS 半小时单量（营业时间内每个半小时槽）
- 现行班次表：每人 / 岗位 / 到店时间 / 离店时间 /
  技能档（会不会煮面、熬汤、收银）
- 煮面岗负载上限：一个煮面工半小时能稳定出多少碗
  （我给本店高峰实测值，或给口径让我先测）
- 兼职可来时段：现有兼职各自能排的时段
- 硬约束：熬汤开火时刻（这个班只能换人、不能取消或
  推到午峰前）、连勤上限、单人每周工时一次调班的
  可接受变动幅度

分析步骤：
1. 把每天切成五段：熬汤备料（开店前）/ 午峰
   11:00-13:30 / 午后谷 / 晚峰 17:00-20:00 / 收工，
   半小时为最小粒度
2. 每个半小时槽算两个数：在岗总人数、在岗煮面岗人数，
   再算「槽单量 ÷ 煮面岗数」的负载
3. 判三类问题（口径固定，不许增减）：
   一、峰上缺人：午峰或晚峰内连续 3 个以上半小时槽
   负载超上限
   二、谷里扎堆：午后谷在岗总人数超过午峰在岗人数的
   我给的比例——谷比峰的人还多，就是结构问题
   三、技能断层：某个峰的槽在岗总数够、但煮面岗为零
   或仅一人且负载超限——不缺人数缺手艺

输出格式：
- 负载总表：时段 / 代表性半小时槽 / 单量 / 在岗总数 /
  煮面岗数 / 负载 / 是否超限（取四周平均）
- 三类问题各一张明细：出现的槽 / 程度 / 涉及的班次
- 改班草案：逐人一行「现班次 → 建议班次」，兼职写清
  几点进几点出；熬汤早班单列一行写谁守；每条草案附
  验证方法——下周同一批槽的负载应落在什么区间，或
  高峰出餐等待应有什么变化
- 最后一列：每人周工时调了多少（不得超过我给的可
  接受幅度）

限制：
- 不预测改班后的营业额、单量、人效百分比——班次影响
  的是出餐能力，不是客流，揽不到自己头上
- 兼职建议只能落在我给的兼职可来时段内，不许发明
  「随时能来的兼职」
- 熬汤班只能换人，不能取消、不能推迟到午峰前才开——
  推迟开火不是排班建议，是换一种汤
- 不写「优化排班结构」「提升人效」这类话；草案之外
  不给笼统建议

为什么这样写

半小时粒度是面馆排班分析的最小可用刻度。面馆的午峰是「尖」不是「块」：11:00 到 13:30 里真正压死的是 11:30-13:00 那一段，按小时看会被平均摊平，按天看更什么都看不见。半小时正好是「一个煮面工出一锅面、翻一轮台」的节拍量级，产能和需求在这个刻度上才对得齐——粒度再粗，分析就变成在描述一个不存在的「平均的一天」。

把「人数」和「煮面岗数」分开算，是把面馆厨房的真实约束显式化。面馆后厨五六个人，会煮面的往往只有两三个：总数够、煮面岗不够的时段，加服务员、加收台都没有用，唯一解是错开煮面工的休息或再训一个。通用排班分析只看人头，会把这类时段误诊为「不缺人」或「都缺人」；分开算之后，「技能断层」才从「忙不过来」这句糊涂话里分离出来，成为可以单独解决的问题（培训、拜师、定岗）。

熬汤班写成不可取消的锚，是防着模型犯它最爱的错误：排班算法眼里「不产生单量的班」就是浪费，砍掉熬汤早班，班次表立刻漂亮——第二天汤不够、汤不对，这个代价在四周单量数据里根本看不见。汤几点开火同时框死了「晚班收工到次日早班」的休息间隔，面馆的合规暗角正在这里，所以它必须作为硬约束从第一行就存在，而不是排完再补救。

逐人调班且限制单次幅度，是因为改班草案最大的落地阻力从来不是数据，是「人的作息被大改」。一次调动幅度小、带验证方法、下周看数据再走第二步——班次结构调整是连续的小步，不是一次推倒重来。每条草案自带验证区间，也是给排班主管的护身：下周数字没落进区间，说明这条调整的假设错了，撤回就是，不必争论。

变量