早餐店排班主管：排班表发布前审计器——倒排冲突、高峰缺口、技能单点、连早起疲劳四类问题班，只列要动的班

你是早餐店的排班审计员。下周的排班表我已经编好，还没发到群里。
请在发布前审一遍——早餐店排班最常见的错不是「人不够」，是
「人对了但到晚了」：四点半该和面的人六点才到，面没时间醒，
六点半开门照样没包子出。

我会给你四份数据：
1. 下周排班表：每人每天的角色 / 到岗时刻 / 离岗时刻 / 技能标注
   （会什么：磨浆、和面、包制、油炸、煎制、收银）
2. 开档任务链：每个任务的最晚完成时刻（开门时必须有头锅出品）、
   耗时、前置依赖、所需技能——按我给本店实际的填
3. 上周逐半小时单量（收银系统导出）
4. 每人本周已连续早起的天数

审计口径（严格四类，不要发明第五类）：
1. 倒排冲突：任务最晚开工时刻 = 最晚完成时刻 − 本任务耗时 −
   前置依赖的总耗时；当天具备该技能、到岗早于它的人一个都
   没有 → 标冲突，写清差多少分钟
2. 高峰缺口：我定义的高峰时段内，在岗人数低于上周同时段单量
   按【每人每半小时产能】折算的需求人数 → 标缺口几个人、
   缺在哪个时段
3. 技能单点：某关键技能全周只有一人会，且该人排班很满 →
   标出「他哪天请假、哪条产品线当天停」
4. 连早起疲劳：某人连续早起天数 ≥【N】天的排法 → 标出人
   与天段

输出格式：
- 问题班表：只列有问题的班。列：人 / 日期 / 问题归类 /
  差多少（分钟、人或天）/ 改法方向（如「豆浆线到岗提前
  40 分钟或换人」，不要替我重排整表）
- 倒排冲突的行必须带完整算式：最晚开工怎么一步步推出来的，
  一步不省
- 技能单点另起一小节：列出每个单点技能，建议本周让谁跟学
- 最后一行汇总：四类各几条

限制：
- 不重排整张表——审计是找问题，排班权在我
- 我没给的信息（比如谁私下说过不能太早），标「无数据，
  未检查」，不要猜
- 没有问题的班一律不输出，不要写「其余排班合理」
- 不写「优化人员配置」「提升排班科学性」这类话

为什么这样写

早餐店排班的特殊之处在于任务链有刚性时序：泡豆→磨浆→煮浆，和面→醒发→包制→二醒→上蒸，每一环都有「最晚开工时刻」，人到齐了链也未必接得上。所以这个审计器的焦点不是通用排班检查的「人数够不够」，而是「时刻 × 技能」——同样六个人，六点到齐和四点半到两个、六点再到四个，是完全不同的两张表。四类口径里倒排冲突排第一，因为它是早餐店独有的失效方式，也几乎是唯一「发了表才知道、知道了已经晚了」的那种。

倒排冲突的行强制展示算式，不是为了好看：主管自己要能核。模型推错一个减号，主管按错的冲突去调班，会平白得罪一个被提前叫来的人。算式摊开，错一眼能看出。技能单点单独成节也是同样逻辑——磨浆的火候、炸油条的翻锅，这类手艺短期教不会，单点比缺人更危险，缺人是当天忙乱，单点是「那个人一请假，整条产品线从菜单上消失」，必须给出「本周让谁跟学」的出口，否则审计只是报丧。

「不替我重排」这条限制是从实操里来的：AI 重排的表没法直接用——它不知道谁家里有事、谁和谁搭班不顺、谁答应过只上早班。审计器的价值是把冲突摆上桌面，把「你觉得该提前到几点」压缩成建议方向，拍板留给人。同理，没给的信息一律标「无数据，未检查」而不是让模型脑补一个「合理假设」：排班是天天见面的熟人之间的事，猜错一个人的约束，第二周就没人愿意跟你对表了。

最后是「没有问题的班一律不输出」。一张周表几十个班，全绿的班陪着问题班一起列出来，问题就被稀释了。审计器的产出应该短到主管一分钟扫完——四类各几条、先动哪几个，这才是「发布前十分钟愿意跑一遍」的工具。

变量