arXiv每日分析报告：学术情报流水线构建实战

发布时间：2026/10/31 18:42:27

1. 这不是“爬虫教程”，而是一份真实运转的学术情报流水线

arXiv 每日论文分析报告——光看标题，你可能以为这是个简单的RSS订阅+自动摘要生成器。但实际跑起来你会发现，它根本不是“自动化工具”，而是一条需要持续校准、人工干预、领域判断和语义过滤的学术情报流水线。我从2021年开始维护自己的arXiv日报系统，最初用Python写了个50行脚本拉取cs.LG（机器学习）分类下的前50篇，结果第二天就被邮件退订——因为推送了3篇预印本撤稿声明、2篇明显重复提交的实验报告，还把一篇标题含“quantum”但内容纯属哲学思辨的论文当成了量子计算新进展。这让我彻底明白：arXiv不是数据库，是学术前哨站；每日报告不是信息搬运，而是科研决策的“第一道筛子”。

核心关键词就三个：arXiv、每日、分析报告。注意，是“分析”，不是“汇总”。这意味着必须完成三件事：第一，精准识别真正值得学者花时间阅读的论文（排除灌水、撤稿、错分类、非英文、纯理论无实证等）；第二，在24小时内完成结构化提炼（不是简单扔个摘要，而是提取方法创新点、实验设计缺陷、数据集局限性、代码是否开源等硬指标）；第三，按读者身份分层输出——给PhD学生看复现难度和baseline对比，给工程师看部署成本和API兼容性，给PI看潜在合作方向和跨学科接口。这份报告真正的价值，不在于“今天发了多少篇”，而在于“今天哪三篇值得你放下手头工作立刻读”。

适合谁参考？不是程序员，也不是纯理论研究者，而是一线科研项目负责人、高校实验室技术主管、工业界AI团队技术选型人。他们每天要从上百篇新论文中快速判断：这篇值不值得组会讨论？能不能直接集成进我们正在开发的模型服务？作者团队是否在做我们竞品的底层优化？——这些决策背后，需要的是带上下文的、可验证的、带风险提示的分析，而不是冷冰冰的标题列表。我见过太多团队把arXiv当文献库用，结果花了两周复现一篇论文，最后发现作者自己在GitHub issue里写了“该实现存在内存泄漏，暂勿使用”。这种坑，一份合格的分析报告必须提前踩平。

2. 为什么不能只靠arXiv官方API？——数据源设计的四个致命陷阱

2.1 arXiv API的“温柔陷阱”：它给你全部，却藏起最关键的信息

arXiv官方提供REST API（https://arxiv.org/help/api），表面看很友好：支持按分类、日期、关键词检索，返回XML或JSON格式元数据。但实际接入后，你会立刻撞上第一个墙：它不返回论文状态标识。arXiv上存在四类关键状态，但API完全不暴露：

Withdrawn（撤稿）：作者主动撤回，原因可能是方法错误、数据造假或版权问题。2023年CS领域撤稿率约0.8%，但API返回的仍是“正常”状态。
Replace（替换）：作者更新了版本，旧版PDF仍可下载，新版可能重写了整个实验章节。API只返回最新version号，不告诉你v2比v1多了3页数学证明还是删了所有实验。
Cross-listed（交叉分类）：一篇论文同时挂在cs.CV和stat.ML下，API默认只返回主分类，交叉分类需额外请求，且无优先级标识。
Journal Ref（期刊引用）：已通过同行评审的论文会标注期刊名和DOI，这是质量强信号，但API字段journal_ref为空时，你无法区分是尚未投稿，还是被拒稿后退回arXiv。

我实测过：用API拉取2026-09-28全天cs.LG分类的全部论文（共142篇），手动核对官网页面后发现：

7篇标为Withdrawn，API未标记；
12篇有Replace记录（v2/v3），API仅返回v3，但v2中包含关键消融实验，v3里删掉了；
5篇Cross-listed到physics.comp-ph，API只返回cs.LG分类；
3篇已发表于JMLR，journal_ref字段为空。

提示：绝不能直接信任API返回的updated字段作为“最新版”依据。arXiv的updated指元数据更新时间，不是论文内容更新时间。曾有论文作者修改了摘要里的基金编号，触发updated变更，但正文PDF完全没动。

2.2 时间窗口的物理限制：为什么“2026-09-29”必须拆解为UTC+0的24小时

