基于arXiv API与LLM的每日论文汇总自动化实践：从抓取到成文

1. 从一份每日论文汇总说起为什么值得认真对待每天早上刷 arXiv 的 cs.AI 分区大概是很多做人工智能方向的人共同的肌肉记忆。但真正坚持下来的人都知道这件事的性价比其实很微妙列表页动辄上百条新论文标题一个比一个唬人点进去摘要读三行就发现跟自己手头的活儿八竿子打不着。时间花了收获却接近于零。所以当我看到有人在做“每日论文汇总”这件事时第一反应不是“这有什么难的”而是“终于有人把这件事系统化了”。这份汇总针对的是 arXiv 的 cs.AI 分区日期标注为 2026 年 9 月 28 日。它要解决的问题很朴素把当天该分区的新论文做一次结构化整理让读者不用逐条点开就能判断哪些值得深读。适合的人群也很明确——做 LLM 应用落地的工程师、跟进多模态方向的算法同学、需要快速判断领域风向的研究者以及那些被“人工智能论文”四个字吸引但不知道从哪下手的学习者。关键词里出现的 arxiv、cs.AI、人工智能、论文、LLM基本框定了这份内容的边界它不是某一篇论文的精读而是一批论文的横向扫描。我做过类似的事情也踩过不少坑。最早我是用 RSS 订阅加手动标记后来换成脚本抓取再后来发现光抓取没用真正的难点在于“怎么筛”和“怎么讲”。一份好的论文汇总价值不在于把标题列全而在于帮读者省下判断成本。下面我就把这类汇总从数据获取到最终成文的完整链路拆开讲包括我实际用过的工具、参数设置、筛选逻辑以及那些只有做过才知道的细节。2. 抓取 arXiv cs.AI 每日列表接口选择与字段取舍2.1 为什么优先用官方 API 而不是爬页面arXiv 提供了官方的查询接口走的是export.arxiv.org/api/query这套 Atom 格式的返回。很多人图省事直接爬列表页 HTML我早期也这么干过结果就是解析规则一改就得重写而且列表页的字段其实比 API 少。官方 API 能直接拿到标题、作者、摘要、分类、提交时间、更新时间和 PDF 链接这些正好是汇总需要的核心字段。调用方式很简单构造一个带search_query的 GET 请求即可。针对 cs.AI 分区查询条件可以写成cat:cs.AI再配合时间范围。这里有个细节arXiv 的 API 对时间过滤支持的是submittedDate格式是[YYYYMMDDTTTTTOYYYYMMDDTTTT]时区默认是 UTC。如果你在北京时间早上跑想抓“昨天”的论文就得把时间窗口往前推 8 小时否则会漏掉一批。import urllib.request import urllib.parse import xml.etree.ElementTree as ET base http://export.arxiv.org/api/query? params { search_query: cat:cs.AI AND submittedDate:[202609270000 TO 202609280000], start: 0, max_results: 200, sortBy: submittedDate, sortOrder: descending } url base urllib.parse.urlencode(params) with urllib.request.urlopen(url) as resp: raw resp.read().decode(utf-8) root ET.fromstring(raw) ns {a: http://www.w3.org/2005/Atom} for entry in root.findall(a:entry, ns): title entry.find(a:title, ns).text.strip().replace(\n, ) summary entry.find(a:summary, ns).text.strip().replace(\n, ) print(title)这段代码我用了很久稳定可靠。max_results我一般设 200因为 cs.AI 单日新论文通常在 100 到 200 篇之间设太小会截断设太大返回里会混入空条目。sortBy用submittedDate降序保证最新的排前面。2.2 摘要清洗那些必须处理掉的脏数据从 API 拿到的摘要文本并不干净。最常见的问题是换行符和多余空格arXiv 的摘要里经常有硬换行直接展示会很难看。另外 LaTeX 公式会以$...$的形式出现如果不处理在纯文本汇总里就是一堆乱码般的符号。我的做法是做一轮轻量清洗把连续空白压成单个空格把$包裹的内容替换成[公式]占位把\cite{}之类的命令去掉。还有一个容易被忽略的点有些论文的标题里带冒号或特殊符号在生成 Markdown 时如果不转义会破坏排版。我一般会把标题里的|替换掉因为表格里|是分隔符。这些细节看起来琐碎但一份汇总如果排版错乱读者第一眼就会失去信任。2.3 去重与版本合并同一篇论文的多个版本arXiv 上同一篇论文可能有 v1、v2、v3 多个版本API 返回时是分开的条目。如果不做合并汇总里会出现同一标题重复多次的情况。我的处理逻辑是按标题的归一化字符串做 key保留最新版本同时在条目里标注版本号。归一化就是把标题转小写、去掉标点、压缩空格。这样即使作者在 v2 里微调了标题也能大概率识别为同一篇。提示去重时不要用论文 ID 做 key因为不同版本 ID 不同也不要用完整标题做 key因为大小写和标点差异会导致漏合并。归一化标题是最稳的折中方案。3. 从两百篇到二十篇筛选逻辑才是汇总的灵魂3.1 先按主题聚类再按热度排序抓取只是第一步真正的功夫在筛选。我试过纯按时间排序直接输出结果就是一份没有重点的流水账。后来改成两步走先按主题聚类再在簇内按某种热度指标排序。主题聚类可以用关键词匹配做粗筛比如把标题和摘要里出现LLM、agent、multimodal、reinforcement learning、diffusion等词的论文分到不同桶里。这种方法不如向量聚类精细但胜在快、可解释、不需要额外模型。热度指标我用的是三个信号的加权摘要长度太短的往往是短文或 position paper、作者数量大团队的工作通常更完整、以及标题里是否包含survey、benchmark、framework这类词。权重可以调我一般给 survey 类加 0.3给 benchmark 加 0.2。这个打分不追求绝对准确目的是把明显值得看的往前排。3.2 用 LLM 做摘要压缩的正确姿势现在很多人会用 LLM 来给论文摘要做二次压缩生成一句话总结。这件事能做但有几个坑。第一不要让模型自由发挥必须给它明确的指令比如“用不超过 40 个字概括这篇论文解决了什么问题、用了什么方法”。第二要给它原文摘要不要只给标题否则模型会编。第三输出格式要约束最好要求它返回 JSON字段固定为problem、method、result方便后续程序处理。我实测下来用中等规模的模型做这件事就够了不需要上最大的模型。因为摘要是结构化的学术文本信息密度高模型的理解难度其实不大。真正影响质量的是 prompt 的约束程度。我常用的模板是这样的你是一名论文摘要助手。请阅读以下论文摘要输出 JSON {problem: 论文要解决的问题20字以内, method: 核心方法30字以内, result: 主要结论或效果20字以内} 不要输出任何解释性文字。摘要如下 {abstract}这个模板跑下来格式错误率很低。偶尔模型会多输出一句话加个正则清洗就行。3.3 人工兜底哪些论文必须亲自看自动化筛选再完善也有它覆盖不到的地方。我的经验是以下几类论文必须人工过一遍标题里出现全新术语的、摘要里提到新数据集的、以及作者单位里有我长期跟踪的团队的。前两类往往代表新方向自动打分可能因为关键词没覆盖而漏掉第三类是因为熟悉团队的工作风格判断起来比模型准。这一步听起来费时间但实际每天也就十来篇十分钟能扫完。而且这个过程本身就是在积累领域感比单纯看汇总有价值得多。4. 汇总成文的结构设计让读者三分钟抓住重点4.1 开篇给结论不要给背景一份论文汇总最忌讳的开头是“今天 cs.AI 分区共收录 XX 篇论文”。读者不关心总数关心的是“今天有什么值得看的”。所以我的写法是开篇直接给三到五条最值得关注的论文每条一句话说清楚它做了什么、为什么重要。这个部分我称之为“今日重点”放在最前面。写这个部分有个技巧不要照抄摘要要用自己的话重述。比如摘要说“we propose a novel framework that leverages...”你就写成“这篇提出了一个 XX 框架核心思路是把 A 和 B 结合起来”。读者要的是人话不是学术腔。4.2 分主题罗列每个主题给一句判断重点之后是按主题分组的完整列表。主题的划分不要太多五到七个比较合适太多会显得碎。每个主题下面列论文每篇给标题、作者、一句话总结。这里的一句话总结可以复用前面 LLM 生成的结果但要人工润色一遍把明显的机器味去掉。主题的命名也有讲究。不要用“其他”这种垃圾桶分类宁可把不好归类的单独列一个“值得注意的零散工作”。主题名要具体比如“LLM 智能体与工具调用”“多模态理解与生成”“强化学习与决策”而不是“大模型相关”“视觉相关”这种模糊说法。4.3 附上可点击的链接和分类标签每篇论文后面附上 arXiv 的 abs 页面链接方便读者直接跳转。链接用 Markdown 的行内链接格式不要直接贴裸 URL。另外可以给每篇打一两个标签比如#LLM、#Agent、#Multimodal方便读者按兴趣筛选。标签不要太多两个足够多了反而干扰。表格在这个场景下很好用。我一般用三列表格标题、一句话总结、标签。标题列放链接总结列控制在一行以内标签列用行内代码格式。这样整份汇总看起来清爽扫一眼就能定位到自己关心的部分。标题一句话总结标签论文 A提出 XX 方法解决 YY 问题#LLM#Agent论文 B在 ZZ 任务上刷新了基准#Multimodal5. 实操中踩过的坑与应对经验5.1 API 限流与重试策略arXiv 的 API 对请求频率有隐性限制短时间内连续请求会被拒。我最早写脚本时没做重试跑一半就断了。后来加了指数退避第一次失败等 3 秒第二次等 9 秒第三次等 27 秒最多重试三次。同时把请求间隔控制在 3 秒以上基本就不会触发限流了。还有一个细节是 User-Agent。有些环境默认的 UA 会被识别为异常流量建议在请求头里带一个正常的 UA 字符串。这不是必须的但能减少很多莫名其妙的失败。5.2 时区问题导致漏抓前面提过时区这里再强调一次。arXiv 的提交时间戳是 UTC而 cs.AI 的“每日列表”在页面上是按 UTC 日期切的。如果你在北京时间早上 8 点抓“昨天”的论文实际上抓的是 UTC 时间前天 16 点到昨天 16 点之间的提交会漏掉昨天 16 点到 24 点UTC的那批。正确做法是把时间窗口设成 UTC 的完整一天或者干脆抓最近 48 小时再按日期过滤。5.3 LLM 生成总结的“幻觉”问题用 LLM 压缩摘要时最怕的是它编造原文没有的内容。我遇到过模型在总结里写“实验在 ImageNet 上达到 SOTA”但原文根本没提 ImageNet。解决办法有两个一是 prompt 里明确要求“只使用摘要中出现的信息”二是生成后做一次关键词校验把总结里的专有名词和原文摘要做匹配匹配不上的标记出来人工复核。这个校验逻辑不复杂用简单的字符串包含判断就能过滤掉大部分幻觉。虽然不能百分百杜绝但能把错误率压到可接受范围。5.4 排版细节别让格式毁了内容Markdown 排版有几个高频坑。第一标题里的#如果没转义会被解析成标题层级。第二摘要里的*和_会被解析成斜体或加粗。第三链接里的括号如果没处理会截断链接。我的做法是在生成 Markdown 之前对所有文本做一次转义把#、*、_、[、]这些字符前面加反斜杠。这一步做完排版问题基本就没了。注意转义不要过度比如中文标点不需要转义转义了反而显示异常。只处理 Markdown 有特殊含义的 ASCII 符号即可。6. 这套流程还能怎么扩展6.1 从单日汇总到趋势追踪单日汇总看的是“今天有什么”但如果把每天的数据存下来就能做趋势分析。比如统计某个关键词在过去一个月的出现频率就能看出哪个方向在升温。我试过用简单的词频统计把agent、reasoning、efficiency这几个词按周画出来趋势还挺明显的。这个扩展不需要额外抓取只要把每天的原始数据落库就行。存储用 SQLite 就够了字段包括论文 ID、标题、摘要、分类、提交时间、抓取时间。查询的时候按日期范围过滤做聚合统计。数据量不大单机完全扛得住。6.2 按读者画像做个性化筛选同一份汇总不同人关心的点不一样。做应用的工程师可能更关心工程落地相关的论文做理论的研究者可能更关心新方法。一个可行的扩展是给读者打标签根据标签调整筛选权重。比如给“工程向”读者提高framework、system、deployment这类词的权重给“理论向”读者提高theorem、proof、analysis的权重。这个功能实现起来不难难的是标签体系的维护。我的建议是先从两三个粗粒度标签做起不要一上来就搞几十个细分标签那样维护成本太高效果也未必好。6.3 把汇总变成可检索的知识库汇总发出去之后过几天就沉底了想找回来很麻烦。一个自然的扩展是把所有汇总内容索引起来做成可搜索的知识库。最简单的做法是用静态站点生成器把每天的汇总生成一个页面再加一个全文搜索。搜索可以用前端方案把索引文件打包进去不需要后端。这样积累几个月之后你就有了一个属于自己的论文库想查某个方向的历史工作直接搜关键词就行。这比每次重新去 arXiv 搜要高效得多而且筛选质量是你自己把控过的比原始搜索结果靠谱。我做这件事最大的体会是论文汇总的价值不在于“全”而在于“准”和“省时间”。把抓取、筛选、成文这条链路跑顺之后每天花在这上面的时间可以控制在半小时以内但产出的内容能帮很多人省下几个小时。这个投入产出比是我愿意持续做下去的原因。