每天早上八点arXiv 的 cs.CV 分类会刷新出当天的预印本列表。这个列表在 2026 年 9 月 9 日这一天新提交加上跨列表更新总数落在四百篇上下。四百篇是什么概念按每篇摘要 150 词算光把摘要从头读到尾就是六万字接近一本小册子。而这里面真正跟你手上课题相关、值得你花两小时精读的通常不超过五篇。我做这份「cs.CV 每日汇总」的出发点特别朴素把四百篇压成二三十条每条一句话讲清它干了什么、属于哪个方向、值不值得点开。它不是替代你读论文而是替你先趟一遍雷把你从信息筛选这件事里解放出来把时间留给真正的精读和动手复现。适合谁看刚入门计算机视觉、还在啃《计算机视觉算法与应用》那本厚书的学生要交大作业、想找条靠谱技术路线的人在工业界做视觉算法、需要盯住某个细分方向最新动向的工程师还有做交叉学科、只想快速判断这条线现在走到哪一步了的研究者。下面我把这份汇总从设计到落地的全过程拆开讲包括筛选逻辑、抓取脚本、速读方法以及这两年踩出来的一堆坑。1. 为什么要每天跟一份 cs.CV 论文汇总先说说这件事的价值到底在哪。计算机视觉这个方向的迭代节奏和别的领域不太一样它的公共节奏被两件事牵着走一是顶会的截稿周期CVPR、ICCV、ECCV 三年两届轮着来NeurIPS、ICLR、ICML 每年一次二是预印本平台的实时发布。前者决定了成果的官方认证时间后者决定了成果的事实曝光时间。这两者之间隔着少则半年、多则一年的时间差。也就是说当一篇工作正式出现在会议论文集里的时候它大概率已经在圈子里被讨论、被复现、被改进过好几轮了。所以对做 CV 的人来说盯着每天的预印本列表本质上是把自己接进了这个领域最快的那个信息通道。但通道快不等于有效。我见过太多人的做法是周末晚上打开列表从头翻到尾收藏夹塞了八十个链接然后一个都没点开。这不是懒是方式不对。信息摄入这件事有个反直觉的规律——单次摄入量越大单位信息的留存率越低。你一天看三十条经过筛选的条目记住的可能有十条你一周看两千条原始标题记住的可能只有三条还是因为标题里有你熟悉的词。所以这份汇总的第一条设计原则就是把发现和消费拆成两个动作每天只做发现深度消费留给真正值得的那几篇。1.1 arXiv 在计算机视觉工作流里的真实位置得先把 arXiv 是什么、不是什么说清楚不然后面所有判断都站不住。arXiv 是一个预印本发布平台不设同行评审门槛有一个基础的格式和分类审核但不评判学术质量。这意味着上面既有后来拿了最佳论文奖的工作也有实验设计得稀里糊涂、结论站不住的东西。我个人的经验是arXiv 上的工作大致可以分成四类判断标准和处理方式完全不同类型典型特征建议处理方式成熟工作方法完整、实验齐全、有开源代码、来自稳定产出团队精读值得复现阶段性成果核心想法清楚但实验只覆盖一两个数据集读方法和实验设置等后续版本综述与调研标题带 Survey、Review、Benchmark存下来需要时当索引查短平快记录篇幅短、缺少对比实验、结论外推严重扫一眼标题即可这个分类不是给论文贴标签是给你自己省时间。我有个习惯看到标题里带 Survey 或者 Benchmark 的直接进资料库文件夹不占当天的阅读预算。这类工作的价值在于你需要的时候能查到而不在于当天读完。1.2 为什么是每天而不是每周这一条我反复验证过。前两年我试过按周汇总效果很差。原因有两个一是记忆的锚点效应你每天花十五分钟扫一遍第二天再看到同一个方向的论文时脑子里会自动建立联系——哦这条线和昨天那篇是同一个思路的变体。按周看的话八十篇全堆在一起这种联系建立不起来。二是精读的启动成本当你手上有一份当天筛出来的、只有三到五篇必读的短名单时你会更容易直接开始读而面对一份八十篇的周报你的第一反应是先放放然后就永远放放了。说白了每日汇总的价值不在于信息量而在于把一次性的大决策拆成每天的小决策。每天只决定这三篇要不要今天读比每周决定这堆里哪五篇值得读要轻松得多执行率也高得多。1.3 这份汇总到底适合谁我把读者分成三类每类的用法不太一样第一类是入门阶段的学生。如果你刚开始学计算机视觉正在啃教材、准备大作业、或者考研复试要聊方向那么这份汇总对你的用法是建立地图。你不需要读懂每一篇你需要知道这个领域大致分成哪几块——图像分类、目标检测、语义分割、深度估计、光流、三维重建、生成模型、多模态、视频理解、医学影像、自动驾驶感知……每块下面现在活跃的问题是什么。看着看着你的地图就画出来了。我强烈建议入门的朋友先把透视几何、相机模型、卷积这些基础打牢再来追前沿否则你看到的全是名词堆砌。第二类是在读研究生和算法工程师。你们有明确的课题方向用法是盯梢。每天扫一遍看你关心的那条线上有没有新东西有没有人在做和你重复的工作有没有可以借用的模块或数据集。这是最典型的用法也是这份汇总设计时最主要的服务对象。第三类是做交叉研究或者只想知道个大概的人。用法是预警。你不需要读细节只需要知道某某方向今年热起来了某个老问题最近有人重新拿出来做。这类读者建议直接看每条的结论句不看方法。2. 汇总的整体设计与筛选思路从四百篇到二三十条中间要经过三轮过滤。这一章讲清楚每一轮在筛什么、为什么这么筛。2.1 三层漏斗从全量到短名单第一层是分类过滤。arXiv 的 cs.CV 分类本身已经是一个粗筛但它还是太宽。我在抓取的时候会同时拉取几个相关分类的交叉列表比如 cs.LG机器学习、cs.AI、eess.IV图像与视频处理、cs.RO机器人。原因是很多视觉工作会同时挂到这几个分类下只盯 cs.CV 会漏掉一部分。2026 年 9 月 9 日这一天跨列表去重之后的有效条目数比单纯的 cs.CV new 列表多了大约百分之十五这个比例不算小。第二层是主题过滤。这一步是纯规则的靠关键词匹配。我会维护一份主题词表比如检测方向匹配 detection、detector、DETR、anchor、NMS分割方向匹配 segmentation、mask、SAM、panoptic生成方向匹配 diffusion、flow matching、consistency、sampler。命中任意一个词就进候选池。这一层的作用不是精选是别把明显无关的剔掉所以阈值设得很松。第三层是人工确认。只有这一层是真正花时间的。候选池通常剩一百到一百五十条我把它按主题分好组然后逐组扫标题和摘要第一句。这一步的判断依据后面 4.1 会详细讲。注意不要在第一层和第二层上过度优化。我早期花了大量时间调关键词权重结果发现真正决定汇总质量的是第三层的人工那几分钟自动化再怎么调也替代不了。2.2 主题分类体系怎么定分类体系是这份汇总的骨架。我的体系是十二个大类下面分小类小类不固定每个月会微调一次。为什么是十二个因为再多就记不住了再少就会出现一条塞不进任何类的尴尬。大类覆盖范围常见子方向检测与定位目标检测、实例分割、关键点开放词汇检测、长尾检测、3D 检测分割与稠密预测语义分割、深度、法向、光流通用分割、视频分割、单目深度生成与合成图像生成、编辑、视频生成扩散采样加速、可控生成、风格迁移三维与重建神经辐射场、高斯泼溅、点云前馈重建、动态场景、大场景多模态与视觉语言图文对齐、视觉问答、视觉定位视觉指令微调、文档理解、视频问答视频与时空理解动作识别、时序定位、跟踪长视频理解、事件相机、运动预测自监督与表征学习预训练、对比学习、掩码建模视觉基础模型、蒸馏、适配器高效推理与部署量化、剪枝、蒸馏、算子端侧部署、稀疏注意力、编译优化医学与生物影像影像分割、病理、显微弱监督标注、跨模态配准自动驾驶与机器人感知、预测、规划接口占据栅格、端到端驾驶、SLAM底层视觉与图像处理超分、去噪、去模糊、增强盲复原、低光照、压缩感知数据集、评测与综述新数据集、新指标、调研鲁棒性评测、偏差分析这套分类有个特点它是按问题分的不是按方法分的。为什么不按方法分因为方法会过时问题不会。五年前大家用卷积现在大家用 Transformer 和状态空间模型但单目深度估计这个问题一直在。按问题分类你的体系能用很多年维护成本低。2.3 打分与排序的规则候选池里的一百多条我需要一个顺序决定先看哪几条。这里用的是一个加权打分权重是我自己拍的但逻辑讲得通score 0.35 × 主题权重 0.25 × 摘要信号词命中数归一化 0.20 × 作者/机构历史命中率 0.10 × 时效性当天为 1隔天衰减 0.10 × 篇幅与完整性有代码链接加分主题权重是我手动设的跟我当前课题强相关的方向权重高。这里有个坑值得说如果你把主题权重设得太极端汇总会退化成只推你已经在看的东西你永远发现不了新方向。我的做法是每个月留出百分之二十的额度给弱相关但有趣的条目强制自己看一眼。这个习惯帮我发现过好几次真正有价值的跨领域方法。3. 抓取与整理的实操流程这一章是能直接抄作业的部分。整套流程跑在一台普通笔记本上不需要服务器。3.1 数据来源与元数据字段数据来源就是这个平台提供的公开查询接口返回的是 Atom 格式的 XML。需要拉取的字段有这些条目标识、标题、摘要、作者列表、分类标签主分类和交叉分类、提交时间、更新版本号、以及摘要里出现的链接和代码地址。其中分类标签和提交时间是最容易被忽略但最有用的两个字段分类标签能告诉你这篇工作自己认为属于哪个领域有时候和你的判断不一样这个差异本身就有信息量提交时间能让你判断这是初版还是第三版修订。3.2 用 Python 拉取与解析下面是我在用的脚本骨架改一下主题词表就能跑。import time import urllib.parse import urllib.request import xml.etree.ElementTree as ET API http://export.arxiv.org/api/query NS {a: http://www.w3.org/2005/Atom} # 主题词表命中任意一个词就进候选池 TOPIC_HINTS { detection: [detection, detector, detr, open-vocabulary], segmentation: [segmentation, mask, panoptic, sam], generation: [diffusion, flow matching, consistency, text-to-image], 3d: [nerf, gaussian splatting, point cloud, reconstruction], vlm: [vision-language, vqa, captioning, multimodal], video: [video, temporal, tracking, action recognition], efficient: [quantization, pruning, distillation, on-device], lowlevel: [super-resolution, denoising, deblurring, restoration], } def fetch(categorycs.CV, max_results400, start0): query fcat:{category} params { search_query: query, start: start, max_results: max_results, sortBy: submittedDate, sortOrder: descending, } url API ? urllib.parse.urlencode(params) with urllib.request.urlopen(url, timeout30) as resp: return resp.read() def parse(xml_bytes): root ET.fromstring(xml_bytes) items [] for entry in root.findall(a:entry, NS): title .join(entry.find(a:title, NS).text.split()) summary .join(entry.find(a:summary, NS).text.split()) published entry.find(a:published, NS).text cats [c.attrib[term] for c in entry.findall(a:category, NS)] authors [a.find(a:name, NS).text for a in entry.findall(a:author, NS)] items.append({ id: entry.find(a:id, NS).text, title: title, summary: summary, published: published, cats: cats, authors: authors, }) return items def tag_topics(items): for it in items: text (it[title] it[summary]).lower() hits [k for k, words in TOPIC_HINTS.items() if any(w in text for w in words)] it[topics] hits return [it for it in items if it[topics]] if __name__ __main__: raw fetch(max_results400) time.sleep(3) # 别忘了礼貌间隔 data parse(raw) print(total:, len(data), filtered:, len(tag_topics(data)))这段代码有几个地方是踩过坑才加上的。time.sleep(3)必须留接口对请求频率是有限制的连续快速请求会被返回错误或者返回空结果而且它不报错就是静默地给你少数据你排查半天以为是解析写错了。max_results单次不要超过 2000超了会被截断到 2000 并且不提示。分页要用start参数配合循环每页 100 到 200 条比较稳。3.3 去重、合并与格式化输出跨分类拉取一定会遇到重复条目。去重不能只看标题因为同一篇工作的标题在修订后可能微调稳妥的做法是用条目标识里的编号去重这个编号在版本更新时保持不变只有版本号后缀会变。import re def dedup(items): seen, out {}, [] for it in items: key re.sub(rv\d$, , it[id].rsplit(/, 1)[-1]) if key not in seen: seen[key] it out.append(it) else: # 保留发布时间更早的初版版本信息另存 seen[key].setdefault(versions, []).append(it[id]) return out格式化输出我建议直接生成 Markdown一条一行格式是- **[主题标签] 标题** —— 一句话说清它干了什么。 关键点方法一句话 / 数据一句话。链接提示摘要里的第一句和最后一句信息密度最高。第一句通常是问题定义最后一句通常是结果或者贡献声明。中间那几句往往是前人怎么做的、有什么问题扫读时可以先跳过。3.4 每天的时间预算怎么分配这套流程我听下来固定成本大概是这样的环节耗时是否可自动化抓取与解析2 分钟完全自动主题打标与打分1 分钟完全自动人工扫读候选池15-20 分钟不能撰写条目一句话10-15 分钟半自动精读必读篇目60-120 分钟不能也就是说汇总本身的固定成本在半小时以内剩下的时间全给精读。如果你的流程超过四十分钟才能产出说明自动化的部分没做够或者你的人工扫读粒度太细了。我见过有人给每条都写三行点评结果每天花两小时整理坚持两周就放弃了。4. 论文速读的判断方法这一章讲的是最核心的手艺怎么在三分钟内判断一篇论文值不值得读。这个判断做准了前面所有自动化才有意义。4.1 三分钟判断法看什么、不看什么我的顺序是固定的标题 → 摘要第一句 → 图表 → 实验表格 → 结论。中间的方法部分先不读。标题三十秒。看它声称解决的是什么问题。如果一个标题里出现了两个以上的名词堆砌比如基于某某的某某某某方法用于某某某某这通常说明作者自己也没想清楚核心贡献是什么警惕。摘要第一句一分钟。这一句一般会说某某任务存在某某问题或者我们提出了某某。如果第一句是近年来某某领域取得了长足进展这种直接跳到倒数第二句。真正好的摘要第一句就是问题最后一句就是结果。图表一分钟。快速翻到方法图看它是不是一眼能看懂。我有个不太严谨但很好用的经验**方法图能在十秒内看懂的论文作者通常思路清晰方法图需要看三分钟还看不懂的大概率是方法本身有问题或者作者表达能力差。**这两种情况都不值得你花时间。实验表格三十秒。只看三件事在哪些数据集上做的、跟谁比的、提升幅度多少。如果只在自家数据集上验证或者只跟三年前的方法比果断放弃。结论三十秒。看作者自己承认的局限性。敢写局限性的论文通常更可信。4.2 摘要里的信号词清单扫读的时候有些词能帮你快速定位论文的性质。我整理了一份自己用的对照表信号词含义处理建议we propose / we introduce常规贡献声明几乎每篇都有看后面的具体内容state-of-the-art / SOTA声称达到最好看对比表格是否公平without training / training-free免训练方法近期热门值得看zero-shot / open-vocabulary零样本、开放词表泛化能力强重点看benchmark / dataset数据集或评测工作存资料库survey / review综述存资料库ablation消融实验说明实验做得细limitation / failure case局限性讨论可信度加分code is available有开源代码可复现性加分注意把training-free和zero-shot这两个词当成高优先级信号是我这两年调整过来的一条规则。原因很实际——工业落地最怕的就是每换一个场景就要重新标注、重新训练免训练和零样本的方法哪怕精度暂时差一点工程价值也往往更高。4.3 笔记模板别让读过的论文白读速读之后一定要留痕不然一周后你只记得好像看过一篇讲这个的。我用的是一个极简模板一条论文不超过六行[日期] [主题标签] 标题 一句话贡献 方法核心一个词或短语 关键数据数据集 提升幅度 我的关联和我在做的 X 有什么关系 / 可以借用的点那个我的关联是整份笔记里最重要的一行。没有这一行你的笔记就只是摘抄不是知识。我翻自己两年前的笔记能立刻用上的全是我的关联写得具体的那几条纯摘抄的那些基本没再看过。5. 常见问题与排查技巧实录这一章是我这两年里真实遇到的坑按出现频率排的。5.1 抓取环节的典型问题问题一抓回来的条目数明显偏少。排查顺序是先看请求参数里的分类名有没有写错大小写敏感cs.CV和cs.cv表现不一样再看是不是单次max_results设太大被截断最后看是不是触发了频率限制。频率限制这个问题最坑它有时候返回的是正常的 XML 结构只是条目少你不仔细对数量根本发现不了。问题二解析出来的摘要里有奇怪的换行和多余空格。这是 XML 里原始文本就带的换行符导致的用 .join(text.split())一行就能清掉。别用正则去替换\n会漏掉\r和连续空格。问题三时区问题导致日期错位。返回的时间是 UTC你在东八区看到9 月 9 日的列表实际对应的可能是本地时间的 9 月 9 日晚上到 9 月 10 日凌晨。如果你按本地日期做归档会出现前后两天的条目交叉。我的做法是统一按 UTC 日期归档在本地显示的时候再转换。5.2 信息过载与筛选失灵症状一候选池越来越大扫读时间从 15 分钟涨到 40 分钟。这说明你的主题词表膨胀了。我的规矩是词表总量控制在八十个词以内每加一个词就要删一个词。症状二连续一周没有找到值得精读的论文。这时候要检查你的主题权重是不是设得太偏或者你的关注方向最近确实是低谷期。前者调权重后者正常不用焦虑一个方向的活跃度本来就有周期。症状三读了很多但感觉没长进。大概率是你只读不写。我强制自己每周写一段两百字的小结讲这周读的东西里有什么共性。写不出来说明这周白读了。5.3 常见问题速查表现象可能原因处理方式抓取条目数异常少分类名错误 / 结果被截断 / 频率限制检查参数加请求间隔同一条重复出现跨分类列表重叠用编号去重去掉版本后缀摘要显示乱XML 原生换行符用 split/join 规范化日期归档错位UTC 与本地时区差异统一按 UTC 归档扫读时间过长主题词表膨胀词表总量设上限定期裁剪找不到可读论文主题权重过偏 / 方向低谷留出探索额度或接受周期读了没长进缺少输出环节每周写一段小结排序结果不合理权重与实际需求脱节每月复盘一次权重提示这套排查表建议直接贴在工位上。里面的每一条我都是真踩过才写进去的尤其是频率限制那条我当初花了整整一个下午才发现问题出在请求间隔上而不是解析代码。6. 长期维护的两个关键点6.1 分类体系会漂移要主动维护刚开始做的时候我以为分类体系定下来就不用动了实际不是。这个领域的重心在移动两年前我的列表里三维重建只有三四个子方向现在光高斯泼溅相关就能分出五六个分支反过来底层视觉里的某些子方向这两年产出明显变少条目一周也就一两条。所以我现在每个月固定花半小时做一次分类复盘看哪些类目长期空着、哪些类目条目多到需要拆开。调整的时候有个原则只在类目连续两个月条目超过总条目百分之十五的时候才拆只在类目连续两个月条目低于百分之三的时候才合。不要因为某一天某个方向突然多了就动结构单日波动噪声太大。6.2 从汇总到选题汇总的真正用途做了这么久我越来越觉得汇总最大的价值不是知道发生了什么而是知道什么还没被做。每天扫一百多条摘要你会慢慢发现一些反复出现的、但始终没人正面解决的问题。比如说你连着两周看到不同团队在做同一个任务的加速但都在某一个具体场景下失效这个共同的失效点就是机会。我个人的做法是维护一个悬而未决清单专门记那些在摘要里被反复提及但没人正面处理的问题。这个清单现在有三十多条其中有三条已经变成了我自己的研究方向。这个清单的写法很简单就是一句话谁在什么条件下失败了失败的共同原因可能是什么。记的时候不用写长关键是持续记、定期回看。另外一个实际的心得是不要试图读完所有条目。我给自己定的规则是每天必读不超过五篇其中至少一篇是弱相关但有趣的。这个配比我从去年调整到现在感觉比只读强相关的产出高。因为强相关的那些你迟早会通过别的渠道知道弱相关的那些往往只有在这个固定的扫读动作里才能碰上。