今天你 AI 赋能了吗?打开浏览器,在地址栏输入 xuefulu.ai,按下 Enter 即可访问学府路1号!
2026年10月17日 星期六 12:32:20
常用网址:案例设计 | 案例导航 | 学府路1号 https://xuefulu.ai | 下载 WorkBuddy https://xuefulu.ai/WorkBuddy.html

一、案例背景与采集目标

前面二十三个案例,我们一个个练了「列表页、详情页、订阅源、开放接口、动态页面」这些招式。这一篇不再引入新招式,而是把已有招式串成一个小项目:从两个真实来源采数据,统一字段、清洗去重,存进数据库,最后让 WorkBuddy 画出图表、给出一句话结论,打包成一份可复现的报告。

本项目的两个来源是:一、广州城市理工学院 · 校园新闻,https://www.gcut.edu.cn/xyxw_183/list.htm ;二、天气网 · 广州历史天气,https://lishi.tianqi.com/guangzhou/202608.html (按月分页,把 2026 年 1 月到 9 月各月页都采一遍)。一个是从校园新闻里按日期数出的「发布节奏」,一个是按日期排的「气温与空气质量」,两者都带日期,正好能按日期对齐,做一张「发布节奏 × 同期天气」的对照看板。

1.1 这个项目要做成什么

1.2 这个项目的难点在哪里

难点具体表现为什么难
两个来源颗粒度不同新闻是「一条一条」,天气是「一天一条」必须先把新闻按发布日聚合,才能和天气对齐
日期口径要统一新闻列表页有发布日,天气页有每日日期都要统一成 YYYY-MM-DD 才能按日 join
同名不同义两个来源都可能有「来源」字段,含义不同统一到标准字段时必须重命名、加前缀
多源合并容易重复同一天既有多条新闻又有一行天气按日期 + 来源联合去重,不能只按日期
项目开始前先写一句话目标。例如「用校园新闻的发布节奏和同期广州天气,看看学校宣传高峰是不是集中在开学与活动季」。目标写不出来,说明你还没想清楚要做什么——这一句话会决定你采哪些字段、画哪些图。
小提醒|先想清楚,再动手。很多人一上来就开采,采完才发现两个来源的字段根本对不上,白费功夫。专业做法是先写一句话目标、再列字段表、最后才动手。把需求前置想清楚,是这个项目最想让你养成的习惯——它比任何技巧都更值钱。

目标站点与交付产物

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

项目内容
示范站点校园新闻 + 历史天气 双源综合
https://www.gcut.edu.cn/xyxw_183/list.htm
把前 35 个案例的能力串成一个小项目:多源采集 → 统一字段 → 清洗去重 → 入库 → 看板 → 报告
延伸站点
  • 天气网 · 广州历史天气 https://lishi.tianqi.com/guangzhou/202608.html(接口源:逐日气温、风向风力与 AQI,与校园新闻合并成一张宽表)
  • 国家统计局 · 数据查询 https://data.stats.gov.cn/easyquery.htm?cn=C01(作为背景数据对照;对脚本请求有反爬(403),浏览器打开正常)
交付产物
  • 数据明细.xlsx(统一字段后的合并明细)
  • 数据明细.html(多源合并视图,可按来源筛选)
  • 数据看板.html(柱状图 / 折线图 / 饼图 + 一句话结论)
  • SQLite 数据库文件 + 项目目录结构说明
  • 交付说明 README(采集口径、字段字典、复现步骤、已知问题)
  • 技能压缩包(从采集到看板的完整项目模板)
难度★★★ 高
合规提示综合各源合规要求取最严者;报告中必须写明数据来源、采集日期、口径与已知局限。

二、数据源与字段设计

本项目的字段设计有一个新要求:统一的标准字段。两个来源各自的字段名和颗粒度都不一样,我们要先定一套「目标字段」,再规定每个来源的原始字段如何映射过来。

2.1 目标站点信息

站点全称网址页面形态与接口规模与角色
广州城市理工学院 · 校园新闻https://www.gcut.edu.cn/xyxw_183/list.htmwebplus 站群纯静态分页列表,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 字段统一的三条要点

  1. 先定「标准字段」,再做映射。不要让两个来源各采各的、最后硬拼。正确顺序是先规定标准字段名与含义,再逐条写清「来源一的哪个字段映射到哪个标准字段」。映射表本身就是一份可复用的文档。
  2. 先统一颗粒度,再对齐。天气是「一天一条」,新闻是「一条一条」,不能直接拼。要先把新闻按发布日聚合成「某天有几条」,才能和天气按日期对齐。这一步是项目成败的关键。
  3. 「来源」字段是关键。每条数据都要标清它来自哪个来源。这样后续既能合并分析,也能随时分开看两个来源的差异,是典型的多源数据习惯。
