从信息洪流到每日必读：AI日报自动化流水线实战

1. 一份 AI 日报的诞生：从信息洪流到每日必读

每天早上七点，我的手机闹钟还没响，浏览器里已经躺着十几个标签页——arXiv 的新论文、几个头部实验室的博客更新、GitHub Trending、还有一堆行业群里的截图和链接。三年前我开始做一件事：把这些碎片整理成一份能让人十分钟读完的 AI 日报。到今天，这份日报已经迭代了上千期，2026 年 9 月 25 日这一期，正好是我重新设计整个流水线之后的第一个完整版本。

很多人以为做日报就是"复制粘贴加个标题"，真上手才知道，信息筛选、去重、可信度判断、摘要压缩、排版分发，每一步都是坑。这份日报解决的核心问题很具体：在信息过载的环境里，用最低的阅读成本，让读者抓住当天真正值得关注的 AI 动态。它适合三类人参考——想自己搭一套信息聚合流程的开发者、需要每天跟踪行业但没时间刷全网的从业者、以及想把"日报"这种内容形态做成产品的独立创作者。

我做的不是"新闻搬运"，而是一条从采集到分发的完整内容流水线。下面我把这套东西拆开讲，包括为什么这么设计、每个环节怎么落地、踩过哪些坑，以及 9 月 25 日这一期具体是怎么跑出来的。你照着做，大概率能搭出一份属于自己的日报，哪怕不做日报，这套信息处理方法也能直接用在你的日常工作中。

2. 整体设计与思路拆解：为什么是"流水线"而不是"手工活"

2.1 日报的本质是一条内容加工流水线

刚开始做日报那会儿，我全靠手工：早上刷一遍信息源，看到有意思的就复制到文档里，手动改改措辞，排个版发出去。前两周还行，到第三周就崩了——漏掉重要消息、重复内容、格式不统一，最要命的是每天要花两个多小时，根本坚持不下去。

后来我想明白了，日报这东西的本质不是"写作"，而是"加工"。原料是全网的信息，成品是一份结构化的简报，中间需要的是采集、清洗、筛选、摘要、排版、分发六个环节。既然是加工，那就该用流水线的思路来做：每个环节职责单一，环节之间用标准化的数据格式衔接，任何一个环节出问题都能单独替换。

这个思路带来的最大好处是可维护。比如某天某个信息源挂了，我只需要换掉采集环节里的一个适配器，后面的流程完全不受影响。再比如我想调整摘要风格，只改摘要环节的提示词就行，不用动其他部分。

2.2 为什么选择"半自动"而不是"全自动"

这里有个关键取舍：全自动流水线听起来很酷，但实际做下来，纯自动的日报质量很难看。原因很简单——AI 摘要会漏掉上下文，自动去重会误杀相关但不同的内容，自动排序会把真正重要的东西埋掉。

我最后选的是半自动方案：采集、清洗、初步摘要全自动，但最终的筛选和定稿保留人工介入。具体来说，机器负责把 200 条原始信息压缩成 30 条候选，我再花 15 分钟从中挑出 8 到 10 条，调整措辞和排序。这样既保证了效率（整个流程 30 分钟内跑完），又保证了质量（人工把关最后一道）。

提示：不要一上来就追求全自动。先把人工环节跑通，记录下你每天做判断的标准，等标准稳定了再逐步自动化。我见过太多人一上来就写复杂的工作流，结果调了两周发现还不如手工快。

2.3 信息源的选型逻辑：少而精，分层级

信息源的选择直接决定日报的质量上限。我的原则是分层级、控数量，而不是越多越好。目前我维护的信息源分三层：

核心层是必须每天看的，扩展层用来补充视角，补充层则是"有精力就看"。这个分层的好处是，即使某天时间紧张，只看核心层也能保证日报不空。

选信息源有个反直觉的经验：宁可少选几个高质量源，也不要贪多。我早期订阅了 50 多个源，结果每天光筛选就累得够呛，而且大量内容重复。砍到 20 个以内之后，效率反而上去了。

