从订阅到报告：用API与自动化构建arXiv每日论文分析流水线

如果你也是每天被 arXiv 冲脸的人肯定懂这种体验睡前刷到某个方向觉得“终于看完了”一觉醒来再看列表又多了几百篇。arXiv 作为全球最活跃的预印本平台几乎把整个计算机科学、物理学、数学和量化金融的最新产出都堆在你面前问题是“最新”这个词在它这里是以小时为单位的。我大概从两年前开始正式跑自己的 arXiv 每日论文分析报告每天自动抓取关注的几个子领域做过滤、去重、排序最后生成一份 10 分钟能刷完的 Markdown 报告推给我。这篇文章就把整套流程拆开来讲从最底层的 arXiv 订阅方式、RSS/API 的使用到流水线脚本怎么设计、常见坑怎么避开适合所有把 arXiv 当作主要信息源的科研人和工程师。1. 每日论文分析报告的整体设计思路1.1 先想清楚报告给谁看、解决什么问题做这种自动化之前我建议你先别急着写代码而是回答一个问题这份报告到底是给谁看的目标读者不同报告形态会差很远。如果只给自己看那只需要过滤逻辑和排序分如果还要发给课题组或同方向的朋友就要把论文的背景信息写得更大白话让别人不看原文也能判断要不要点进去。我遇到的真实场景是自己同时关注 NLP、多模态和 Agent 三个方向每个方向每天都有几十甚至上百篇新论文全量看根本不现实。人的精力是有限的一天能精读的论文不会超过五篇需要的是“从噪声里捞信号”。所以报告的第一性设计原则不是把当天全部论文列出来而是做一道减法哪些值得花 10 分钟扫一眼哪些值得花 30 分钟精读哪些直接忽略。另一个被很多人忽略的问题是报告应该保留多少上下文。最开始我仅仅输出标题和链接时间长了发现根本想不起来当初为什么收藏某篇。后来我强制每条记录回答四个问题这是什么工作、用了什么方法、验证了什么场景、和我的关注方向有什么关联。想清楚这四个问题之后报告的信息量才真正够用。1.2 报告里每一行都应该回答哪些问题我最终形成了一份固定模板每条论文包含这几个部分标题与 arXiv ID必须附带绝对链接方便点击第一作者和机构归属用于快速识别熟悉团队所属分类比如 cs.CL、cs.AI、eess.SY方便按域归档原始摘要的压缩版本保留方法、任务、结论三个关键信息推荐的候选理由比如“命中关键词 LLM Agent”“和之前读过的某篇同团队”打分与排序用统一规则算出的分数决定这条在报告里的位置。这个模板看起来简单但每条字段背后都有讲究。比如机构归属arXiv 并不会非常规范地给出机构名很多作者填的是形如 “Google Research”“MIT CSAIL” 的字符串需要做归一化才能聚合统计。又如摘要压缩早期我直接截取前 200 个字符结果经常截到半句话后来改成先切句子再拼接明显靠谱得多。1.3 为什么现成的邮件订阅和公众号不够用一定有人问arXiv 自己有邮件订阅各种学术公众号也会做论文速递为什么还要自己造轮子答案是现成方案解决的是共性问题你的需求永远是特殊的那一个。arXiv 官方的每日邮件订阅覆盖面很广但它不做筛选把你订阅分类下的所有论文一封邮件全砸过来。我实测只订阅一个 cs.CL 分类每天也会收到 100 条以上其中真正值得点开的可能不到 20 条。公众号速递的问题是时效性和覆盖面不可控编辑口味会决定今天推什么而一个科研人真正需要的不是编辑认为的“热点”而是和自己研究方向高度相关的“待读清单”。自己搭流水线的另一个好处是可持续积累。每天的报告都会存成 Markdown 和 JSON 文件时间一长就变成了一个私人领域的知识追踪库。你可以随时回看三个月前某天出现了什么工作也可以统计某个方向是在变热还是变冷这些能力是任何现成订阅都不给的。2. 先把订阅链路理清邮件、RSS、API 怎么选2.1 官方邮件订阅仍然是最保底的方案很多人问 arxiv 怎样订阅最简单也最稳妥的办法就是直接在 arXiv 官网上登录账号进入订阅设置勾选自己关注的分类比如 cs.AI、cs.CL、physics.optics 等等。系统会在每个工作日按固定时间给你发出一封包含当日新论文列表的邮件。这份邮件最大的优点是稳定你不用担心网络波动、脚本崩溃或者接口变更只要邮箱还在论文就不会丢。但它的问题也很明显没有优先级、没有个性化、没有排除规则。像我这种订阅了三个分类的人几乎每天都会收到一份长得吓人的列表标题和摘要挤在一起阅读体验并不好。所以我把官方邮件当作保底方案确保信息不丢失但不会把它作为唯一的阅读入口。真正用来精读分析的是我自己搭的那套 API 流水线。2.2 RSS适合在阅读器里快速扫一眼如果你不想把信息链路做得太复杂另一个值得尝试的中间方案是 RSS。arXiv 每个分类都有对应的 RSS/Atom 地址你可以把它扔进 Feedly、Inoreader 这类阅读器里实现移动端秒开秒扫。相比邮件RSS 的更新更快而且你可以在阅读器端做标签、高亮、略过规则等于给邮件订阅加了一层轻量筛选。我自己的使用习惯是地铁上打开阅读器把 RSS 里带有关键词“Agent”“LLM”的标题标星到了办公室之后再对着星标内容到 API 流水线生成的详细报告里去精读。RSS 的优势在于轻它不需要你去维护任何服务但它的劣势也在于轻过滤规则只能在阅读器客户端层面做很难做到排序和多源融合。2.3 API自动化报告的数据源真正把信息流变成结构化数据的方案是直接调 arXiv 官方 API。它的基本思路是先用你关注的分类和关键词构造一个查询语句然后 API 会返回当天提交的一批论文的 Atom XML 数据里面包含了标题、作者、摘要、分类、链接、更新时间等完整字段。API 地址的格式通常是http://export.arxiv.org/api/query通过参数拼接出搜索条件。比如想取当天 cs.CL 和 cs.AI 的最新论文可以这样写curl http://export.arxiv.org/api/query?search_querycat:cs.CLORcat:cs.AIsortBysubmittedDatesortOrderdescendingstart0max_results50我这里故意没用https是因为在不少企业内网里早期 HTTPS 证书曾遇到过问题后来官方全面支持后再用https即可具体以官方文档为准。API 会返回 Atom 格式的 XMLPython 里用feedparser解析起来非常方便。官方 API 的更新频率是按分钟级的完全能满足“每天一次”的报告任务。但要注意它并不是无限量爽读官方对请求频率有明确限制一般来说不要超过每秒 1 次请求也不要用过于复杂的并发。正常做日报一天只需请求几次完全在合理范围内。2.4 三种订阅方式的组合策略看到这里你应该明白了邮件、RSS、API 并不是互相替代的关系而是三个不同信息密度的层级。我用了很长一段时间后整理出下面这张对比表订阅方式延迟信息密度自动化难度适合场景官方邮件高通常每日一封低全量推送最低零配置兜底防止漏看RSS中等按分类实时更新较低需要自己扫低配置阅读器即可移动端快速刷选API高分钟级高可自定义较高需写代码生成日报、统计分析我现在的组合策略可以总结成三层邮件兜底保证信息不丢RSS 解决随手刷的需求API 负责每天凌晨定时拉取数据并生成精读报告。这套组合已经跑了一年多基本没有出现过重大遗漏偶尔因为 API 超时少抓了几篇也能靠官方邮件补上。3. 从抓取到报告完整实现一份每日更新3.1 抓取当天的论文数据先写一个最简单的抓取函数。这里我直接用requests请求 API再用feedparser解析返回结果。需要注意的点是feedparser对 Atom 里的arxiv命名空间支持得不错但要把分类、期刊引用、评论字段单独提取时一定要先确认字段名。import requests import feedparser from datetime import datetime, timezone base http://export.arxiv.org/api/query params { search_query: cat:cs.CL OR cat:cs.AI OR cat:cs.MA, sortBy: submittedDate, sortOrder: descending, start: 0, max_results: 100, } resp requests.get(base, paramsparams, timeout30) resp.raise_for_status() feed feedparser.parse(resp.content) for entry in feed.entries: title entry.title.replace(\n, ).strip() link entry.link paper_id link.rsplit(/, 1)[-1] categories [tag[term] for tag in entry.tags] published entry.published print(paper_id, categories, title)这里有个很常见的坑feedparser返回的entry.id通常长这样http://arxiv.org/abs/2609.01234abs直接提取entry.id末尾的编号最省事。但有些情况下entry.id末尾会带v1这样的版本号做去重时要特别小心建议只用链接里的基础 ID也就是把末尾的版本号去掉。3.2 字段抽取和摘要清洗论文的摘要字段里经常混合着 LaTeX 公式比如$L_{train}$、\( \nabla \)、\[...\]这类写法写入 Markdown 报告时如果不处理渲染出来是一团乱码。我写了一个简单的清洗函数来做这几件事import re def clean_abstract(text: str) - str: # 去掉行内公式和行间公式替换为空格 text re.sub(r\\\[.*?\\\], , text, flagsre.S) text re.sub(r\\(.*?\\), , text, flagsre.S) text re.sub(r\$\$.*?\$\$, , text, flagsre.S) text re.sub(r\$.*?\$, , text, flagsre.S) # 折叠空白 text re.sub(r\s, , text).strip() # 处理 Markdown 保留字符 text text.replace(|, \\|).replace(\n, ) return text这个函数并不是完美的 LaTeX 解析器但它能应付绝大多数论文摘要。真正的极端情况比如公式跨行还嵌套我的策略是直接把那一整段当成纯文本不做精细解析。因为日报的用途是快速判断相关性而不是做排版出版物。作者字段也要做一下处理。feedparser会返回多个name标签要做成“第一作者 等”的形式避免报告列表被人名刷屏。机构信息我一般会单独收集从作者地址字段里提取但权威性不足只用于粗略判断团队背景。3.3 打分和排序怎么判断哪篇最值得读排序是整个流水线里最有争议的部分。最开始我按更新时间硬排结果发现当天中午放的论文永远排在前面其实它们不一定更重要。后来我改成多因子打分每个因子都给了明确的权重。我用的打分公式大概是这样的score w1 * category_score w2 * keyword_score w3 * freshness_score w4 * team_score w5 * length_penalty其中category_score表示这篇论文的所属分类和你关注核心领域之间的相关度核心分类给 3 分相邻分类给 1 分无关分类给 0 分。keyword_score是标题命中关键词的加权和标题里命中一个核心词给 5 分摘要里命中给 2 分如果标题同时命中多个核心词可以给更高的指数分。freshness_score用于奖励当天首次出现的组合比如“Agent alignment”今天第一次同时出现就额外加 1 分。team_score是作者机构和你已知团队的匹配度这块数据需要自己维护不用一开始就做。length_penalty是给摘要特别短的论文做惩罚因为有时候短的摘要意味着信息量不足宁愿稍微降权。打分逻辑并不复杂难点在于权重怎么设。我的建议是不要盲目模仿别人的权重而是在跑了一周后对照自己真实点开的论文回算看高分的是不是你真正会读的。我也经历过设定的权重把一堆标题党论文顶到最前面的情况后来把关键词命中权重降下来之后才算正常。3.4 去重避免一稿多发和早版本覆盖arXiv 上同一天反复出现相似标题、同一作者内容重投的情况并不少见。为了不让报告里出现两条基本一样的论文我加了一个简单的去重层。先对标题做归一化小写、去标点、把数字统一保留、把空格压缩。然后计算两两之间的 Jaccard 相似度也就是共有的词数除以两篇标题的词元集合数。如果相似度大于 0.85就保留分数更高的那篇删掉另一篇。版本覆盖也在这个步骤里处理。同一篇论文提交了 v1 和 v2只保留 first published 日期等于当天的那一篇后面修的版本不算新论文。这个逻辑用一句话就能判断只看published字段不看updated字段。3.5 生成 Markdown 报告与定时推送最后一步是生成报告。我按每天的日期命名比如2026-09-23-ai-report.md文件内容分三部分顶部放当天的统计摘要中间放核心推荐列表底部放全量列表作为附录。核心推荐列表只保留打分排名前 15 的论文每一条的格式都一样### [2609.12345] 论文标题 - 作者xxx 等 - 分类cs.CL / cs.AI - 一句话用对比学习做跨模态对齐在三个 benchmark 上超过基线。 - 分数23.5 - 链接https://arxiv.org/abs/2609.12345推送方式我用过很多种最终还是选了两条路径。第一条是每天定时把 Markdown 渲染成 HTML 后发邮件给自己第二条是推送到一个群机器人的 Webhook方便在手机上预览。GitHub Actions 的 cron 表达式我常用的是每天凌晨 3 点跑一次避开 API 早高峰。name: daily-arxiv-report on: schedule: - cron: 0 3 * * * workflow_dispatch: {} jobs: build: runs-on: ubuntu-latest steps: - uses: actions/checkoutv4 - uses: actions/setup-pythonv5 with: python-version: 3.12 - run: pip install -r requirements.txt - run: python report.py --date 2026-09-23 - uses: actions/upload-artifactv4 with: name: report path: reports/2026-09-23*.md如果你的服务器在国内直接用系统 crontab 也可以差别不大。用 GitHub Actions 触发的好处是不需要自己养一台机器缺点是对固定时区的调度需要算好 cron 时间避免到时没跑或者跑太频繁。4. 我在排坑过程中记下的问题清单4.1 API 返回乱码或请求失败这套流水线跑了大半年后我碰到最多的不是逻辑问题而是网络和接口稳定性问题。比如requests.get偶尔会超时尤其是一次请求超过 100 条时API 响应动不动就要几十秒一旦某个中间节点不稳定请求就直接失败。我的处理方式很简单也很有效把单次抓取数量控制在 100 条以内并给请求加三重重试。第一重try/catch捕获超时第二重退避重试间隔 2 秒、4 秒、8 秒第三重如果前两次都失败就触发官方邮件订阅做兜底至少保证当天的论文不会被彻底漏掉。另一个要注意的是 API 的请求频率限制。虽然官方只说不允许高并发但实际踩坑后发现如果一下子并发发起 5 个请求很容易返回503或者空结果。建议把所有查询任务排成一个队列串行执行一天最多也就请求 10 次完全不会触线。4.2 LaTeX 符号导致报告里一团乱如果直接把摘要原封不动写进 Markdown你会看到一堆$、\frac、\begin{aligned}不仅难看连基本可读性都没有。我踩过的坑是用正则清洗时把代码里的斜杠误删尤其当摘要里出现\emph{IEEE}这种语义化标签弄不好会把作者的名字也吃掉。稳妥的做法是先备份原始摘要清洗结果只用于展示不覆盖原数据。遇到看着奇怪的论文再去翻原始摘要不要让清洗逻辑损失信息。对于很少见的复杂公式我倾向于保留部分数学表达尤其是核心方法的符号因为那往往是理解论文的关键。4.3 时间“当天”到底怎么算这边有个一开始没注意到的问题arXiv 的“当天”并不是我们常规理解的今天零点。它用的提交时间带有时区返回字段形如2026-09-22T20:00:00Z。如果直接用本地时间判断“是否今天”在北京时间早上 8 点跑脚本时会把美东时间前一天晚上的一部分论文划到今天导致报告连续两天重复。我的解法是把判断统一成 UTC 日期。先解析published字段时把Z替换为00:00再用.date()取 UTC 日期和脚本运行日期做对比。这样虽然牺牲了一点“美东时间当天”的感知但换来了跨时区的稳定一致。from datetime import datetime published_str 2026-09-22T20:00:00Z dt datetime.fromisoformat(published_str.replace(Z, 00:00)) pub_date dt.astimezone(None).date() # 统一用 UTC用这个方法筛出pub_date target_date再进入后续流程就不会出现重复或漏掉的情况。4.4 分类后缀容易看错刚开始接触 arXiv 的人最容易把分类看混。cs.LG是机器学习cs.CL是计算语言学cs.AI是人工智能cs.MA是多智能体系统cs.NE是神经与进化计算eess.SY是系统与控制。你看光是首字母缩写就很接近更不要说跨学科论文经常同时挂三个分类。我的解决方法是维护一张自己的分类映射表把每个分类对应到内部关键词。比如论文只挂在stat.ML而没挂cs.LG我也照样会抓进来因为很多统计学习论文其实和深度学习强相关。分类表不用太复杂但一定要按自己的研究范围定制不能照搬官方分类字典。4.5 过滤词太粗或太细关键词是整个流水线的灵魂但也是最容易翻车的地方。只用单个词过滤比如“Transformer”一天能命中几百篇基本等于没过滤用太具体的词组比如“LoRA reinforcement learning”一天可能一篇都中不了等于把自己关进信息茧房。我的经验是把关键词分成核心词和上下文词两级。核心词单独命中只加基础分必须同时出现上下文词才给高分。例如核心词是“Agent”上下文词是“memory”“planning”“tool”只有“Agent planning”同时出现才打高标签。这样既不会因为单词太宽而爆炸也不会因为组合太严而漏掉相关论文。5. 进阶玩法把报告从“列表”进化成“导览”5.1 用 LLM 生成一句话点评和中文摘要如果你像我一样每天报告里的论文量在 50 到 100 篇之间纯靠人工扫标题仍然很累。这时可以引入 LLM 做一层“导览”。我的做法是先把抓到的结构化数据组装成一个精简的文本然后让模型给每篇论文输出一句话点评、三个关键词、以及推荐理由。以下论文来自 arXiv请为每一篇生成一句话中文导览指出它解决的问题、方法和可能的价值 标题xxx 摘要yyy成本方面一天 100 篇论文大概消耗几十万 token如果用开源模型自托管成本几乎为零只是需要一台内存足够的机器。如果走云端接口建议只让 LLM 处理前 30 个候选而不是全量数据因为评分的排序已经帮你把最值得看的论文挑出来了。这类导览不需要追求文采重点是把“这篇论文值不值得点开”的决策成本降低。我看到好的导览会顺手把它写进自己的 Obsidian 库时间长了就是一笔知识资产。5.2 和 Zotero、Obsidian 联动日报只有被沉淀下来才有价值。我每天生成报告后会用脚本把核心推荐的前 15 篇转成 BibTeX 格式直接导入 Zotero 收藏夹。这样万一以后写论文需要引用相关内容不需要再到 Answer 检索里翻半天。Obsidian 联动更轻量一些我每天会在日记页面里插入当日报告的链接并用dataview展示最近七天的分数趋势。刚开始这样做会觉得多此一举但坚持一个月后再回看你能看到自己的关注点是怎么迁移的哪些方向从火热变得冷淡哪些团队持续稳定出活这些信息对选题和研究规划很有帮助。5.3 给团队做共享周报沉淀数据当这套流水线运行一段时间后手里的历史数据会慢慢变成一个小型统计库。我会在每周日写一段脚本统计本周高分论文的团队分布、机构分布和关键词分布生成一份精简的周报发给课题组。周报的格式比日报更重视趋势不逐篇列论文而是用表格展示“本周值得关注的团队”和“热度上升的关键词”这两项。很多同事反馈比起自己每天刷 arXiv这种周报能更高效地感知领域动态。当然隐私问题也要注意团队内部的统计只做聚合不要公开具体个人的阅读行为。如果你也想做类似的系统我的建议是从最简单的 OpenAI 替代方案也好开源模型也好先别追求美观和完整先跑通一条核心链路抓取、过滤、排序、推送。然后再根据自己真实的使用反馈逐步加入 LLM 导览、数据沉淀和团队协作这些进阶能力你会发现整个收益是指数级上升的。最后说点掏心窝的话。这套东西最难的地方不是写代码而是确认你到底关注什么。我第一版脚本花了整个周末写抓取和解析结果跑出来的报告自己都不想看原因是过滤规则和权重完全没有反映真实兴趣。后来用两周时间记录自己每天真正点开的论文一点点调关键词和权重才慢慢找到感觉。工具只是放大你的判断力前提是你得先知道自己要什么。