每天刷 arXiv 的 cs.LG 分类差不多是我近三年雷打不动的习惯。但说句实话这个习惯越来越难坚持——cs.LG 的日更新量早就飙到四五百篇一篇篇点开看标题、扫摘要大半个小时就没了真正能留下印象的却没几篇。后来我实在忍不住干脆写了一套自动化汇总流程把每天新出的机器学习论文先抓下来、清洗、打分、排序再交给大模型做一轮摘要和关键词提取最后生成一份可以直接刷的结构化报告。项目本身不复杂但做完之后最大的感受是工具解决的不是“读不读”的问题而是“筛什么”的问题。这篇文字把整套流程的架构、代码、参数和踩过的坑完整复盘一遍希望给同样在论文海里挣扎的人一点参考。这套流程适合谁如果你在高校做机器学习相关课题或者在公司跟进算法前沿每天都需要固定时间刷论文如果你是刚开始入门想找一条有过滤机制的学习路径而不是被推荐算法牵着走那这套方法也同样适用。它不要求你懂多深的工程知识Python 基础加一个能调大模型 API 的账号就够。下面先从需求拆解讲起。1. 为什么需要一套自己的论文汇总流程1.1 论文量级膨胀从日更100篇到日更500篇要理解为什么需要自动化先看一个数字。2020年我刚开始关注 cs.LG 分类时每天的更新量大概在100到150篇周末甚至更低到了2024年之后日常更新量稳定在400到600篇遇到顶会投稿截止前一天冲到800篇也不奇怪。换句话说光是把所有标题扫一遍就要滑动很久的滚轮更别提逐篇打开摘要了。更麻烦的是这个数字背后还藏着交叉分类的问题。arXiv 的论文可以同时挂在两三个分类下cs.LG 和 stat.ML 高度重叠还有一部分发散到 cs.AI、cs.NE、cs.CV。如果你只订阅 cs.LG 的 RSS实际上会漏掉很多挂在其他分类但核心内容属于机器学习的论文如果你把所有相关分类都订阅上重复率又高得离谱。这种“量又大、边界又模糊”的情况手工处理几乎是无解的。1.2 现有工具的局限推荐算法不适合做科研过滤市面上不是没有论文推荐工具但用下来总觉得差点意思。基于引用量的排序对新论文极不友好刚挂出来的论文引用量为零永远排在最后面基于用户行为的学习模型又会把你推向热门子领域长尾方向的小众论文很难得到曝光。还有一个被很多人忽视的问题这类工具大多做的是“相关性推荐”而不是“重要性筛选”。科研场景下我需要的是另一套逻辑先按自己的研究方向和关注列表做硬过滤再对剩下的论文做重要度评分最后才轮到人来决定读不读。这个流程里机器筛一遍的价值不是替代人做判断而是把人的判断集中用在真正值得的地方。所以我决定自己写一套核心目标只有一个每天早上给我一份高质量的短名单而不是把几百篇论文原封不动推到面前。1.3 时间管理模型每天20分钟加周末精读把需求再拆细一点落到时间维度上。每天投入论文的时间是有限的我给自己设定的目标是每天早上用15到20分钟看完昨天全量论文的结构化摘要标记出3到5篇值得精读的论文等到周末再安排整块时间细读。这个目标要求汇总流程在每天固定时间产出一份“短名单”同时保留完整的“候选池”和“全量存档”方便随时回溯。基于这个模型技术方案的目标就很清晰了抓取要自动、过滤要可解释、排序要稳定、结果要方便回溯。后面每一部分的实现都是围绕这几个目标展开的。我见过很多人在搭这类工具时一上来就想上多复杂的架构其实核心就一条把每天几百篇论文压缩成一份能快速看完的报告这个闭环跑通才算真正有用。2. 整体方案设计与技术选型2.1 流水线的四个层级我的方案整体拆成四层每一层之间用 JSON 数据传递互不共享状态抓取层按时触发从 arXiv API 拉取此前24小时符合条件的论文元数据存到本地数据库。过滤层用关键词词表和负向词表对标题、摘要做加权评分筛出候选集。增强层对候选集调用大模型 API生成结构化摘要、核心贡献点和标签。分发层把结果渲染成 Markdown 报告推送到自己的仓库或笔记系统。这样分层最大的好处是调试方便。某一层挂了不影响其他层的日志和结果而且每一层都能单独跑不用每次都从头拉数据。我实际开发时也是按这个顺序一层一层加的先跑通抓取和报告再慢慢加过滤和 AI 增强避免一上来就陷入细节。2.2 技术选型为什么是 arXiv API 加 SQLite层次方案替代选项选择原因抓取arXiv API Python爬虫 / RSS订阅API 字段完整、格式稳定对服务器友好存储SQLiteJSON文件 / MySQL查询方便去重和增量更新很容易写定时GitHub Actions cron本地 cron / 云服务器免费、自带日志、无需自建运维摘要大模型 API纯规则抽取理解能力更强摘要质量好得多很多人一上来就想用爬虫抓 arxiv.org我强烈不建议。arXiv 官方提供了一套完整的 API支持按分类、按时间、按关键词查询返回标准的 Atom XML 格式。和爬虫相比有三点明显优势第一字段结构稳定标题、摘要、作者、发布时间、分类都有固定字段不用每天跟着网页改版去改解析逻辑第二服务端有明确的访问规范合理频率下不会封 IP第三API 返回的数据里包含 submitter 注释、期刊引用、DOI 这些网页上不方便提取的元数据信息量更大。存储层我用 SQLite 而不是 JSON 文件原因是写查询太方便了。每天几百条记录按日期查、按分类统计、按论文 ID 去重几条 SQL 就能搞定。如果用 JSON去重逻辑还得自己实现。SQLite 是单文件存储后期要搬到另一台机器上直接复制文件就行完全够用。2.3 表结构与数据流库里面最核心的表就一张我命名为 papers字段大致是这样arxiv_id去掉版本号的论文ID、title、summary、authors、published、updated、categories、score、is_new。另外一张 processed 表记录每天已经调用过大模型的论文 ID避免重复消耗 API 额度。设计表的时候有一个细节值得注意arxiv_id 必须存储去掉版本号的版本。原因后面踩坑部分会详细讲简单来说就是同一篇论文更新到 v2、v3 之后API 返回的 id 都会变但核心论文是同一篇只有去掉 v 后缀才能正确去重。这个字段如果设计错了整个增量更新逻辑都会出问题。3. 核心实现数据抓取与结构化3.1 arXiv API 的调用细节先看抓取部分的代码。这段代码我跑了很长时间核心是构造正确的查询参数和解析 Atom XMLimport urllib.request import urllib.parse import xml.etree.ElementTree as ET from datetime import datetime, timedelta, timezone API_URL http://export.arxiv.org/api/query def fetch_papers_since(days1): end datetime.now(timezone.utc) start end - timedelta(daysdays) # arXiv 官方不推荐单次查询拿太大窗口这里用 2000 上限覆盖一天的量 query urllib.parse.urlencode({ search_query: cat:cs.LG OR cat:stat.ML, start: 0, max_results: 2000, sortBy: submittedDate, sortOrder: descending, submittedDate: f[{start.isoformat()} TO {end.isoformat()}], }) url f{API_URL}?{query} req urllib.request.Request(url, headers{User-Agent: paper-watcher/0.1}) with urllib.request.urlopen(req) as resp: data resp.read() ns {atom: http://www.w3.org/2005/Atom} root ET.fromstring(data) papers [] for entry in root.findall(atom:entry, ns): full_id entry.find(atom:id, ns).text.split(/abs/)[-1] # 去掉版本号作为去重主键 arxiv_id full_id.split(v)[0] title .join(entry.find(atom:title, ns).text.split()) summary .join(entry.find(atom:summary, ns).text.split()) published entry.find(atom:published, ns).text updated entry.find(atom:updated, ns).text categories [c.get(term) for c in entry.findall(atom:category, ns)] papers.append({ arxiv_id: arxiv_id, full_id: full_id, title: title, summary: summary, published: published, updated: updated, categories: categories, }) return papers这段代码有三个要点值得展开。第一search_query 我写的是cat:cs.LG OR cat:stat.ML因为这两个分类高度重叠单查 cs.LG 会漏掉不少好论文两个一起查再合并去重才是完整的机器学习每日更新视图。第二max_results 设成2000是为了覆盖24小时的量但遇到投稿高峰期可能不止2000条所以完整实现里还应该有分页循环每次取1000条判断返回条数是否等于 max_results等于就继续往下翻。第三User-Agent 必须写清楚标识arXiv 官方文档明确要求调用方提供可联系的标识空 UA 很容易被限流。解析 Atom XML 时我用了 Python 自带的 ElementTree用命名空间http://www.w3.org/2005/Atom查找条目不要用正则去解析 XML那种做法在字段顺序变化时会崩得很难看。标题和摘要注意要压缩多余空白因为 API 返回的文本里经常有换行和多余空格直接使用会导致报告排版混乱。3.2 标题与摘要的关键词评分抓回来之后不能直接看先做一轮自动打分。我的做法是维护一张权重表把研究方向拆成若干个主题词每个词配一个权重。评分对象是标题和摘要拼接后的文本对每个命中词累加权重最后标准化到0到100。词表设计大概长这样词权重词权重reinforcement learning5LLM / large language model4diffusion4multimodal3gradient / optimization3control / robotics4benchmark / dataset-2survey / overview-1application / system-1empirical study纯应用-2重点不是词表一开始写得多全而是每周根据精读结果动态调整。比如一开始我把 GNN 设为正权重后来发现自己对图神经网络方向关注度下降了就把它降成0。这个调整过程就是让过滤逻辑和真实研究兴趣对齐的过程也是整条流水线里最需要时间投入的部分。打分函数不用复杂简单的加权求和就够def score_paper(title, summary, pos_words, neg_words): text f{title} {summary}.lower() score 0 for w, s in pos_words.items(): if w in text: score s for w, s in neg_words.items(): if w in text: score - s return max(0, min(round(score / 10 * 100), 100))这个函数刻意做得简单因为过滤阶段要的是稳定和可解释不是玄学。每条论文被筛出来或者被滤掉都能明确说出是因为命中了哪些词。这一点对调试非常重要复杂的机器学习排序模型反而不好调。3.3 增量更新与去重增量更新的逻辑是每次运行都跑一个足够宽的时间窗口然后与库里的 arxiv_id 对比新增的论文标记为 is_new1已存在的论文只更新 updated 字段并且不触发后续的 AI 处理。这里有一个细节arXiv 的更新记录分为 published 和 updated 两个时间戳。有些论文提交几天后会更新版本如果是作者主动修改补充实验一般只需要更新记录但如果 API 返回的摘要里出现 Withdrawn 字样说明这篇论文被作者撤回了必须单独标记不能混进正常候选。我最初没处理这个情况导致有段时间报告里出现几篇已经撤稿的论文点进去才发现是空的。3.4 报告生成与归档过滤完成后把 is_new1 且打分较高的论文渲染到 Markdown 报告里按分数从高到低排列。每条包含 arxiv 链接、标题、分类、评分摘要、AI 标签等。报告生成用最朴素的 f-string 拼接就够了不需要引入模板引擎因为格式非常固定自己控制起来反而更灵活。生成的报告按日期归档到仓库目录文件名带上日期比如digest-2026-09-30.md。这样做的价值在于回溯三个月后你想找当时关注过的一篇论文直接打开对应日期的报告就能查比在浏览器历史里翻高效得多。4. AI 辅助的摘要生成与标签系统4.1 为什么要在流水线里引入大模型关键词打分能解决“过滤”问题但解决不了“提炼”问题。几百篇论文过完评分之后剩下来的几十篇仍然需要逐篇读摘要。这一步我引入了大模型 API对候选论文做结构化阅读。输入是标题加摘要输出包含四个字段一句话贡献、几个关键词标签、推荐阅读理由、一个0到5的推荐分数。这四个字段拼起来就是报告里最核心的短名单卡片。很多人问为什么不直接用现成的论文总结网站我的经验是现成工具很难适配个人研究方向。通用摘要工具给出的结果没有针对性不会告诉你这篇论文和你的研究兴趣到底相关在哪。自己调 prompt 可以让 AI 输出更有方向感比如你的方向是离线强化学习模型就会在 reason 字段里特地说清楚这篇论文的算法和离线场景有什么关联这种定制化是通用工具做不到的。4.2 Prompt 设计结构化输出加反幻觉约束大模型输出质量很大程度上取决于 prompt。我用来做论文摘要的 system prompt 长这样SYSTEM_PROMPT 你是一名机器学习领域的研究助理。请基于论文标题和摘要产出以下字段 1. contribution: 一句话概括该论文的核心贡献不超过40个汉字。 2. tags: 3-5个关键词用英文小写逗号分隔。 3. reason: 用一句话说明这篇论文值得关注的原因不超过60个汉字。 4. score: 一个整数范围0-55表示与前沿相关且可能有方法创新。 只输出 JSON不要输出其他内容。 不要编造摘要中不存在的信息。 USER_PROMPT fTitle: {title}\nAbstract: {abs_text}这个 prompt 有四个点很关键。一是“不要编造摘要中不存在的信息”必须写进去大模型在论文标题和摘要这类半结构化文本上很容易脑补方法细节如果不加约束报告里会出现很多原文根本没有的说法。二是返回格式必须用 JSON方便程序直接解析如果你让模型自由发挥后续提取字段会非常痛苦。三是 score 字段让模型打但只做参考人工精读时我会用自己的判断覆盖它模型打分稳定但不够敏锐人的判断才是最终标准。四是温度参数要调低一般设 0.1 到 0.2追求确定性输出减少同一篇论文在两天内被打出不同标签的情况。调用部分用 Python 的 requests 包就够了注意记录每次调用的输入输出到日志文件我遇到过 API 返回了非 JSON 的情况有日志才能快速定位是模型问题还是调用问题。4.3 批量处理与成本控制每天进入 AI 处理的论文量大概是候选集的规模。假设一天有500篇新论文经过关键词过滤后留下100篇左右每篇输入输出加在一起约1千 token一天总消耗约100k token。按主流 API 的价格计算一天几块钱人民币一个月一百出头成本完全可接受。但对于个人项目来说成本不是主要问题速率限制才是。批量调用 API 时必须在循环里加延时或者用官方 SDK 里自带的重试机制否则很容易触发429限流。我一般每两次请求之间 sleep 0.5 秒一天跑下来总共就多花几十秒换来的是一次成功执行。还建议在脚本开头加一个开关控制是否真正调用 API调试过滤逻辑时先跑假数据避免浪费额度。有个小设计值得分享我只在候选论文上调用大模型不在全部500篇上调用。因为关键词过滤已经比较可靠被滤掉的论文大概率不是你的方向没必要喂给大模型。这一条规则直接帮你省掉80%以上的 API 调用量。4.4 人工精读机器管的和机器不管的报告生成之后90% 的工作已经自动化完成了剩下的是人的活。我每天花15分钟扫一遍报告重点关注分数4和5的论文逐一点开原文页面看看图表、公式和实验设置判断是否放进周末精读列表。这个过程机器替代不了但机器的价值在于它把原本500篇论文的筛选空间压缩到一个几十条的短名单里让我把宝贵的注意力用在该用的地方。扫报告也有技巧。我一般先看 AI 生成的 contribution 字段如果一句话讲不清这篇做了什么说明它表达有问题直接跳过如果 contribution 看起来很新颖再去看 reason 字段提到的相关性和 score。只有这两关都过我才会点开原文。这样下来每天真正点开原文的论文通常在5到10篇之间比从前漫无目的地刷强太多了。5. 实战踩坑记录与问题排查5.1 时区引起的丢论文这个坑我踩过好几次。arXiv 的 submittedDate 字段用的是美东时间ET不是 UTC。如果脚本里按 UTC 的零点做时间窗口你会发现上午跑出来的结果常常少了前一个晚上提交的论文因为美东时间的零点对应北京时间的中午12点或下午1点时间窗口写窄了就会漏。我的处理方式是用一个足够宽的窗口比如每次拉取“当前 UTC 时间往前推30小时”的数据然后在代码里用论文的 published 字段再做一次本地时间过滤。宁可多拉、重复处理也不要漏。重复运行会自动去重漏了就要等第二天这是不可接受的。这个改完之后我再没遇到过凌晨论文大面积缺失的情况。5.2 API 返回的重复条目调用 arXiv API 做分页时如果你设置了 start 和 max_results 往后翻会发现下一页的开头和上一页的结尾有几条重复。这不是 API 的 bug而是机制问题查询过程中有新论文提交排序结果发生了变化导致翻页边界漂移。解决办法很简单分页循环时记录已经见过的完整 ID凡是重复直接跳过。这个逻辑和数据库里的去重是同一套只是位置不同一个在 API 层一个在存储层。遇到重复条目千万不要用 set 直接去重因为你需要保留条目在报告里的原始顺序。我用的是 dict以完整 ID 为 key首次出现时写入后续遇到就忽略这样既能保证去重又能维持顺序。5.3 分类边界的判断cs.LG 和 stat.ML 的交叉问题前面说过实际使用中我还发现很多纯理论学习挂在 math.PR 或 math.ST 下一些和神经科学结合的模型挂在 q-bio.NC 下。如果你的研究领域比较交叉建议把 search_query 写成多个分类的 OR 组合同时把抓到的 categories 字段存下来方便后续统计究竟哪些分类贡献了最多潜在相关论文。我现在的配置稳定在 cs.LG、stat.ML、cs.AI 三个分类cs.NE 只在特定时期临时加。这个组合不是一步到位的而是根据两个月的数据统计慢慢调出来的。每次调整都记在 README 里后面排查问题时有据可查。5.4 常见问题速查表现象可能原因解决办法凌晨论文大量丢失时间窗口用了本地时区而非 UTC窗口放宽到30小时再用 published 字段过滤API 返回403或429请求频率过高或 UA 未设置设置 User-Agent循环加延时指数退避同一天出现重复论文API 分页结果重叠记录已见 ID跳过重复摘要里出现 Withdrawn论文被作者撤稿单独标记不进入候选池大模型输出幻觉prompt 缺少约束在 prompt 中写明“不要编造”温度调低LaTeX 公式显示混乱摘要里有 $...$ 符号用正则把公式部分替换成 [math] 占位符最后一个 LaTeX 的问题我没在代码里体现但很值得单独说。arXiv 摘要里大量出现$...$这种公式标记直接喂给大模型和大模型输出到报告时都会产生格式问题。我加了一个正则在预处理阶段把公式内容替换成[math]占位符对模型理解没有明显影响却能显著提高报告的可读性。这些坑每个都对应一次真实的调试过程。日志一定要认真看我把每次运行的结果都写到 logs 目录出了一切怪现象的先查日志而不是猜代码。自动化脚本最怕“安静地出错”日志就是破除安静的武器。6. 个人体会与一些扩展建议到这里这套论文汇总流程的技术细节就基本讲完了。最后聊聊个人体会。做这个项目之前我一直觉得“刷论文”是一件应该靠自律完成的事做完之后我才意识到自律是解决不了信息过载的工具才能。每天固定产出一份短名单让我从“被动刷到什么都看”变成了“主动筛选值得看什么”这十几分钟的时间花得比以前高效得多。对刚入门的朋友多说一句。我自己的学习路径是先看吴恩达的课程建立全局观再啃西瓜书补理论细节最后回到论文来接触前沿。论文汇总不是给新手的第一站但当你对机器学习的几个主要方向有了基本概念之后它会成为你跟进领域进展最稳定的一条输入渠道。热词里的那些“期末复习”“课程设计选题”之类的问题本质上都是同一件事——你的信息筛选能力决定了你的学习效率而信息过载恰恰是新手的最大障碍。给想复现的人几个建议。第一别一开始就追求功能完整先做到“每天有报告”这个最小闭环再逐步加分强、AI 摘要、标签第二关键词权重表是项目的灵魂但它不是一次性写好的而是根据你每周实际精读的结果不断调整的第三报告要方便回溯我会在每周日的归档文件里顺手记一笔本周精读了哪几篇累计一个月就能看到自己的阅读偏好和研究轨迹。这个项目后续还可以往几个方向扩展用向量检索做语义相似度聚类把每日新增论文和我的论文库做相似度匹配每天自动给出“和你最近研究的相似度最高的5篇”或者把报告推送到笔记软件做自动化归档让信息流自动进入知识库。但不管怎么扩核心价值始终是同一个——在一个信息严重过量的领域里给自己造一个可信的过滤器然后把省下来的时间花在真正值得的阅读上。