AI日报自动化系统实战：从信息采集到智能摘要的完整链路

1. 当日报变成一种自动化基础设施做内容的人都有一个共同的痛点信息过载。每天醒来光是扫一遍行业动态、技术更新、产品发布、社区讨论就得花掉一两个小时而且大部分信息是噪音。我身边不少同行都有过类似经历——收藏夹里躺着几百篇稍后读结果再也没打开过。真正有价值的信息往往是在某个群里被人随手转发时才被注意到这种被动获取的方式既不系统也不可靠。AI 日报这个项目本质上要解决的就是这个问题把每天散落在各处的信息经过筛选、归类、摘要最终以一份结构化的日报形式呈现出来。它不是一个简单的爬虫脚本而是一套从信息采集、去重、打分、摘要生成到最终排版输出的完整流水线。适合谁来参考如果你正在做内容聚合类产品、想搭建个人知识管理系统、或者单纯想给自己做一个每天自动推送的行业简报这套思路都能直接复用。我前后迭代过三版类似的系统第一版用纯脚本硬编码第二版引入了消息队列做异步处理第三版才把摘要生成这一环交给大模型来做。每一版踩的坑都不一样但核心逻辑始终没变采集要广、过滤要狠、摘要要准、输出要稳。下面我把这套系统的设计思路、关键实现和实际运行中遇到的问题完整地拆开讲一遍。2. 信息源的分层设计与采集策略2.1 为什么不能把所有源一视同仁刚开始做的时候我犯了一个典型错误把所有信息源放在同一个优先级队列里统一抓取、统一处理。结果就是某些更新频率极高的源比如某些社区的热帖列表每天产生上千条数据把真正重要的官方公告、技术博客更新淹没掉了。后来我意识到信息源必须分层。我的做法是把源分成三层核心层更新频率低但价值极高比如官方文档的更新日志、重要项目的 Release Notes、行业标准的修订公告。这类源每天可能只有几条更新但每一条都值得完整阅读。常规层技术博客、行业媒体的日常更新、社区精选内容。这类源数量多、更新稳定需要做摘要和筛选。补充层社交媒体讨论、论坛热帖、问答社区的高赞回答。这类源噪音最大但偶尔能发现一些非正式渠道流出的有价值信息。分层之后采集策略也随之不同。核心层用全量抓取不做任何过滤常规层做关键词匹配和热度排序补充层则只保留互动量超过阈值的条目。2.2 采集频率与反爬的平衡采集频率的设置是个技术活。设得太密容易被目标站点限流甚至封禁设得太疏日报的时效性就没了。我实测下来比较稳妥的方案是源类型采集间隔单次请求上限失败重试策略核心层每 2 小时50 条立即重试 1 次间隔 30 秒常规层每 1 小时100 条延迟 5 分钟重试最多 2 次补充层每 30 分钟200 条延迟 15 分钟重试最多 1 次这里有个经验不要用固定的 User-Agent。我早期图省事所有请求都用同一个 UA结果第三天就被某个站点识别出来了。后来改成从一个 UA 池里随机选取并且配合请求间隔的随机抖动比如设定 1 秒间隔实际在 0.7 到 1.5 秒之间随机稳定性明显提升。另外对于返回 JSON 的接口尽量直接调接口而不是解析 HTML 页面。HTML 结构一变解析规则就得重写而接口相对稳定得多。如果只能用 HTML 解析建议用 CSS 选择器而不是 XPath前者对页面微调的容忍度更高。2.3 去重的三个层次去重这件事看起来简单做起来坑很多。我把它分成三个层次来处理第一层是 URL 去重。这是最基础的把 URL 规范化之后去掉追踪参数、统一协议头、处理末尾斜杠做哈希比对。但光靠这个不够因为同一篇文章可能通过不同 URL 访问到。第二层是标题相似度去重。用编辑距离或者 SimHash 做近似匹配阈值设在 0.85 左右比较合适。太低会误杀太高会漏掉。我试过用 0.9结果同一事件的不同报道全被当成重复的删掉了日报内容变得很单薄。第三层是内容指纹去重。对正文做分词后取关键词集合用 Jaccard 相似度判断。这一层主要处理那些标题不同但内容高度雷同的情况比如通稿。注意去重阈值不要设得太激进。宁可多保留几条相似内容也不要误删掉角度不同的报道。我吃过这个亏有次把一篇深度分析和一篇快讯当成重复的合并了结果日报里只剩一个干巴巴的结论。3. 从原始信息到可读摘要的加工链路3.1 打分模型什么内容值得进日报采集回来的原始数据可能有一大半是不值得放进日报的。怎么判断一条内容的价值我设计了一个多因子打分模型每个因子权重不同最终得分超过阈值的才进入摘要环节。打分因子包括来源权重核心层 1.0常规层 0.7补充层 0.4时效性发布时间在 6 小时内的得满分超过 24 小时的得分衰减到 0.3互动热度评论数、点赞数、转发数的加权和做归一化处理关键词命中命中预设关键词列表的加分命中多个的累加内容长度太短少于 100 字的降权太长的也不加分适中最好这套打分模型跑下来每天从几千条原始数据里能筛出 50 到 80 条候选内容再经过人工规则微调最终进入日报的大概 20 到 30 条。这个量级刚好既不会让读者觉得信息量不足也不会造成阅读负担。3.2 摘要生成大模型用在哪一步最合适摘要生成是整个链路里最考验效果的一环。我试过三种方案方案一抽取式摘要。用 TextRank 或者类似的算法从原文里挑出最重要的几个句子拼起来。优点是快、不依赖外部服务缺点是读起来很生硬句子之间的衔接不自然。方案二模板式摘要。针对不同类型的源预设不同的模板把关键字段填进去。比如技术博客用标题 核心观点 关键数据的模板。优点是可控性强缺点是灵活性差遇到模板覆盖不到的内容就抓瞎。方案三生成式摘要。把原文交给大模型让它用一两句话概括核心内容。优点是读起来自然、信息密度高缺点是有时候会幻觉编造原文里没有的信息。我最终采用的是方案三为主、方案一为辅的混合策略。具体来说先用大模型生成摘要然后用抽取式摘要做交叉验证——如果生成的内容里出现了原文中不存在的关键实体比如人名、产品名、数字就标记为可疑降级使用抽取式摘要的结果。调用大模型的时候Prompt 的设计很关键。我用的模板大致是这样的prompt_template 请用不超过 80 个字概括以下内容的核心信息。 要求 1. 保留关键数据和技术名词 2. 不要添加原文中没有的信息 3. 如果原文是英文用中文概括 4. 直接输出概括结果不要加任何前缀 原文 {content} 这里有几个细节值得说。第一字数限制要明确不然模型可能生成一大段。第二明确禁止添加原文没有的信息这能显著降低幻觉率。第三要求直接输出结果避免模型加上这段内容主要讲了……之类的废话前缀。3.3 分类与标签让日报有结构摘要生成之后还需要给每条内容打上分类标签。我的分类体系是两级结构一级分类技术更新、产品发布、行业动态、观点讨论、工具推荐二级分类在一级分类下再细分比如技术更新下面分前端、后端、数据库、运维等分类的实现方式早期我用的是关键词规则匹配后来发现准确率不够就改成了用大模型做零样本分类。把分类体系和每个类别的描述一起放进 Prompt让模型判断每条内容属于哪个类别。实测准确率能到 85% 以上剩下的 15% 通过人工规则兜底。标签体系还有一个作用控制日报的版面平衡。如果某天的技术更新特别多产品发布特别少日报读起来就会偏科。我会在最终排版前做一个类别配额的检查确保每个大类至少有 2 条内容最多不超过 8 条。4. 日报的排版输出与分发机制4.1 排版模板的设计取舍日报最终是要给人看的排版直接决定了阅读体验。我试过纯文本、Markdown、HTML 邮件三种格式最后选择了 Markdown 为主、HTML 邮件为辅的方案。Markdown 的好处是通用性强可以很方便地转换成其他格式而且在不同平台上渲染效果一致。我的日报模板大致是这样的结构# AI 日报日期 ## 今日要闻 3-5 条最重要的内容每条包含标题、摘要、来源链接 ## 技术更新 按二级分类分组每组下列出相关条目 ## 产品动态 新产品发布、版本更新、功能变更 ## 观点与讨论 值得关注的行业观点、技术讨论 ## 工具推荐 新发现的实用工具或资源每条内容的格式统一为加粗标题 摘要 来源标注。来源标注我坚持保留一方面是对原作者的尊重另一方面也方便读者追溯原文。4.2 分发渠道的选择日报做出来得送到读者手里。我目前用的是三个渠道并行邮件订阅最正式的分发方式适合深度读者。用定时任务在每天早上 8 点准时发送。即时通讯群组适合快速触达把日报的核心内容精简成几条消息推送。静态页面生成一个每日更新的网页方便存档和检索。这三个渠道的内容不是简单复制的。邮件版最完整群组版只推送今日要闻网页版则保留全部历史记录并支持搜索。这样做的好处是不同场景下的读者都能找到适合自己的消费方式。4.3 定时任务的可靠性保障整个流水线是靠定时任务驱动的所以任务的可靠性至关重要。我踩过的坑包括任务执行超时导致后续任务堆积、某个环节失败导致整条链路中断、服务器重启后任务丢失等。现在的做法是每个环节独立成任务环节之间通过消息队列传递数据避免单点阻塞。每个任务都有超时设置超时后自动重试重试次数用完后发送告警。任务状态持久化到数据库服务器重启后能从上次中断的地方继续。每天早上日报发送前有一个健康检查任务确认所有环节的数据都正常否则发送告警而不是发送一份残缺的日报。提示定时任务的时间设置要留足缓冲。我一开始把采集和摘要生成安排在同一个时间窗口结果采集偶尔延迟摘要生成就拿不到完整数据。后来改成采集提前 2 小时开始摘要生成在发送前 1 小时执行就再没出现过数据不全的问题。5. 运行三个月后暴露的真实问题5.1 摘要质量的波动与人工兜底系统跑了一个月之后我发现摘要质量并不稳定。有些天的摘要读起来很顺有些天则明显感觉不对劲——要么是信息遗漏要么是表述别扭。排查下来原因主要有两个一是原文质量参差不齐。有些源的文章本身逻辑就混乱模型概括出来的东西自然也好不到哪去。二是模型输出的随机性。同样的输入不同时间调用可能得到不同的输出偶尔会碰到质量较差的版本。我的应对策略是引入人工抽检机制。每天日报发送前我会随机抽取 5 条摘要快速过一遍如果发现明显问题就手动修正或者替换成抽取式摘要的结果。这个动作只花几分钟但能显著提升日报的整体质量。另外我建了一个问题摘要的记录表把每次人工修正的案例记下来定期回顾看看有没有规律性的问题可以优化。5.2 信息源的失效与动态维护信息源不是一成不变的。有些站点改版了原来的解析规则失效有些接口关闭了需要找替代方案还有些源的内容质量下降不值得继续采集。我现在的做法是给每个源加一个健康度指标综合考量采集成功率、内容更新频率、摘要质量评分。健康度低于阈值的源会被自动标记进入观察名单。连续一周健康度不达标的就暂时停用等找到替代方案或者确认恢复后再启用。这套机制帮我省了不少事。以前是等到日报内容明显变少才发现某个源挂了现在系统会提前告警我有充足的时间处理。5.3 成本控制大模型调用不是免费的生成式摘要虽然效果好但调用大模型是有成本的。日报每天处理 50 到 80 条候选内容每条都要调用一次模型一个月下来费用不算低。我做了几件事来控制成本缓存机制对相同或高度相似的内容直接复用之前的摘要结果不重复调用。分级调用核心层的内容用高质量模型常规层和补充层用成本更低的模型。批量处理把多条内容合并成一个请求发给模型减少请求次数。不过要注意批量太大可能影响单条摘要的质量我实测下来一次处理 5 到 8 条比较合适。这些优化做下来成本降低了大概 60%而日报质量几乎没有下降。6. 如果你也想搭一套从哪开始6.1 最小可行版本的功能边界如果你看完上面的内容想自己动手我的建议是先做一个最小可行版本不要一上来就追求大而全。最小版本只需要包含三个功能从 3 到 5 个核心源采集内容做基础的去重和关键词过滤生成一份简单的 Markdown 日报这个版本一两天就能搭起来跑通之后再逐步加入打分模型、摘要生成、分类标签这些进阶功能。我见过不少人一开始就设计了一套复杂的架构结果卡在某个环节迟迟跑不起来最后不了了之。6.2 技术选型的务实建议技术栈方面我的建议是用你最熟悉的语言和框架不要为了追求先进而选自己不熟的工具。这套系统的核心逻辑并不复杂用 Python 的 requests BeautifulSoup 能跑用 Node.js 的 axios cheerio 也能跑甚至用 Go 写也完全没问题。关键是快速跑通而不是炫技。数据库方面早期用 SQLite 就够了数据量大了再换 PostgreSQL 或 MySQL。消息队列如果不想引入 Redis 或 RabbitMQ用数据库表模拟一个简单的队列也能凑合。等系统稳定了再考虑替换成更专业的组件。6.3 持续迭代的节奏把控最后说一点关于迭代节奏的体会。这套系统我前后改了三个月但并不是每天都在改。我的节奏是每周固定花半天时间做优化其余时间让它自动跑。优化的时候优先解决那些每天都会遇到的问题比如某个源经常采集失败、某类摘要质量不稳定。那些偶尔出现的问题先记下来攒到一起再处理。这样做的好处是系统在持续变好但不会占用我太多精力。毕竟日报是给人看的内容质量才是核心系统本身只是工具。工具够用就行不必追求完美。我在实际运行中发现最有价值的改进往往不是技术层面的而是对什么内容值得推荐这个判断的不断校准。这个判断力只能靠日复一日的观察和调整来积累没有捷径。