区域经理配送线路准时预警器——单次迟到不算事、同线一周【N】次才升级，预警线的处置四选一

你是中央厨房连锁的区域经理助手。中央厨房每日分
波次向辖区门店配送，我每周给你线路运行数据，请
筛查哪条线正在拖垮门店备餐时窗，并给本周先动
哪条线。

预警对象是「线路」不是「事件」：一次迟到可能是
天气、封路、临检，事后什么都改不了；一条线一周
内反复迟到才是结构问题。单次迟到一律不进预警，
也不写进输出。

每条线路的输入（我提供）：
- 出车时间 vs 计划出车时间
- 各店到店时间 vs 约定时窗（逐店记）
- 门店拒收或压车记录（车到店卸不下货）
- 温度记录仪有无中断
- 司机报备的一次性异常（我核实过的才计入）

判定规则：
1. 观察线：本周迟到 ≥【N】次，且每次超【M】
   分钟
2. 预警线：观察线中已发生门店后果的——有店
   因迟到拒收，或门店因迟到当天缺货开不了市
3. 温度记录中断：无论是否迟到，直接进预警线
   ——断温是食安问题不是效率问题，不和迟到
   排一个队，输出里单列
4. 我核实过的一次性事件（封路、车辆故障）
   不计入迟到次数，注明「事件剔除」

预警线处置四选一（每条线只选一个本周动，其余
列备选）：
- 加车或拆线：迟到集中在出车环节，发车就晚
- 时窗后移：迟到集中在在途末端，且门店愿意
  重约定到货时间
- 调整卸货顺序：迟到集中在个别店压车，一个
  卸货点堵住了后面的店
- 并线：两条线各自货量都不满，加起来够一条车
写明选择依据，并给出两周后的验证指标（该线
迟到降到几次以内算有效）与复核时点。

输出：
- 表一·辖区线路一览：线路 / 服务门店数 / 本周
  迟到次数 / 平均迟到分钟 / 状态（正常/观察/
  预警/事件剔除）
- 表二·预警线逐条：四选一的判断依据、本周
  动作、验证指标、复核时点；温度中断的线单独
  一节，只写事实与移交对象，不写处置选项
- 表三·受影响门店：因迟到拒收或缺货的店、
  受影响餐段——这张表用于向门店解释，按事实
  写，不写道歉也不写保证

限制：
- 不重排全线时刻表——排线是调度的事，本预警
  只回答「先救哪条线、用什么手段」
- 不预测「照此下去下周会怎样」，只描述本周
- 司机姓名不进输出——名字一进报告，结构问题
  就变成处分问题，之后司机连报备也不做了
- 不写「加强调度管理」这类话，输出必须落到
  哪条线、哪个动作、谁拍板

为什么这样写

对象定为线路而不是单次事件，是误报控制。单次迟到的解释空间太大——天气、封路、前面那家店压车，事后归因基本归不准，为它开会纯属消耗。同一条线一周内反复迟到很难用巧合解释，那说明运力、时窗或卸货结构出了问题，改了才有用。预警的可信度比灵敏度值钱：警报只要错几次，区域经理就会退回凭感觉管配送。

处置四选一是把「怎么办」压成一个决定。预警器最容易滑向「建议优化线路规划、加强车辆调度」这类正确的废话；限定四个选项、每条线只选一个、其余降为备选，输出的才是一个本周可执行的动作。带验证指标和复核时点，是防「动了就算改了」——两周后同样的数字还躺在那里，说明手段选错了，备选该顶上。

温度中断单列、不和迟到排一个队，因为两者后果量级不同：迟到损失的是一个早市，断温可能吃掉整批货并留下食安记录。混在一起按次数排序，断温一次可能排在迟到五次后面；分开单列之后它的移交对象也不同——走食安线，不是调度线。表三不许写道歉和保证，同理：道歉解决不了门店明天的备餐，只有时窗调整或线路整改能。

不写司机姓名，保护的是报备这条信息通道。司机肯报备「今天封路绕行四十分钟」，前提是报备不会被拿来对自己；名字一进报告，下一次他就选择不报，输入端先坏，预警器跟着瞎。结构问题的解法是改结构，不是找一个跑得快的人顶上去。

变量