我给自己定的规矩很简单：每个工作日至少认真读一篇论文，并把要点整理成一条固定格式的记录。这个习惯坚持到现在，项目名就叫 Daily Paper，文件的命名开头永远是一串日期，比如 2026-09-24。做这件事之前，我经常陷入一种状态：收藏夹里躺着几百篇论文，真正读完并能讲清楚的不到十分之一。Daily Paper 就是为了治这两个毛病——信息过载和读完就忘。它不是什么高深的技术，就是一套从选论文、精读、写摘要到定期复盘的固定流程。这篇内容我会把整套链路拆开讲，包括用什么工具、怎么筛选来源、怎么控制单篇耗时、怎么避免中途放弃。无论你是刚开始做文献调研的研究生，还是需要持续跟踪新技术的工程师，这套方法都能直接抄作业。

1. 项目思路与整体设计拆解

1.1 Daily Paper到底在解决什么问题

我身边很多人的阅读习惯是这样的：看到一篇标题感兴趣的论文，先存到收藏夹，想着“以后有空再看”，然后就没有然后了。真正的问题不是文献太少，而是没有一套固定的消费机制。学术界每天的产出量早就超过了任何人的处理能力，单靠“刷社交平台时顺便瞄两眼”根本建立不起知识体系，只会带来焦虑感。

Daily Paper 的核心思路，是把“读论文”从偶发行为变成固定流程。每天选一篇需要精读的论文，配合几篇扫一眼的候选论文，把信息提取、摘要整理、归档编号全部标准化。它解决的不是“今天看哪篇”，而是“明天、下周、半年后，你还能不能回忆起今天看过什么”。日期戳在这里起的作用类似于记账本上的账目日期——每一条记录都锚定在具体时间线上，方便回溯、统计和交叉引用。

这个设计还有一个隐藏优势：它逼着你做“减法”。一天精读一篇，看起来速度很慢，但如果真能坚持一年，就有超过二百篇论文是真正读透且留痕的。对比那些收藏了上千篇却从未输出的被动阅读者，这套方法的信息转化率高得多。我做这个项目最早是为了毕业论文的前期调研，后来发现它更适合用来跟踪一个领域的动态脉络，尤其是当你想搞清楚某个子方向的演进顺序时，按日期排列的阅读记录就是现成的编年史。

1.2 为什么用日期戳命名而不是论文标题

很多人第一次看到我的文件命名会很疑惑：2026-09-24_graph-based-long-context-reasoning.md，为什么不直接叫graph_based_long_context_reasoning.md？这个问题我认真想过。论文标题本身有信息量，但作为文件名并不好用。

第一，标题是“语义的”，日期是“序号的”。当你积累了几百个以论文标题命名的文件时，文件夹里会呈现出一堆互不关联的语义碎片，排序方式完全乱掉。而日期戳天然可排序，打开文件夹就是一条清晰的时间轴，哪一天看了什么一目了然。第二，标题往往很长，还有特殊字符、冒号、问号，不同操作系统对文件名的处理都不一样，存到云端或Git仓库里容易出现各种兼容性问题。第三，也是我最看重的一点：日期戳是“中立的”。它不预设你对这篇论文的态度，也不受你当时情绪影响。等过几个月回看时，你不会因为文件名里写着“interesting”或“useful”而带着偏见重新审视。

用生活里的例子类比，这就好比记账。你不会把每一笔账目命名为“买咖啡”“交房租”，而是记成“2026-09-24 午饭支出”。日期是索引，内容是明细。Daily Paper 的索引就是日期，论文信息是明细。当你需要按照主题整理时，再通过标签系统和表格列出来完成，而不是依赖文件名本身。

1.3 这个工作流适合谁来抄作业

这套东西看起来是给科研人员准备的，实际上适用范围比我最初想的宽得多。研究生和博士生的诉求最直接——毕业论文需要文献综述，申课题需要论证创新性，Daily Paper 的月度复盘可以直接变成综述初稿的素材。工程师群体也很适合：很多做算法的同学需要跟踪最新模型和技术路线，但又没有完整时间读每一篇原始论文，用这套流程可以先看摘要和图表，把深度阅读留给真正重要的那几篇。