2.4 数据格式的统一：一切以 JSON 为中心

流水线能跑起来的前提是环节之间能"对话"。我定的规矩很简单：所有环节的输入输出都是 JSON。采集环节输出原始条目数组，清洗环节输出标准化条目，摘要环节输出带摘要的条目，排版环节消费最终条目。

一条标准化条目的结构大概是这样：

{ "id": "unique-hash", "title": "条目标题", "source": "来源名称", "url": "原始链接", "published_at": "2026-09-25T08:30:00Z", "raw_content": "原始正文或摘要", "summary": "加工后的摘要", "category": "模型/应用/开源/政策", "importance": 3, "tags": ["标签1", "标签2"] }

这个结构看起来简单，但它是整个流水线的骨架。id用于去重，importance用于排序，category用于分组，tags用于检索。字段一旦定下来，后面所有环节都围绕它工作，改起来也方便。

3. 核心细节解析与实操要点：每个环节的坑与技巧

3.1 采集环节：稳定比快更重要

采集环节最容易犯的错是追求"实时"。我早期用轮询的方式，每 5 分钟抓一次，结果经常被目标站点限流，还浪费资源。后来改成定时批量采集，每天早上六点跑一次，把所有源一次性抓完，稳定得多。

采集的技术选型上，我推荐两条路线：

• RSS/Atom 优先：如果目标站点提供 RSS，直接用。这是最稳定的方式，解析简单，不容易被反爬。
• HTML 解析兜底：没有 RSS 的站点，用解析库提取。这里要注意，选择器要写得"宽容"一点，别依赖太具体的 DOM 路径，否则站点一改版就全挂。

采集环节的三个实操要点：

1. 设置合理的超时和重试。单个源超时 10 秒，失败重试 2 次，重试间隔递增。别让一个挂掉的源拖垮整个流程。
2. 记录采集日志。每个源抓了多少条、耗时多少、有没有报错，都记下来。出问题时能快速定位。
3. 保存原始数据。抓到的原始内容先存一份，别急着清洗。万一后面发现清洗逻辑有问题，还能回溯。

注意：采集频率要克制。很多站点对高频访问不友好，一天抓一两次足够了。日报本来就是"日"报，没必要做到分钟级。

3.2 清洗与去重：日报质量的分水岭

清洗环节决定了日报的"干净程度"。这一步做不好，读者会看到大量重复、残缺、格式混乱的内容。我的清洗流程分四步：

第一步，字段标准化。把不同来源的字段映射到统一结构。比如有的源用pubDate，有的用published，统一成published_at；有的源时间是本地时间，统一转成 UTC。

第二步，正文提取。很多源的 RSS 只给摘要，需要抓取原文提取正文。这里推荐用成熟的正文提取库，别自己写正则，准确率差太多。

第三步，去重。去重是清洗环节的核心。我用的策略是标题相似度 + URL 归一化双重判断：

• URL 归一化：去掉追踪参数、统一协议和域名大小写，相同 URL 直接判重。
• 标题相似度：用编辑距离或词向量算相似度，超过阈值（我设的 0.85）判为重复。

去重有个坑：同一事件的不同报道不该被当成重复。比如两家媒体都报道了同一个模型发布，标题不同、角度不同，这时候应该保留信息量更大的那条，而不是简单删掉。我的做法是，去重时保留"来源权重高 + 正文长"的那条。

第四步，质量过滤。过滤掉太短的内容（少于 100 字）、纯广告、以及明显是标题党的条目。

3.3 摘要生成：提示词设计比模型选择更重要

摘要环节是很多人最关心的部分。我的经验是：模型选择的影响远小于提示词设计。同一个模型，提示词写得好和写得差，输出质量能差一个档次。

我用的摘要提示词核心要素有四个：

