天气预警数据怎么做成运营产品：从区域告警到停工与改约

运营团队通常不缺天气 App，缺的是“这条预警影响哪些门店、仓库、线路和班次，谁来决定停工，客户怎样改约，事件更新或撤销后如何恢复”。把所有 severe weather 通知转发到群里，会很快变成没人读的噪声。

r/logistics 的一则危险天气跟踪讨论里，发帖者需要人工筛选可能影响运营的较大预警并邮件通知。帖子没有提供可验证的业务规模或效果，只能作为问题线索：原始天气告警如何转换成针对地点、资产和职责的运营待办？

预警、预报和观测不能混为一个风险分数

预警是授权机构针对特定事件、区域和时段发布的信息；预报表达未来天气条件；观测描述已经测到的现象。产品可以把它们放在同一地点页，但必须保留不同来源与语义。用温度阈值自己生成的运营提醒，不应伪装成官方 warning。

NWS API 文档提供 forecasts、alerts、observations 等公共数据，并说明 /alerts/active 可以按区域过滤。该服务面向美国 NWS 覆盖，不是全球天气来源。跨国产品需要逐地区核对官方机构、许可、字段和可用性，不能用一个美国接口承诺全球告警。

每条来源记录建议保存 authority、identifier、sent、status、message type、event、urgency、severity、certainty、effective/onset/expires、区域几何、instruction、references 和抓取时间。标准化标签服务于路由，官方标题、说明与指令用于最终展示。

CAP 是事件协议，不是通知文案模板

OASIS Common Alerting Protocol 1.2定义了 identifier、sender、sent、status、msgType、scope，以及 info 中的 urgency、severity、certainty、area 等字段。status 还可区分 Actual、Exercise、Test 等类型。产品若忽略这些字段，测试消息可能误触真实停工流程。

CAP 还通过 references 关联此前消息，message type 可以表达 Alert、Update、Cancel 等关系。去重不能只看标题和区域；同一事件的更新可能改变生效时间、范围或指令，撤销也不能被当成普通新告警。事件存储应保留版本链，并让业务动作知道自己基于哪个版本。

严重度、紧迫性和确定性是不同维度。一个极端但未来才可能发生的事件，与已经观察到、需要立即行动的事件，路由方式不应相同。产品可以把三者映射到业务策略，但不能自行改写官方含义。

地理命中要经过地点模型

企业地点不是一个城市名。门店、仓库、工地、员工班次、配送线路和供应商可能跨越多个县区或预警多边形。第一版至少保存经确认的坐标、行政区域、时区、地点类型、营业时段和责任人。

区域匹配要区分官方 zone/county 标识与 polygon。只有行政区命中时，系统可标记覆盖较粗；有多边形时再做点或线路相交。地点落在边界附近、坐标不准确或移动资产位置过旧，都要降低自动化级别。

一个 shipment 穿过预警区域，也不等于一定延误；一个仓库不在 polygon 内，也可能因道路、停电或上游承运商受影响。天气命中只是运营风险输入，不能直接生成确定损失结论。可与站内的物流异常处置方法结合，但承运商实际事件仍是另一份证据。

业务规则要落到具体动作

预警产品的规则不是“severity = severe 就发短信”，而是“某类地点在营业时段收到某类实际告警后，创建哪个级别的任务，并通知谁确认”。仓库可能检查装卸和电力，现场服务团队可能暂停派工，零售门店可能决定提前闭店，客服则准备改约口径。

每条规则都需要 owner、适用地点、告警条件、提前量、建议动作、确认人和升级时限。涉及人员安全的停工与复工不应由通用模型自动决定；系统负责汇总官方信息、预案和影响范围，授权负责人负责作出决定。

通知也要分层：

• 值班人员收到可处理任务、来源指令和受影响地点。
• 地点负责人确认营业、停工、撤离、远程办公或继续观察。
• 员工和客户只收到与自己相关、已经批准的行动信息。
• 管理层看到未确认地点、通知送达和升级状态，而不是所有原始告警。

没有更新不等于没有风险

NWS Alerts Web Service 说明建议调用频率不高于每 30 秒，并说明超出限制可能被临时限制访问。产品必须遵守来源要求，利用缓存和条件请求；对几十个地点分别高频查询，不代表更实时。

监控层应记录最后成功请求、最后有效告警时间、响应延迟、解析失败和来源公告。若 API 不可用，界面显示“告警覆盖中断”，不能显示绿色的“当前无预警”。对关键场景还要预先定义独立的官方接收渠道与人工核对步骤，而不是事故发生后临时找第二个天气网站。

消息投递同样需要回执和备用路线。短信已发送不等于员工已理解或安全；高优先级任务应有确认、升级和现场负责人。恢复后，系统补齐中断窗口内的更新与撤销，并核对是否产生重复或相互冲突的业务动作。

复盘的是决定质量，不是通知数量

一次天气事件结束后，应记录哪些地点命中、何时首次发现、负责人何时确认、采取了什么动作、实际运营影响和复工依据。误报需要区分：官方告警覆盖较宽、地点数据错误、规则过敏，还是业务负责人选择了保守策略。

有了多次事件，团队才能调整规则。例如某类门店需要更早改约，某条线路只在承运商也出现异常时升级，某个地点坐标长期不准。不要从一次“没有损失”反推此前停工决定错误，也不要把天气产品宣传成能消除自然灾害风险。

MVP 可以从一种告警来源、十个固定地点和三类业务动作开始。验收一条 Update 和一条 Cancel 的版本链，演练一条 Test 消息不会触发真实通知，再模拟来源中断。只有在地点映射、授权、送达和恢复都稳定后，才扩展到预报阈值、移动资产和跨国来源。

本文讨论的是天气数据进入运营工作流的方法，不是气象、安全或劳动法律意见，也不代表 EveryInfra 已发布天气预警产品。原始告警的价值，在于它被可靠地翻译成一个有地点、有负责人、有证据、也有停止条件的运营决定。