案例 19｜历史天气数据采集（双通道）

一、案例背景与采集目标

天气是离日常生活最近的一类公开数据：早上要不要带伞、今天适不适合户外跑、老人要不要减少外出，都靠它。它同时也是最适合练「整月采全」的数据源——页面结构规整，但里面藏着两个机关：页面只给半截数据，剩下半截要走接口；站点还会反过来限你的速。把这两个机关都过了，你就掌握了采集真实站点最核心的两样本事。

本案例的目标站点：天气网 · 历史天气（广州），网址 https://lishi.tianqi.com/guangzhou/202608.html。它的网址规律很好记：城市拼音 + 年月，换一个月份就换一个页面，例如 https://lishi.tianqi.com/guangzhou/202607.html 就是 2026 年 7 月。

1.1 为什么挑这个站点

• 公开、无需登录，属于本课鼓励的「可运行示范」数据；
• 结构规整但暗藏机巧——页面上明明写着整月的统计结论，逐日明细却只肯给你前十天，剩下的必须自己拼接，正好用来练「页面 + 接口」的组合拳；
• 站点会限流，而且限得很真——连续请求两次就可能被拦，还会给回一个「伪装成正常页面的 404」。这是课堂上学「断点续跑 + 双通道兜底」的最佳现场。

1.2 这个案例要拿到什么

• 广州 2011 年 1 月至今、逐月连续的逐日天气明细（每天一行：日期、天气现象、最高温、最低温、风向、风力、空气质量指数、PM2.5；实测 2011 年 1 月与 2026 年 9 月页面均在线）；
• 每个月的官方统计卡（平均高温、平均低温、极端高温、极端低温、平均空气质量）；
• 每个月的气温走势图（站点页面上那张原生图表）；
• 把逐日明细独立重算一遍，与站点的月度统计卡逐月交叉校验，验证我们采到的数据可信。

1.3 这个站点最关键的一个机关

打开任意一个历史月份页面，你会看到一整月的表格——但只有 1 日到 10 日是真数据，11 日以后的表格是空壳，要等你点「查看更多」时才由前端去后台取。也就是说：

所以本案例的采集逻辑是：先用页面把前十天与统计卡拿到，再用接口把 11 日到月末补齐，最后按日期合并去重。这也解释了一个新手常犯的错误——「我明明看到整月都在，为什么采下来只有十天」。

1.4 这个案例的难点在哪

目标站点与交付产物

下表是本篇用到的真实站点。绿色是课堂可稳定复现的示范站点；橙色是延伸站点，多数有登录墙或风控，课堂上只讲结构、原理与合规边界，不教绕过。

二、数据源与字段设计

这个站点有两套结构相同的通道：PC 端与移动端。数据字段完全一样，区别只在于路径与限流强度——这正是我们能在 PC 端被限流时用移动端兜底的原因。

2.1 逐日明细字段（14 个）

2.2 月度统计卡字段（站点自己算好的结论）

2.3 三个必须写死的口径

• 数据要「页面 + 接口」取并集。只采页面会丢掉每月后二十天；只采接口会丢掉统计卡。两段在 11 日附近有重叠，按日期去重、页面数据优先。
• 空气质量缺失要留空。这个站点的空气质量数据大约从 2017 年 11 月才有，更早的月份站点用 0 占位。必须要求「把这类占位值标成缺失、留空」，否则算出来的「历史平均空气质量」会被一堆假 0 拉低。
• 「数据来源通道」这一列不能省。双源采集时，同一个日期可能两条通道都有数据，留下来源列，才能做「两源是否一致」的交叉校验，也才能在发现问题时定位是哪条通道出的错。

三、零代码操作步骤

下面是在 WorkBuddy 里完成本案例的完整流程。全程不需要你写一行代码，但每一步都要动手核对。

1. 新建对话，粘贴下一节的「采集提示词」，网址用 https://lishi.tianqi.com/guangzhou/202608.html。
2. 先只采一个月。说「先只采 2026 年 8 月，把逐日明细和月度统计卡都给我看」。
3. 核对三件事。① 这个月是不是整月都齐（不是只有 10 天）；② 空气质量列的范围对不对；③ 统计卡的四项数值有没有单独存下来。
4. 验证「页面 + 接口」是不是都走到了。如果只有 1 到 10 日，说明只采了页面，要明确要求「11 日到月末请从站内接口补齐」。
5. 再采一整年。说「按同样规则采 2025 年全年 12 个月，注意控制频率，被限流就等一会儿再继续，已经采好的不要重复采」。
6. 放开全量。确认一年没问题后，说「继续采 2011 年 1 月到 2026 年 9 月的其余月份，凑成 2011 年 1 月至今的完整序列」。这一步会被限流拖得比较久，让它在后台跑。
7. 生成三件套。说「把数据整理成：数据明细 Excel、可检索的明细网页、带图表的数据看板，看板里的高温用红、低温用蓝」。
8. 做交叉校验。说「用逐日明细重算每个月的平均高温、平均低温、极端高低温，和统计卡比对，把不一致的月份单独列出来」。
9. 顺手把气温走势图也导出。说「把每个月的走势图导出成图片，并做一个可按年份筛选的图库页」。