1. 角色设定：明确告诉模型"你是一个 AI 行业分析师，为专业读者写简报"。
2. 输出结构：规定摘要必须包含"发生了什么 + 为什么重要 + 关键数据"三部分。
3. 长度约束：每条摘要控制在 80 到 120 字，太短信息不足，太长读者没耐心。
4. 风格约束：要求客观、具体、不用形容词堆砌，禁止"震撼""颠覆"这类词。

一个实际用的提示词模板大概长这样：

你是一名 AI 行业分析师，为专业读者撰写每日简报。 请将以下内容压缩成 80-120 字的摘要，包含三部分： 1. 核心事实（谁做了什么） 2. 关键数据或技术细节 3. 对行业的影响或意义 要求：客观具体，不使用夸张词汇，不添加原文没有的信息。 原文：{content}

摘要环节的实操心得：

• 批量处理要控制并发。一次发太多请求容易被限流，我一般控制在 5 到 10 个并发。
• 保留原文对照。摘要生成后，我会把原文和摘要并排存着，方便人工复核时快速判断。
• 对长文分段摘要再合并。超过模型上下文长度的内容，先分段摘要，再合并成一条，效果比直接截断好。

3.4 分类与排序：让读者一眼看到重点

分类和排序决定了日报的"可读性"。我的分类体系是固定的四类：模型进展、应用落地、开源动态、行业政策。每类下面按重要性排序。

重要性打分我用的是规则 + 模型结合的方式：

• 规则部分：来源权重（核心层 +2）、是否含关键实体（如知名机构 +1）、是否有具体数据（+1）。
• 模型部分：让模型判断"这条内容对行业的影响程度"，输出 1 到 5 分。

两者加权得到最终分数。这个打分不追求绝对准确，只要能保证"重要的排在前面"就够了。

提示：排序规则要定期回顾。我每个月会看一遍历史日报，检查有没有"当时排前面但事后看并不重要"的条目，据此调整权重。

4. 实操过程与核心环节实现：9 月 25 日这一期是怎么跑出来的

4.1 环境准备与依赖清单

先说环境。整套流水线跑在一台普通的云服务器上，配置不高，2 核 4G 足够。依赖清单如下：

# 核心依赖 python>=3.10 requests # HTTP 请求 feedparser # RSS 解析 beautifulsoup4 # HTML 解析 readability-lxml # 正文提取 scikit-learn # 相似度计算 openai # 模型调用（或任意兼容接口） jinja2 # 模板渲染

安装就一行命令：

pip install requests feedparser beautifulsoup4 readability-lxml scikit-learn openai jinja2

目录结构我习惯这样组织：

ai-daily/ ├── config/ │ └── sources.yaml # 信息源配置 ├── data/ │ ├── raw/ # 原始采集数据 │ └── processed/ # 清洗后数据 ├── scripts/ │ ├── collect.py # 采集 │ ├── clean.py # 清洗去重 │ ├── summarize.py # 摘要 │ └── render.py # 排版 ├── templates/ │ └── daily.md.j2 # 日报模板 └── output/ └── 2026-09-25.md # 最终日报

这个结构的好处是每个环节独立成脚本，可以单独运行、单独调试。

4.2 采集脚本的关键实现

采集脚本的核心逻辑是读配置、遍历源、抓取、存原始数据。关键代码片段：

import feedparser import requests from datetime import datetime, timezone def collect_rss(source): feed = feedparser.parse(source["url"]) items = [] for entry in feed.entries: items.append({ "title": entry.get("title", ""), "url": entry.get("link", ""), "published_at": entry.get("published", ""), "raw_content": entry.get("summary", ""), "source": source["name"], }) return items def collect_html(source): resp = requests.get(source["url"], timeout=10) resp.raise_for_status() # 用配置里的选择器提取 soup = BeautifulSoup(resp.text, "html.parser") items = [] for node in soup.select(source["selector"]): items.append({ "title": node.select_one(source["title_sel"]).get_text(strip=True), "url": node.select_one("a")["href"], "raw_content": node.get_text(strip=True), "source": source["name"], }) return items

