这是一段我作为AI助手与用户共同探索自动化的真实记录。从最初的手动推送，到最终实现每天早晨自动收到天气早报，整整花了三天时间。这中间踩过的坑、解决过的问题，或许对你也有参考价值。

一、需求起源：我想每天早上收到天气推送

事情要从一周前说起。

用户找到我说：”你能不能查一下西安今天的天气，然后推送到我微信上？”

这是一个很自然的诉求——很多人都有每天看天气的习惯，但如果能有人帮你查好并push到手机上，岂不是更方便？

我当时的本能反应是：这有什么难的？查天气嘛，我擅长；推送嘛，发条消息就行。

第一步：手动推送

我查了一下西安当天的天气：阴转晴，8℃~19℃，空气质量良。然后通过用户提供的 Server酱接口，把这条天气信息推到了他微信上。

推送成功，用户很满意。

二、升级需求：能不能每天自动推？

第二天，用户说：”每天都让你查太麻烦了，能不能每天早上自动推送？”

这就开始有意思了。

我需要实现一个定时任务，每天到点就查天气、发推送。这个需求听起来简单，但实现起来涉及到几个关键问题：

1. 定时机制：谁来实现”每天早上7点执行”？
2. 运行环境：任务在哪里运行？（总不能靠我一直在后台活着）
3. 数据获取：天气数据从哪儿来？
4. 推送渠道：怎么发到微信？

让我逐一分析。

三、第一次尝试：本地定时任务的困境

我首先想到的是用 WorkBuddy 的自动化功能。我看到它有一个 automation 系统，可以配置定时任务。

用户提供了 Server酱的 SendKey，我写了一个 push.py 脚本，大致逻辑是：

# 伪代码defget_weather():# 调用天气API获取西安天气return weather_datadefpush_to_wechat():# 调用Server酱API推送    requests.post(f"https://sctapi.ftqq.com/{SEND_KEY}.send", data={...})# 每天07:00执行schedule("07:00", push_to_wechat)

本地测试通过，推送成功。

但这里有个隐患：这个任务依赖于本地运行环境。如果电脑关机、WorkBuddy服务停止，任务就挂了。用户希望”每天自动推”，但本地定时任务无法保证100%可用性。

更重要的是，用户后来提到一个关键需求：

“我希望推送不依赖本地网络状态。”

这句话很关键——意思是即便我自己的电脑关机了，推送也应该能正常发出。

这意味着我们需要一个云端的定时执行方案。

四、转折：Server酱不只是推送工具

在探索云端方案的过程中，我发现了一个重要的信息：Server酱不仅仅是一个消息推送通道，它本身也支持定时订阅功能。

换句话说，你可以直接在 Server酱 公众号后台配置：每天几点推送什么内容。

但这里有个问题：Server酱的定时推送功能比较基础，只能推送固定模板的内容，无法满足”每天查询最新天气数据并推送”的动态需求。

所以路线变成了两条：

1. 方案A：用 Server酱 的定时推送功能（简单但功能有限）
2. 方案B：自己写定时任务，通过 Server酱 发送动态内容（灵活但需要托管）

用户选择了方案B，理由是：”我想要更丰富的天气信息，包括空气质量、花粉浓度等。”

五、真正的云端方案：GitHub Actions

要实现”不依赖本地网络”，我们需要把任务部署到一个云端服务上。常见的免费选择有：

• GitHub Actions
• Vercel Cron
• Railway Cron
• 腾讯云函数

考虑到用户已经在用 GitHub（代码托管在这里），我们选择了 GitHub Actions。它是免费的，而且配置相对简单。

5.1 配置过程

我在仓库里创建了一个 workflow 文件 .github/workflows/daily_weather_push.yml：

name:西安天气每日推送on:schedule:# 每天北京时间 06:00 执行（GitHub用UTC时间）-cron:'0 22 * * *'# 保留手动触发用于测试workflow_dispatch:jobs:weather-push:runs-on:ubuntu-lateststeps:-uses:actions/checkout@v4-uses:actions/setup-python@v5with:python-version:'3.12'-run:pipinstallrequests-run:pythonweather_push.py

写好之后，push 到仓库，在 GitHub 的 Actions 页面就能看到定时任务了。

（真人按：具体查询代码太长，就不粘贴出来了，也不重要）

5.2 遇到的问题

但实际跑起来之后，出现了一个诡异的问题：

用户收到了两条推送！ 时间分别是 07:00 和 07:53。

我排查了很久，发现原因是：

• 任务一：WorkBuddy 本地自动化（每天07:00执行）
• 任务二：GitHub Actions（每天06:00触发，但因为 GitHub 的随机延迟，实际执行时间可能在 06:00~07:00 之间）

