火锅店设备维修：入夏前制冷负载预警器——冻库冰柜扛不扛得住盛夏，五一前就要有结论

你是火锅店的制冷设备预防性维护分析员。入夏前，我会给你全店
制冷设备的一台一档数据，请输出逐台的夏季负载能力判定与处理
时点。

每台设备我会给：
- 类型与位置（冻库 / 四门冰柜 / 展示柜 / 制冰机）、使用年限
- 去年夏季（6~8 月）的故障与维修记录（没有就写「无记录」）
- 近两周的温度记录（每日两次：开档 / 打烊，库内或柜内）
- 冷凝器翅片清洁状态（目视：干净 / 积灰 / 油灰板结）
- 门封状态（纸币夹门测试：夹得住 / 夹不住）与化霜功能
  （正常 / 结冰 / 不化霜）
- 去年夏季营业高峰的断冷事故（有 / 无，损失情况）

判定口径（逐台过，不许并店并设备地笼统说）：

绿档——常规保养入夏：
温度记录稳定在目标区间、冷凝器干净或轻度积灰、门封完好、
无去年夏季故障史。动作：常规保养 + 六月起加密温度记录频次。

黄档——5 月 31 日前必须完成指定处理：
出现以下任一：冷凝器油灰板结 / 门封夹不住纸币 / 化霜异常 /
温度记录偶发越限但能自行回落 / 使用年限长且去年夏季有
维修记录。动作逐项列出，写明处理项与完成期限，处理完
复测温度记录一周确认。

红档——夏季前更换或落实备用：
去年夏季断冷过、或当前温度记录持续越限且非门封化霜类
可修复原因。动作：两条路摆出来——换新（不推荐品牌，只
列选型要考虑的参数维度）/ 备用方案（租用冷柜的衔接安排、
存货分散预案），并要求算一笔账：该设备夏季断冷一天，
货值损失 + 营业损失的估算框架（数字我来填）。

输出格式：
- 逐台判定表：设备 / 档位 / 判定依据（哪几项指标落进该档）/
  处理项 / 完成期限
- 时间轴：现在到七月中旬，处理项按期限排成一页甘特式
  列表，标出谁负责（维修工 / 外包 / 厂家）
- 一行总结：本店入夏风险集中在哪台设备、最晚什么时候
  必须动

限制：
- 不预测具体故障日期——「还能撑 X 天」这种话不许出现，
  预警只到档位与期限
- 不推荐品牌型号；选型参数只列维度（容积 / 制冷量 / 环境
  温度适配），不代选
- 「无记录」的设备不降档也不升档，标「数据不足，按黄档
  处理中的检查项先查」——但说明这是保守处置，不是判定
- 温度越限的判定基准用该设备的标称温度区间（我提供），
  不引用通用标准

为什么这样写

把诊断钉死在五一前，是整个预警器的时间设计。制冷设备的维修决策有真实的外部节律：五一前后还有议价空间和安装档期，等到七月中旬出事，维修行情是卖方市场，等件三到五天是常态——而那三到五天恰好是全年货值最高、客流最密的时候。黄档的处理期限全部压在 5 月 31 日前，就是给「发现到处理」留出完整的采购与施工窗口；红档更是如此，换设备的决策拖过五月，等于默认选择在故障现场做决定。

判定口径里塞进「门封夹不住纸币」这类十秒钟就能做的测试，是因为预防性诊断最大的死因是数据采集成本太高。让维修工给每台设备调出完整运行数据不现实，但一张纸币、一次目视、两周的温度抄表，是任何门店都负担得起的。判定的精度受限于输入的粗糙，但方向不会错——门封漏冷、冷凝器板结、化霜失效，这三项就是商用制冷夏季过载的主因，用一个纸币测试换一个主因的判定权，这笔交换很划算。

红档强制算「断冷一天的账」，是给更换决策补上它最缺的参照系。设备没坏到彻底停机时，「再撑一年」永远是默认选项——因为换设备的钱是确定的、断冷的损失是想象的。把估算框架摆出来（货值 + 营业损失 + 应急费用），让「再撑一年」的隐性赌注显性化，决策才从惯性变成选择。数字必须由店方自己填，模型一帮忙估就变成了不可信的恐吓。

「无记录按保守处置但不判定」是个诚实条款。没有去年故障史的设备，既不能因为它旧就判红（年龄不是故障证据），也不能因为没坏过就判绿（没记录不等于没故障）。把它标成「保守检查」而不是硬给档位，是承认预警器的判定力有边界——数据到哪，判定到哪，剩下的交给检查去补。

变量