标准字段名建议用英文小写、简洁一致,写进数据库时最省事;中文含义写在映射表里说明即可。命名统一,是工程化数据管理的第一步。

AI 助手小贴士|两个来源的字段往往只能对上一半。让 WorkBuddy 先出一份「映射表」,把对不上的字段单独标出来,你再决定是舍去还是另想办法,远比直接开采稳妥。

打开 WorkBuddy 或任意 AI 对话工具,试试这样问:请先把校园新闻和历史天气两个来源各自的字段列出来,做一份映射到标准字段的对照表;对不上的字段单独标注,先不要采集。

课程思政|数据安全与法治素养 · 多源合并,边界反而更多

这次要合并两个来源,看起来数据更多了,其实合规要求也更高:两个来源各自的授权范围要都遵守,来源都要标注,不能因为合并就模糊了「这份数据是谁的、从哪来的」。多源数据的伦理,第一句就是「来源必须可追溯」。

三、零代码操作步骤

工具与技能|先看清三个角色,再动手

本篇全程零代码:你把要求说清楚,AI 去执行,你负责验收。三个角色分工如下——浏览器技能指的是腾讯开源的 BrowserSkill,它能让 AI 直接操作你电脑上真实的浏览器(可复用已经登录的状态),自己开一个独立窗口干活,不打扰你正在看的网页;遇到验证码、登录或确认弹窗,它会停下来交给你本人处理。

角色负责什么在本案例里具体做什么
你确认字段清单、验收结果、清洗与合规把关盯字段清单、核对结果、处理异常(如验证码)
WorkBuddy接中文指令:探字段 → 批量采 → 清洗 → 导出交付物拆解本篇的采集任务并跑完全量、产出交付物
浏览器技能
BrowserSkill
以真实浏览器打开页面:跑脚本渲染、滚动 / 翻页 / 点开详情、截图留证;可复用本机浏览器已登录状态,遇到验证码或登录弹窗会停下来交给你处理两个来源各采一遍,再合并成一张标准表

五步操作主线(全课程统一,每一篇都按这个顺序推进):

  1. 定目标与字段:先看本篇第二节的字段表,把「要哪几列、每列什么口径、要多少条」说清楚——字段清单就是验收标准,说不清就会拿回一张字段乱七八糟的表。
  2. 现场踩点(浏览器技能 BrowserSkill):分别打开校园新闻列表页与历史天气页,确认两边的字段口径与时间粒度。
  3. 小样试采(WorkBuddy):各采一小段(校园新闻 2 页 / 天气 1 个月),先验证标准字段能对齐。
  4. 核对与清洗:① 合并后的列名与标准字段表完全一致吗;② 有没有空行与重复;③ 看板的三张图能不能用合并表复现出来。
  5. 导出与归档:导出交付物(数据明细表 / 可筛选明细页 / 数据看板 / 可复用的技能包),文件名带上采集日期,并写清数据来源、采集时间与已知局限。
起手一句话(可直接复制):用浏览器技能 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存入 SQLitedata.db能按来源、按日期查询
7生成图表与结论,打包报告report/ 目录三张图 + 一句话结论 + 说明文件

对应到 WorkBuddy 里的具体操作如下。

  1. 第一步,说目标与字段。把一句话目标与标准字段表发给它,请它复述一遍确认无误。
  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 月各月页都采一遍,导出 source_weather_20261008.xlsx。
  4. 第四步,合并。让它把两份表按映射关系合并成一张 merged_raw_20261008.xlsx,并保留 source 列。
  5. 第五步,清洗。统一日期成 YYYY-MM-DD、数值去单位、按「date + source」去重,导出 merged_clean_20261008.xlsx。
  6. 第六步,入库。让它把清洗后的表写入 data.db(SQLite),表名叫 campus。
  7. 第七步,出图与报告。让它画折线图、柱状图、散点图等至少三张,写一句话结论,并整理进 report/ 目录。
数据库不用你懂 SQL。你只要会说「存进 SQLite,方便我之后按来源和日期筛选」,WorkBuddy 就会把建表、写入、查询一并做好,还会给你几条示例查询语句。
项目最容易乱在文件命名上。开工前先把「文件命名规范」发给它,让它从第一步就照规范命名,比最后再重命名省事得多。可以直接这样问:本项目的文件命名规范是「类型_来源_日期」,例如 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 看板怎么设计:图表选择

看板不是「图越多越好」,而是「每张图回答一个问题」。按要说明的问题来选图型,是这一步的核心。