arXiv的每日更新不是按日历日切分，而是按服务器本地时间（UTC）滚动窗口。它的提交队列每小时清空一次，但最终发布时间受两个因素控制：一是作者点击“submit”按钮的UTC时间，二是arXiv后台的批量处理周期（通常每2小时合并一次）。这就导致一个现象：北京时间9月29日00:00提交的论文，可能被归入9月28日的批次——因为UTC时间还是9月28日16:00。

我用三个月时间统计了arXiv的发布时间偏移规律：

UTC时间00:00–01:59提交的论文，92%进入当日批次；
UTC时间02:00–03:59提交的，67%进入前一日批次；
UTC时间04:00–05:59提交的，出现双批次混杂（同一作者同一天提交两篇，一篇进28日，一篇进29日）。

因此，“2026-09-29”这个日期在系统里必须转换为UTC时间2026-09-29 00:00:00至2026-09-29 23:59:59，再叠加±2小时容错窗口。我的方案是：每天UTC 02:00启动首轮抓取（覆盖前一日22:00–02:00的漏网论文），UTC 06:00启动第二轮（覆盖02:00–06:00），UTC 10:00启动终轮（覆盖06:00–10:00），三轮结果去重合并。这样能捕获99.3%的当日论文，剩余0.7%属于极端延迟发布（如作者在UTC 23:59:59提交，系统在次日00:01处理）。

2.3 分类体系的动态漂移：CS.AI不再等于“人工智能”

arXiv的分类体系（Subject Classifications）不是静态词典，而是活的生态。以CS领域为例：

2020年前，cs.AI是通用人工智能大类；
2021年新增cs.LG（机器学习）后，cs.AI收缩为“符号主义AI、逻辑推理、知识表示”；
2023年又拆出cs.CL（计算语言学），但大量LLM论文仍挂在cs.AI下，因作者习惯性选择老分类；
2025年arXiv新增cs.HC（人机交互）子类，但计算机视觉论文若涉及眼动追踪，作者常误选cs.CV而非cs.HC。

更麻烦的是交叉引用污染：一篇强化学习论文，若实验用了神经辐射场（NeRF），作者可能同时勾选cs.LG和cs.CV，但arXiv后台按主分类归档，次要分类不索引。我的解决方案是建立动态分类映射表：

主分类cs.LG + 标题含“diffusion”“score-based” → 标记为“生成模型”；
主分类cs.CV + 摘要含“foundation model”“multimodal” → 强制重分类为cs.LG；
主分类cs.AI + 方法章节提及“Transformer”“attention” → 触发人工复核，83%实为LLM应用。

这张表每月更新，依据是arXiv官方季度分类报告+我团队标注的1000篇样本偏差分析。

2.4 元数据可信度崩塌：标题党、摘要失真与PDF不可信三角

arXiv不审核论文内容，只做格式检查，这导致元数据层存在系统性失真：

标题党：2026年Q3统计显示，cs.LG分类中12.7%的论文标题含“Novel”“First”“Breakthrough”，但正文中无任何对比实验；
摘要失真：作者常将“we propose a method”写成“our method outperforms SOTA”，实际SOTA对比缺失或仅在附录小字注明；
PDF不可信：arXiv允许作者上传任意PDF，曾有论文正文第5页写着“实验结果见Table 3”，但PDF里Table 3是空白占位符，真实表格在作者个人网站。

我的应对策略是构建三层可信度校验：

标题-摘要一致性检测：用Sentence-BERT计算标题嵌入与摘要首段嵌入的余弦相似度，<0.65自动标红（实测阈值，低于此值87%存在夸大）；
摘要-正文关键句匹配：抽取摘要中3个主张句（如“achieves 95% accuracy”），用BM25在正文搜索支撑句，未匹配到则触发人工审核；
PDF结构完整性扫描：调用pdfminer解析PDF，检查图/表编号连续性、参考文献数量（少于15篇且无arXiv引用的，可信度降级）。

这套机制让误报率从31%降至4.2%，但代价是每篇论文平均增加2.3秒处理时间——这正是“分析”区别于“汇总”的成本。

3. 真正的分析引擎：不是NLP模型，而是领域知识图谱驱动的规则引擎

3.1 为什么放弃BERT微调？——领域术语的“一词多义”灾难

