看到“因天气恶劣蚊虫滋生各位猎人们出门记得防蚊”这句话时我所在的玩家社群里正被连续几天的暴雨和高温轮流折腾。大家前一秒还在讨论配装和任务路线下一秒就开始抱怨小区楼下的蚊子多得有点夸张。两件事在夏天奇异地同步了游戏里的猎人在打各种虚构怪物现实中的猎人在防蚊子。但我更愿意把这句话当成一个工程问题来看。为什么天气预报显示 28℃、湿度 78%我就应该意识到蚊子今天会很凶为什么每次雨后两三天小区和公园里的蚊虫密度就明显上了一个台阶这些看似零散的生活经验背后其实是一套可以量化的环境指标。与其每次都被咬几个包才后悔不如把“出门防蚊”从感觉驱动改成数据驱动。这篇文章不打算写驱蚊液测评也不打算讨论偏方。我想聊的是如何用天气数据和一小段代码做一个出门防蚊提醒工具怎么把温度、湿度、降雨这些天气变量映射成防蚊风险等级以及这个看起来很小的需求真正落地时涉及的定时任务、日志、异常处理和外部依赖管理为什么比大多数人想象的要复杂一点。1. 蚊子变多不是错觉但也不要只靠体感判断1.1 一场暴雨加上高温为什么蚊子就多了蚊子的生命周期里水是绕不开的一环。从卵到幼虫再到蛹前面几个阶段基本离不开静止水体。这也是为什么降水之后蚊子数量会明显上升雨水形成了大量临时积水比如花盆托盘、废旧轮胎、地下室、排水沟、楼顶凹坑这些地方都可以成为繁殖场所。温度的作用同样关键。蚊虫的发育和活动受温度影响很大低温时活动明显下降温度合适时繁殖周期会缩短。再加上高温带来的高湿环境蚊子的存活率也会跟着变化。所以“天气恶劣”这四个字其实对应的是两个很具体的条件降水增加带来了更多的繁殖场所高温高湿提供了更合适的发育窗口。两个条件叠在一起蚊虫滋生就不是错觉而是一个可解释的过程。这里要说明一点我讲的是生物学上的常识逻辑不是某个研究机构的精确结论。不同地区的优势蚊种、具体温度和积水量不同实际密度会有差异。但作为判断方向这套逻辑是够用的。1.2 体感判断最坑的三个地方我在社群里观察到一个现象很多人判断“今天要不要防蚊”靠的是“现在有没有被咬”。这个标准其实有很大延迟。第一个误区是“下雨天没有蚊子”。恰恰相反下雨之后的一段时间才是蚊虫密度上升的窗口。雨停之后积水还在温度和湿度又合适蚊子只会更多而不是更少。第二个误区是“太阳大、温度高蚊子应该少”。三十多度的正午确实不容易看到蚊子但那是活动减少不是没有蚊子。真正影响密度的是最近几天的积温和积水条件而不是当前这一小时的体感。第三个误区是“我家住高层不用管”。蚊子确实飞行能力有限但它可以借助楼道、电梯、管道和绿植一路往上高层依然会有蚊虫问题只是概率和密度有差异。这三个误区说明一件事体感是即时的、局部的而蚊虫密度是累积的、环境的。想要做好防蚊第一步就是把判断依据从“主观感受”换成“客观变量”。2. 与其说“防蚊”不如先把风险等级算出来2.1 影响蚊虫密度的几个环境变量如果要做一套防蚊预警规则至少要考虑四个变量温度决定蚊虫发育速度和活动活跃度。湿度影响蚊子存活率和觅食积极性。降雨提供繁殖所需的积水条件而且有一定滞后性。时段蚊子活动有明显的昼夜节律黄昏和黎明通常是高峰。除了这四个更精细的方案还可以加入风力、气压、附近水体距离、历史气象数据等。但对于一个出门提醒工具来说前面四个变量已经能覆盖大部分判断需求。这里有一个关键点预警不是预报具体的蚊子数量而是预报“概率趋势”。我们无法准确数出楼下有多少只蚊子但可以根据环境变量判断“今天蚊虫风险偏高还是偏低”。趋势判断恰好是规则系统擅长的事。2.2 一套可以直接用的评分规则我建议把风险等级设计成 0 到 10 分变量区间评分温度低于 15℃0温度15℃ - 20℃1温度20℃ - 30℃2温度30℃ - 35℃1温度高于 35℃0相对湿度低于 40%0相对湿度40% - 60%1相对湿度60% - 80%2相对湿度高于 80%3近 24 小时降雨无降雨0近 24 小时降雨小雨1近 24 小时降雨中雨2近 24 小时降雨大雨/暴雨3当前时段白天非高峰0当前时段清晨或黄昏2总分 0-3 是低风险4-6 是中风险7-10 是高风险。需要说明的是这套评分是按常见逻辑搭的示例规则不追求生物学上的精确。不同地区可以调整权重比如北方干燥地区湿度权重可以低一点南方湿热地区湿度权重可以高一点。关键是先把规则骨架立起来后续用真实观测数据去校准。2.3 风险等级怎么映射到出门建议评分本身没有意义映射成行动才有意义。低风险时可以正常出门但敏感人群还是建议随身带驱蚊液。中风险时建议穿浅色长袖长裤避开草丛和水边黄昏时段缩短户外停留时间。高风险时建议调整出行时间避开清晨和黄昏两个高峰必要时使用含有效成分的驱蚊剂并检查家里有没有未清理的积水。把等级映射成行动这个提醒工具才算真正闭环。3. 用天气 API 做一个“出门防蚊提醒”小工具3.1 环境准备与关键约定要用天气 API第一件事是确定数据源。国内常见做法是申请天气服务商的 API Key然后把城市 ID 或经纬度传过去拿到实时天气数据。具体选哪家我建议根据使用频率和免费额度决定而不是一味追求数据最全。这里有一个重要提醒各家天气 API 的字段名、返回结构和调用限制都不一样。下面的代码是参考结构目的是把思路讲清楚落地前一定要以官方文档为准先用一条真实请求验证返回内容。环境方面只需要 Python 3 和 requests 库。Windows、macOS、Linux 都支持没有特殊依赖。3.2 拉取天气数据的代码结构import requests # 示例结构实际 URL、参数、字段以所选天气服务的官方文档为准 API_KEY your_api_key LOCATION 101010100 # 城市 ID 或经纬度 def fetch_weather(): url https://api.example.com/v3/weather/now params { key: API_KEY, location: LOCATION, unit: metric } resp requests.get(url, paramsparams, timeout10) resp.raise_for_status() data resp.json() # 多数天气服务会在 now 或 data 字段里返回实时天气 return data.get(now) or data.get(data, {}).get(now)这段代码逻辑很简单构造请求、带参数、发请求、转 JSON、取出实时天气。但现实里最容易出问题的恰恰是这些步骤之间的细节API Key 是否有效是否欠费或超额度。城市 ID 是否对应当前城市。返回结构里温度是字符串还是数字是否需要转换。温度单位是摄氏度还是华氏度。请求超时时间设多长API 不可用时怎么办。这些都会在后面排查章节继续展开。3.3 把评分逻辑接进去拿到温度、湿度和降雨情况后就可以套用前面的评分表。我建议把评分逻辑单独写成函数这样后续调整权重和阈值时不用动主流程。def calculate_risk(temp, humidity, rain_level, is_peak_hour): score 0 # 温度评分 if temp 15 or temp 35: score 0 elif temp 20 or temp 30: score 1 else: score 2 # 湿度评分 if humidity 40: score 0 elif humidity 60: score 1 elif humidity 80: score 2 else: score 3 # 降雨评分0 无雨1 小雨2 中雨3 大雨及以上 score rain_level # 时段评分 if is_peak_hour: score 2 return score def risk_level(score): if score 3: return 低风险 elif score 6: return 中风险 else: return 高风险这块代码本身几乎没有难度关键是评分规则要可配置。我的建议是不要硬编码在判断条件里而是把阈值和权重放在一个字典或配置文件里。数据变化了改配置就行不用改逻辑。3.4 提醒怎么发出去算出了风险等级还要让用户在出门前看到。最简单做法是直接打印到控制台适合本地手动运行。进阶一点把提醒推到手机或群里。常见做法是走群机器人 Webhook比如企业微信和钉钉都支持。只要往一个 Webhook 地址 POST 一段 JSON就能把消息发到群里。也可以接一个独立的通知服务或者直接发邮件。我建议优先选团队已经在用的协作工具省去额外配置。Webhook 的调用方式通常就是向一个 URL POST 一段 JSONimport requests def send_webhook(url, content): payload { msgtype: text, text: {content: content} } resp requests.post(url, jsonpayload, timeout5) resp.raise_for_status()注意不同平台的消息格式不一样同样的 JSON 换个平台可能就推送失败。这只是示例结构不是通用标准。4. 从手动跑脚本到每天自动提醒手动跑一次脚本只能说明代码能运行。真正要让工具产生价值必须自动化。这一步才是初学者最容易翻车的地方。4.1 定时任务怎么配Linux 上最常见的做法是 cron。比如每天早上 06:30 跑一次30 6 * * * cd /path/to/project python3 mosquito_alert.py logs/alert.log 21macOS 也可以用 cron或者用 launchd。Windows 则建议使用任务计划程序。这些方案在各自系统里都是原生能力没有额外成本。配置定时任务时有几个具体问题要提前验证Python 解释器路径是绝对路径还是相对路径。cron 环境里的 PATH 通常和你终端里不一样。脚本依赖的模块是否安装到了 cron 同一个 Python 环境里。日志目录是否存在脚本里是否写死了相对路径。环境变量比如 API Key在 cron 环境下是否还能读取到。这些看起来都是小问题但你会发现在自动化任务里环境差异才是最大的敌人。4.2 日志、异常和重试不能省脚本一旦进入无人值守状态就不能再靠人盯着控制台。至少要做到三件事。第一记录日志。每次运行要能看出来天气数据拿到了没有评分算出来是多少推送成没成功。建议在关键节点都打一行日志。第二异常处理。API 请求网络超时、返回异常状态码、推送通道临时不可用这些都是常态。要捕获异常并且至少记录下错误信息。更稳妥的做法是区分“可以重试的错误”和“不能重试的错误”网络超时可以隔几分钟重试一次参数错误重试多少次都没意义。第三失败可见。定时任务失败时不一定会有人发现。常见做法是失败时推一条告警到同一个群或者把错误写进单独的错误日志文件。宁愿多一个提醒也不要让脚本默默失败一个月。4.3 依赖外部服务时要留退路天气 API 是外部依赖外部依赖就一定会变化。可能今天接口还正常明天字段就调整了可能免费额度耗尽请求开始报错可能对方服务升级返回结构变了。所以我的建议是不要把外部返回直接当可信输入。解析时要做类型转换和安全取值关键字段缺失时要有默认值。同时在代码里保留一个 mock 数据入口接口不可用时可以先用固定数据测试评分和推送链路。这里暴露了一个更普遍的问题小工具看似简单但一旦依赖第三方服务、定时任务和消息通道它就具备了分布式系统的最小特征。你需要开始考虑可用性、依赖、失败模式和可观测性。5. 预警只是第一步行动闭环才是重点5.1 不同风险等级对应的行动清单预警系统的价值不在于“告诉你今天蚊子多”而在于“告诉你今天应该怎么做”。我建议把行动清单提前准备好。低风险时可以正常活动但敏感人群随身带驱蚊液家里保持纱窗完好。中风险时户外活动穿浅色长袖长裤避免在草丛、水边、灌木附近长时间停留。家里检查花盆托盘、水桶、地漏等地方有没有积水。高风险时调整户外活动时间避开清晨和黄昏两个高峰时段去草地、树林或水源地时使用驱蚊剂并及时补涂小区里如果积水严重可以联系物业处理公共区域的积水点。行动清单要具体到“做什么”而不是只说“注意防蚊”。5.2 智能硬件能帮上什么忙除了预警工具市面上还有一些智能硬件可以配合智能灭蚊灯可以定时开关通过诱蚊灯管配合风扇风干智能驱蚊器可以按计划释放驱蚊液小型的温湿度传感器可以补充本地微气候数据让评分规则不再依赖单一来源。如果你的条件允许可以在院子或阳台放一个温湿度传感器把本地数据接入评分系统效果会比单纯依赖天气 API 更贴近真实环境。但这属于进阶玩法需要额外的硬件和网络配置不一定适合所有人。5.3 什么时候这套方案不适合这套基于天气 API 的预警方案更适合城市或近郊场景因为它假设你的活动范围和气象站测得的天气情况差别不大。如果你在山区、森林、水库周边活动微气候差异会非常大。气象站显示湿度 60%实际谷底可能已经接近 90%。这种情况需要优先依赖本地监测数据而不是远程 API。另外蚊虫密度还受周边环境治理影响。有的小区物业定期清理积水、做消杀蚊虫密度会明显偏低有的小区绿植密集、雨水收集不到位蚊虫密度会持续偏高。同样是中风险天气实际体验可能完全不同。数据工具只能提供趋势不能替代实地观察。6. 提醒没生效按这个顺序排查自动化的工具一定会出问题。早点接受这个设定会省很多事。关键是排查的时候不要东一榔头西一棒子按链路一层层看。6.1 先把现象说清楚排查前先记录现象是完全没提醒还是提醒发出来了但内容不对是偶尔不推送还是连续几天都没有是只有某个城市的数据不对还是所有城市都不对现象描述得越具体排查范围就越小。“北京昨天有提醒今天没有”和“这个工具从来没推送成功过”完全不是同一个问题。6.2 按这个顺序排查我建议的顺序是输入 → 环境 → 参数 → 服务边界。第一步查输入。先用一条手动请求看天气 API 返回了什么。如果返回里温度是空的或者城市 ID 报错后面所有逻辑都不用看问题在数据源。第二步查环境。手动在终端跑一遍脚本确认正常。然后手动执行一次定时任务命令看能不能跑通。如果手动可以但定时任务不行大概率是 PATH、Python 环境、工作目录或环境变量的问题。第三步查参数。检查评分函数收到的温度、湿度、降雨值是否符合预期。有时问题不是 API 没返回而是字段名变了代码里取不到值直接抛异常或拿到 None。第四步查服务边界。确认 API 额度是否用完Webhook 地址是否失效定时任务是否因为系统休眠没有执行。这类问题通常要在日志里才能看到。6.3 一次排查的完整示例假设现象是“连续三天没有收到推送”。按顺序排查先手动请求 API发现返回正常再手动跑脚本发现脚本报错输出在日志里原因是 Webhook 返回了 401查 Webhook 配置发现机器人地址变更过期更新地址后手动推送成功最后看定时任务记录确认第二天早上已经正常执行。整个排查过程不到十分钟但不按顺序可能半天都不知道问题出在推送服务上。7. 这类“小提醒”的真正价值是把经验变成流程7.1 从防蚊到更通用的场景做完这个防蚊提醒工具之后你会发现它的骨架可以用在很多地方户外作业的高温预警、物流运输的暴雨提示、大棚种植的湿度监测、活动策划的天气风险预案。它们共享同一条链路采集数据 → 建立规则 → 计算风险 → 推送提醒 → 执行行动。区别只是数据源、规则和行动清单不同。所以这个防蚊工具真正的收获不是“我省了买驱蚊液的钱”而是掌握了一条把经验转成规则、把规则转成代码、把代码转成自动化流程的路径。7.2 先跑通再迭代最后工程化最后一段话给想动手做的人。不要一开始就追求天气数据精准、评分规则科学、推送通道丰富。先用免费 API 和最简单的控制台输出跑通一条最小链路能拿到天气能算出等级能打出提醒。然后再加定时任务再加日志和异常处理最后再考虑接 Webhook、接传感器、接多城市。这个顺序能让你在每个阶段都保持“能看到结果”的状态不会因为一次引入太多不确定性而卡住。回到开头那句话因天气恶劣蚊虫滋生各位猎人们出门记得防蚊。游戏里的猎人需要提前备好消耗品现实中的猎人同样需要提前判断风险。数据不会替你做决定但它能让你在出门之前就做出更好的决定。