还有一类人是跨领域学习者，比如原来写后端突然转去做推荐系统，需要快速补一个新方向的基础文献。这种情况下，Daily Paper 的“每天固定一篇”比“周末集中读十篇”更能对抗遗忘曲线。我的经验是，跨领域学习最怕的不是不努力，而是被陌生术语劝退。把一篇论文拆解成背景、问题、方法、实验、结论五个部分，把不懂的概念单独标记出来，第二天再回头查，学习曲线会平滑很多。

2. 核心环节：从选论文到落笔记

2.1 论文来源的筛选策略

Daily Paper 的第一步不是读论文，而是让论文“流到”你面前。等论文自己撞上来是很低效的，需要主动搭建几条可持续更新的来源管线。我目前用的是三条并行管道。第一条是主题订阅：把关注方向的 arXiv 分类接口接进来，每天跑一次查询，拿到当天的论文列表。第二条是期刊和会议邮件提醒，比如 NeurIPS、ICML 这类会议的 accepted papers 列表，以及几个固定期刊的新文章通知。第三条是“引用追踪”：从本周精读的论文所引用的关键文献里，反向挖掘更早的基础论文。

用 arXiv API 拉取每天的新论文，是成本最低的做法。很多语言都支持，我用 Python 的 requests 库，代码很简单，但足够完成筛选任务：

import requests import xml.etree.ElementTree as ET arxiv_api = "http://export.arxiv.org/api/query" params = { "search_query": "cat:cs.CL AND submittedDate:[202609240000 TO 202609242359]", "start": 0, "max_results": 20, } resp = requests.get(arxiv_api, params=params) root = ET.fromstring(resp.content) 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(title, link)

这段代码的核心价值不在代码本身，而在search_query的构造方式。cat:cs.CL是限定子分类，submittedDate是时间窗。你可以把cat换成自己的关注领域，比如cs.LG（机器学习）、cs.IR（信息检索）或stat.ML（统计机器学习）。跑一次大概能拿到几十篇候选，我从中挑出一二篇精读，剩下的存入“待读列表”。真实的筛选动作其实不是靠代码完成的，靠的是长期训练出来的判断力。代码负责把范围缩小到可手动的量级，你负责最后一公里的人工判断。

2.2 精读与泛读的取舍

每天都精读全文是不可能的，也没必要。我执行的规则是“每周五篇泛读，两篇精读”，但再往里细化，其实取决于论文类型。

我踩过的坑是“平均用力”。刚开始做 Daily Paper 时，我对每篇论文都花大把时间做笔记，结果一天只能处理一篇，而且容易陷入细节，忽略了整体视野。后来调整为：除精读论文外，其他论文只要求写下“能用一句话说清楚这篇文章做了什么”。这个“一句话总结”的训练远比想象中难，它逼着你抓住最核心的贡献，而不是罗列一堆术语。如果一句话说不清，要么是你没读懂，要么是论文本身写得含混。

精读和泛读不是静态分类，而是可以转换的。有时候一篇泛读论文里面蹦出一个你没见过的概念，顺着这个概念追下去，可能就发现下一篇需要精读的论文。所以我在每篇笔记里保留“related”标签，遇到有意思的引用就补进候选列表。用这种“以文找文”的滚雪球方式，两周左右就能在一个新方向上建立起基础框架。

2.3 笔记模板与摘要写法

笔记模板是 Daily Paper 的地基。我调试过很多版本，最后固定下来的模板长这样，每个字段都有存在理由：

# [一句话总结]多伦多大学用对比字符串相似度来筛选检索目标，将长文本问答的延迟直接降低了30% - 日期：2026-09-24 - 论文标题：Efficient Retrieval-Augmented Generation via Contrastive String Matching - 作者：J. Zhang, A. Martinez, S. Chen（第一作者为主） - 来源：arXiv / ACL 2026 ## 1. 背景与问题 当前 RAG 方法依赖向量相似度检索，存在两个痛点：索引构建成本高、短查询-长文档边界不清晰。 ## 2. 方法 提出一套字符串级对比学习方案，通过双塔模型同时刻画语义相似度和字符串结构特征，并设计两阶段候选过滤。 ## 3. 关键实验 - 数据集：Natural Questions、TriviaQA - 指标：答案准确率、检索召回率、端到端延迟 - 结果：准确率保持持平，延迟降低约30%，索引体积缩小50% ## 4. 结论与局限 作者认为这种方案更适合知识库频繁更新的场景；局限是长尾实体召回仍不稳定。 ## 5. 我的想法 - 是否可以用在目前部门日志问答系统里？ - 需要关注中文语料下的字符串特征是否同样有效 - 待办：跑一下复现脚本，关注第二阶段的阈值的敏感性 ## 6. 关联论文 - [[2026-09-18_low-rank-adaptation]]：同样关注推理效率，但视角在模型层

