一、案例背景与采集目标
前面二十三个案例,我们一个个练了「列表页、详情页、订阅源、开放接口、动态页面」这些招式。这一篇不再引入新招式,而是把已有招式串成一个小项目:从两个真实来源采数据,统一字段、清洗去重,存进数据库,最后让 WorkBuddy 画出图表、给出一句话结论,打包成一份可复现的报告。
本项目的两个来源是:一、广州城市理工学院 · 校园新闻,https://www.gcut.edu.cn/xyxw_183/list.htm ;二、天气网 · 广州历史天气,https://lishi.tianqi.com/guangzhou/202608.html (按月分页,把 2026 年 1 月到 9 月各月页都采一遍)。一个是从校园新闻里按日期数出的「发布节奏」,一个是按日期排的「气温与空气质量」,两者都带日期,正好能按日期对齐,做一张「发布节奏 × 同期天气」的对照看板。
1.1 这个项目要做成什么
- 多源采集:校园新闻 + 历史天气,两个来源都采;
- 字段统一:把两个来源的字段对齐成一张按日期索引的标准表;
- 清洗去重:去空格、统一日期与数值格式、按日期去重;
- 存入 SQLite:把结果落成一个本地数据库文件;
- 生成图表看板:至少三张图,并说明每张图为什么选这种图;
- 一句话结论:用一句话说清图表说明了什么;
- 打包交付:数据明细.xlsx / 数据明细.html / 数据看板.html / 技能压缩包。
1.2 这个项目的难点在哪里
| 难点 | 具体表现 | 为什么难 |
|---|---|---|
| 两个来源颗粒度不同 | 新闻是「一条一条」,天气是「一天一条」 | 必须先把新闻按发布日聚合,才能和天气对齐 |
| 日期口径要统一 | 新闻列表页有发布日,天气页有每日日期 | 都要统一成 YYYY-MM-DD 才能按日 join |
| 同名不同义 | 两个来源都可能有「来源」字段,含义不同 | 统一到标准字段时必须重命名、加前缀 |
| 多源合并容易重复 | 同一天既有多条新闻又有一行天气 | 按日期 + 来源联合去重,不能只按日期 |
目标站点与交付产物
下表是本篇用到的真实站点。绿色是课堂可稳定复现的示范站点;橙色是延伸站点,多数有登录墙或风控,课堂上只讲结构、原理与合规边界,不教绕过。
| 项目 | 内容 |
|---|---|
| 示范站点 | 校园新闻 + 历史天气 双源综合 https://www.gcut.edu.cn/xyxw_183/list.htm 把前 35 个案例的能力串成一个小项目:多源采集 → 统一字段 → 清洗去重 → 入库 → 看板 → 报告 |
| 延伸站点 |
|
| 交付产物 |
|
| 难度 | ★★★ 高 |
| 合规提示 | 综合各源合规要求取最严者;报告中必须写明数据来源、采集日期、口径与已知局限。 |
二、数据源与字段设计
本项目的字段设计有一个新要求:统一的标准字段。两个来源各自的字段名和颗粒度都不一样,我们要先定一套「目标字段」,再规定每个来源的原始字段如何映射过来。
2.1 目标站点信息
| 站点全称 | 网址 | 页面形态与接口 | 规模与角色 |
|---|---|---|---|
| 广州城市理工学院 · 校园新闻 | https://www.gcut.edu.cn/xyxw_183/list.htm | webplus 站群纯静态分页列表,16 条/页;无反爬 | 校园公开新闻,约 955 页、上万条 |
| 天气网 · 广州历史天气 | https://lishi.tianqi.com/guangzhou/202608.html | 按月分页的静态页,含月度统计卡与每日明细(天气、最高温、最低温、风向、风力、AQI) | 按月一页,把 2026 年 1—9 月各月页都采一遍 |
2.2 完整字段表(14 个字段)
| 字段名 | 字段含义 | 示例值 | 口径与备注 |
|---|---|---|---|
date | 日期 | 2026-03-05 | 统一成 YYYY-MM-DD,两个来源都按它对齐 |
source | 数据来源标记 | 校园新闻 | 固定值:校园新闻 / 历史天气 |
source_type | 来源类型 | 静态页 | 标记本行数据采自静态页还是数据接口;本项目两个来源都是静态页 |
category | 分类 | 校园动态 | 新闻取栏目,天气取天气现象 |
title | 标题或现象 | 我校学子在省级竞赛中获佳绩 | 新闻取标题,天气取当日代表现象 |
value | 数值指标 | 12 | 新闻=当日新闻条数;天气=当日最高温 |
value2 | 第二数值指标 | 12 | 新闻与 value 相同;天气=当日最低温 |
unit | 数值单位 | 条 | 新闻=条;天气=摄氏度 |
extra | 附加指标 | 200 | 新闻=当日第一条新闻的栏目;天气=AQI |
link | 原始链接 | https://www.gcut.edu.cn/2026/0930/c183a214616/page.htm | 新闻详情页地址或天气月页地址 |
batch_id | 采集批次 | 20261008_01 | 格式为「日期_轮次序号」,同一天补采时序号递增,便于追溯是哪一轮采回的 |
check_status | 校验状态 | 字段齐全 | 取值为「字段齐全」或「缺关键字段」;入库前逐行检查并标注 |
dedup_key | 去重键说明 | date + source | 本项目统一按「日期 + 来源」联合去重,与清洗规则保持一致 |
fetch_time | 采集时间 | 2026-10-08 15:20 | 采集当时的时间戳,精确到分钟 |
2.3 来源字段映射表
| 标准字段 | 校园新闻来源映射 | 历史天气来源映射 |
|---|---|---|
date | 列表页发布日 | 每日明细的日期 |
source | 固定填「校园新闻」 | 固定填「历史天气」 |
source_type | 静态页(webplus 站群分页列表,无公开数据接口) | 静态页(按月分页的历史天气页,无公开数据接口) |
category | 新闻所属栏目 | 天气现象(晴/多云/雷阵雨) |
title | 新闻标题 | 天气现象(同日聚合时取代表现象) |
value | 该日新闻条数(按日聚合) | 当日最高温 |
value2 | 该日新闻条数(同 value) | 当日最低温 |
unit | 条 | 摄氏度 |
extra | 第一条新闻的栏目 | AQI(0~500) |
link | 新闻详情页地址 | 该月天气页地址 |
batch_id | 首轮填「当天日期_01」,定点补采时序号递增,与日志对应 | 同一轮逐月采集共用一个批次号,按月分页采完 1—9 月为一批 |
check_status | 缺标题或发布日记「缺关键字段」,其余记「字段齐全」 | 缺日期或最高温/最低温记「缺关键字段」,其余记「字段齐全」 |
dedup_key | 同日多条新闻已聚合为一行,键为该日日期加来源 | 每月页每日一行,键同样为日期加来源;两来源键不重叠 |
fetch_time | 采集当时的时间戳 | 采集当时的时间戳 |
2.4 字段统一的三条要点
- 先定「标准字段」,再做映射。不要让两个来源各采各的、最后硬拼。正确顺序是先规定标准字段名与含义,再逐条写清「来源一的哪个字段映射到哪个标准字段」。映射表本身就是一份可复用的文档。
- 先统一颗粒度,再对齐。天气是「一天一条」,新闻是「一条一条」,不能直接拼。要先把新闻按发布日聚合成「某天有几条」,才能和天气按日期对齐。这一步是项目成败的关键。
- 「来源」字段是关键。每条数据都要标清它来自哪个来源。这样后续既能合并分析,也能随时分开看两个来源的差异,是典型的多源数据习惯。
AI 助手小贴士|两个来源的字段往往只能对上一半。让 WorkBuddy 先出一份「映射表」,把对不上的字段单独标出来,你再决定是舍去还是另想办法,远比直接开采稳妥。
打开 WorkBuddy 或任意 AI 对话工具,试试这样问:请先把校园新闻和历史天气两个来源各自的字段列出来,做一份映射到标准字段的对照表;对不上的字段单独标注,先不要采集。
课程思政|数据安全与法治素养 · 多源合并,边界反而更多
这次要合并两个来源,看起来数据更多了,其实合规要求也更高:两个来源各自的授权范围要都遵守,来源都要标注,不能因为合并就模糊了「这份数据是谁的、从哪来的」。多源数据的伦理,第一句就是「来源必须可追溯」。
三、零代码操作步骤
工具与技能|先看清三个角色,再动手
本篇全程零代码:你把要求说清楚,AI 去执行,你负责验收。三个角色分工如下——浏览器技能指的是腾讯开源的 BrowserSkill,它能让 AI 直接操作你电脑上真实的浏览器(可复用已经登录的状态),自己开一个独立窗口干活,不打扰你正在看的网页;遇到验证码、登录或确认弹窗,它会停下来交给你本人处理。
| 角色 | 负责什么 | 在本案例里具体做什么 |
|---|---|---|
| 你 | 确认字段清单、验收结果、清洗与合规把关 | 盯字段清单、核对结果、处理异常(如验证码) |
| WorkBuddy | 接中文指令:探字段 → 批量采 → 清洗 → 导出交付物 | 拆解本篇的采集任务并跑完全量、产出交付物 |
| 浏览器技能 BrowserSkill | 以真实浏览器打开页面:跑脚本渲染、滚动 / 翻页 / 点开详情、截图留证;可复用本机浏览器已登录状态,遇到验证码或登录弹窗会停下来交给你处理 | 两个来源各采一遍,再合并成一张标准表 |
五步操作主线(全课程统一,每一篇都按这个顺序推进):
- 定目标与字段:先看本篇第二节的字段表,把「要哪几列、每列什么口径、要多少条」说清楚——字段清单就是验收标准,说不清就会拿回一张字段乱七八糟的表。
- 现场踩点(浏览器技能 BrowserSkill):分别打开校园新闻列表页与历史天气页,确认两边的字段口径与时间粒度。
- 小样试采(WorkBuddy):各采一小段(校园新闻 2 页 / 天气 1 个月),先验证标准字段能对齐。
- 核对与清洗:① 合并后的列名与标准字段表完全一致吗;② 有没有空行与重复;③ 看板的三张图能不能用合并表复现出来。
- 导出与归档:导出交付物(数据明细表 / 可筛选明细页 / 数据看板 / 可复用的技能包),文件名带上采集日期,并写清数据来源、采集时间与已知局限。
用浏览器技能 BrowserSkill 打开 https://www.gcut.edu.cn/xyxw_183/list.htm(校园新闻 + 历史天气 双源综合),把这一页每条记录能采到的字段名和示例值列出来,先不要采集。下面的「任务拆解」表把整个项目分成 7 步。请严格按顺序推进,每一步都验收后再进下一步。
| 步骤 | 做什么 | 产出 | 怎么验收 |
|---|---|---|---|
| 1 | 写一句话目标,确定标准字段 | 目标句 + 字段表 | 目标能回答「要说明什么」 |
| 2 | 采集校园新闻列表并聚合 | source_news.xlsx | 按发布日聚合的每日条数对得上 |
| 3 | 采集历史天气各月页 | source_weather.xlsx | 每日明细字段与标准字段对得上 |
| 4 | 字段统一为一张标准表 | merged_raw.xlsx | 列名与字段表完全一致 |
| 5 | 清洗去重 | merged_clean.xlsx | 无空行、无重复、日期格式统一 |
| 6 | 存入 SQLite | data.db | 能按来源、按日期查询 |
| 7 | 生成图表与结论,打包报告 | report/ 目录 | 三张图 + 一句话结论 + 说明文件 |
对应到 WorkBuddy 里的具体操作如下。
- 第一步,说目标与字段。把一句话目标与标准字段表发给它,请它复述一遍确认无误。
- 第二步,采校园新闻。从
https://www.gcut.edu.cn/xyxw_183/list.htm采列表页,取回标题、栏目、发布日,并按发布日聚合成每日条数,导出source_news_20261008.xlsx。 - 第三步,采历史天气。从
https://lishi.tianqi.com/guangzhou/202608.html开始,把 2026 年 1—9 月各月页都采一遍,导出source_weather_20261008.xlsx。 - 第四步,合并。让它把两份表按映射关系合并成一张
merged_raw_20261008.xlsx,并保留 source 列。 - 第五步,清洗。统一日期成 YYYY-MM-DD、数值去单位、按「date + source」去重,导出
merged_clean_20261008.xlsx。 - 第六步,入库。让它把清洗后的表写入
data.db(SQLite),表名叫 campus。 - 第七步,出图与报告。让它画折线图、柱状图、散点图等至少三张,写一句话结论,并整理进
report/目录。
本项目的文件命名规范是「类型_来源_日期」,例如 source_news_20261008.xlsx。之后所有文件都按这个规范命名,不要用「新建表格1」这类名字。四、提示词模板与追问技巧
综合实战的提示词分两次发:先发项目总纲,再发分步指令。总纲让助手理解全局,分步指令让每一步都能单独验收。
4.1 项目总纲(第一步发)
我要做一个小型数据项目,请你全程协助,先理解需求,不要马上开干。
【项目目标】用校园新闻的发布节奏和同期广州天气,看学校宣传高峰是否集中在开学与活动季。
【数据来源】
来源一:广州城市理工学院 校园新闻,https://www.gcut.edu.cn/xyxw_183/list.htm
来源二:天气网 广州历史天气,https://lishi.tianqi.com/guangzhou/202608.html
(按月分页,把 2026 年 1 月到 9 月各月页都采一遍)
【标准字段】date(日期 YYYY-MM-DD)、source(来源标记)、source_type(来源类型)、
category(分类)、title(标题或现象)、value(数值指标)、value2(第二数值指标)、
unit(单位)、extra(附加指标)、link(原始链接)、batch_id(采集批次)、
check_status(校验状态)、dedup_key(去重键说明)、fetch_time(采集时间)
【最终产出】
1. 两份原始数据 source_news、source_weather
2. 合并后的标准表 merged_raw
3. 清洗后的 merged_clean
4. SQLite 数据库 data.db(表名 campus)
5. 至少三张图:折线图(校园新闻每日条数、最高/最低温)、柱状图(各月新闻量)
6. 一句话结论 + 一份说明文件 README
【工作要求】
- 文件命名规范:类型_来源_日期,例如 source_news_20261008.xlsx
- 每一步先给我看结果,我确认后再做下一步
- 校园新闻按发布日聚合成每日条数;天气取每日明细
- 请先把上面这些理解复述一遍,并指出我没说清的地方
4.2 分步指令(逐步发)
第 2 步:请从 https://www.gcut.edu.cn/xyxw_183/list.htm 采集校园新闻列表,
取回标题、栏目、发布日,并按发布日聚合成「每日新闻条数」,
先在对话里给我表格预览,确认后再导出 source_news_20261008.xlsx。
第 3 步:请从 https://lishi.tianqi.com/guangzhou/202608.html 开始,
把 2026 年 1—9 月各月历史天气页都采一遍,
取每日的日期、天气现象、最高温、最低温、风向、风力、AQI,
导出 source_weather_20261008.xlsx。
第 4 步:请把两个来源的两张表,按映射关系合并成一张标准表,
保留 source 列标明每条来自哪个来源,导出 merged_raw_20261008.xlsx。
第 5 步:请清洗合并表:日期统一成 YYYY-MM-DD、数值去掉单位、
按「date + source」去重,导出 merged_clean_20261008.xlsx,并告诉我清洗前后各有多少条。
第 6 步:请把清洗后的数据写入 SQLite 数据库 data.db,
表名用 campus,并给我三条示例查询语句(按来源、按日期、按月份)。
4.3 三条常用追问指令
追问一(合并对不上):
合并后有些行的 category 是空的,请检查是映射写错了、
还是原文本来就没有,两种情况分别处理并告诉我原因。
追问二(图表要说明):
三张图都要有标题、坐标轴名称和单位,并在图注里说明为什么选这种图型;
每张图下面配一句话说明它反映了什么,不要只有图没有解读。
追问三(做成可复现):
请把所有步骤整理成一份 README,
写清数据来源、采集日期、字段口径、清洗规则、运行顺序,
让别人照着 README 能复现出同样的结果。
4.4 看板怎么设计:图表选择
看板不是「图越多越好」,而是「每张图回答一个问题」。按要说明的问题来选图型,是这一步的核心。
| 要说明的问题 | 合适的图型 | 为什么 |
|---|---|---|
| 校园新闻每日条数的时间变化 | 折线图 | 时间序列看趋势,折线最直观 |
| 最高温 / 最低温的时间变化 | 折线图(双线) | 两条温度线放同一坐标,便于对照 |
| 各月新闻发布量对比 | 柱状图 | 分类之间的数量对比,柱状最清楚 |
| 气温与新闻量的关联 | 散点图 | 看两个连续变量之间有没有关系 |
AI 助手小贴士|报告写完先别交。让 WorkBuddy 站在「审查者」的角度挑毛病:哪一步没有依据、哪个数字对不上、哪张图其实没说明问题。
打开 WorkBuddy 或任意 AI 对话工具,试试这样问:请你以数据审查者的身份,检查这份报告:哪些结论缺少数据支撑?哪些步骤别人无法复现?逐条指出并给出修改建议。
五、结果核对、清洗与保存
这一步把整个项目的产物摆出来。先看「项目目录结构」——一份专业的交付,目录本身就是说明书。
5.1 项目目录结构
campus_project/
├── README.md ← 项目说明:目标、来源、口径、运行顺序
├── raw/
│ ├── source_news_20261008.xlsx ← 校园新闻,按日聚合
│ └── source_weather_20261008.xlsx← 历史天气,每日明细
├── clean/
│ ├── merged_raw_20261008.xlsx ← 合并后的标准表
│ └── merged_clean_20261008.xlsx ← 清洗去重后的表
├── data/
│ └── data.db ← SQLite 数据库(表名 campus)
├── charts/
│ ├── chart_line_news.png ← 折线图:校园新闻每日条数
│ ├── chart_line_temp.png ← 折线图:最高温 / 最低温
│ └── chart_scatter.png ← 散点图:气温 vs 新闻量
├── report/
│ ├── 数据明细.xlsx ← 合并后的明细(多 Sheet)
│ ├── 数据明细.html ← 可筛选、可排序的单页
│ ├── 数据看板.html ← 图表看板 + 一句话结论
│ └── 技能压缩包.zip ← 下次换数据源即可复用的采集与看板模板
└── logs/
└── build_20261008_log.txt ← 全过程日志
5.2 清洗与建库指令
请完成整个项目的数据处理,把每一步的产物放进对应目录:
① 采集:校园新闻按日聚合、历史天气取每日明细,存到 raw/ 目录;
② 合并:统一成标准字段,保留 source 列,存到 clean/merged_raw_20261008.xlsx;
③ 清洗:日期统一成 YYYY-MM-DD、数值去掉单位、按「date + source」去重,
存到 clean/merged_clean_20261008.xlsx,并报告清洗前后条数;
④ 入库:写入 data/data.db,表名 campus;
⑤ 出图:折线图(新闻条数)、折线图(高低气温)、散点图(气温 vs 新闻量)各一张,
存到 charts/,每张图配标题、坐标轴名称与图注;
⑥ 结论:给出一句话结论,说明宣传高峰与季节/天气的关系。
5.3 保存与归档约定
| 约定 | 规则 | 原因 |
|---|---|---|
| 文件命名 | 类型_来源_日期 | 一眼看出是什么、从哪来、哪天生成 |
| 原始数据 | raw/ 目录只增不改 | 原始文件是唯一事实来源,永不覆盖 |
| 日志 | 每步记录时间、条数、异常 | 出问题可追溯,也便于复现 |
| 口径说明 | README 写清字段与清洗规则 | 别人能复现,自己能复盘 |
| 交付清单 | 数据明细.xlsx / 数据明细.html / 数据看板.html / 技能压缩包 | 四件套齐全,才叫一次完整交付 |
AI 助手小贴士|把「清洗前后条数差」单独记进日志,是发现数据问题的快捷线索。差得太多,往往是去重口径出了问题——多源合并时尤其常见。
打开 WorkBuddy 或任意 AI 对话工具,试试这样问:请把清洗前后各多少条、删掉了多少条重复、多少条空值,写进日志文件并向我汇报。
课程思政|工匠精神与严谨求实 · 可复现,是对读者的承诺
一份报告最打动人的地方,不是图做得漂亮,而是「别人照着说明能跑出同样的结果」。要做到这一点,你要把来源、口径、清洗规则、运行顺序都写清楚。愿意花时间写 README 的人,交出来的东西才值得信任——可复现,就是数据工作者对读者的承诺。
六、常见问题与合规红线
6.1 五个高频问题
| 现象 | 原因 | 怎么处理 |
|---|---|---|
| 两个来源合并后很多字段是空的 | 映射关系没写全,或原文本来缺失 | 先明确映射表,区分「映射错」与「原文缺」 |
| 新闻和天气对不上日期 | 新闻没按日聚合,颗粒度不一致 | 先把新闻按发布日聚合,再和天气按日期 join |
| 合并后行数暴涨 | 去重口径太宽 | 按「date + source」去重,并说明口径 |
| 图表看不出想说明的问题 | 图表类型选错了 | 趋势用折线、数量对比用柱状、两变量关系用散点 |
| 报告结论和图对不上 | 结论写得太满,超越了数据范围 | 让结论严格对应图里的数字,避免夸大 |
6.2 三条合规红线
- 两个来源各自合规。合并不会让不合规的数据变合规;校园新闻与历史天气都要单独确认是公开、无需登录、允许采集的页面。
- 来源可追溯。每一行数据都要带 source 标记,报告要注明来源与采集日期,不能只给结论不给依据。
- 成果用于学习与研究。打包的报告用于课程与个人作品展示;原始数据不外传、不贩卖,涉及第三方内容的按原平台规则使用。
课程思政|数据安全与法治素养 · 项目可以小,底线不能松
综合实战把前面所有招式都用上了,也把前面所有红线都聚到了一起。此刻最该记住的是:项目再完整、图再好看,只要有一个来源越了界,整份报告就会被质疑。把合规当成项目的第一条需求,而不是最后一个检查项——这是从「会采数据」走向「能交付数据」的分界线。
七、随堂自测(10 题)
点击选项即可判分,答错的题会立刻显示解析。
1综合实战项目里,「标准字段」这套设计的主要作用是?
- A. 让字段名看起来更洋气
- B. 把不同来源的字段统一成同一套,合并与统计才不乱
- C. 减少采集条数
- D. 让文件更小
2校园新闻与历史天气颗粒度不同(一个是条目、一个是每日一行),正确的处理是?
- A. 直接把两条新闻塞进同一天的那一行
- B. 把天气也拆成一条一条
- C. 先把新闻按发布日聚合成每日条数,再按日期对齐
- D. 放弃其中一个来源
3把清洗后的数据存进 SQLite,最直接的好处是?
- A. 文件更小
- B. 图表更漂亮
- C. 不用再清洗
- D. 可以按来源、日期等条件快速查询与筛选
4本项目里「各月新闻发布量对比」最适合用哪种图?
- A. 柱状图
- B. 全部用饼图
- C. 全部用折线图
- D. 散点图
5清洗前后条数差得特别多,最先应该检查的是?
- A. 电脑有没有中毒
- B. 图表配色
- C. 去重口径是否统一、主键选择是否合理
- D. 报告的字数
6要让别人能复现你的项目,最关键的产物是?
- A. 漂亮的图表
- B. 一份写清来源、字段口径、清洗规则与运行顺序的 README
- C. 一张封面图
- D. 几个数据库文件
7项目交付清单里,除数据明细.xlsx 与数据明细.html 外,本案例要求的另外两项是?
- A. 封面图和演示视频
- B. 数据库和一些截图
- C. 只要求一个 Excel 文件
- D. 数据看板.html 和技能压缩包
8看板上「气温与新闻量的关联」最适合用哪种图?
- A. 柱状图
- B. 饼图
- C. 散点图
- D. 折线图
9本项目对原始文件的处理原则是?
- A. raw/ 目录只增不改,原始文件是唯一事实来源
- B. 随时覆盖成最新版本
- C. 清洗后就可以删掉原始文件
- D. 统一改名成「新建表格」
10把合规检查放在项目一开始而不是最后,主要好处是?
- A. 可以让项目更慢
- B. 早点确认每个来源都允许采集,避免做到最后才发现要推倒重来
- C. 可以减少图表数量
- D. 可以让 README 更短