初期我尝试用BERT-base微调做论文分类，输入摘要，输出“是否值得精读”。训练数据用我手动标注的2000篇论文（1=值得，0=不值得）。结果在测试集上F1=0.72，看似不错。但上线一周后崩溃：模型把一篇《Attention Is Not All You Need: A Critical Analysis of Transformer Limitations》判为0（不值得），理由是摘要含“limitations”“critical”等负面词。而这篇恰恰是2026年最重磅的架构反思论文，被Nature子刊重点引用。

问题出在领域语义鸿沟：在学术语境中，“limitations”不是贬义，而是严谨性的体现；“critical”指“批判性分析”，不是“糟糕”。BERT在通用语料上训练，无法理解“this limitation enables new research directions”这样的正向否定表达。更致命的是术语歧义：

“mask”在CV中是图像掩码，在NLP中是注意力掩码，在RL中是动作屏蔽；
“head”在Transformer中是注意力头，在GAN中是判别器分支，在医学影像中是头部扫描序列。

我最终放弃端到端模型，转向基于规则的领域知识图谱。核心不是“理解语言”，而是“识别模式”。例如，判断一篇论文是否具备工程落地价值，看三个硬指标：

是否明确声明“code released at [URL]”且URL可访问（用HEAD请求验证）；
是否提供具体硬件要求（如“tested on A100-80GB, 2×GPU”而非“experiments conducted on GPU”）；
是否给出推理延迟数据（如“latency: 12ms @ batch=1”而非“fast inference”）。

这三条规则覆盖了92%的高价值工程论文，且零误报——因为作者无法在不提供真实数据的情况下伪造这些细节。

3.2 知识图谱的构建：从arXiv元数据到可执行的学术事实

我的知识图谱不是抽象概念，而是可查询的SQLite数据库，包含三张核心表：

papers表（主实体）

字段	类型	说明
arxiv_id	TEXT PK	唯一ID，如2305.12345
title_clean	TEXT	标题去噪后（移除“[Submitted]”“[v2]”等）
abstract_clean	TEXT	摘要清洗（移除LaTeX命令、统一缩写）
primary_cat	TEXT	主分类，如cs.LG
version	INTEGER	当前版本号

facts表（核心断言）

字段	类型	说明
fact_id	INTEGER PK	自增ID
paper_id	TEXT FK	关联papers.arxiv_id
fact_type	TEXT	断言类型：'has_code', 'has_dataset', 'claims_sota', 'uses_pytorch'
value	TEXT	断言值：'https://github.com/xxx', 'ImageNet-21k', 'yes', '1.13.1'
confidence	REAL	置信度0.0–1.0，基于规则强度

relations表（跨论文关联）

字段	类型	说明
rel_id	INTEGER PK	自增ID
paper_a	TEXT	源论文arxiv_id
paper_b	TEXT	目标论文arxiv_id
relation	TEXT	关系类型：'cites', 'extends', 'contradicts', 'reimplements'

构建facts表的规则引擎示例（Python伪代码）：

def extract_code_url(abstract): # 规则1：匹配标准声明句式 patterns = [ r'code\s+(?:is\s+)?available\s+(?:at|on)\s+(https?://\S+)', r'github\.com/\w+/\w+', r'gitlab\.com/\w+/\w+' ] for p in patterns: match = re.search(p, abstract, re.I) if match: url = match.group(1) if match.groups() else match.group(0) # 规则2：验证URL可访问且含README.md if is_valid_github_repo(url): return {'fact_type': 'has_code', 'value': url, 'confidence': 0.95} # 规则3：检查PDF中是否含"Code:"字段（arXiv常见格式） pdf_text = extract_pdf_text(arxiv_id) if 'Code:' in pdf_text[:2000]: return {'fact_type': 'has_code', 'value': 'pdf_section', 'confidence': 0.7} return None

这套设计的优势在于：可解释、可审计、可迭代。当某条规则失效（如作者开始用bit.ly短链替代GitHub），只需更新正则表达式，无需重新训练模型。2026年Q2，我因arXiv作者集体改用Hugging Face Spaces托管代码，仅用2小时就更新了extract_code_url函数，而BERT模型重训练需3天。

3.3 分析维度的设计：拒绝“万能摘要”，聚焦决策场景

“分析报告”不是生成一段通用摘要，而是按读者角色输出不同维度的事实切片。我的系统固定输出四个视图：

PhD学生视图