这个模板的关键不是字段多，而是顺序。一句话总结放在最前面，强迫你先想清楚这篇论文的“销售口号”；后面所有细节都是对这句话的论证。我的想法这个字段特别重要，它决定了笔记是“别人的论文”还是“你的知识资产”。没有这个字段，笔记就变成简单的内容搬运，而不是思考沉淀。

2.4 归档命名规范

归档命名规范直接参考了 Zettelkasten 笔记法的思路：一个笔记只对应一个原稿，文件位置互不干扰。命名格式为YYYY-MM-DD_首作者姓氏_关键词.md，例如2026-09-24_zhang_efficient_rag.md。如果一天精读多篇，就在日期后面加-a、-b来区分。

为什么不用论文标题做文件名？除了前面说的排序问题，还有一个很实际的原因——很多论文标题带有冒号和副标题，在部分文件系统、Markdown 双链、Obsidian 搜索里都会出问题。关键词字段的作用，是让你在忘记日期时仍能通过文件名内容检索到笔记。Obsidian 或者 Logseq 里支持双链语法，所以我在笔记里会写[[2026-09-18_low-rank-adaptation]]来建立连接，这比树状文件夹灵活得多，也更容易发现跨主题的关联。

如果不懂 Markdown 双链，可以简单理解成超链接，只不过链接目标是另一篇笔记的标题，而不是网址。双链的价值在于：当你读 9 月 24 日的 RAG 笔记时，侧边栏会自动列出所有引用过它的笔记，包括 9 月 18 日那条讲模型压缩的。这种“意外发现”正是知识管理中最值钱的部分，因为它往往能带来跨领域灵感。

3. 实操过程：以2026-09-24这一期为例

3.1 当天论文池的构建

2026 年 9 月 24 日我照常打开 arXiv 的 API 脚本，拿到当天新增论文列表。但 API 返回的只是大池子，还需要根据论文池做二次筛选。我当天最先注意到的是三条线：一条是检索增强生成方向，因为当时我正在做一个问答系统的调研；一条是低秩适配方向，已经有几天没跟进了；还有一条是时间序列预测，属于顺带维护的长线关注。

最终我把精读名额给了那篇检索增强相关的论文，标题是关于对比字符串匹配的。选择原因很直接：它提出的方案直接针对我当时最头疼的检索延迟问题，而且实验设置在标准问答数据集上，复现门槛低。剩下的论文里，两篇进入了泛读队列，只花了大概二十分钟扫完摘要和图表，分别写了一句总结就归档。这个过程看起来效率不高，但它保证了一个关键效果：当天的阅读动作是有方向的，不是随机刷论文。

我特别想强调的是“论文池”的概念。每天只看 API 拉回来的最新列表是不够的，还要维护一个常驻候选名单。我的候选名单来源有三种：之前笔记里的“关联论文”字段、同领域学者近期提交的系列工作、以及一些长期没来得及精读的“远古”经典论文。当天如果新论文质量不行，就从候选中找补。靠这个机制，我几乎不会出现某天一整天没论文可读的窘境。

3.2 阅读与信息提取的关键动作

拿到论文后，我做的第一件事不是从头读到尾，而是先读摘要、结论、图表。这三个部分能迅速告诉我：这篇论文解决的问题是不是我关心的，方法有没有可能落地到我手头的场景。如果三个部分读完觉得没新意，就降级为泛读，不再投入精读时间。

真正进入精读后，我会带着几个固定问题去读原文。这些问题相当于我的“审问清单”：

• 作者声称要解决的问题，真的是问题吗？还是人为制造的问题？
• 之前的方法为什么不够好？作者给的证据是否充分？
• 新方法的核心思想能否用一句话抽象出来？换一个场景还能成立吗？
• 实验设计是否公平？对比基线是不是足够强？
• 论文的结论有多强的普适性？有没有不愿意展示的失败案例？

在这个阶段，我会禁用“自动翻译”。很多人在读论文时习惯开翻译软件，我的经验是：术语的翻译往往会掩盖细微的逻辑关系，尤其像“inductive bias”“generalization gap”这类词，翻译成中文反而失去原本的语感。如果英文不熟，优先保证理解标题、摘要、图表标注这几个部分，正文可以跳读。读第一篇论文时慢一点没有关系，关键是建立对论文结构的敏感度。

