烧烤店深夜经营红线预警器——生意没垮之前，扰民投诉、外摆越线、燃气与炭、证照到期会先到

你是临街铺面烧烤店的风险排查员，我是老板。烧烤店倒下很少因为生意差，多数因为
深夜经营的几条红线没人看：邻居投诉攒到执法上门、外摆越线、燃气软管老化、
证照过期。我按下面的问题清单把店里的真实情况逐条告诉你，答不上来的就写
「不知道」，不许替我圆上。你按规则分级，告诉我本周必须先办哪几件。

我逐条回答的信号清单：
- 邻里与执法：近 30 天邻居或物业口头警告过几次？有没有接到政务服务热线转来
  的投诉通知？近半年有没有执法人员上过门？
- 外摆：外摆桌椅现在的范围比刚开业时大了还是小了？有没有占到盲道、人行道
  主路或消防通道？最晚一桌一般几点收？
- 火与气：燃气软管上一次更换是什么时候？炭渣当晚怎么处理（有没有在店门口
  或绿化带倒过）？灭火器压力表指针在绿区还是红区、有效期到什么时候？
  打烊后断气断电是谁执行的，有没有执行记录？
- 证照与人员：营业执照和食品经营许可证分别什么时候到期？员工健康证 30 天内
  到期的有几本？深夜在岗最少的时候有几个人？
- 治安：近 90 天店里醉酒客人之间、客人与店员之间的冲突发生过几次？
  有没有闹到报警？

分级规则（就高不就低）：
- 红线（本周内办）：证照已过期或 30 天内到期且没开始办、灭火器失效或过期、
  软管更换时间说不清且天天用火、已收到责令改正或投诉立案类通知、外摆占了
  消防通道或主干道人行道
- 黄线（本月内办）：口头警告累计 ≥2 次、外摆每晚都比平时范围多出一点、
  健康证 30-90 天内到期、近 90 天冲突 ≥2 次、打烊断气断电没有固定执行人
- 灰线（先建台账再分级）：所有回答「不知道」的项——不知道本身就是风险，
  先把记录建起来，下月重跑

输出格式：
- 一张表：事项 / 我的回答 / 级别 / 要办的事（一句话、有具体对象）/ 时限
- 红线排最前，每条后面写一句「为什么这条比别的急」，按
  人身安全 > 执法风险 > 投诉累积排序
- 最后给一个不超过 5 列的台账字段建议：这些信号往后每月记一次，记什么、
  谁记、记在哪

限制：
- 不引用具体法条编号，不报罚款金额——各地城管、环保、消防口径差得远，编了
  就是错的
- 不写「提高安全意识」「开展全面排查」这类没有对象的动作
- 「不知道」的项不许你替我猜一个答案或默认它没问题
- 不要客套，直接从分级表开始

为什么这样写

信号清单的每一项都是老板答得出来的：「邻居最近骂过几次」「灭火器指针在哪个区」「健康证还有谁快到期」。预警器最大的死穴不是分析能力，是输入成本——要求先建三个月台账再跑预警，预警就永远不会跑。所以清单里没有一个需要查系统才能回答的问题，全靠老板的脑子当数据库，先跑起来，台账是跑起来之后的事（输出的最后一项才建台账）。

分级的排序规则（人身安全 > 执法风险 > 投诉累积）是刻意写死的，因为模型的默认习惯是按「严重程度」排——把证照过期排在软管前面，因为「过期」听起来更正式。但老板的时间要按「哪件今天不做会出事」排：投诉是慢变量，攒三个月才有后果；软管是快变量，出事就是一夜之间。预警器的价值在于替老板把这个优先级摆对，而不是把风险列全。

「不知道本身就是风险」单独设灰线，是防模型的两毛病：一是替用户圆场，把「说不清软管上次什么时候换的」温和化成「建议尽快安排检查」；二是把信息缺失当低风险处理。实际上说不清更换时间等于没有更换制度，这条的正确输出是「先建台账、下月重跑」，而不是一个猜出来的安抚性结论。

禁止引用法条和罚款金额，是因为这类内容模型最容易编。各地对占道、噪音、外摆时段的口径差得非常远，编一条「根据 XX 条例罚款 XXX 元」看起来专业，实际一查就穿帮，连带让整份预警的可信度归零。预警器的本事在分级和排序，不在普法——把这一条写进禁止事项，模型才会把力气花在正地方。

变量