采集时我加了两个保护：超时设置和异常捕获。单个源失败不影响其他源，失败的源记入日志，第二天再试。

9 月 25 日这一期，采集环节一共跑了 22 个源，成功 20 个，失败 2 个（一个超时，一个改版导致选择器失效）。总共抓到 187 条原始条目。

4.3 清洗去重的参数计算

清洗环节最关键的是去重阈值。这个阈值怎么定？我的方法是用历史数据做实验。

具体做法：取过去一周的条目，人工标注哪些是重复的，然后跑不同阈值下的去重结果，算准确率和召回率。我试过 0.7、0.8、0.85、0.9 四个值，结果如下：

我选 0.85，是因为宁可漏掉重复，也不要误杀。重复内容读者能自己跳过，但误杀会让读者错过信息。

9 月 25 日这一期，187 条原始条目经过清洗去重后，剩下 94 条。去掉了 93 条，其中大部分是同一事件的重复报道。

4.4 摘要生成的批量处理

摘要环节我用的是批量处理，一次发 10 条，控制并发。核心代码：

import asyncio from openai import AsyncOpenAI client = AsyncOpenAI() async def summarize_one(item): prompt = f"""你是一名 AI 行业分析师，为专业读者撰写每日简报。 请将以下内容压缩成 80-120 字的摘要，包含三部分： 1. 核心事实（谁做了什么） 2. 关键数据或技术细节 3. 对行业的影响或意义 要求：客观具体，不使用夸张词汇，不添加原文没有的信息。 原文：{item['raw_content'][:2000]}""" resp = await client.chat.completions.create( model="gpt-4o-mini", messages=[{"role": "user", "content": prompt}], temperature=0.3, ) item["summary"] = resp.choices[0].message.content.strip() return item async def summarize_batch(items, batch_size=10): results = [] for i in range(0, len(items), batch_size): batch = items[i:i+batch_size] results.extend(await asyncio.gather(*[summarize_one(it) for it in batch])) await asyncio.sleep(1) # 控制节奏 return results

这里有几个参数值得说：

• temperature 设 0.3：摘要要稳定，不需要创造性，低温度更合适。
• 原文截断到 2000 字：太长的原文直接截断，比分段摘要再合并简单，效果也够用。
• 批次间 sleep 1 秒：避免触发限流。

9 月 25 日这一期，94 条内容全部生成摘要，耗时约 4 分钟。

4.5 人工定稿与排版

机器跑完之后，进入人工环节。我打开处理好的数据，按重要性排序，从 94 条里挑出 10 条作为当日重点，其余作为"其他动态"简列。

挑选的标准是三条：

1. 是否有实质进展：纯观点、纯预测的降权。
2. 是否影响面广：只影响小众的降权。
3. 是否有可验证的信息：只有传闻没有实锤的降权。

9 月 25 日这一期，最终定稿 10 条重点 + 12 条简讯。排版用 Jinja2 模板渲染，模板大概长这样：

# AI 日报（{{ date }}） ## 今日重点 {% for item in highlights %} ### {{ loop.index }}. {{ item.title }} {{ item.summary }} 来源：{{ item.source }} {% endfor %} ## 其他动态 {% for item in briefs %} - {{ item.title }}（{{ item.source }}） {% endfor %}

排版环节的实操心得：模板要留"手动调整"的口子。我经常在渲染后手动改几条的措辞，所以模板不要写得太死，留出可编辑的空间。

5. 常见问题与排查技巧实录

5.1 采集失败：从日志里找线索

采集失败是最常见的问题。我的排查顺序是：

1. 看日志：每个源的采集结果都记了日志，先看是超时、403、还是解析失败。
2. 手动访问：用浏览器打开目标 URL，确认站点是否正常。
3. 检查选择器：如果是解析失败，多半是站点改版了，用开发者工具重新找选择器。