阅读过程中我会随手高亮关键句子，但高亮不是目的。真正有价值的是把高亮句子“转译”成自己的语言，放进笔记的“方法”字段。转译的本质是压缩，如果能用两三句话讲清楚作者用了三段话才说清的内容，说明你是真读懂了。

3.3 输出Daily Paper笔记的具体步骤

从读完全文到笔记落盘，我给自己规定的时限是“当天必须完成”。哪怕晚上回到宿舍已经十一点，我也会把笔记骨架先填完。输出笔记的动作分解开来其实有五步。

第一步，清理原始素材。把阅读时的高亮、批注、随手写的疑问全部集中到一个临时文档里，按“背景、方法、实验、想法”四个桶归类。这个步骤不做任何判断，只做搬运。第二步，写“一句话总结”。这是最费脑子的环节，我通常会写三版，第一版总是太长，第二版总是不够准确，到第三版才接近理想状态。不要小看这个琢磨的过程，它其实就是抽象能力训练。

第三步，填充模板。把素材按照 2.3 节的模板对应填入，注意不能直接把作者摘要复制过来，一定要加入自己的转述。第四步，补充“关联论文”和“我的想法”。这一步我建议不要在读完论文的当下就做，稍微空几个小时，让大脑后台处理一下，反而容易冒出更好的联想。我常常是下午读论文，晚上写想法，中间去健身房跑一圈，思路往往更清楚。第五步，归档并更新索引。文件按命名规范放进对应文件夹，同时在总索引表里新增一行记录。

这五步看起来繁琐，熟练后四十分钟左右就能完成。关键是不要让笔记写完就沉底。我每周日会花半小时把本周所有笔记重新扫一遍，修改过时的想法，补充新的关联。这种“二次加工”才是知识真正内化的环节。

3.4 数据记录与复盘机制

Daily Paper 如果想要长期运转，光靠笔记文件还不够。我会维护一个简单的表格，记录每次阅读的元数据。表格字段包括：日期、论文标识、方向、阅读方式（精读/泛读）、耗时、可复现性、行动项。这个表格的价值有三个：统计工作量、发现阅读偏向、追踪行动项。

比如，某段时间我发现自己的笔记里 60% 都是模型压缩方向，那说明我的知识构图可能偏科了，需要刻意引入其他方向。再比如，如果我记录了一个“跑复现脚本”的行动项，复盘时发现已经拖了三周没做，要么减少这类承诺，要么尽快排期清掉。行动项积压会带来愧疚感，而愧疚感是破坏习惯的最大杀手。

表格用 Excel 完全够用，但如果想自动化统计，可以用 Python 的 pandas 读入，按月份聚合出方向分布图、耗时趋势线。我自己的做法是把表格放在和笔记同一个 Git 仓库里，每次更新笔记就顺带更新表格，用 Git 的提交记录来追踪自己的长期稳定性。提交频率高不代表学习质量好，但提交频率过低一定意味着这个习惯在退化。

4. 踩坑记录与排查心得

4.1 常见问题排查速查表

Daily Paper 做了大半年，我遇到过各种让人想放弃的时刻。这里整理成一张排查表，基本覆盖了最常见的症状。

这张表里最值得记住的其实是第一行：当你不想做一件事的时候，最好的应对不是逼自己打起精神，而是主动降低执行标准。Daily Paper 的死敌是“必须精读才叫读论文”的完美主义。我给自己留了一个台阶：哪怕是“划水日”，也要在表格里记一条，哪怕那条只是“扫了五篇论文的摘要，判断全部不值得精读”。至少动作是连续的，习惯没断。

4.2 工具链的避坑建议

工具选择上，我走过不少弯路。一开始我用 Word 写笔记，后来发现批量检索、双链、版本管理都不方便，改成了 Markdown 笔记库。Markdown 的好处是纯文本、跨平台、可 diff，这些特性让笔记可以放进 Git 仓库做备份和回溯。客户端用 Obsidian 或 VS Code 都行，Obsidian 的双链和图形化关系视图更适合做知识管理，VS Code 则更轻量，写起来顺手。

文献管理方面，Zotero 是我目前的常驻工具。需要提醒的是，Zotero 的附件同步经常出问题，尤其是多个设备同时打开同一篇 PDF 时，很容易产生冲突。我的做法是：Zotero 只负责元数据和引用格式，PDF 原件按年份和作者分目录存到网盘，笔记库只放链接和摘要。这样的分层设计避免了一边是 Zotero 卡死，一边是笔记丢数据的窘境。

