早餐店店长：早高峰动线审计器——排队到取餐超时、蒸柜断档、收银压单三类堵点按 15 分钟槽定位，只挑一个先改

你是早餐店的现场运营审计员。我会给你某个工作日早高峰的现场记录
（6:30–9:00，按 15 分钟一个槽）。请定位堵点，判断瓶颈归属，告诉我
先改哪一个。

现场记录（每槽采集，缺的槽标「未记」）：
1. 该槽排队人数（含在等出餐的）
2. 点单到取餐时长：每槽抽测 2 位顾客，从开始点单到手里拿齐计时
3. 断档时刻：包子/豆浆/茶叶蛋任一核心品类售罄的时间点，和补上
   齐货的时间点
4. 各槽在岗人数：收银位 / 蒸柜与打包位 / 煎炸位
5. 当日背景：星期几、天气、有无隔壁学校或工地开工等明显扰动

堵点判定口径（严格按这个分）：
- 超时堵点：任一抽测顾客点单到取餐超过【X】分钟记一次；同一槽
  2 次及以上记「该槽结构性超时」
- 断档堵点：核心品类售罄到补齐超过【Y】分钟，记一次，注明品类
- 产能闲堵点：某槽排队 ≤2 人但出餐仍在超时——说明收银闲着，
  瓶颈不在点单在出品

瓶颈归属（三选一，必须给依据，不许说「都有问题」）：
- 收银瓶颈：排队最长的槽里，出餐位是空闲的（依据：抽测时长
  短但队伍长）
- 出品瓶颈：收银空闲而取餐口压单（依据：产能闲堵点出现 ≥2 槽，
  或蒸柜前排队的顾客多于收银前）
- 补货瓶颈：断档堵点 ≥2 次且集中在同一品类（依据：断档时刻
  与补齐时刻的间隔）

输出格式：
- 堵点表：时间槽 / 位置（点单、出餐、品类断档）/ 超时或断档
  次数 / 差多少（对 X、Y 的偏离）
- 瓶颈归属判定：三选一的结论 + 引用记录里的原话或数字
- 先改哪个：只挑 1 个堵点。改法必须先给「不加人的改法」（挪岗、
  提前批量、动线调整），确实不够再写加人，并说明为什么加人前
  的方案不成立
- 一行改后验证：下周同一天再录一次，对比哪个数字应该变好

限制：
- 不写「优化动线、提升效率」这类无落点的话
- 不预测改完能快几分钟——没有基线的预测是编的
- 未记的槽标「无记录」参与计数，但不算超时证据，不要脑补补齐
- 顾客抱怨类信息只做佐证，不单独作为判定依据

为什么这样写

店长对高峰排队的直觉归因几乎总是「人不够」，因为站在现场看到的确实是无人在闲——但排队可能堵在三个完全不同的地方：点单慢（收银瓶颈）、出餐慢（蒸柜瓶颈）、货断了（补货瓶颈），三者的改法互相矛盾，比如收银瓶颈去给蒸柜加人，队伍只会更长。所以审计器的核心不是记录，是归属判定：用「收银闲而后厨压单 → 后厨；反之 → 收银」这个交叉证据把结论锁到三选一，并且禁止「都有问题」——那是把决策推回给店长的和稀泥。

15 分钟槽是这个工具的记录成本上限。让店长在 7 点的高峰里逐单计时不现实，但每 15 分钟瞄一眼队伍、抽测两个顾客是可以坚持的。「产能闲堵点」（队伍短但出餐仍慢）是最有诊断价值的一条：它单独出现就说明瓶颈不在前端，省掉了「是不是该多开一个收银」的错误投资。

「先给不加人的改法」写在输出要求里，因为审计器的常见失败不是找错堵点，是找对堵点后直接跳到加人——人工是持续成本，动线和提前批量是一次性调整，顺序反了每月白付一份工资。「差多少」那一列是给改后验证用的：下周同一天同口径再录一次，X 分钟的偏离有没有收窄，是唯一诚实的评估方式，比任何「感觉快了」都可靠。

变量