ECCV 2026底层视觉论文汇总：从信息追踪到复现验证的完整工作流

每年ECCV的录用名单一出来底层视觉方向的交流群里总会有一轮求论文、求代码的“扫货”。今年这个节奏来得更早——很多研究组在投稿阶段就把预印本挂上了arXiv代码仓库也在同步准备中。作为长期整理超分辨率、图像恢复、去雨去雾这些方向的从业者我想把“汇总”这件事本身拆开讲讲它不只是把几十个标题和链接堆在一起更是一条从信息源、筛选规则、字段结构到复现验证的完整工作流。这篇文章就是我的工作流全貌适合所有打算跟进ECCV2026底层视觉论文的同学无论你是刚入门的研究生还是需要快速截图复现的工程师。先说清楚一个现实这份汇总贴的“持续更新”四个字决定了它的核心不是一次性生成一个静态清单而是建立一条能持续产出高质量论文链接的信息流水线。ECCV是两年一届的欧洲计算机视觉会议与CVPR、ICCV并称三大顶会底层视觉方向在里面一直占着相当重的比例。按照往届节奏投稿截止后大约两到三个月出录用结果会议通常在秋季举行。现在这个时间点很多论文还处于评审或预印本阶段官方录用名单也没有完全公布所以真正有价值的不是去“等一份现成清单”而是掌握一套能在论文放出后第一时间抓到、筛出、整理好的方法。这篇文章把我自己的完整流程写出来你可以直接照着搭一套。1. 为什么ECCV2026的底层视觉论文值得单独开一个跟踪专题1.1 ECCV在底层视觉方向上的地位底层视觉low-level vision这个方向在三大顶会里的占比一直很稳定。以我自己的统计习惯来看ECCV论文池子里凡是涉及图像重建、恢复、增强的内容通常能占到收录总量的15%到20%。原因是底层视觉有一套非常标准的评测体系——PSNR、SSIM、LPIPS这些指标一摆算法好坏可以量化对比做起来相对“有抓手”投稿的确定性也比很多开放性问题要高。这也是为什么超分辨率、去噪、去模糊、去雨、去雾这些子方向会有那么多paper在同一届会议里出现。因为这些任务共享底层逻辑给定一张质量退化的图像想办法通过模型把它还原成清晰、干净、符合视觉预期的结果。区别只在于退化模型怎么定义——是下采样模糊、加噪声、雨痕叠加还是大气散射导致的对比度下降。1.2 “持续更新”类汇总帖的合理预期很多同学看到“持续更新”这个词以为点进来就能拿到一份完整的论文列表下载即用。实际维护过这类清单的人都知道论文发布是一个渐进过程先是OpenReview上出现匿名投稿版再是录用后作者放camera-ready很多代码仓库要等到论文被接收甚至会议临近时才公开。这意味着任何在录用名单公布之前生成的“完整清单”都一定是过时的。所以我更愿意把这篇汇总定位成一个“框架实时入口”框架是告诉你每个方向应该关注哪些问题、哪些论文值得重点追踪实时入口是给你一套信息抓取和筛选规则让官方信息一放出来你能比我更快更新自己的清单。这个能力比直接复制一份PDF列表有用得多。2. 底层视觉六个子方向从问题定义到近年技术演进2.1 图像超分辨率从PSNR导向到感知质量导向超分辨率是底层视觉里最成熟、参与人数最多的子方向。任务本身很好理解给一张低分辨率图重建出高分辨率图。但“怎么定义好”这件事这些年发生了明显变化。早期SRCNN、EDSR、RCAN这一批方法核心优化目标是PSNR追求像素级的均方误差最小化。结果就是重建出来的图虽然指标高但放大看纹理很“糊”缺少真实感。后来SRGAN、ESRGAN引入了对抗生成网络用感知损失和对抗损失逼着模型生成更锐利的纹理PSNR不一定高但人眼看着舒服很多。到了近两年Transformer结构全面渗透进超分领域。SwinIR是绕不开的代表作它把Swin Transformer的窗口注意力搬到了图像重建上在经典超分基准上把PSNR往上推了一大截。HAT则进一步结合了Channel Attention和窗口注意力专门处理大放大倍数的场景。这个方向在ECCV2026值得关注的点我认为是“效率”Transformer效果好但计算量大如何在保持画质的同时把推理速度压到移动端可用的水平会是很多论文的切入点。2.2 图像增强与暗光恢复真实场景数据比模型更重要图像增强和暗光恢复解决的问题比超分更“杂”。超分至少有明确的降采样退化模型暗光图像则会同时带有噪声、色彩偏移、动态范围压缩等多种问题退化模型很难用一个简单的公式描述。之前大家熟知的RetinexNet、Zero-DCE核心思路是基于Retinex理论把图像分解成光照分量和反射分量再对光照做调整。这套理论解释性强但在极端暗光下效果有限。后来URetinex-Net这类工作开始用深度网络直接学习光照图估计和反射图恢复在低照度数据集上效果提升明显。这个方向在2026年ECCV投稿里大概率会出现的一个趋势是“真实数据对”的利用用同一场景不同曝光时间的成对数据或者用长曝光短曝光监督网络训练。这种方法的难点不在模型而在数据采集的硬件同步和配准。如果你要做这个方向最好先想清楚自己的数据从哪来而不是一上来就换模型架构。2.3 去噪与去模糊退化参数估计与条件生成去噪和去模糊在数学本质上都是逆问题已知观测图像y和退化算子H去求清晰图像x。H是加性噪声去模糊的H是模糊核卷积。两者最大的坑在于H本身事先往往不知道需要模型去估计。经典做法分两步先估计噪声水平或模糊核再做非盲复原。但端到端学习的框架早就把这个过程折叠成了一个黑盒。NAFNet是近几年我特别推崇的一个baseline它在UNet结构上做了简化——去掉非线性激活函数只保留线性门控反而在GoPro、SIDD等多个恢复数据集上刷出了很稳定的效果。这个工作证明了好的训练策略和结构设计有时候比复杂模块更管用非常适合作为新方法的对比基线。ECCV2026上这个方向值得关注的一个是“大模型做去噪”的思路利用扩散模型的生成先验去解决极端退化下的纹理重建另一个是“物理信息驱动”的回归即在网络结构里显式建模退化过程而不是完全交给网络黑盒拟合。两条路线各有适用场景整理清单时可以分开维护。2.4 去雨与去雾合成数据与真实数据的鸿沟去雨、去雾这两个方向听名字很具体但做起来特别考验对数据集的理解。去雾领域最经典的AOD-Net用了一个简化的散射模型来端到端预测清晰图像后来的DehazeFormer把Transformer用在去雾上在合成雾数据集上指标提升很大。去雨方向从SPA-Net开始就很强调真实雨图数据的重要性因为合成雨滴的形状、方向、密度和真实场景差距太大模型训练得再漂亮拿到真实雨天里很容易“翻车”。这类任务有个共同毛病评测指标提升很快但视觉效果提升不明显或者说泛化性不足。我看论文时养成了一个习惯——下载作者放出的测试结果图自己放大看细节而不是只看指标表格。很多去雨去雾论文在合成测试集上PSNR很高但输出的天空区域会有奇怪的色块或纹理污染。这些缺陷是指标看不出来的。2026年这个方向应该会有更多工作尝试弥合合成到真实的gap比如用无监督域适应、用更真实的物理渲染引擎生成雨雾数据、或者在推理时引入场景深度信息。整理汇总时我建议把“用了什么训练数据”“在哪些真实场景上做了验证”作为关键字段记录下来这比记录它涨了多少PSNR重要得多。2.5 图像修复Inpainting与联合恢复从“抠掉”到“长出来”图像修复是底层视觉里艺术感比较强的一个方向任务是补全图像中被遮挡或损坏的区域。传统方法靠扩散方程或纹理合成一点一点往里填速度慢且容易产生模糊边界。LaMa用了一种基于傅里叶变换的快速卷积修出来的纹理和结构一致性非常好而且速度很快是我目前处理图像修补的首选工具。2026年这个方向会和扩散模型结合得更深先用扩散模型生成符合语义的内容再通过引导采样保证生成区域与周围环境的光照、风格一致。这种做法的缺点是迭代次数多、速度慢所以很多论文会在这里加蒸馏或少步推断。修复任务的评估也很有争议现有的FID、LPIPS都不能完全反映“补出来是否真实”这也是论文里可以“做文章”的地方。联合恢复则是一个更综合的趋势一张真实图片可能同时有模糊、噪声、低分辨率多种问题过去是一个任务一个模型现在很多工作尝试用一个模型解决多个退化类型。Restormer就是其中代表作它使用高效的Transformer结构处理多种恢复任务在去雨、去噪、去模糊上都达到了当时的最好水平代码开源也很完整。这种“一个模型打多份工”的思路在ECCV2026的投稿里必然会继续出现。2.6 视频底层视觉时序一致性是被忽视的重点如果用一句话概括视频超分和其他视频恢复任务的核心难点那就是“时序一致性”。单帧图像的恢复算法在视频上逐帧跑一遍画面经常会闪个不停明明每一帧静态看都很清晰连起来看就是“闪烁抖动”。因此视频方向的工作要在网络结构里引入光流对齐或时序注意力让相邻帧的特征互相参考。ECCV这些年视频恢复的投稿量一直在涨但高质量开源代码的比例不高原因是视频训练数据大、训练周期长很多作者只放测试代码不放训练代码。整理这个子方向的汇总时我特别看重作者是否提供完整训练配置和示例数据否则论文很难复现参考价值大打折扣。3. 论文从哪来五条信息渠道与一套筛选策略3.1 arXiv关键词监控动手搭一个低配版“论文雷达”很多人都是隔三差五手动去arXiv上搜一下“super resolution”这样效率太低。我的做法是写一个简单的Python脚本用arXiv的API按关键词自动拉取当天更新的论文摘要再把包含指定词组的条目汇总到本地Markdown文件里。import urllib.request import urllib.parse import xml.etree.ElementTree as ET query all:image super-resolution OR all:low-level vision OR all:image restoration url ( http://export.arxiv.org/api/query?search_query urllib.parse.quote(query) start0max_results30sortBysubmittedDatesortOrderdescending ) with urllib.request.urlopen(url) as resp: data resp.read() root ET.fromstring(data) ns {atom: http://www.w3.org/2005/Atom} for entry in root.findall(atom:entry, ns): title entry.find(atom:title, ns).text.strip().replace(\n, ) link entry.find(atom:id, ns).text.strip() print(f{title}\n {link}\n)这个脚本放到服务器上配合crontab每天早上自动运行一次把结果追加到一个“今日新文”文件里。成本几乎为零但能保证你不会漏掉任何挂着super resolution关键词的新论文。3.2 OpenReview录用论文的第一手来源ECCV的投稿和评审系统是OpenReview。在官方录用名单公布之前OpenReview上的投稿版本往往是信息最早、最全的地方。你可以按会议ID搜索再按“low-level vision”“image restoration”等主题词筛选。这里有个经验OpenReview的论文页面在评审阶段就能看到投稿原文和评审意见如果一篇论文的评审意见里有“missing comparisons”“lack of ablation”这类批评通常说明实验还不够扎实即使被录用复现时也容易踩坑。反过来如果评审一致通过且代码链接已经在论文里给出那这篇论文的复现价值就高很多。3.3 GitHub Trending与社交网络代码优先的信号源底层视觉方向有一个很好的生态传统很多论文在投稿阶段就会把代码仓库设为public并在Twitter、小红书、知乎等平台宣传。GitHub Trending的“Today”榜单也经常能看到新开源的超分或恢复项目。我自己的筛选信号是仓库有没有完整的README、有没有提供预训练权重、有没有训练和测试脚本。只要三者齐备哪怕论文还没被任何会议接收也值得放进汇总表。因为这些仓库的作者通常对这个代码比较有信心且后续被会议接收的概率不低。3.4 会议报告与综述视频信息滞后的利用ECCV录用名单公布后有很多博主、研究组会做论文导读视频这类二次创作内容可以帮助快速抓重点。不过信息通常滞后于arXiv和OpenReview所以我只把它作为“补充确认”渠道用来发现自己信息流里漏掉的论文而不会用它作为第一信息来源。3.5 筛选策略宁可少而精不要多而杂一份论文汇总帖最容易犯的毛病是“什么都往里塞”。最后变成一堆链接的大杂烩反而没参考价值。我的筛选标准有三条论文方向必须明确落在超分、增强、恢复、去雨、去雾、修复、去噪、去模糊这些核心范围内擦边的低质工作不录。必须能拿到可访问的论文PDF最好附带代码链接。没有代码的论文也会收录但会增加一个“无代码”标签供自己在复现时区分优先级。训练方法或模型架构有独特性而不是单纯在别人的框架上改个损失函数调个参。按这个标准维护的汇总表即使只有二三十条也比塞了上百条“可能有用的链接”有价值得多。4. 可持续更新的论文汇总表字段设计、去重机制与更新节奏4.1 一个字段齐全的汇总表应该长什么样我用Notion维护这份汇总表字段设计经过了多次调整当前版本如下字段说明示例方向超分/去噪/去雨/去雾/增强/修复/联合恢复超分辨率论文标题完整英文标题Efficient Backbone for Real-World SR作者/单位方便判断组内工作延续性xxx LabarXiv ID用于回溯PDF2510.xxxxxPDF链接arXiv或OpenReview地址arxiv.org/abs/...代码链接GitHub或项目主页github.com/xxx/xxx代码状态未放出/已放出/放出一部分已放出训练数据合成/真实/混合混合评价指标论文使用的核心指标PSNR, SSIM, LPIPS复现难度高/中/低中个人备注创新点、可借鉴的地方用Mamba替换Transformer这个字段结构涵盖了论文检索、代码复现和后续引用三个环节的需求。特别是“训练数据”一栏很多时候决定了论文的结果在真实场景里能不能复现只看PDF摘要看不到这个信息。4.2 去重与防伪同一篇论文的多种形态跟踪论文时间久了一定会遇到同一篇工作以多种形态出现预印本、会议版、期刊扩展版、甚至换了个标题又投了一次。如果在汇总表里重复收录会污染整个数据的质量。我的去重规则是看作者名单和核心方法名。只要第一作者相同、方法核心模块名称相同即使标题不同也按同一篇工作处理只保留信息最全的那个版本。另外还要警惕“挂了ECCV名号的假链接”——在官方录用名单公布之前声称“已被ECCV2026接收”的文章如果没有OpenReview或官方通知佐证基本可以判定为信息不实或作者自说自话。收录时我会标注“预印本/未验证接收状态”。4.3 更新节奏每周固定一个维护时段“持续更新”不是想起来才去碰一下而是要固定节奏。我的习惯是每周五下午花三十分钟先在arXiv上跑一遍本周的搜索脚本再刷OpenReview的ECCV2026板块最后过一遍GitHub Trending。把新增论文填入表格并给状态变化的论文更新标签。这套节奏坚持下来有个额外好处不需要临时突击每次只处理增量信息维护成本低注意力也能保持专注。如果你用GitHub Pages或Gitee Pages维护自己的论文清单还可以直接把表格导出成Markdown推送一次就完成一次对外更新。我在实际维护中就是这么做的公开的汇总版本和私有表格保持同步公开版只展示论文标题、方向、链接和阶段标签把个人备注留在自己的表格里。5. 复现底层视觉论文前必须搞懂的数据集与评价指标5.1 基准数据集别再只看Set5和Set14了很多刚入门的同学复现超分论文时第一反应是去下Set5、Set14、BSD100这几个老牌数据集。这些数据集图片数量少、分辨率低、内容单一只能用于快速验证训练流程是否跑通把它当作算法能力的最终评判标准远远不够。现在主流超分论文一般会跑Urban100、Manga109、DIV2K、Flickr2K这几个基准。Urban100包含大量建筑和纹理结构能检验模型对规则纹理的重建能力Manga109是漫画图像线条和网点的重建难度很高DIV2K作为训练集已经成为事实标准很多预训练模型都是基于它训练的。如果你要复现论文并对比指标务必使用和论文相同的训练集和测试集否则对比结果没有意义。图像恢复方向的数据集差异更大。去噪常用SIDD真实智能手机噪声、DND基准噪声去模糊常用GoPro高速摄影合成的运动模糊、REDS视频去模糊去雨常用Rain100H、Rain100L及真实雨图数据集去雾常用RESIDE。每个数据集的退化类型和采样方式都不同论文里说了“在SIDD上达到了SOTA”你拿到GoPro上去验证结果当然对不上。5.2 评价指标PSNR/SSIM/LPIPS的边界与坑PSNR是像素级的均方误差计算简单、物理意义明确但它和人的主观感知相关性很差。SSIM从亮度、对比度、结构三个维度评价图像相似性比PSNR进了一步但对纹理区域的评价仍然不敏感。LPIPS用深度网络特征做感知相似度计算更贴近人类观察近年已经成为恢复论文的标准配置。这三个指标放在一起能比较全面地反映模型性能但使用时要注意计算细节PSNR的计算需要确定像素值范围是[0,1]还是[0,255]不同论文实现可能不同。很多超分论文在评估时会在RGB三个通道上分别计算PSNR再取平均而有的论文只计算Y通道的PSNR这两者结果不同对比时必须对齐。有些论文的测试阶段开启了self-ensemble对输入做8种几何变换推理后再反变换取平均这通常会带来0.1~0.3dB的提升复现时如果不开启指标就和论文对不上。我的经验是拿到一个代码仓库后先不要跑自己的实验先复现论文报告里的核心指标。如果复现结果和论文有较大出入优先检查上面这几个细节而不是怀疑模型结构写错了。5.3 训练集、测试集与退化设置的对齐底层视觉论文的复现最容易被忽略的就是退化设置。以超分为例经典超分是“双三次下采样”bicubic downsampling但真实世界超分里的退化往往还包含模糊、噪声和压缩伪影。同一张图用不同的退化方式生成低分辨率图像训练出来的模型完全不同。Real-ESRGAN这类方法成功的原因之一就是它把退化的随机性做到了极致随机模糊核、随机噪声、随机尺寸缩放、JPEG压缩伪影全部作为数据增强手段让模型见过足够多样的“真实退化”。复现这类方法时训练数据的生成代码必须和论文保持一致否则你训练出来的模型能力会有很大偏移。我见过好几个同学用经典超分的退化方式去训练一个本应面向真实场景的恢复模型结果测试结果自然惨不忍睹问题根本不在于网络结构或训练策略。6. 底层视觉开源代码地图从经典工具箱到最新仓库6.1 工具箱类项目适合做实验脚手架如果你要做底层视觉方向的实验不建议每次从头搭训练代码。直接使用成熟工具箱能省掉大量工程化时间。BasicSR是我用得最多的一个框架它围绕超分和恢复任务封装了数据加载、模型定义、训练器、测试器、指标计算全流程基于它修改模型结构非常方便。MMagic是OpenMMLab系列中的视觉生成工具箱覆盖了包括超分、修复、抠图、生成在内的更多方向模块化程度更高但学习曲线也更陡。两个工具箱的选择标准很简单如果只是做超分和恢复BasicSR足够如果需要在多个生成类任务之间切换用MMagic更合适。不要两个都装在同一套代码里混着用环境依赖上很容易起冲突。6.2 经典单点仓库带着源码去理解方法除开工具箱很多经典方法都有独立仓库非常适合精读源码理解方法细节仓库对应论文备注Real-ESRGANReal-ESRGAN: Training Real-World Blind Super-Resolution with Pure Synthetic Data真实世界盲超分训练数据生成管线非常完整SwinIRSwinIR: Image Restoration Using Swin TransformerTransformer恢复的代表作代码结构清晰RestormerRestormer: Efficient Transformer for High-Resolution Image Restoration多任务恢复主干适合做baseline对照NAFNetNAFNet: Nonlinear Activation Free Network for Image Restoration极简网络也能刷高指标证明训练策略的重要性LaMaResolution-robust Large Mask Inpainting with Fourier Convolutions修复方向实用度极高这几个仓库我都完整读过源码它们有一个共同优点训练和测试逻辑分离得很干净数据预处理、模型结构、损失函数、指标计算都在不同文件里阅读起来不会一头雾水。新人想理解底层视觉的工程实现从SwinIR和NAFNet开始读性价比最高。6.3 判断一个代码仓库是否靠谱的三个信号不是所有论文提供的代码都值得花时间复现。我拿到一个仓库后会先看三件事是否提供了预训练权重和下载脚本。没有权重只有代码的仓库训练时间可能以周为单位很多人根本跑不动。训练配置是否完整。只有测试脚本没有训练脚本的仓库作者很可能自己都没完整训练过不建议作为基准。依赖列表是否明确。缺少requirements.txt或者环境配置说明含糊的仓库会让你在装环境上耗费大量时间。这三个信号都满足的仓库复现起来通常比较顺利。有一个信号不满足就要在心里打个问号先看看issue区有没有人遇到过类似问题。7. 从论文到复现环境、数据、训练测试不一致的实战坑7.1 环境依赖PyTorch版本与CUDA版本是第一道坎底层视觉的代码仓库普遍基于PyTorch但不同论文对PyTorch版本的要求差异可能很大。SwinIR这类较早期的仓库在PyTorch 1.x上验证比较多直接用新版PyTorch跑有时会报一些算子不兼容的错误。Restormer仓库里对某些Transformer组件的实现依赖特定版本的einops和timm。Real-ESRGAN在训练时如果GPU显存不够可能需要调整批大小和patch尺寸而不是照搬默认配置。我的建议是每个项目单独建一个conda环境按仓库README里给你的配置文件来装依赖不要用全局环境直接跑。为省事而混装环境最后大概率会陷入版本地狱反复卸载重装的时间远超一开始建环境的时间。7.2 数据坑下载链接失效与文件结构不对很多仓库在README里给出了数据集的下载链接但这些链接往往是作者自己传的网盘时间久了容易失效。我的备选方案是直接去数据集官网或官方GitHub仓库下载原始数据再按作者的预处理脚本手动处理。预处理脚本通常包括裁剪、配对、划分训练测试集这几个步骤只要输入数据格式对脚本一般能直接跑通。这里特别提醒一下DIV2K这类的常见数据集不同仓库对它的预处理方式可能不同有的保留原始分辨率做training有的会先裁剪成固定patch再打包成lmdb格式。如果你下载的是别人做好的lmdb版本要确认生成这个lmdb的预处理参数是否和论文一致否则训练数据分布可能出现细微偏差影响最终效果。7.3 训练与测试不一致指标波动的隐蔽来源训练阶段和测试阶段必须使用完全相同的数据预处理方式这条铁律在实际复现中经常被打破。比如Super-Resolution任务训练时对高清图做双三次下采样生成低分辨率图测试时候直接把原图缩放成目标尺寸来算PSNR两者对不齐指标自然对不上。另一个隐蔽的问题是padding。很多深度网络为了保证特征图尺寸不变会在卷积或注意力模块中加入padding而padding的方式zero padding还是reflect padding在不同实现里可能不一样直接导致边缘像素的重建效果不同。遇到复现指标始终差一点点的情况优先检查数据预处理和padding设置。7.4 指标核对把复现结果与论文报告逐项对齐跑通整个流程后第一步是核对测试集上的PSNR/SSIM/LPIPS与论文报告进行对比。如果差异超过0.2dB通常说明哪里设置出了问题。如果没有差异再尝试关闭论文里提到的self-ensemble等测试时增强观察指标下降幅度是否和论文一致以此判断自己的测试流程是否完全复刻了论文的设置。我见过一个典型的错误复现某篇Transformer超分论文时忘记加载预训练权重直接用随机初始化的模型测试PSNR比论文低了一大截折腾了两天才发现问题。这类低级错误虽然听起来可笑但在连续调试几天之后很容易出现所以我在测试脚本里会强制打印模型加载权重的路径和是否成功校验避免这种无效排查。8. 维护一份论文汇总的完整工作流我的每周固定动作与最终建议8.1 每周固定动作清单我维护这份ECCV2026底层视觉汇总的日常节奏基本稳定在每周一次一次半小时左右。具体动作按顺序是这样的运行arXiv关键词脚本把当日新增论文写入待处理队列。打开OpenReview上的ECCV2026投稿列表按“image restoration”等关键词过滤记录新出现的投稿。刷GitHub Trending和已关注研究组的主页看有没有新放出的代码仓库。把新论文填入Notion汇总表补充方向、链接、代码状态等字段。检查已有的表格条目更新代码状态和接收状态。把公开版Markdown同步到GitHub仓库形成一次对外更新。这套流程不需要额外投入太多时间但能保证信息始终处于“基本最新”的状态。8.2 表格README双轨既方便自己管理也方便别人阅读如果只是自己看一个Notion表格就够了但对外的汇总帖需要用Markdown README呈现。我的方案是维护一个GitHub仓库根目录放README.md作为总入口里面按方向分小节列出论文表格同时把包含个人备注的Notion私有表格留在自己手里避免把太多主观信息暴露到公开环境。这样做的好处是公开链接稳定方便在群聊里分享私有表格可以肆无忌惮地记录“这篇论文的实验其实不太可信”“这个仓库的权重下载不了”等真实判断。两套内容由同一份维护流程驱动不会产生重复录入的工作量。8.3 关于“持续更新”的务实心态最后想多说一句维护这类论文汇总帖最难的不是技术而是坚持。很多人在录用名单公布那几天热情高涨后面很快就断更了。我的建议是把这件事当成一个轻量级习惯而不是负担设定一个固定的低维护频率哪怕每次只更新几条只要中间不断一年下来积累的信息量会非常可观。如果你也想给自己搭一套论文跟踪系统先从复制文中的arXiv脚本开始再按自己的需求建一个表格模板。不用等ECCV2026最终录用名单出来现在就开始把预印本、OpenReview投稿和代码仓库信息往里填等到官方名单公布时你手里的列表已经比绝大多数人先跑了两三个月。