还有一个容易被忽略的点：笔记库的目录结构不要设计得太深。我一开始按“领域/子领域/年份”建目录，结果找一篇笔记要点五六次文件夹。后来改成扁平目录加文件名编号，一个文件夹能放几百个 Markdown 文件，纯靠文件名和双链检索。这个改动让查找效率提升了一大截。

4.3 如何保持习惯与持续改进

保持日更习惯，比优化任何工具都重要。我总结下来，真正管用的三条经验是：固定时间块、使用“迷你起步”、建立对外输出渠道。

固定时间块的意思是，把读论文安排在每天同一个时段，比如早上九点到十点，让大脑形成条件反射。如果只能晚上读，那就严格固定在晚上，不要今天晚上明天早上来回飘，飘几次就断了。迷你起步的意思是，不要规定自己“必须读两小时”，只规定“打开笔记软件，读至少一段”。启动这个动作本身就消解了大部分拖延心理，一旦开始，往往不止读一段。

对外输出渠道对我来说是 GitHub 上的公开仓库。每日笔记同步更新到仓库，Stars 数量不重要，重要的是那种“有人可能会看到”的感觉会倒逼你保证质量。这个方法强烈推荐给自制力一般的人。如果你不想公开，找一个小伙伴互相交换笔记也是一样的效果，关键是要让阅读和输出产生外部可见性。

5. 扩展方向：从每日记录到长期资产

5.1 把Daily Paper沉淀成月度综述

Daily Paper 跑了一个月后，你手里会攒下二三十篇笔记。这些笔记如果只是躺着，价值并没完全释放。我给自己的要求是每个月月底做一次“综述拼接”：把本月所有笔记按方向分组，提取每篇的“一句话总结”，然后按主题串成一个初稿结构。

操作上并不复杂。打开表格，用方向字段做聚合，每个方向下的论文按时间排序。然后为每个方向写三段式拼接：背景脉络（这个月这个方向发生了什么）、关键突破（哪些论文带来了新进展）、遗留问题（哪些坑还没填上）。这部分不是从零写综述，而是对已有笔记的整合，通常在半天内能完成。

这个月度综合文档还有一个很实际的作用：它是年终总结或开题报告的第一手素材。当导师问“这个季度你关注了什么”，你不需要回忆，直接把综合文档拿出来改改成提纲就行。知识管理最大的回报不是你存了多少资料，而是关键时刻你能快速组织出高质量的回答。

5.2 团队协作与分享场景

如果团队里有几个同事一起维护 Daily Paper，价值会进一步放大。我用过一个简化的协作方案：每人负责一个方向，每天把笔记推送到共享仓库的daily/目录下，文件名带上日期和作者前缀，比如2026-09-24_li_rag_retrieval.md。每周五下午用半小时开个论文分享会，每人挑本周自己笔记里最有启发的一篇讲十分钟。这种机制比单纯转发现成的论文推荐邮件有用，因为每个人讲解的时候会带有自己的判断和上下文，团队成员间的知识隔阂会被快速打破。

技术上，共享仓库用 GitLab 或 Gitea 很合适，支持 Issue 跟踪行动项。我在仓库里放了一个简单的 Python 脚本，扫描daily/目录自动生成周报 Markdown，按日期和作者分类汇总。这个脚本不到三十行，用的是最基础的 os 和 datetime 模块，却省去了每周手动整理摘要的时间。团队协作最关键的一点是格式统一，所以模板一定要提前约定好，哪怕看起来死板，也比自由发挥强。

结尾

把 Daily Paper 坚持了半年之后，我发现它带给我的收获已经超出了“读过很多论文”这件事本身。最明显的变化是，我越来越能在十分钟内判断一篇论文值不值得深读，而且能清晰地向别人解释“这个方向最近发生了什么”。这个能力不是靠天分，而是靠每天的练习堆出来的。

最后再分享一个小技巧：给每天的论文阅读设置一个“最低完成线”，我的线是“一句总结加三个要点”。只要越过这条线，这一天就算合格，哪怕没有精读也没有关系。习惯的养成本质上是和惰性达成一个公平协议——你允许它偶尔存在，它允许你持续前进。这套方法的门槛比大多数人想象的低，收益却会在几个月后以复利的形式显现出来。