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.LGlightweight, efficient, test-time, verifier推理阶段优化占主流精读时要重点看延迟和算力开销cs.CLalignment, preference, self-improve偏好对齐从 RLHF 走向更简化、更便宜的手法cs.CV3D recon, Gaussian, single-view轻量重建热度不减但对泛化性的评估很关键cs.AIplan, rollback, tool-use, environmentAgent 的工程化议题明显多于纯算法创新我之所以每次都关注标题词频不只是为了追踪热点。更实际的作用是校准阅读路线当某个词连续两周高频出现我就会去翻这一波工作都在引用哪些早期论文通常能顺藤摸瓜找出真正有价值的源头工作。比如“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 APIimport urllib.request import xml.etree.ElementTree as ET base http://export.arxiv.org/api/query?search_querycat:cs.CV query base ANDsubmittedDate:[202609230000TO202609240000]start0max_results200 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, inference3优先看推理阶段同类工作latent, diffusion, generative2生成模型方向跟进SOTA, comprehensive, unified-2警惕宏大但空洞的表述reproduction, negative result3鼓励诚实复现类文章实际跑下来这套白名单加黑名单能把每天需要人工浏览的比重降到三分之一左右。我不追求它替我做判断只希望它帮我把明显值得看的东西顶到前面把明显不值得看的东西先沉到底部。今天早上过滤后列表从两百多篇缩小到七十余篇我再从这七十余篇里做人工筛选压力小很多。4.3 报告终稿的固定格式与周复盘我的每日报告格式并不花哨按领域分区每个分区先写一句总览再列要点最后给 2-3 条“值得下周追踪”的线索。这个格式的好处是它不需要我每天切换思路看一眼标题就知道该往哪个区块放。所有报告按日期归档到本地日志目录周五花半小时做一次周复盘本周精读了哪些方向、有没有连续看到同一个问题的不同解法、下周要不要调整关注关键词。这套流程在最开始执行时并不顺利前两周经常因为“怕错过重要论文”而囤一堆没读完的标签结果周末反而更焦虑。后来我意识到每日分析的价值根本不在于穷尽而在于保持一个稳定、持续、有判断力的输入通道。雷打不动地每天做比某一天狂读三十篇有用得多。5. 半年复盘读论文的品位比数量更重要坚持写了大半年分析报告之后我发现自己最大的变化其实不是“读得快了”而是“判断得准了”。一开始我也踩过那种“每天十篇起步标记了不读下次再看还是陌生”的误区后来才慢慢摸到一些更可靠的经验。5.1 读得久不代表读得准判断力才是复利以前我看到一个热门方向会忍不住把相关论文全下载下来攒一个文件夹然后就没有然后了。现在我会刻意控制“收藏”的冲动真正进精读名单的论文每天不超过三篇。半年下来我对几个核心方向的来龙去脉反而比那些“下载了三百篇”的人更清楚。因为精读过的每篇文章都在大脑里留下了结构化的位置后来再读新文章时能快速回答“它比我读过的那篇强在哪、弱在哪、前提条件是什么”。这种能力是慢慢积累出来的没有捷径。5.2 精读上限三篇宁深勿浅精读名单一旦超过三篇就不自觉地滑向泛读最后每篇都只记得标题和摘要。我现在宁可只精读两篇、每篇读透也绝不浅尝五篇。所谓的“读透”对我来说意味着能回答三个问题它解决什么问题、它的核心假设是什么、如果去掉某一个模块它还能不能成立。第三个问题最费时间但也是最值得花时间的地方。5.3 把论文当作一次假设检验来读最后一条心得可能听起来有点抽象但做研究之后会很受用读每篇论文时试着把作者的隐含假设写出来。比如“轻量化蒸馏”那篇文章隐含假设是单一模型能容纳多视图一致性“验证重分配”那篇隐含假设是解码时增加验证步骤的收益大于开销。检验这个假设是否成立比记住公式更重要。如果假设是成立的那这篇论文大概率有价值如果假设本身就很脆弱那无论实验指标多漂亮都只是在局部问题上做了一个短期修补。就在整理今天这份报告的过程中我又给下周的筛选规则加了一条凡是只汇报平均提升、不给分位数和误差范围的文章一律降到泛读档。这个细节看似很小但对于判断真实收益非常关键。每天坚持做这样一件“小而不难”的事半年下来你对一个领域的感知会变得完全不同。 
长河君 · 2026/11/4 8:48:08 · 阅读 1.2k 每日arXiv论文筛选：聚焦轻量化与推理期优化
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.LGlightweight, efficient, test-time, verifier推理阶段优化占主流精读时要重点看延迟和算力开销cs.CLalignment, preference, self-improve偏好对齐从 RLHF 走向更简化、更便宜的手法cs.CV3D recon, Gaussian, single-view轻量重建热度不减但对泛化性的评估很关键cs.AIplan, rollback, tool-use, environmentAgent 的工程化议题明显多于纯算法创新我之所以每次都关注标题词频不只是为了追踪热点。更实际的作用是校准阅读路线当某个词连续两周高频出现我就会去翻这一波工作都在引用哪些早期论文通常能顺藤摸瓜找出真正有价值的源头工作。比如“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 APIimport urllib.request import xml.etree.ElementTree as ET base http://export.arxiv.org/api/query?search_querycat:cs.CV query base ANDsubmittedDate:[202609230000TO202609240000]start0max_results200 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, inference3优先看推理阶段同类工作latent, diffusion, generative2生成模型方向跟进SOTA, comprehensive, unified-2警惕宏大但空洞的表述reproduction, negative result3鼓励诚实复现类文章实际跑下来这套白名单加黑名单能把每天需要人工浏览的比重降到三分之一左右。我不追求它替我做判断只希望它帮我把明显值得看的东西顶到前面把明显不值得看的东西先沉到底部。今天早上过滤后列表从两百多篇缩小到七十余篇我再从这七十余篇里做人工筛选压力小很多。4.3 报告终稿的固定格式与周复盘我的每日报告格式并不花哨按领域分区每个分区先写一句总览再列要点最后给 2-3 条“值得下周追踪”的线索。这个格式的好处是它不需要我每天切换思路看一眼标题就知道该往哪个区块放。所有报告按日期归档到本地日志目录周五花半小时做一次周复盘本周精读了哪些方向、有没有连续看到同一个问题的不同解法、下周要不要调整关注关键词。这套流程在最开始执行时并不顺利前两周经常因为“怕错过重要论文”而囤一堆没读完的标签结果周末反而更焦虑。后来我意识到每日分析的价值根本不在于穷尽而在于保持一个稳定、持续、有判断力的输入通道。雷打不动地每天做比某一天狂读三十篇有用得多。5. 半年复盘读论文的品位比数量更重要坚持写了大半年分析报告之后我发现自己最大的变化其实不是“读得快了”而是“判断得准了”。一开始我也踩过那种“每天十篇起步标记了不读下次再看还是陌生”的误区后来才慢慢摸到一些更可靠的经验。5.1 读得久不代表读得准判断力才是复利以前我看到一个热门方向会忍不住把相关论文全下载下来攒一个文件夹然后就没有然后了。现在我会刻意控制“收藏”的冲动真正进精读名单的论文每天不超过三篇。半年下来我对几个核心方向的来龙去脉反而比那些“下载了三百篇”的人更清楚。因为精读过的每篇文章都在大脑里留下了结构化的位置后来再读新文章时能快速回答“它比我读过的那篇强在哪、弱在哪、前提条件是什么”。这种能力是慢慢积累出来的没有捷径。5.2 精读上限三篇宁深勿浅精读名单一旦超过三篇就不自觉地滑向泛读最后每篇都只记得标题和摘要。我现在宁可只精读两篇、每篇读透也绝不浅尝五篇。所谓的“读透”对我来说意味着能回答三个问题它解决什么问题、它的核心假设是什么、如果去掉某一个模块它还能不能成立。第三个问题最费时间但也是最值得花时间的地方。5.3 把论文当作一次假设检验来读最后一条心得可能听起来有点抽象但做研究之后会很受用读每篇论文时试着把作者的隐含假设写出来。比如“轻量化蒸馏”那篇文章隐含假设是单一模型能容纳多视图一致性“验证重分配”那篇隐含假设是解码时增加验证步骤的收益大于开销。检验这个假设是否成立比记住公式更重要。如果假设是成立的那这篇论文大概率有价值如果假设本身就很脆弱那无论实验指标多漂亮都只是在局部问题上做了一个短期修补。就在整理今天这份报告的过程中我又给下周的筛选规则加了一条凡是只汇报平均提升、不给分位数和误差范围的文章一律降到泛读档。这个细节看似很小但对于判断真实收益非常关键。每天坚持做这样一件“小而不难”的事半年下来你对一个领域的感知会变得完全不同。