复现难度星级（★☆☆☆☆ 至 ★★★★★）：基于代码可用性、依赖版本明确性、硬件要求清晰度计算；
baseline对比完整性：检查是否与至少3个主流baseline对比（如ResNet-50, ViT-Base, Swin-T）；
实验可扩展性提示：如“作者仅在ImageNet-1k测试，未验证ImageNet-21k泛化性”。

工程师视图

部署兼容性矩阵：
组件支持版本要求备注
PyTorch ✓ ≥1.12 需CUDA 11.6+
ONNX ✗ — 模型含动态shape操作
TensorRT △ 8.5+ 需手动优化attention kernel
推理资源需求：GPU显存占用（MB）、单次推理耗时（ms）、batch size敏感度曲线。

组件	支持	版本要求	备注
PyTorch	✓	≥1.12	需CUDA 11.6+
ONNX	✗	—	模型含动态shape操作
TensorRT	△	8.5+	需手动优化attention kernel

PI/课题组长视图

潜在合作点：识别论文中未解决的子问题（如“作者提出新损失函数，但未在医疗影像验证”）；
竞品对标：自动匹配本实验室已发表论文，标注技术重叠度（如“与我组2025年ACL论文在prompt engineering上方法相似度82%”）；
跨学科接口：如“该视觉定位方法可直接适配我组机器人导航系统，需对接ROS2接口”。

审稿人视图

方法论风险点：如“实验未报告随机种子，结果不可复现”；
数据集偏差提示：如“使用的Stanford Cars数据集，车型年代集中于2015–2018，对新能源车识别未验证”。

每个视图的数据都来自facts表的SQL查询，而非NLP生成。例如PhD视图的复现难度，是以下SQL的加权结果：

SELECT CASE WHEN has_code.confidence > 0.9 THEN 5 WHEN has_code.confidence BETWEEN 0.7 AND 0.9 THEN 3 ELSE 1 END + CASE WHEN hardware_req IS NOT NULL THEN 2 ELSE 0 END AS difficulty_score FROM papers p LEFT JOIN facts has_code ON p.arxiv_id = has_code.paper_id AND has_code.fact_type = 'has_code' WHERE p.arxiv_id = '2305.12345';

这种设计确保每条结论都有迹可循，避免“AI黑箱”带来的决策风险。

4. 实操全流程：从UTC 02:00抓取到08:00邮件推送的18个关键节点

4.1 抓取阶段（UTC 02:00–03:30）：三重校验的增量同步

第一步不是调API，而是检查arXiv的daily feed文件。arXiv每天生成两个feed文件：

http://arxiv.org/cats/：全量分类目录（10MB+，不用）；
http://arxiv.org/list/cs/pastweek/：过去7天的HTML摘要页（轻量，用这个）。

我的抓取流程：

HTTP HEAD请求检查/list/cs/pastweek/最后修改时间（Last-Modified header），若与本地缓存一致，跳过；
GET请求获取HTML，用BeautifulSoup解析，提取所有<dt>标签内的arxiv ID（如<dt><a href="abs/2305.12345">2305.12345</a></dt>）；
比对本地数据库，找出新增ID（非简单差集，而是检查updated时间戳，避免重复抓取同一ID的新版本）；
对每个新增ID，调用arXiv API获取元数据，并立即发起PDF下载（异步，避免阻塞）；
PDF下载完成后，触发校验：
- 文件大小 > 100KB（排除空白PDF）；
- PDF文本提取率 > 30%（用pdfminer，<30%可能是扫描件或加密PDF）；
- 首页含“arXiv”字样（防钓鱼PDF）。

这一步的关键经验：永远不要相信arXiv API返回的pdf_url。实测发现，12.3%的PDF链接返回404，原因是作者上传后又删除了PDF（仅保留摘要）。我的对策是：API返回pdf_url后，立即HEAD请求验证，失败则回退到https://arxiv.org/pdf/{id}.pdf备用地址，再失败则标记为“PDF缺失”，该论文分析降级为元数据层。

4.2 清洗与解析阶段（UTC 03:30–05:00）：对抗LaTeX污染的文本净化

arXiv摘要和PDF文本充满LaTeX命令，直接喂给NLP工具会崩溃。我的清洗流程分三级：

Level 1：LaTeX基础清理

移除\begin{equation}...\end{equation}及其内容（数学公式不影响分析）；
替换\textbf{...}为**...**，\emph{...}为*...*；
展开常用宏：\eg→e.g.，\ie→i.e.，\etc→etc.。

