企业官网建设流程全解析

1. 从一份论文汇总清单说起：我为什么要做这件事

每天早上刷 arXiv 的 cs.AI 板块，已经成了我这两年雷打不动的习惯。但说实话，这个习惯一度让我很痛苦——列表太长，标题太密，摘要太学术，真正值得点进去细读的可能不到十分之一。更麻烦的是，当你隔了一周再回头看，那些当时觉得"有点意思"的论文早就沉到列表底部，找都找不回来。所以我从去年开始，给自己定了一个规矩：每周固定花两个小时，把 cs.AI 当天的论文做一次人工筛选和结构化整理，形成一份可以长期留存的汇总笔记。这份 2026.09.28 的汇总，就是其中一期的产物。

你可能会问，现在不是有各种论文推荐工具和自动摘要服务吗，为什么还要手动做这件事？我的答案很直接：自动工具能帮你过滤噪音，但没法帮你建立判断力。一篇论文值不值得读，往往取决于你当前在做什么项目、踩过什么坑、对哪个方向有直觉。这种判断，机器替不了你。而手动整理的过程，恰恰是逼自己快速扫读、快速判断、快速归档的训练。坚持半年之后，我发现自己读论文的速度至少快了三倍，而且对领域脉络的感知明显更清晰了。

这份汇总适合谁看？如果你是刚入门 AI 方向的学生，它能帮你建立"每天扫一遍 arXiv"的节奏感；如果你是从业多年的工程师，它能给你一个结构化的参考框架，让你知道别人是怎么做论文筛选和归档的；如果你正在准备大作业、开题报告或者技术调研，这份汇总里的分类思路和工具链可以直接抄作业。我不打算在这里复述每篇论文的摘要——那是 arXiv 自己就能做的事——我要分享的是怎么把一堆零散论文变成一份有用的知识资产，以及在这个过程中我踩过的坑和总结出的方法。

2. 论文汇总的整体设计思路：不是搬运，是重构

2.1 为什么我不做"标题+摘要"的简单罗列

最开始做汇总的时候，我也走过弯路。第一版就是直接把 arXiv 列表复制下来，每篇论文附上标题、作者、摘要前两句，看起来信息很全，实际上根本没法用。问题出在哪？摘要写的是作者想让你看到的东西，不是你想知道的东西。作者会说"我们提出了一种新颖的框架"，但你真正关心的是"这个框架解决了我手头哪个问题"、"它的方法和我上周看的那篇有什么区别"、"代码开不开源"、"实验在什么规模上做的"。

所以从第三期开始，我彻底改了结构。每篇论文我只保留四个字段：一句话核心贡献、方法关键词、和我当前工作的关联度、是否值得深读。这四个字段逼着我在扫读时做判断，而不是做搬运。判断错了没关系，下一期可以修正，但判断这个动作本身是有价值的。久而久之，你会形成自己的"论文品味"——看到标题就能大致猜到这篇论文的成色。

2.2 分类维度怎么定：按任务、按方法还是按应用

分类是汇总的骨架。我试过三种分法，最后固定下来的是混合分类。纯按任务分（比如 NLP、CV、RL）太粗，cs.AI 现在大量论文是跨模态、跨任务的；纯按方法分（比如 Transformer、Diffusion、Agent）又太细，很多论文同时用了好几种方法。我现在的做法是：先按大方向分三到四类，比如"基础模型与训练方法"、"智能体与工具使用"、"多模态与生成"、"评测与安全"，然后在每一类内部按具体任务排二级标签。

这样分的好处是，当你带着具体问题来查的时候，可以先定位大方向，再在二级标签里快速找到相关论文。比如你最近在做 LLM 的单元测试生成，那"智能体与工具使用"下面的"代码生成与验证"标签就是你的重点区域。分类维度不是一成不变的，它会随着你关注方向的变化而调整。我每季度会回顾一次分类体系，把长期没有论文进入的类别合并掉，把突然增多的新方向单独拆出来。

2.3 工具链选型：为什么是 Zotero + Obsidian + 一个脚本

工具这块我折腾过不少组合，最后稳定下来的是Zotero 管元数据、Obsidian 管笔记、一个 Python 脚本管抓取和初筛。Zotero 的好处是它能自动从 arXiv 抓取 BibTeX 和 PDF，而且标签系统很灵活，我可以给每篇论文打上"待读"、"在读"、"已归档"、"重点引用"几个状态标签。Obsidian 的好处是双向链接，我可以在笔记里写"这篇的方法和 [[某篇旧论文]] 很像"，然后一键跳过去对比。