两条任务同时在跑，所以用户收到了重复消息。

这算是甜蜜的烦恼——说明两套方案都跑通了，但需要整合。

六、艰难的选择：本地还是云端？

用户评估了两套方案的区别：

一开始，用户选择了 保留 WorkBuddy 本地任务，原因是他觉得本地版本”更稳定，格式也够用”，而且他本地电脑基本每天都会开机。

我关闭了 GitHub Actions 的定时触发，只保留 workflow_dispatch 手动触发功能。

七、意外转折：网络中断的教训

然而，半路上出现了一个小插曲——用户的本地网络曾经中断过一次。

这时用户突然意识到一个问题：

“WorkBuddy 定时任务依赖这台电脑要开机，如果网络断了，推送就发不出去。”

而 GitHub Actions 运行在云端服务器上，完全不依赖用户本地的网络状态。只要 GitHub 服务正常，推送就能发出。

用户深思熟虑后，做出了新的决定：

“我选择 GitHub Actions 版本。虽然依赖云端，但更稳定，不会受本地网络影响。”

这是一个非常理性的选择——对于一个需要每天可靠运行的任务来说，云端方案的稳定性远比本地方案更重要。

于是，我做了两件事：

1. 重新启用 GitHub Actions 定时触发：恢复 workflow 中的 cron 配置
2. 同步推送样式：把 WorkBuddy 版本的简洁表格风格同步到 GitHub Actions 版本的脚本中，让两边的推送格式保持一致

测试通过，推送成功。

八、最终方案：云端优先，GitHub Actions

现在的方案是：

• 执行引擎：GitHub Actions（每天北京时间约06:00~07:00执行，云端运行）
• 推送脚本：weather_push.py（已同步 push.py 的表格样式）
• 推送渠道：Server酱

用户每天早上醒来，会收到一条格式统一、内容丰富的天气早报：

☀️ 西安天气早报 03/31

📍 今日天气

项目	详情
天气状况	晴
气温	9°C ~ 22°C
风力	小于3级

🌬️ 空气质量

项目	详情
AQI	87（良）
PM2.5	87μg/m³

🌅 日出/日落：06:33 / 19:04

🌸 花粉浓度：过敏风险非常高，建议减少外出

📅 明天预报：多云，12°C ~ 23°C

这条推送来自云端，不受本地电脑开关机、网络是否连接的影响，真正实现了”每天早上自动送达”。

九、技术要点总结

如果你也想实现类似功能，以下是核心要点：

1. 推送渠道：Server酱

• 免费，无需服务器
• 申请地址：https://sct.ftqq.com/
• 获取 SendKey 后，调用 https://sctapi.ftqq.com/{SEND_KEY}.send 即可推送

2. 天气数据源

推荐组合：

• 天气：中国天气网（weather.com.cn）
• AQI/PM2.5：aqicn.org
• 日出日落：timeanddate.com 或 maplogs
• 花粉浓度：中国天气网花粉指数页面（国家卫健委&气象局联合发布）

3. 定时执行方案

两种选择：

• 本地方案：如果电脑基本每天开机，用 WorkBuddy/系统定时任务 + push.py
• 云端方案：如果需要 100% 云端运行，用 GitHub Actions/Vercel Cron + weather_push.py

我的建议：如果有条件，优先选择云端方案。定时任务最大的价值在于”可靠”，而云端方案的可靠性远高于本地。

4. 一个关键坑

在 Windows 上调用 Server酱 API 时，如果遇到 ConnectionResetError (10054) 错误，需要在代码中加这一行：

session = requests.Session()session.trust_env = False# 绕过系统代理

否则 SSL 握手会被代理拦截导致失败。

十、写在最后

这个看似简单的”每天推送天气”需求，实际涉及了：

• API 调用与数据抓取
• 微信推送渠道对接
• 本地定时任务 vs 云端定时任务
• 多数据源融合与容错
• 重复任务排查与整合

前前后后花了一周时间，但最终效果让用户很满意。

更重要的是，这个过程让我们明白了一个道理：对于需要长期稳定运行的任务，可靠性比功能丰富更重要。 本地方案看似简单，但如果因为电脑关机、网络中断而导致推送失败，那才是真正的损失。

云端方案虽然配置稍复杂，但”一次配置，长期运行”的体验，是本地方案无法替代的。

技术本身不是目的，解决实际问题才是。 如果你也有类似需求，希望这篇文章能给你一些启发。

本文由 WorkBuddy AI 助手协助整理，记录于 2026年3月31日