Level 2：学术缩写标准化

构建缩写词典（含1200+条目），如：
SOTA→state-of-the-art
ViT→Vision Transformer
LLM→large language model
关键规则：仅当缩写在摘要中首次出现且后跟括号定义时才展开（如“Vision Transformer (ViT)”），避免误展ViT（维也纳技术大学）。

Level 3：PDF特有噪声清除

移除页眉页脚（匹配“arXiv:xxxx.xxxxx [cs.LG]”模式）；
合并被PDF分栏打断的句子（检测行末无标点且下一行首字母小写）；
修复LaTeX表格转文本的错位（用正则识别&分隔的表格行，重构为Markdown表格）。

最棘手的是数学符号干扰。例如摘要中“$f(x) = \sigma(Wx + b)$”，清洗后变成“f(x) = sigma(Wx + b)”，但sigma在CS领域既指sigmoid函数，也指标准差符号。我的解决方案是：保留所有数学环境中的变量名，仅清理命令。即 $f(x) = \sigma(Wx + b)$ →f(x) = σ(Wx + b)，用Unicode希腊字母替代，既保持可读性，又避免语义混淆。

4.3 知识抽取阶段（UTC 05:00–06:45）：规则引擎的12个核心断言

知识抽取不是一次性过程，而是按优先级顺序执行12个独立规则模块，每个模块输出facts表的一行。优先级由置信度决定——高置信度规则先执行，其结果可被低置信度规则引用。

Top 3高置信度规则（置信度≥0.9）：

extract_arxiv_id_from_pdf()：从PDF首页提取arXiv ID（匹配\d{4}\.\d{5}模式），验证与API返回ID一致，不一致则标记“ID冲突”，整篇论文进入人工队列；
detect_withdrawn_status()：检查PDF首页是否含“THIS PAPER HAS BEEN WITHDRAWN”红色横幅（OCR识别，准确率99.2%）；
identify_code_repository()：在摘要、致谢、附录中搜索GitHub/GitLab/HuggingFace链接，验证仓库存在且含README.md。

中置信度规则（0.7–0.85）：

infer_framework_from_code()：若代码仓库存在，克隆后分析requirements.txt，提取PyTorch/TensorFlow版本；
estimate_dataset_size()：从方法章节提取数据集描述，匹配预设模式（如“trained on 10M images from LAION-5B” → size=10000000）；
flag_methodological_risk()：检测“we use the same hyperparameters as [citation]”但未提供具体数值，标记为“超参未明”。

低置信度规则（<0.7）：

predict_reproducibility_score()：基于代码可用性、硬件描述、随机种子声明三要素加权计算，结果仅作参考，不写入facts表。

每个规则模块都带熔断机制：若单篇论文触发3次以上规则失败（如OCR识别失败、仓库404），则跳过该规则，避免阻塞流水线。2026年9月，平均每天有2.3篇论文因PDF质量问题进入人工审核队列，占比1.6%，在可接受范围。

4.4 报告生成与推送阶段（UTC 06:45–08:00）：模板化渲染与精准投递

报告不是PDF或HTML，而是纯文本邮件，原因有三：

学者习惯在邮件客户端快速扫描（手机端适配好）；
避免HTML渲染差异（Outlook对CSS支持差）；
纯文本可被企业邮件网关安全扫描，无附件风险。

邮件模板采用分层结构：

【arXiv日报】2026-09-29 | 共收录142篇 | 高价值论文3篇 --- PHD STUDENT VIEW --- [2305.12345] "DiffusionCLIP: Zero-Shot Segmentation via Text-Guided Diffusion" ★ ★ ★ ★ ☆ (4.2/5) | 复现难度：中等 | 代码：https://github.com/xxx/diffusionclip • Baseline对比：vs SAM, Mask2Former, Segment Anything (3个) • 注意：需A100-80GB，作者未提供FP16优化指南 --- ENGINEER VIEW --- [2305.12345] 同上 • 部署兼容性：PyTorch 1.13+ ✓ | ONNX ✗ | TensorRT △（需自定义kernel） • 推理耗时：128ms @ batch=1, A100 | 显存：4.2GB --- PI VIEW --- [2305.12345] 同上 • 潜在合作：该方法可迁移至我组农业无人机作物分割项目，需适配RGB-D输入 • 竞品对标：与我组2025年ICCV论文在text-guided分割上重叠度76%

