1. 从一条资讯流说起我为什么要做这个AI资讯聚合项目每天早上七点半我习惯性地打开几个固定的信息源扫一遍过去24小时内全球AI领域发生了什么。这个习惯保持了两年多直到今年3月初我意识到一个问题信息源太多重复率太高真正有价值的技术进展反而被大量融资新闻和产品发布稿淹没了。3月28日这天尤其典型我花了将近四十分钟才把当天值得关注的内容筛出来其中大部分时间浪费在了同质化内容的交叉验证上。于是我决定动手做一个轻量级的AI技术资讯聚合与筛选工具核心目标很简单给定一个日期比如3月28日自动抓取多个公开信息源去重、分类、按技术价值排序最终输出一份可以直接阅读的摘要。这个项目不涉及任何敏感数据源全部基于公开可访问的技术博客、学术预印本平台和开发者社区。这个项目适合几类人参考一是想系统跟踪AI技术进展但苦于信息过载的开发者二是需要快速了解某个时间段内技术动态的技术管理者三是对信息聚合、文本去重、自动摘要感兴趣想找一个完整练手项目的工程师。整个方案的技术栈不复杂Python为主核心依赖就是requests、BeautifulSoup、sentence-transformers和少量正则处理不需要GPU也能跑。我把它命名为“AI Daily Digest”下面把整个设计思路、实现细节和踩过的坑完整拆一遍。2. 整体架构设计与技术选型考量2.1 为什么选择“抓取-清洗-去重-排序-摘要”五段式流水线最开始我想过用现成的RSS聚合工具试了两个开源方案后发现两个致命问题一是它们对“技术价值”没有判断能力融资新闻和论文更新混在一起二是去重逻辑太粗糙同一篇论文被多个平台转载后会被当成多条独立内容。所以我决定自己写一套流水线把每个环节拆开方便单独调优。五段式流水线的设计逻辑是这样的抓取层负责从多个源拉取原始内容清洗层把HTML标签、广告、导航栏等噪音去掉去重层用语义相似度而非简单的标题匹配来识别重复内容排序层根据预设的技术价值权重打分摘要层对高分内容生成简短的中文摘要。每一层的输出都是下一层的输入层与层之间用JSON格式传递数据方便调试和替换。这个架构最大的好处是解耦。比如后来我发现某个源的抓取频率需要调整只需要改抓取层的配置不影响其他环节。再比如去重阈值需要微调也只动一个参数就行。2.2 信息源的选择标准与分类策略信息源的选择直接决定了最终输出的质量。我给自己定了三条标准第一内容必须是公开可访问的不需要登录或特殊权限第二更新频率稳定至少每周有更新第三内容以技术进展为主而非纯商业新闻。最终我选了四类源学术预印本平台关注最新论文标题和摘要、主流技术博客关注工程实践和工具更新、开发者社区的热门讨论关注实际问题和解决方案、以及少数几个专注AI技术分析的独立博客。每类源在排序时的权重不同学术类权重最高因为论文通常代表最新的技术突破社区讨论权重次之因为能反映实际落地中的问题商业新闻类权重最低只在没有其他内容时作为补充。这里有个细节值得展开我没有把任何需要特殊网络环境才能访问的源纳入进来全部选择公开可直连的站点。这不仅是合规要求也保证了工具的通用性——任何人拿到代码都能直接跑通。2.3 去重策略从标题匹配到语义向量去重是整个项目里最容易被低估的环节。一开始我用的是标题的编辑距离阈值设0.8结果发现同一篇论文在不同平台上的标题翻译差异很大编辑距离根本识别不出来。比如“Attention Is All You Need”和“注意力机制就是你所需要的一切”在编辑距离上差得很远但显然是同一篇论文。后来换成了语义向量方案用sentence-transformers把标题和摘要的前200字编码成768维向量计算余弦相似度超过0.85就判定为重复。这个方案的效果立竿见影重复内容的识别率从原来的60%左右提升到了95%以上。代价是编码过程需要一些时间但在CPU上跑几百条内容也就几十秒的事完全可以接受。注意语义去重的阈值需要根据你的信息源特点调整。如果源之间转载频繁阈值可以设低一点0.8如果源比较独立阈值可以设高一点0.9避免误杀。3. 核心模块的详细实现与关键参数3.1 抓取层如何稳定获取多源内容抓取层我用了requests加BeautifulSoup的组合没有上Scrapy是因为项目规模不大没必要引入重型框架。每个源对应一个抓取函数函数内部处理该源特有的分页逻辑和内容提取规则。关键参数有两个请求间隔和超时时间。请求间隔我设的是每个源之间至少3秒同一个源翻页时至少5秒。这个数值是实测出来的——再快的话某些源会返回429状态码再慢的话整体抓取时间会超过10分钟影响使用体验。超时时间设的是15秒超过就跳过该条记录日志后继续。import requests from bs4 import BeautifulSoup import time def fetch_source(url, headersNone, retries2): default_headers { User-Agent: Mozilla/5.0 (compatible; AIDigestBot/1.0) } if headers: default_headers.update(headers) for attempt in range(retries 1): try: resp requests.get(url, headersdefault_headers, timeout15) if resp.status_code 200: return BeautifulSoup(resp.text, html.parser) except requests.RequestException as e: print(f抓取失败: {url}, 错误: {e}) time.sleep(3) return None这里有个经验不要试图用多线程加速抓取。我试过用concurrent.futures开8个线程同时抓结果三个源直接封了IP恢复访问花了将近一个小时。后来改成单线程顺序抓取虽然慢一点但稳定性高得多。对于个人项目来说稳定比快更重要。3.2 清洗层从HTML到纯文本的标准化处理清洗层的任务是把抓取到的HTML转换成干净的文本。我定义了一个标准化的输出格式每条内容包含标题、正文摘要前500字、来源名称、发布时间、原文链接五个字段。清洗规则包括去掉script和style标签、去掉导航栏和页脚通过识别常见的class名如nav、footer、sidebar、把连续空白字符合并成一个空格、去掉常见的广告关键词所在段落。最后一步用了一个简单的规则如果某个段落的文本长度小于20字且包含“广告”“推广”“赞助”等词直接丢弃。def clean_html(soup): for tag in soup([script, style, nav, footer, aside]): tag.decompose() text_blocks [] for p in soup.find_all([p, h1, h2, h3, li]): text p.get_text(stripTrue) if len(text) 20 and any(kw in text for kw in [广告, 推广, 赞助]): continue if text: text_blocks.append(text) full_text .join(text_blocks) full_text .join(full_text.split()) return full_text清洗层最容易出问题的地方是编码。有些源返回的页面是GBK编码requests默认按UTF-8解码会出乱码。我的处理方式是在抓取时先检测resp.encoding如果是ISO-8859-1就手动设为GBK或UTF-8。这个坑我踩了两次才记住。3.3 去重层语义向量的计算与阈值调优去重层的核心代码如下用sentence-transformers的all-MiniLM-L6-v2模型这个模型体积小约80MB、速度快、效果够用。from sentence_transformers import SentenceTransformer from sklearn.metrics.pairwise import cosine_similarity import numpy as np model SentenceTransformer(all-MiniLM-L6-v2) def deduplicate(items, threshold0.85): texts [item[title] item[summary][:200] for item in items] embeddings model.encode(texts, show_progress_barFalse) keep_indices [] for i in range(len(embeddings)): is_duplicate False for j in keep_indices: sim cosine_similarity([embeddings[i]], [embeddings[j]])[0][0] if sim threshold: is_duplicate True break if not is_duplicate: keep_indices.append(i) return [items[i] for i in keep_indices]阈值0.85是经过多次测试确定的。我拿3月28日当天的数据做了人工标注发现0.85能正确识别出95%的重复内容同时误杀率不到3%。如果调到0.8误杀率会上升到8%左右一些相关但不重复的内容会被错误合并。提示如果你的信息源以中文为主建议把模型换成paraphrase-multilingual-MiniLM-L12-v2对中文语义的捕捉更准确。我实测下来中文内容的去重准确率能从82%提升到91%。3.4 排序层技术价值权重的设计逻辑排序层是我花心思最多的地方。最初我想用简单的关键词匹配来打分比如出现“突破”“首次”“新方法”就加分。但实际跑下来发现这种规则太容易被标题党利用而且无法区分“真正有技术含量的突破”和“PR稿里的自吹自擂”。后来我设计了一个多维度的打分体系每个维度0到10分加权求和。维度包括来源权威性学术源9分技术博客7分社区5分商业新闻3分、内容类型论文8分工程实践7分工具更新6分行业分析4分、技术深度通过检测是否包含具体的技术术语如“transformer”“diffusion”“RLHF”等来判断每出现一个加1分上限10分、时效性24小时内10分48小时内7分更早5分。权重分配是来源权威性0.3内容类型0.25技术深度0.3时效性0.15。这个权重是我根据自己阅读偏好调的你可以根据自己的需求改。比如你更关注工程落地可以把内容类型的权重调高更关注最新进展就把时效性权重调高。3.5 摘要层如何生成可读的中文摘要摘要层我没有用大模型因为调用成本高且速度慢。我用的是一种基于规则和TextRank结合的方案先提取正文中的关键句包含技术术语最多、位置靠前的句子然后用模板拼接成一段话。具体做法是对每条内容取清洗后的正文前1000字用jieba分词后计算每个句子的TF-IDF得分选取得分最高的两个句子加上标题和来源信息组成最终摘要。如果正文太短少于200字就直接用原文。import jieba.analyse def generate_summary(text, title, source): if len(text) 200: return f[{source}] {title}{text} sentences [s.strip() for s in text.split(。) if len(s.strip()) 10] if not sentences: return f[{source}] {title} keywords jieba.analyse.extract_tags(text, topK10) scored [] for sent in sentences: score sum(1 for kw in keywords if kw in sent) scored.append((score, sent)) scored.sort(reverseTrue) top_sents [s for _, s in scored[:2]] return f[{source}] {title}{。.join(top_sents)}。这个方案的好处是完全离线、速度快、不依赖任何外部API。缺点是摘要的流畅度不如大模型生成的但对于快速浏览来说完全够用。4. 完整实操流程从零跑通3月28日的数据4.1 环境准备与依赖安装整个项目只需要Python 3.8以上版本依赖包如下pip install requests beautifulsoup4 sentence-transformers scikit-learn jieba numpy如果你用的是国内网络环境sentence-transformers的模型下载可能会比较慢。我的做法是提前把模型下载到本地然后用本地路径加载model SentenceTransformer(/path/to/local/all-MiniLM-L6-v2)模型文件大约80MB下载一次就行后续都从本地加载速度很快。4.2 配置文件的设计与参数说明我把所有可调参数都放在一个config.yaml里方便修改。主要参数包括参数名默认值说明fetch_interval3不同源之间的抓取间隔秒page_interval5同一源翻页间隔秒timeout15单次请求超时时间秒dedup_threshold0.85语义去重相似度阈值weight_source0.3来源权威性权重weight_type0.25内容类型权重weight_depth0.3技术深度权重weight_freshness0.15时效性权重max_items30最终输出的最大条数这些参数没有绝对的最优值需要根据你的信息源特点和使用习惯来调。我的建议是先用默认值跑一遍看看输出结果是否符合预期然后有针对性地调整。4.3 运行流程与中间结果检查整个流程用一个main.py串起来运行命令就是python main.py --date 2025-03-28程序会依次执行抓取、清洗、去重、排序、摘要五个步骤每一步都会在控制台输出进度信息。比如抓取完成后会显示“共抓取到156条原始内容”清洗后显示“清洗后剩余142条”去重后显示“去重后剩余89条”排序后显示“排序完成取前30条”最后输出摘要。我强烈建议在第一次运行时把中间结果保存下来方便排查问题。我在代码里加了一个debug模式开启后会把每一步的中间数据存成JSON文件import json def save_debug(data, step_name): with open(fdebug_{step_name}.json, w, encodingutf-8) as f: json.dump(data, f, ensure_asciiFalse, indent2)这样如果最终输出有问题可以逐层往回查看是哪一步出了偏差。4.4 3月28日实际运行结果分析3月28日这天我跑了三次第一次因为某个源改版导致抓取失败修了选择器后第二次跑通第三次是调了去重阈值后的最终版本。最终输出30条内容其中学术论文12条、工程实践8条、工具更新6条、行业分析4条。从内容上看当天比较集中的技术方向包括多模态模型的效率优化、代码生成工具的评测方法、以及小样本场景下的微调策略。这些内容如果靠人工从原始信息流里筛选至少需要半小时而工具跑一遍只需要不到3分钟。有个细节值得注意去重环节过滤掉了23条重复内容其中大部分是同一篇论文被不同平台转载。如果没有去重最终输出里会有大量重复阅读体验会差很多。5. 常见问题与排查技巧实录5.1 抓取失败状态码与应对策略抓取环节最常见的问题就是各种非200状态码。我把遇到过的和应对方式整理成了表格状态码含义应对方式403禁止访问检查User-Agent换成常见浏览器标识429请求过频增加请求间隔降低抓取频率500服务器错误跳过该条记录日志下次重试503服务不可用等待几分钟后重试或暂时跳过该源301/302重定向requests默认跟随检查最终URL是否正确403是最常见的通常是因为User-Agent被识别为爬虫。我的做法是准备三个不同的User-Agent轮换使用并且每个源单独配置。429则需要耐心把间隔调到5秒以上基本就能解决。5.2 去重误杀如何判断阈值是否合理去重阈值设得太低会导致误杀把相关但不重复的内容合并掉。判断方法很简单随机抽10条被判定为重复的内容人工检查是否真的是同一件事。如果超过2条是误杀说明阈值太低了。我遇到过一种特殊情况两篇不同论文都在讨论“扩散模型在视频生成中的应用”标题和摘要的语义相似度达到了0.87被判定为重复。但实际上它们是不同的方法一篇侧重效率优化一篇侧重质量提升。这种情况就需要把阈值调到0.9以上或者引入更细粒度的判断逻辑比如检测是否包含不同的技术术语。5.3 排序偏差为什么有些好内容被排到了后面排序偏差通常来自两个原因一是权重设置不合理二是技术深度检测的关键词表不够全。我最初的关键词表只有20个词后来扩充到了80多个覆盖了主流的技术方向。扩充后一些原本被低估的内容排到了前面。另一个经验是不要完全依赖自动排序。我现在的做法是自动排序后人工快速扫一遍前50条手动调整几条明显被低估的内容。这个过程只需要一两分钟但能显著提升最终输出的质量。5.4 摘要质量如何让生成的摘要更可读规则摘要最大的问题是句子之间缺乏连贯性读起来像关键词堆砌。我的改进方法是在拼接句子时加一些连接词比如“该工作提出了”“实验表明”“具体来说”等让摘要读起来更像一段完整的话。另外如果两个句子的关键词重叠度太高就只保留一个避免重复。这个逻辑用简单的集合运算就能实现def merge_sentences(sents): if len(sents) 1: return sents kw1 set(jieba.analyse.extract_tags(sents[0], topK5)) kw2 set(jieba.analyse.extract_tags(sents[1], topK5)) if len(kw1 kw2) / max(len(kw1), 1) 0.6: return [sents[0]] return sents5.5 性能优化从8分钟到3分钟的调优过程最初版本跑一次要8分钟主要时间花在语义编码上。优化措施有三个一是把模型换成更小的all-MiniLM-L6-v2之前用的是all-mpnet-base-v2体积大3倍二是只对标题和前200字编码而不是全文三是把编码结果缓存起来同一篇内容第二次出现时直接读缓存。优化后跑一次只需要不到3分钟其中抓取占1分半编码占1分钟其他环节加起来不到30秒。对于每天跑一次的使用频率来说这个速度完全可以接受。6. 后续可扩展的方向与个人经验这个工具目前只覆盖了文本类信息源后续可以考虑加入对视频和播客内容的处理通过语音转文字后再走同样的流水线。另一个方向是加入个性化推荐根据用户的阅读历史调整排序权重让输出更贴合个人兴趣。我在实际使用中最大的体会是自动化工具的价值不在于完全替代人工而在于把人工从重复劳动中解放出来。以前我每天花40分钟筛信息现在花5分钟检查工具的输出并做微调节省下来的时间可以用在真正需要深度思考的事情上。最后分享一个小技巧如果你也想做类似的项目建议先从单一信息源开始跑通整个流水线后再逐步增加源。我一开始就上了8个源结果调试选择器花了两天时间如果从1个源开始半天就能跑通然后再逐个增加效率会高很多。