案例 04｜多源新闻聚合与去重（RSS订阅）

一、案例背景与采集目标

前两个案例，我们一条一条地翻某一个新闻网站的列表页和详情页。可现实里的资讯需求往往不是「盯一家」，而是「盯一件事」——同一个政策、同一场发布会、同一份数据，十几家媒体都在报。只采一家，视野太窄；一家一家地采，字段对不齐、重复一大堆，最后还要花大量时间做合并。

这一案例换个思路：用订阅源（RSS / Atom）把多家媒体的更新一次性取回。订阅源是网站主动对外发布的一份标准化资讯清单，本质是一份 XML 文件，字段固定、结构统一，天然绕开了「各家页面长得都不一样」这个最大的麻烦。

1.1 这一篇用哪些真实站点

示范站点是中国新闻网（简称中新网）的 RSS 订阅中心，地址 https://www.chinanews.com.cn/rss/。打开这个页面你会看到，它把时政、财经、社会、国际、文化等多个频道各自做成一个独立的订阅地址（形如 https://www.chinanews.com.cn/rss/china.xml 这样的 .xml 文件），每个源里放着该频道最近的一批稿件。这是一个公开提供、无需登录、也没有反爬的站点，非常适合作为聚合练习的第一站。

延伸站点再配两家：36氪 https://www.36kr.com/feed（商业科技媒体，RSS 2.0）、少数派 https://sspai.com/feed（效率工具媒体，RSS 2.0）。这三个源恰好都是 RSS 2.0，标签名能直接对上；但订阅源还有另一套常见格式 Atom，字段名完全不同，后面那张「字段映射表」把两套都列了出来。

1.2 这个案例要拿到什么

• 从 3~5 个订阅地址，各取最近的一批条目；
• 把各家的字段映射成同一套：标题、链接、发布时间、摘要、来源媒体；
• 把发布时间统一成同一个格式，方便排序与跨天比较；
• 把同一件事的多家报道合并、去重，一条内容只留一次；
• 只保留「上次采集之后」的新条目，实现增量更新。

1.3 为什么订阅源比直接采页面省事

可以打个比方：订阅源就像媒体给你留了一个「取件窗口」，你不用翻它的整个院子，只要按时去窗口取就行。这也解释了为什么做资讯聚合的人，第一步总是先找有没有订阅源，找不到才退回去采页面。

1.4 这个案例真正的难点在哪

采到数据不难，难在把三家的数据拼成一张干净的表。具体有三关：第一关是字段映射，本案例这三个源都是 RSS 2.0，标签名能直接对上；但订阅源还有另一套常见格式 Atom，它的发布时间叫 updated、链接写在 link 标签的 href 属性里，两套标签名完全不同，遇到 Atom 就得按映射表换过来。第二关是时间对齐，中新网用的是 Thu, 08 Oct 2026 07:30:00 +0800 这种 RFC822 格式，不换算成 2026-10-08 07:30 就没法排序；第三关是跨源判重，不同媒体的链接肯定不同，但讲的可能是同一件事。这三关解决了，聚合才算真正做成。

1.5 聚合出来的表能回答什么问题

对齐、去重做完之后，这张表就不只是「一堆标题」了，它能回答很多实打实的问题：

• 覆盖度：同一件事到底有几家媒体在报，谁报得最早；
• 口径差异：同一份数据，财经媒体和科技媒体各挑了哪个角度；
• 更新节奏：某个频道一天更新多少条，什么时段更新最密；
• 线索发现：哪条资讯被多家同时选用，往往就是当天真正重要的信息。

这些问题用单家媒体都答不全，只有把多家对齐到一张表之后才看得清楚——这正是聚合的价值所在。

目标站点与交付产物

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

二、数据源与字段设计

数据源是几家媒体公开的订阅地址。我们先看示范站点——中新网 RSS 订阅中心的结构，再把各家字段对齐到同一套。

2.1 站点信息表