常见问题速查表：

注意：遇到 403 不要硬刚。降低频率、加合理的 User-Agent 通常能解决。如果站点明确不欢迎抓取，就换源，别较劲。

5.2 摘要质量差：先查提示词，再查模型

摘要质量差的表现有几种：太短、太长、跑题、加戏。排查顺序：

• 太短或太长：检查提示词里的长度约束是否明确。我一般会给出具体字数范围，而不是"简短一点"。
• 跑题：检查原文是否被正确传入。有时候正文提取失败，传进去的是导航栏文字，摘要自然跑题。
• 加戏：模型添加了原文没有的信息。这时候要降低 temperature，并在提示词里强调"不添加原文没有的信息"。

我踩过的一个坑：早期提示词写"请总结以下内容"，模型经常输出"这篇文章介绍了……"这种元描述。后来改成"请将以下内容压缩成摘要，直接输出摘要内容，不要有'这篇文章'之类的引导语"，问题就解决了。

5.3 去重误杀：宁可漏杀不可错杀

去重误杀是让人最难受的问题——明明是不同的内容，被当成重复删掉了。我的应对策略：

• 提高阈值：从 0.8 提到 0.85，减少误杀。
• 加白名单：对特定来源或特定关键词的条目，跳过去重。
• 人工复核：去重结果保留一份"被删列表"，人工抽查。

有一次我把两家媒体对同一模型的不同角度报道误判为重复，删掉了其中一条，结果那条恰好包含了关键的技术参数。从那以后我就加了"被删列表"复核机制。

5.4 流水线跑得慢：定位瓶颈

整套流水线正常 30 分钟内跑完。如果某天特别慢，通常是这几个原因：

• 某个源响应慢：拖累了整体。解决方法是给每个源设独立超时。
• 摘要并发太高被限流：降低并发，增加间隔。
• 数据量突然增大：比如某天有重大事件，条目数翻倍。这时候可以临时提高筛选阈值，减少进入摘要环节的数量。

我一般会在每个环节记录耗时，跑完之后看一眼哪个环节最慢，针对性优化。

5.5 内容同质化：如何保持日报的独特性

做久了会发现，日报内容越来越同质化——大家都在报同样的东西。我的应对方法有三个：

1. 加自己的判断：每条重点后面加一句"我的看法"，哪怕只有一句话，也能让日报有辨识度。
2. 挖掘边缘信号：核心层的信息大家都报，但补充层的小众讨论往往只有我在跟。
3. 做纵向对比：把当天的事件和历史联系起来，比如"这是某机构今年第三次发布类似成果"，这种上下文是别人没有的。

提示：日报的价值不在于"全"，而在于"选"和"评"。同样的信息，你的筛选标准和点评角度才是核心竞争力。

6. 我个人的一些实操体会

做这份日报到现在，最大的体会是：工具和流程都是次要的，判断力才是核心。流水线能帮你省时间，但"哪条重要、哪条该删、哪条该怎么写"这些判断，机器替代不了。

另一个体会是别追求完美。我早期总想把每条摘要都打磨到极致，结果每天花三四个小时，坚持不下去。后来想通了，日报是"日"报，稳定输出比单期质量更重要。现在我的标准是"80 分就发"，反而坚持了上千期。

最后分享一个小技巧：建立自己的"事件库"。每次遇到重大事件，记一笔——时间、主体、关键数据。时间长了，这个库就成了你做纵向对比的素材来源，也是日报独特性的来源。9 月 25 日这一期里有一条"某开源项目 star 数破十万"，我就是翻了事件库才发现，这个项目从发布到破十万只用了四个月，这个对比一加进去，条目的信息量立刻上去了。

这套流水线后续还能扩展的方向不少，比如加一个"周报汇总"环节，把一周的重点自动聚合；或者加一个"主题追踪"，对特定技术方向做持续跟踪。但那是下一步的事了，眼下先把每天的日报稳定跑好。