那个 Python 脚本做的事情很简单：每天定时拉取 arXiv cs.AI 的 RSS，按关键词过滤掉明显不相关的（比如纯理论证明、纯综述），然后把剩下的标题和摘要写进一个 Markdown 文件，我人工过一遍之后再把有价值的条目手动导入 Zotero。为什么不直接全自动导入？因为全自动导入的结果就是 Zotero 里堆了几千篇你永远不会看的论文，标签系统直接崩溃。人工过一遍虽然慢，但保证了每一条进入系统的记录都是你真正扫过的。

提示：脚本里我加了一个"去重"逻辑，用标题的 SimHash 做近似匹配，避免同一篇论文因为跨列表（cs.AI 和 cs.CL 同时出现）被重复抓取。这个细节很小，但省了我不少清理时间。

3. 核心细节解析：一份高质量汇总的五个关键动作

3.1 扫读阶段：如何在 30 秒内判断一篇论文值不值得读

扫读不是逐字读，而是带着问题扫。我给自己定了三个必问的问题：第一，这篇论文解决的是新问题还是老问题的新解法？新问题通常更值得关注，因为老问题的新解法往往只是在刷点。第二，它的实验规模是什么级别？如果只在 toy dataset 上跑，那结论的可靠性要打问号。第三，它有没有开源代码？有代码的论文，复现成本低一个数量级，优先级直接拉高。

具体操作上，我只看三个地方：标题、摘要最后两句、图表标题。标题告诉你它想干什么，摘要最后两句通常是作者自认为的贡献总结，图表标题能快速暴露实验设置。这三个地方扫完，基本就能判断要不要进入下一轮。我实测下来，一篇论文平均 20 到 30 秒就能过一遍，一个上午的 cs.AI 列表大概 80 到 120 篇，两小时内能全部扫完并做好初筛。

3.2 精读阶段：笔记应该记什么，不该记什么

进入精读的论文，我一般控制在每期 5 到 8 篇。精读笔记我坚持一个原则：只记"我以后会用到的信息"，不记"论文里写了什么"。具体来说，我会记四样东西：方法的核心公式或伪代码（如果我能用一句话说清楚就不抄公式）、实验里最让我意外的那个数字、作者在 limitation 里承认的短板、以及我自己的一个疑问或联想。

不记的东西也很明确：不抄摘要、不抄 related work、不抄大段实验表格。这些东西 Zotero 里都有，笔记里再抄一遍纯属浪费时间。我见过很多人的论文笔记做得像读书报告，工工整整但从来不看第二遍。笔记的价值在于"二次调用"，如果你三个月后遇到相关问题，能在笔记里快速找到"当时那篇论文是怎么处理的"，那这份笔记就是合格的。

3.3 归档阶段：标签体系怎么设计才不会崩

标签体系是汇总能不能长期维护的关键。我的标签分三层：状态标签（待读/在读/已归档/重点引用）、方向标签（基础模型/智能体/多模态/评测安全）、项目标签（当前项目名）。状态标签管流程，方向标签管检索，项目标签管关联。三层标签组合起来，你可以快速回答"我当前项目里用到的多模态论文有哪些是重点引用的"这种问题。

标签数量要克制。我一开始给每篇论文打七八个标签，结果标签系统迅速膨胀到几百个，检索的时候根本不知道选哪个。后来我定了一个硬规矩：每篇论文最多三个方向标签，项目标签不超过两个。宁可少打，不可滥打。每季度清理一次，把半年没用过的标签删掉，保持体系精简。

3.4 关联阶段：怎么把新论文挂到旧知识树上

这是最容易被忽略但价值最高的一步。每精读完一篇论文，我会强制自己问：它和我知识树上的哪个节点有关？是补充了某个方法的细节，还是反驳了某个之前的结论，还是把两个原本不相关的方向连起来了？找到关联之后，我会在 Obsidian 里建一条双向链接，并在两边各写一句话说明关联是什么。

这个动作看起来费时间，但它带来的复利效应非常惊人。半年之后，你的知识树会自然长出很多"跨方向连接"，而这些连接往往就是新想法的来源。我现在的几个项目灵感，基本都是从这个关联网络里冒出来的。论文不是孤岛，汇总的价值就在于把孤岛连成大陆。

