1. 今天的投稿热度：轻量化与推理期优化继续占主导
早上照例打开 arXiv 的 cs 板块刷最新提交，今天的更新量比暑假那段时稳定了不少。我扫了约四五十篇标题才开始打标签，边看边在草稿纸上记下高频词。整体感觉非常明显：cs.CV、cs.CL、cs.LG 三个板块依然是主力军，而“lightweight”“efficient”“test-time”“verifier”这几个关键词在标题里反复出现。以前大家比的是谁能用更少的显存把模型训出来，现在越来越多的文章比的是“在同样一次回答里，怎么把计算花在刀刃上”——典型如测试时计算分配、验证器、拒绝采样这一类思路。
另一个值得注意的点是，cs.CL 板块里“alignment”还经常出现，但跟着“RLHF”走的文章明显少了，取而代之的是“preference optimization”“direct alignment”这类更轻量的偏好对齐。而 cs.CV 这边，“3D reconstruction”和“Gaussian”依旧是高频词，但不少新工作都在做“用更小的模型做单图重建”。这个走向和过去几个月的趋势基本一致：2026 年的研究重点已经不完全是把模型做大，而是如何在中端算力下拿到更可靠的收益。这个判断直接影响我今天愿意精读哪些文章，也决定了哪些论文只需要扫一眼摘要就可以归档。
1.1 从标题词频看：哪些方向最拥挤
我把今天比较大的几个板块标题快速过了一遍，做了个简单统计。与其列一堆抽象分析，不如直接用一张表说清楚：
| 板块 | 今日高频词 | 我看到的信号 |
|---|---|---|
| cs.LG | lightweight, efficient, test-time, verifier | 推理阶段优化占主流，精读时要重点看延迟和算力开销 |
| cs.CL | alignment, preference, self-improve | 偏好对齐从 RLHF 走向更简化、更便宜的手法 |
| cs.CV | 3D recon, Gaussian, single-view | 轻量重建热度不减，但对泛化性的评估很关键 |
| cs.AI | plan, rollback, tool-use, environment | Agent 的工程化议题明显多于纯算法创新 |
我之所以每次都关注标题词频，不只是为了追踪热点。更实际的作用是校准阅读路线：当某个词连续两周高频出现，我就会去翻这一波工作都在引用哪些早期论文，通常能顺藤摸瓜找出真正有价值的源头工作。比如“test-time”这个词连续刷屏之后，我找到的那几篇关于验证器和计算重分配的原始论文，反而比后来跟风刷榜的文章更有阅读价值。
1.2 藏在角落里的交叉学科稿
还有一个容易被漏掉的类型：交叉学科投稿，比如把生物序列、材料结构这类建模问题投到 cs.LG 下来；以及一批“负结果”或“诚实复现”类的经验论文，标题往往不起眼，作者甚至会直接在标题里写“We reproduced and found”。这类文章通常不会被社区顶到前排，但对于真正做工程落地的人来说，价值往往比一篇花哨的基准刷榜高得多。
今天早上我就看到一篇把注意力换成傅里叶特征线性注意力的生物序列建模文章，方法本身挺直接，但实验做得很扎实。这种文章如果不是每天坚持刷标题，很容易被淹没在几百篇更新里。这也正是我坚持做每日分析报告的原因：不是每个工作都会通过社交媒体的热度自动走到你面前，很多时候得靠自己的筛子把它捞出来。
2. 今天列入精读名单的四类工作
按今天的观察，我把四篇论文列入了精读名单。它们并不全是“热门高分”文章，但每一篇都代表了一个我最近比较关注的问题方向。我读论文的习惯是拿到一篇先不急着看公式，先逼自己回答一个问题：这篇文章试图改写的隐含假设是什么？回答不了这个问题，往下读就很容易变成机械的词汇浏览。
2.1 视觉推理模型里的“验证器重分配”
先说视觉语言推理方向。今天有一篇工作的核心痛点很明确：多模态大模型在复杂视觉问题上回答质量不稳，直接堆大参数又不划算。所以它把注意力放在了“解码阶段多花一点计算”上——训练时用中等规模的模型，推理时在输出答案前先生成若干个中间验证步骤，每个步骤都会重新对准图像中的证据区域，最后再合并成最终答案。
“把算力花在验证而不是生成”这个假设我认为是成立的，尤其在视觉推理这种容易产生幻觉的场景里。但真正到工程落地就有一个很现实的问题：多阶段调用会把首字延迟明显拉高，可能从几百毫秒变成好几秒，而论文里往往不会给出端到端时延指标。所以我读这篇文章时，特意去翻实验部分有没有带延迟数据，以及有没有配合投机采样、并行验证这类工程优化。没有这些数据，文章方法再好，也只能停留在 idea 层面。
2.2 Token 图谱上的结构先验
第二篇工作偏向长文档和知识密集型问答，解决的问题是标准自注意力缺少显式结构信息。它的做法是在 token 序列之上额外抽取一个“语义邻近图”，让信息既沿着序列流动，也沿着图中一跳、两跳的路径传递。这样做的好处是长上下文里的关键实体能更快相遇，减少远距离信息丢失。
我判断这类工作的作者大概率是 NLP 出身，因为整个实验设计围绕的是离散实体、共现关系、表格推理这类任务，而不是通用 benchmark 的单纯刷分。对做 RAG 或长文本应用的人来说，这种结构增强思路可以直接迁移到检索重排环节。我读的时候会特别关注一个问题：图的构建成本高不高？是动态构建还是预计算？如果需要额外一次语义分析模型来做建图，那整体收益就要重新算账，不能只看下游任务指标涨了多少。
2.3 三维重建的轻量化蒸馏
三维重建依然是持续出成果的领域。今天这篇属于 splatting 类方法的进一步演化：把多视图大模型的能力蒸馏到一个小模型上，让小模型在单张图输入时也能生成近似多视角一致的几何与外观输出。这类工作的卖点是推得动、能落地，但评估环节经常有坑——如果训练集和测试集来自同一套场景分布，指标再好看也说明不了泛化性。
我精读时会重点看两件事：一是有没有跨域实验，比如对不同光照、不同相机参数的数据做零样本测试；二是蒸馏损失的设计，如果只保留了渲染一致性，而不做特征层面的一致性约束，那模型在遇到分布偏移时崩得会非常快。如果实验部分只有三张相似数据集的表格，我不会给太高评价。
2.4 Agent 长任务里的回滚与容错
第四篇严格说不是纯算法论文，而是一个系统实现。内容是多 Agent 在复杂任务中互相调用工具时，如果其中一个 Agent 产生了错误中间结果，系统如何定位问题并回滚到最近一个可信状态。它的思路是把分布式系统里的“检查点 + 日志回放”搬到 LLM 执行过程中，换来长链路任务成功率的提升。
我把它列入精读，不是因为它方法多惊艳，而是因为它代表了一个工程方向：当 Agent 系统从 demo 走向稳定服务，容错和可观测性一定比单点聪明更重要。论文实验用的是长链路工具调用任务，并且把失败日志做了分类分析，这一点非常实用。如果后续开源了执行日志，会很适合拿来做二次开发或模拟故障注入测试。
把这几篇放在一起看，共同点是它们都在强调可靠性和可控开销，而不是单纯的效果提升。相比前几年那种“为了涨一个点把模型做大十倍”的玩法，2026 年的论文成熟度确实提高了不少。
3. 三层过滤器：把每天几百篇论文压到三篇
arXiv 每天新增的论文数量非常可观，如果每一篇都点开看，两三个小时就没了，而且什么都看不深。所以我的日常不是“读完所有论文”，而是“在正确的时间选出少数几篇值得全神贯注的论文”。这套筛选能力是我写每日分析报告以来收获最大的部分。
3.1 标题、摘要、图表：我的判断规则
我给自己定了一套三层过滤器，每一层只需要几十秒。
第一层是标题。标题里同时出现“增强”“优化”“改进”这类字眼，却又不说清楚任务边界的，我会警惕；直接给出任务名和场景的，优先级更高。像“面向通用智能的高效统一框架”这种标题，往往信息量为零。
第二层是摘要。我会重点看三件事：第一句能不能在十秒内说清要解决的问题？中间有没有给出具体做法？最后有没有出现“在多个数据集上显著提升”这种空泛收尾？凡是三条里占了两条负面信号的，基本降级为泛读。
第三层是图表。对备选精读的论文，我会先扫一遍图。误差条很重要，如果图里只有三根柱子、没有误差区间，说明实验不太经得起重复。有没有跨域对比也很关键，没有 cross-domain 或 ablations 的图，我一般不会花时间精读。
| 信号 | 倾向处理 | 理由 |
|---|---|---|
| 标题含具体任务名与场景 | 精读候选 | 定位清晰，大概率有明确贡献 |
| 标题很宏大但无边界 | 跳过或泛读 | 大概率是包装型论文 |
| 摘要给出做法并能自圆其说 | 精读 | 可复现概率高 |
| 图表有误差条、有跨域实验 | 优先精读 | 实验更扎实 |
| 仅有单一数据集、无误差条 | 放弃 | 结论说服力不足 |
3.2 今天我果断跳过的几篇论文长什么样
今天我也跳过了一些典型的“包装型论文”。其中一篇标题叫“面向通用智能的高效统一框架”，摘要里却只在一个单一任务数据集上汇报结果，我连图都没点开就归档了。另一篇通篇在强调“SOTA”，但对比的 baseline 没有一项是近两年提出的新方法，这类对比其实参考价值很有限。
还有一种要跳过的是“配方堆叠论文”：把五个已有技巧组合一下，刷出一个新数字，但完全说不清楚每个模块的贡献边界。这种论文读了也不容易形成可迁移的认知，因为它没有提供任何关于问题的结构性洞察。倒不是说它没有价值，只是对我的时间和精力来说，回报太低。
4. 每天写这份分析报告，我用到的工具与固定流程
写每日分析报告这件事，真正难的不是“读”，而是“坚持”。为了让这套流程可持续，我做了不少工具化的工作，把每天要消耗的意志力降到最低。现在每天花在筛选上的时间大约四十分钟，精读一到两小时，写报告三十分钟。
4.1 本地抓取当天提交：用脚本把候选列表收拢
我很少依赖订阅邮件，因为邮箱里论文列表一旦堆积到周末，反而更不想点开。我选择每天早上用脚本主动抓取当天的 arXiv 更新，做一遍初步过滤。下面是一个最简单的拉取示例，用 Python 调 arXiv API：
import urllib.request import xml.etree.ElementTree as ET base = "http://export.arxiv.org/api/query?search_query=cat:cs.CV" query = base + "+AND+submittedDate:[202609230000+TO+202609240000]&start=0&max_results=200" with urllib.request.urlopen(query) as resp: data = resp.read() root = ET.fromstring(data) for entry in root.findall("{http://www.w3.org/2005/Atom}entry"): title = entry.find("{http://www.w3.org/2005/Atom}title").text.strip() summary = entry.find("{http://www.w3.org/2005/Atom}summary").text.strip() print("-", title[:80])这段脚本本身不复杂，但它把“等邮件推送”变成了“主动取数据”，心态会完全不一样。我每天固定早上八点半跑一次，把结果存到本地 md 文件里，当天晚上再回来看。只需要按需调整 cat: 后面的分类代码，就可以同时拉 cs.CL、cs.LG、cs.AI 等多个板块。
4.2 关键词打分与黑名单：把人工阅读量压缩到三分之一
只抓标题列表还不够，我还会在脚本里加一个简单的关键词打分逻辑。每个方向给一组正向词和负向词，跑完以后自动排序，把分数最高的文章置顶。
| 词/方向 | 权重 | 用途 |
|---|---|---|
| test-time, verifier, inference | +3 | 优先看推理阶段同类工作 |
| latent, diffusion, generative | +2 | 生成模型方向跟进 |
| SOTA, comprehensive, unified | -2 | 警惕宏大但空洞的表述 |
| reproduction, negative result | +3 | 鼓励诚实复现类文章 |
实际跑下来，这套白名单加黑名单能把每天需要人工浏览的比重降到三分之一左右。我不追求它替我做判断，只希望它帮我把明显值得看的东西顶到前面，把明显不值得看的东西先沉到底部。今天早上过滤后，列表从两百多篇缩小到七十余篇，我再从这七十余篇里做人工筛选，压力小很多。
4.3 报告终稿的固定格式与周复盘
我的每日报告格式并不花哨：按领域分区，每个分区先写一句总览，再列要点，最后给 2-3 条“值得下周追踪”的线索。这个格式的好处是它不需要我每天切换思路，看一眼标题就知道该往哪个区块放。所有报告按日期归档到本地日志目录，周五花半小时做一次周复盘：本周精读了哪些方向、有没有连续看到同一个问题的不同解法、下周要不要调整关注关键词。
这套流程在最开始执行时并不顺利，前两周经常因为“怕错过重要论文”而囤一堆没读完的标签，结果周末反而更焦虑。后来我意识到，每日分析的价值根本不在于穷尽，而在于保持一个稳定、持续、有判断力的输入通道。雷打不动地每天做，比某一天狂读三十篇有用得多。
5. 半年复盘：读论文的品位比数量更重要
坚持写了大半年分析报告之后，我发现自己最大的变化其实不是“读得快了”，而是“判断得准了”。一开始我也踩过那种“每天十篇起步，标记了不读，下次再看还是陌生”的误区，后来才慢慢摸到一些更可靠的经验。
5.1 读得久不代表读得准，判断力才是复利
以前我看到一个热门方向，会忍不住把相关论文全下载下来，攒一个文件夹，然后就没有然后了。现在我会刻意控制“收藏”的冲动，真正进精读名单的论文每天不超过三篇。半年下来，我对几个核心方向的来龙去脉反而比那些“下载了三百篇”的人更清楚。因为精读过的每篇文章都在大脑里留下了结构化的位置，后来再读新文章时，能快速回答“它比我读过的那篇强在哪、弱在哪、前提条件是什么”。这种能力是慢慢积累出来的，没有捷径。
5.2 精读上限三篇，宁深勿浅
精读名单一旦超过三篇，就不自觉地滑向泛读，最后每篇都只记得标题和摘要。我现在宁可只精读两篇、每篇读透，也绝不浅尝五篇。所谓的“读透”，对我来说意味着能回答三个问题：它解决什么问题、它的核心假设是什么、如果去掉某一个模块，它还能不能成立。第三个问题最费时间，但也是最值得花时间的地方。
5.3 把论文当作一次假设检验来读
最后一条心得可能听起来有点抽象，但做研究之后会很受用：读每篇论文时，试着把作者的隐含假设写出来。比如“轻量化蒸馏”那篇文章，隐含假设是单一模型能容纳多视图一致性；“验证重分配”那篇，隐含假设是解码时增加验证步骤的收益大于开销。检验这个假设是否成立，比记住公式更重要。如果假设是成立的，那这篇论文大概率有价值；如果假设本身就很脆弱，那无论实验指标多漂亮，都只是在局部问题上做了一个短期修补。
就在整理今天这份报告的过程中，我又给下周的筛选规则加了一条：凡是只汇报平均提升、不给分位数和误差范围的文章，一律降到泛读档。这个细节看似很小，但对于判断真实收益非常关键。每天坚持做这样一件“小而不难”的事，半年下来，你对一个领域的感知会变得完全不同。