2.2 统一字段表（三家都要对齐到这套）

这一列示例值统一以同一条中新网资讯为例，方便横向对照；该条是构造出来的样本，「链接」与「条目编号」只演示格式，不必按址访问。换成你自己订阅源里的真实条目即可。

2.3 字段映射表：把各家的叫法归到一处

同一件事，不同的源叫法不一样。先把映射关系写成一张表，再交给 AI，它就不会把 Atom 的链接采成空值。

2.4 中新网 RSS 的频道结构

回到示范站点 https://www.chinanews.com.cn/rss/，它的订阅入口是按频道拆开的，常用的几个是：

• https://www.chinanews.com.cn/rss/china.xml 时政、finance.xml 财经、world.xml 国际、society.xml 社会、scroll-news.xml 即时新闻，以及文化、体育等频道；
• 每个频道是一份独立的 XML，头部 channel 里写着频道名与简介，下面挂着该频道最近的一批 item；
• 同一家媒体的多个频道，头部信息可以只取一次，item 逐条映射到统一字段——「一源多频道」正是订阅源最省事的地方。

三、零代码操作步骤

下面是在 WorkBuddy 里完成本案例的完整流程。你依然不写一行代码，但要负责说清标准、核对结果。

1. 先把订阅地址收集好。打开中新网 RSS 中心 https://www.chinanews.com.cn/rss/，挑「国内新闻」「财经新闻」两个频道，再把 36氪的 https://www.36kr.com/feed 一并贴进对话，说明「这是三家媒体的订阅源，先帮我确认每个源属于哪种格式」。
2. 要求先探格式。让它先分别打开三个源，告诉你每个源属于哪种格式、根标签是什么、里面有哪些字段、最近有多少条，先不要采数。
3. 给出统一字段表与映射表。直接把本篇 sec2 的两张表贴进对话，让它按这张表把三家数据取成同一套字段。
4. 先试一条源。让它只处理中新网，看看标题、链接、条目编号、时间、摘要是不是都取到了，再放开其余两家。
5. 处理时间格式。明确要求「发布时间统一成 2026-10-08 07:30 格式，能排序，能比较早晚」。
6. 做跨源去重。说「请先用条目编号去重，再按标题指纹找出不同来源但内容相同的条目，只保留最早发布的那一条，并在备注里写明还有哪几家也报了」。
7. 做增量更新。把上一次的结果文件发给它，说「只新增这次比上次多出来的条目，已有的不要重复」。
8. 导出并归档。导出成 Excel，文件名按「数据类型_日期」的约定，原始版和清洗版各留一份。

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

下面这段可以直接复制。它的关键是把三个源地址、统一字段、映射关系、去重口径一次说清。

请帮我做一个多源新闻聚合任务。

【订阅源】3 个订阅地址（请先逐个确认格式：RSS 还是 Atom）：
  源1（中国新闻网·时政新闻）：https://www.chinanews.com.cn/rss/china.xml
  源2（中国新闻网·财经新闻）：https://www.chinanews.com.cn/rss/finance.xml
  源3（36氪）：https://www.36kr.com/feed
  源索引页：https://www.chinanews.com.cn/rss/

【第一步：先探格式】
  先分别打开三个源，告诉我每个源的根标签是 rss 还是 feed（即 RSS 还是 Atom），
  最近有多少条，各有哪些字段（重点看有没有 guid / id、category、author）。
  先不要采集。

【第二步：按统一字段取数】
  统一字段按这个顺序：
  1. 来源媒体   2. 栏目   3. 标题   4. 链接（绝对地址）
  5. 条目编号（guid 或 Atom 的 id）
  6. 发布时间原文（原样保留）
  7. 发布时间（统一成 2026-10-08 07:30）
  8. 摘要（去掉 HTML 标签）   9. 作者（没有就留空）
  10. 源格式（RSS 2.0 / Atom）  11. 内容指纹（标题去标点后取哈希）
  12. 采集时间   13. 数据批次

  字段映射规则：
  - 标题 ← title
  - 链接 ← link（Atom 的地址在 link 标签的 href 属性里，别采空）
  - 条目编号 ← guid（RSS）或 id（Atom）
  - 发布时间原文 ← pubDate（RSS）或 updated（Atom）
  - 摘要 ← description（RSS）或 summary（Atom）
  - 作者 ← author（Atom 里嵌在 author 的 name 子标签）
  - 来源媒体 ← channel 或 feed 下的 title