3.5 输出阶段：汇总笔记的最终形态长什么样

最终的汇总笔记，我固定用 Markdown 写，结构是：本期概览（三到五句话总结本期最值得关注的趋势）、分类论文列表（每篇四字段）、本期精读笔记（五到八篇的详细笔记）、下期关注点（三到五条）。概览部分逼自己写趋势判断，哪怕判断错了也要写，这是训练领域直觉的方式。下期关注点则是给未来的自己留钩子，避免下一期从零开始。

这份笔记我会同步到自己的知识库，也会分享给几个固定交流的朋友。分享这个动作很重要，因为当你知道有人会看的时候，你会写得更认真。而且朋友的反馈经常能指出你忽略的论文或错误的判断，这种外部校准是独自做汇总得不到的。

4. 实操过程：从零搭建一套论文汇总流水线

4.1 环境准备与依赖安装

先说环境。我用的是 Python 3.11，主要依赖三个库：feedparser用来解析 arXiv 的 RSS，requests用来抓取补充信息，simhash用来做标题去重。安装命令很简单：

pip install feedparser requests simhash

Zotero 装桌面版，装一个Better BibTeX插件用来管理引用键。Obsidian 装桌面版，开一个 vault 专门放论文笔记。这三个工具都是免费的，而且跨平台，Windows、macOS、Linux 都能跑。如果你不想装 Python，也可以用 Zotero 自带的 RSS 订阅功能，但过滤和去重就得手动做了，效率会低不少。

注意：arXiv 的 RSS 有频率限制，别写太激进的抓取间隔。我设的是每 6 小时抓一次，完全够用，也不会给对方服务器造成压力。

4.2 抓取脚本的核心逻辑与参数说明

脚本的核心逻辑分四步：拉取 RSS、解析条目、关键词过滤、输出 Markdown。关键词过滤这块我维护了两个列表：白名单（比如 "agent"、"reasoning"、"multimodal"、"evaluation"）和黑名单（比如 "survey"、"position paper"、"extended abstract"）。白名单命中任意一个就保留，黑名单命中任意一个就丢弃，两个都没命中的进"待定"区，我人工扫的时候再决定。

去重用的是 SimHash，阈值设的 3。这个阈值的意思是，两个标题的 SimHash 汉明距离小于等于 3 就认为是同一篇。实测下来这个阈值比较稳，既不会漏掉真正的重复，也不会把相似但不同的论文误判成同一篇。输出格式是标准 Markdown，每篇论文一个二级标题，下面跟标题、作者、摘要链接、初筛标签。

4.3 人工筛选的操作节奏与时间分配

脚本跑完之后，我会在早上通勤的时候用手机过一遍"待定"区，把明显不相关的划掉。到工位之后，花 40 分钟过一遍白名单区，做初筛标记。下午抽 1 到 1.5 小时做精读，一般能精读 3 到 4 篇。剩下的精读任务放到第二天早上。整个流程下来，每天投入大概 2 到 2.5 小时，一周五天，周末不干活。这个节奏我坚持了快一年，没有出现过明显的倦怠，因为每天的量是可控的，不会积压。

时间分配上有个小技巧：把扫读和精读分开在不同时段做。扫读需要快速切换注意力，适合碎片时间；精读需要深度专注，适合整块时间。混在一起做，效率会打对折。我试过把两者都放在晚上，结果扫读拖沓、精读走神，后来改成早上扫读、下午精读，效果好很多。

4.4 笔记模板与字段定义

Obsidian 里我建了一个论文笔记模板，字段固定为：标题、作者、链接、核心贡献、方法关键词、实验规模、开源情况、我的判断、关联笔记、状态。这个模板用 Templater 插件自动填充，新建笔记的时候一键生成。字段定义我写在一个单独的说明文件里，避免时间久了忘记每个字段该填什么。

"我的判断"这个字段最重要，我要求自己必须写一句带立场的话，比如"这篇的方法在长上下文场景下大概率不 work，因为它的注意力复杂度还是 O(n²)"。带立场的判断哪怕错了，也是有价值的，因为它逼你形成观点。不带立场的描述，比如"这篇提出了一个新方法"，写了等于没写。

4.5 定期回顾与体系维护

每周末我会花 30 分钟做一次小回顾：检查本周笔记有没有漏填字段、标签有没有打错、关联链接有没有断。每季度做一次大回顾：重新审视分类体系、清理僵尸标签、把长期没进展的方向归档。这个维护动作看起来琐碎，但它是体系能长期运转的前提。没有维护的体系，三个月就会变成垃圾场，这是我踩过的最大的坑。