四、提示词模板与追问技巧

下面这段可以直接复制。注意三件事：把「页面 + 接口」写死、把缺失值口径写死、先小后大分批来。

请帮我采集天气网的历史天气数据，城市广州。

【目标站点】https://lishi.tianqi.com/guangzhou/202608.html
  网址规律是 城市拼音 + 年月，例如 202607 就是 2026 年 7 月。
  注意：页面服务端只渲染每月 1~10 日的明细，11 日到月末必须从站内接口补齐
  （POST https://lishi.tianqi.com/monthdata/guangzhou/{年月}）。
  移动端 m.tianqi.com 结构同构，PC 端被限流时可以切过去。

【采集范围】先只采 2026 年 8 月给我验证，我确认后再采全量。

【需要字段】
  一、逐日明细（每天一行）
    1. 日期（统一成 2026-08-15 格式）
    2. 年月 / 星期
    3. 城市
    4. 天气现象（照录原文）
    5. 最高温、最低温（只要数字，不要「℃」）
    6. 风向（如 东南风）
    7. 风力（如 2 级）
    8. 空气质量指数 AQI、PM2.5（没有就留空）
    9. 数据来源通道（pc / wap）
  二、月度统计卡（每月一行）
    10. 平均高温、平均低温、极端高温、极端低温、平均AQI、缺失天数

【执行要求】
  - 必须把「页面 1~10 日」和「接口 11 日到月末」取并集，按日期去重
  - 空气质量缺失要留空，不要把站点上的占位 0 当成真实值
  - 支持断点续跑：已采好的月份自动跳过，中断后重跑同一条命令能接着采
  - 控制频率，被限流就等一会儿再继续，不要提高频率硬闯
  - 有效性要按内容判断：页面要有正常正文，接口要能解析出 JSON，
    不要只看状态码是不是 200
  - 输出 Excel，文件名 guangzhou_weather.xlsx

4.1 三条常用追问指令

追问一（只有十天）：
  采回来每个月只有 1 到 10 日，后半月的明细丢了。
  请从站内接口 /monthdata 把 11 日到月末补齐，并和页面数据按日期合并去重。

追问二（缺失值被当成 0）：
  早期月份的平均空气质量是 0，这是站点的占位符，不是真实值。
  请把这类 0 判为缺失、留空，并在质量说明里写清楚从哪个月份开始才有空气质量数据。

追问三（交叉校验）：
  请用逐日明细重算每个月的平均高温、平均低温、极端高温、极端低温，
  与站点统计卡逐月比对，把差值超过 2 摄氏度的月份单独列出来，并说明可能的原因。

五、结果核对、清洗与保存

采集到的逐日明细样例（示例数据，字段形态与真实一致）：

5.1 六步清洗，一句话一条

① 去单位：
   把最高温、最低温里的「℃」去掉，只保留数字。

② 统一日期：
   把日期统一成 YYYY-MM-DD，并按日期正序排列；派生「年月」「星期」两列。

③ 缺失归一：
   把 AQI 与 PM2.5 的占位值 0 判为缺失、置空，并统计每个月缺失的天数。

④ 新增温差列：
   新增「温差」= 最高温 − 最低温。

⑤ 交叉校验：
   用逐日明细重算每月的平均高低温、极端高低温，与统计卡比对，
   差值 ≤2 摄氏度视为一致；不一致的月份单列出来并说明原因。

⑥ 输出交付：
   先给我 Excel 数据明细，再生成可检索明细网页和数据看板。

5.2 这套流程最后交付哪些东西

六、常见问题与合规红线

6.1 这个站点上最容易踩的五个坑

6.2 三条合规红线

1. 只采公开信息。历史天气、空气质量属公开发布信息，可以采；但不要试图获取需要登录或付费的内容。
2. 控制频率。这个站点的限流很敏感，本案例要求低频、支持断点续跑、命中限流就退避等待，不去想办法绕过。
3. 不冒充官方。采集结果只作课堂分析，不得包装成气象服务对外发布，也不得声称是官方数据。

七、随堂自测（10 题）

点击选项即可判分，答错的题会立刻显示解析。