【第三步：合并去重】
  - 三家结果合并成一张表
  - 先按「条目编号」去重，再按「内容指纹」找同稿多源
  - 重复的只留最早发布的一条，备注列写明「还有哪几家也报了」

【执行要求】每个请求之间间隔 1 秒以上，不要并发；先只处理源1给我确认，通过后再处理全部三个。

4.1 三条常用追问指令

第一版结果多半还会在细节上打折扣，下面三句随时准备追加。

追问一（修时间格式）：
源1的发布时间是 «Thu, 08 Oct 2026 07:30:00 +0800» 这种 RFC822 格式，
请全部转成 2026-10-08 07:30，统一后再按时间倒序排列。

追问二（加强判重）：
现在只按条目编号去重，漏掉了「同一事件、不同链接」的情况。
请改成按「标题指纹 + 相邻发布时间」来判重，
相似的只保留最早的一条，并在备注里列出重复来源。

追问三（做增量）：
这是我上次采的结果文件，请对比这次的新数据，
只把「上次之后新增的条目」追加进来，已有的不要重复，
最后告诉我新增了几条。

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

三家合并之后，先看下面这张结果样例（节选，示例数据）：

5.1 五项核对，一样一样过

• 条数：三家加起来是不是接近预期，有没有整源采空；
• 字段：链接能不能点开，条目编号有没有缺失，摘要有没有残留 HTML 标签；
• 时间：格式是否统一，有没有漏网的 RFC822 原文没换算；
• 重复：有没有同一件事出现好几行，条目编号去重与指纹判重各生效了没有；
• 来源：来源媒体列是不是每一条都有值，三家有没有混在一起。

5.2 一段清洗指令，直接复制

请对合并后的结果做以下清洗：
① 去掉每列的首尾空格与换行符；
② 发布时间统一成 YYYY-MM-DD HH:MM，并新增一列「发布日」只保留日期；
③ 摘要列去掉所有 HTML 标签与多余空白；
④ 先按条目编号去重，再按「标题指纹 + 发布时间相差不超过 6 小时」判重，
   重复的只保留最早一条，备注列写明重复来源；
⑤ 增加一列「数据批次」，统一填 20261008_09，方便以后多次采集对齐。

5.3 保存与增量约定

news_agg_20261008_09.xlsx        ← 本次原始汇总（保留）
news_agg_20261008_09_clean.xlsx  ← 清洗并去重后的版本
news_agg_all.xlsx                ← 累积总表：每次新增的都追加进来
news_agg_log.txt                 ← 日志：时间、各源条数、去重条数、新增条数

5.4 去重前后要留个账

去重做了多少、删了哪些，最好在日志里记一笔，方便回头核对：

六、常见问题与合规红线

6.1 五个高频问题

6.2 三条合规要点

1. 订阅源是网站公开提供给人订阅的，正常读取属于作者期待的使用方式，但仍要控制频率、不要高频轮询。
2. 只摘要与标题用于课程分析，不要把多家正文整篇搬走再发布；确需引用时注明来源与链接。
3. 聚合不改变著作权归属。表里集齐了十家的标题，也不代表这些内容归你所有。

再补一条实操经验：合并之后，「来源媒体」这一列要一直留着。它是后面所有「哪家报得多、哪家报得早」类分析的分组依据；一旦为了让表「看起来整齐」把它删掉，这张聚合表就退化成了普通清单，也就失去了多源的意义。

七、随堂自测（10 题）

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