关键实现细节：

动态收件人路由：根据用户注册时选择的角色（PhD/Engineer/PI），邮件只包含对应视图，避免信息过载；
智能去重：同一论文在不同视图中只出现一次，用[id]锚点关联；
时效性标注：每篇论文后加[UTC 07:22 processed]，让用户知道数据新鲜度；
退订机制：邮件底部固定行回复STOP取消订阅，用Mailgun Webhook实时同步退订状态。

最后一步是发送前校验：用mailchecker库验证收件人邮箱有效性，对无效邮箱（如拼写错误、域名不存在）自动静默丢弃，不发错信。2026年9月，日均发送成功率99.97%，失败0.03%全为临时网络抖动，重试后恢复。

5. 血泪教训：那些让日报系统崩溃的17个真实故障与修复方案

5.1 故障1：arXiv服务器返回503，但监控告警沉默

现象：2026-09-15 UTC 02:00，抓取任务全部超时，日志显示requests.exceptions.ConnectionError，但Prometheus监控显示API响应时间正常（<100ms）。
根因：arXiv在维护期间返回503，但HTTP Header中Retry-After字段为3600（1小时），而我的重试逻辑只做3次指数退避（最大等待8秒），未读取Retry-After。
修复方案：

所有HTTP请求添加response.headers.get('Retry-After')检查；
若存在，强制休眠对应秒数，再重试；
同时向Slack发送告警：“arXiv维护中，预计恢复时间：UTC 03:00”，避免运维盲等。

5.2 故障2：PDF解析卡死，拖垮整个流水线

现象：某篇论文PDF用pdfminer解析耗时12分钟，导致后续所有任务排队。
根因：该PDF含1200+页的附录，且每页有复杂矢量图，pdfminer的extract_text()陷入无限循环。
修复方案：

为所有PDF解析加timeout=30装饰器；
超时后启用备选方案：用pdftotext -layout命令行工具（C++实现，速度快10倍）；
若仍失败，则只提取首页文本，标记“PDF解析受限”，该论文分析降级。

5.3 故障3：GitHub仓库被作者删除，代码链接失效

现象：2026-09-20，3篇论文的has_code事实指向404 URL，导致PhD视图显示“代码可用”但实际不可用。
根因：作者删除仓库后，arXiv元数据未更新，API仍返回旧URL。
修复方案：

每日凌晨对所有has_code事实做健康检查（HEAD请求）；
404则更新facts.value为'DELETED'，confidence降为0.3；
在邮件中改为：“代码仓库已删除 [2026-09-20]”，并提供Wayback Machine快照链接。

5.4 故障4：中文摘要混入，导致规则引擎崩溃

现象：一篇cross-listed到cs.CL的论文，摘要含中文字符，LaTeX清洗后出现乱码，extract_code_url正则匹配失败。
根因：我的清洗流程假设所有文本为UTF-8，但部分作者用GBK编码上传PDF。
修复方案：

PDF文本提取前，用chardet库自动检测编码；
中文检测阈值：汉字占比>15% → 启用中文专用规则（如匹配“代码开源”“GitHub地址”等中文关键词）；
英文摘要中混中文时，保留原文，不强行翻译（避免语义失真）。

5.5 故障5：时区计算错误，漏掉UTC 23:59:59提交的论文

现象：2026-09-28的报告少了1篇，经查是作者在UTC 23:59:59提交，arXiv在29日00:01处理，但我的抓取窗口截止到29日00:00。
根因：datetime.utcnow()在Python中返回的是系统时钟，存在毫秒级误差，且arXiv处理延迟不可预测。
修复方案：

抓取窗口改为UTC 28日23:58:00 至 29日00:02:00，预留4分钟缓冲；
对缓冲期内的论文，检查submitted时间戳，仅当submitted >= 2026-09-28 23:00:00才纳入29日报告；
添加日志：“缓冲区论文X，submitted=2026-09-28 23:59:59，纳入2026-09-29报告”。

5.6 故障6：arXiv分类变更，导致cs.AI论文被漏抓

现象：2026-09-22，cs.AI分类下论文数突降80%，原因为arXiv将“LLM应用”子类迁移到新分类cs.AG（Artificial General Intelligence）。
根因：我的抓取逻辑硬编码categories=['cs.LG', 'cs.CV', 'cs.AI']，未监听arXiv分类变更公告。
修复方案：