要说明的问题合适的图型为什么
校园新闻每日条数的时间变化折线图时间序列看趋势,折线最直观
最高温 / 最低温的时间变化折线图(双线)两条温度线放同一坐标,便于对照
各月新闻发布量对比柱状图分类之间的数量对比,柱状最清楚
气温与新闻量的关联散点图看两个连续变量之间有没有关系
一句话结论要能被图支撑。「说明宣传高峰」这个目标,对应的一句话结论可能是「校园新闻发布量在 3 月和 9 月开学季明显高于其他月份」。有数字、有依据,才叫结论。

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 三条合规红线

  1. 两个来源各自合规。合并不会让不合规的数据变合规;校园新闻与历史天气都要单独确认是公开、无需登录、允许采集的页面。
  2. 来源可追溯。每一行数据都要带 source 标记,报告要注明来源与采集日期,不能只给结论不给依据。
  3. 成果用于学习与研究。打包的报告用于课程与个人作品展示;原始数据不外传、不贩卖,涉及第三方内容的按原平台规则使用。
「把项目做漂亮」不等于「把数据边界放宽」。为了凑够两个来源,去采需要登录或明确禁止采集的页面,是这个项目里最不该犯的错。宁可来源少一点,也要每个来源都干净、合规、可追溯。

课程思政|数据安全与法治素养 · 项目可以小,底线不能松

综合实战把前面所有招式都用上了,也把前面所有红线都聚到了一起。此刻最该记住的是:项目再完整、图再好看,只要有一个来源越了界,整份报告就会被质疑。把合规当成项目的第一条需求,而不是最后一个检查项——这是从「会采数据」走向「能交付数据」的分界线。

七、随堂自测(10 题)

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

已答 0 / 10 · 正确 0 —

1综合实战项目里,「标准字段」这套设计的主要作用是?

  • A. 让字段名看起来更洋气
  • B. 把不同来源的字段统一成同一套,合并与统计才不乱
  • C. 减少采集条数
  • D. 让文件更小
答案:B。多源数据必须先统一字段口径,否则合并时列名对不上、含义不一致,后续统计无法进行。

2校园新闻与历史天气颗粒度不同(一个是条目、一个是每日一行),正确的处理是?

  • A. 直接把两条新闻塞进同一天的那一行
  • B. 把天气也拆成一条一条
  • C. 先把新闻按发布日聚合成每日条数,再按日期对齐
  • D. 放弃其中一个来源
答案:C。多源合并前必须先统一颗粒度,把新闻按日聚合成每日条数,才能和天气按日期 join。

3把清洗后的数据存进 SQLite,最直接的好处是?

  • A. 文件更小
  • B. 图表更漂亮
  • C. 不用再清洗
  • D. 可以按来源、日期等条件快速查询与筛选
答案:D。数据库的价值在于结构化的查询能力,方便后续反复筛选与统计。

4本项目里「各月新闻发布量对比」最适合用哪种图?

  • A. 柱状图
  • B. 全部用饼图
  • C. 全部用折线图
  • D. 散点图
答案:A。分类之间的数量对比,柱状图最清楚;折线图适合看时间趋势,散点图适合看两个变量的关系。

5清洗前后条数差得特别多,最先应该检查的是?

  • A. 电脑有没有中毒
  • B. 图表配色
  • C. 去重口径是否统一、主键选择是否合理
  • D. 报告的字数
答案:C。条数骤减通常说明去重口径有问题,比如主键选得太宽,把不该删的记录删掉了。

6要让别人能复现你的项目,最关键的产物是?

  • A. 漂亮的图表
  • B. 一份写清来源、字段口径、清洗规则与运行顺序的 README
  • C. 一张封面图
  • D. 几个数据库文件
答案:B。可复现的核心是把过程与口径写清楚,别人照着 README 才能跑出同样的结果。

7项目交付清单里,除数据明细.xlsx 与数据明细.html 外,本案例要求的另外两项是?

  • A. 封面图和演示视频
  • B. 数据库和一些截图
  • C. 只要求一个 Excel 文件
  • D. 数据看板.html 和技能压缩包
答案:D。本案例的交付清单是数据明细.xlsx、数据明细.html、数据看板.html、技能压缩包四件套,齐全才算一次完整交付。

8看板上「气温与新闻量的关联」最适合用哪种图?

  • A. 柱状图
  • B. 饼图
  • C. 散点图
  • D. 折线图
答案:C。要看两个连续变量之间有没有关系,散点图最合适;折线图用于时间趋势,饼图用于占比。

9本项目对原始文件的处理原则是?

  • A. raw/ 目录只增不改,原始文件是唯一事实来源
  • B. 随时覆盖成最新版本
  • C. 清洗后就可以删掉原始文件
  • D. 统一改名成「新建表格」
答案:A。原始数据必须原样保留,清洗出错时才能回退;随意覆盖会让整个项目失去可追溯性。

10把合规检查放在项目一开始而不是最后,主要好处是?

  • A. 可以让项目更慢
  • B. 早点确认每个来源都允许采集,避免做到最后才发现要推倒重来
  • C. 可以减少图表数量
  • D. 可以让 README 更短
答案:B。合规是项目的前置需求,越早确认越省事;放到最后,一旦发现来源越界,前面的工作可能全部作废。