5. 常见问题与排查技巧实录

5.1 抓取失败或条目缺失怎么办

最常见的问题是 RSS 抓取失败，原因通常是网络波动或者 arXiv 临时调整了 feed 格式。排查步骤很简单：先用浏览器直接打开 RSS 地址，看能不能正常显示；如果能显示但脚本报错，那就是解析逻辑的问题，检查feedparser的版本，有时候升级一下就好了。条目缺失一般是关键词过滤太严，把白名单放宽一点，或者把黑名单里的词挪到"待定"区人工判断。

还有一种情况是 arXiv 的 RSS 只保留最近若干条，如果你隔了几天没抓，中间的就丢了。解决办法是改用 arXiv 的 API 按日期范围查询，虽然麻烦一点，但不会丢数据。我现在的做法是 RSS 和 API 双通道，RSS 做日常增量，API 做补漏。

5.2 论文太多筛不过来怎么破

这是新手最容易遇到的问题。我的建议是先做减法，再做加法。一开始不要把网撒太大，只盯两到三个和你当前工作最相关的关键词，其他一律不看。等你对这几个方向的论文有了基本盘，再逐步扩展。我第一年只盯 "LLM agent" 和 "code generation" 两个方向，第二年才加上 "multimodal" 和 "evaluation"。

另一个技巧是设置"最低实验规模"门槛。比如我要求进入精读的论文，实验至少要在两个公开 benchmark 上做过，或者模型参数量不低于某个量级。这个门槛能过滤掉大量灌水论文，虽然会误伤一些有价值的 small-scale 工作，但整体效率提升明显。

5.3 笔记写了从来不看怎么解决

这个问题本质上是笔记和实际工作脱节。解决办法是强制建立"调用场景"：每次开始一个新任务或者遇到一个具体问题，先去笔记库里搜一遍，看有没有相关记录。搜不到就记下来，作为下次读论文的重点。搜到了就用起来，用完在笔记里补一句"这次用到了，效果如何"。这样笔记就活了，而不是死档案。

我还会定期做"笔记复述"：随机抽三篇旧笔记，用自己的话把核心内容讲一遍，讲不出来的说明当时没理解透，回去重读。这个动作很痛苦，但效果极好，能有效防止"假性理解"。

5.4 常见问题速查表

5.5 几个我踩过的坑和独家技巧

第一个坑是过度追求覆盖率。我一开始想把 cs.AI 所有论文都过一遍，结果每天花四五个小时，两周就崩了。后来想明白了，覆盖率不重要，命中率才重要。你不需要知道所有论文，你只需要知道和你相关的那些。

第二个坑是笔记写太细。我曾经把一篇论文的公式推导完整抄了一遍，花了两个小时，之后再也没看过。现在我的原则是：能一句话说清楚就不写第二句，能引用原文就不自己转述。

独家技巧方面，我强烈推荐给论文打"情绪标签"。比如"这篇读起来很爽"、"这篇读得我头疼"、"这篇让我怀疑人生"。情绪标签看起来不专业，但它能帮你快速回忆起当时的阅读体验，而阅读体验往往和论文质量高度相关。读起来爽的论文，通常思路清晰、实验扎实；读得头疼的，往往是方法复杂但动机不明。

6. 这套方法还能怎么扩展

这套流水线跑顺之后，我做了几个扩展。一个是加了一个"引用追踪"模块，用 Semantic Scholar 的 API 查每篇精读论文的被引情况，把高引论文自动标出来，作为重点精读的候选。另一个是加了一个"趋势统计"模块，每月统计一次各方向论文数量变化，用简单的折线图看趋势，比凭感觉判断靠谱得多。

还有一个扩展方向是把汇总和写作打通。我现在写技术文章或者做分享的时候，素材基本都来自平时的论文笔记，因为笔记里已经有结构化的判断和关联，直接调用就行，不用临时抱佛脚。这个打通之后，读论文的投入产出比又上了一个台阶。

如果你也想搭一套类似的流水线，我的建议是从最小可用版本开始：先只做抓取和人工筛选，跑两周，觉得节奏能坚持，再加笔记和归档。一上来就搭全套，大概率会因为维护成本太高而放弃。工具是为人服务的，别让人给工具打工。