企业官网建设流程全解析

1. 从一篇“每日论文分析报告”说起：为什么我要把 arXiv 刷成流水线

每天早上七点半，我的邮箱里会准时躺着一封自己写给自己的邮件，标题格式固定是“arXiv 每日论文分析报告 YYYY-MM-DD”。点开之后，是当天 arXiv 上与我研究方向相关的十几篇新论文，每篇都带着一句话的核心贡献、方法关键词、和我已有工作的关联度打分，以及“值得精读 / 扫一眼 / 直接跳过”的三档标签。这套东西不是某个现成服务推给我的，而是我自己搭的一条小流水线跑出来的结果。今天这篇博文，我就拿“arXiv 每日论文分析报告2026-09-24”这一天的报告作为样本，把整条链路从订阅、抓取、筛选、分析到成文，完整拆一遍。

先说清楚这套东西解决什么问题。做研究或者做工程的人都知道，arXiv 每天新增的论文量是海量的，光是 cs.CL、cs.CV、cs.LG 这几个大类，一天几百篇是常态。靠人肉刷列表，结果只有两个：要么漏掉真正重要的，要么被大量低相关内容淹没，刷了半小时啥也没记住。我需要的不是“更多论文”，而是“更少但更准的论文”，并且每篇都带上足够的上下文，让我能在三十秒内判断要不要花两小时去读。这就是“每日论文分析报告”的核心价值——它把信息过载问题转化成了一个排序和摘要问题。

这套流程适合谁参考？三类人。第一类是刚进组的研究生，还没建立起自己的论文追踪习惯，需要一套能直接抄的模板；第二类是做工程但需要跟进前沿的开发者，没时间系统读论文，只想知道“这周有没有能用到我项目里的新方法”；第三类是做技术情报、投资分析或者内容创作的人，需要快速摸清某个方向最近的动向。不管你属于哪一类，下面的内容都能按需裁剪——重活我干了，你挑能用的部分搬走就行。

关键词我先摆在这：arXiv、论文分析报告、订阅、抓取、筛选、摘要、打分。这几个词基本覆盖了整条链路的每个环节，后面每个章节我都会围绕它们展开，不会跑偏。

2. 整体设计思路：为什么是“订阅 + 抓取 + 本地分析”而不是现成工具

2.1 现成服务的三个硬伤

市面上追踪 arXiv 的工具不少，有网页版的、有邮件订阅的、有做成 App 的。我前后试过七八个，最后都放弃了，原因集中在三点。

第一是筛选维度太粗。大部分工具只支持按 arXiv 分类（比如 cs.CL）或者关键词订阅，但关键词匹配是字面匹配，我关注“retrieval augmented generation”，它会把所有标题里带 retrieval 的论文都推给我，包括做数据库检索的、做图像检索的，噪音极大。我需要的是语义层面的相关性，而不是字符串层面的。

第二是摘要质量参差。有些工具直接截取论文摘要的前两句，但 arXiv 摘要的写法千奇百怪，有的前两句全是背景铺垫，真正的贡献藏在第三句。我需要的是“这篇论文到底做了什么新东西”，而不是“这篇论文在讨论什么领域”。

第三是无法定制输出。我想要的是每天一封邮件、按相关性排序、带打分和标签、能直接归档成 Markdown 的格式。现成工具要么只能网页看，要么邮件格式固定死，改不了。

2.2 自建流水线的四个模块

想清楚这些之后，我把整条链路拆成了四个模块，每个模块职责单一，方便单独替换和调试。

• 订阅模块：负责确定“我要关注哪些方向”。不是简单填几个关键词，而是维护一份“兴趣画像”，包含核心关键词、负向关键词、以及几个我信任的种子论文标题，用来做语义相似度锚点。
• 抓取模块：负责每天从 arXiv 拉取新增论文的元数据。arXiv 官方提供了 API，返回 Atom 格式的 XML，包含标题、作者、摘要、分类、提交时间、PDF 链接等字段，够用了。
• 分析模块：这是整条链路的核心。对每篇论文做三件事——相关性打分、贡献摘要、标签分类。相关性打分用嵌入向量做余弦相似度，贡献摘要用规则加模板生成，标签分类用关键词加分类映射。
• 成文模块：把分析结果渲染成一份结构化的 Markdown 报告，按打分排序，分档展示，最后通过邮件或者本地文件输出。

2.3 为什么不用大模型一把梭

有人会问，现在大模型这么强，为什么不直接把论文标题和摘要丢给模型，让它输出分析结果？我试过，结论是：可以，但不划算，也不稳定。

不划算是因为成本。一天几百篇论文，每篇都调一次大模型 API，一个月下来费用不低，而且大部分论文其实和我无关，没必要为它们花钱。不稳定是因为大模型的输出格式会飘，今天让它输出 JSON，明天可能就给你加一段解释性文字，解析起来很烦。更重要的是，大模型对“相关性”的判断依赖提示词，而提示词很难精确表达“我关心的 retrieval augmented generation 是指用外部知识增强生成，不是指数据库检索”这种细微差别。

所以我的方案是分层处理：先用轻量的嵌入模型做粗筛，把几百篇砍到十几篇；只对这十几篇调用大模型做精细摘要和标签。这样成本可控，格式也稳定，因为进入精处理阶段的论文数量少，我可以对输出格式做严格校验。

2.4 一天的报告长什么样

先给你看看 2026-09-24 那天的报告结构，心里有个底。整份报告分四块：

1. 今日概览：新增论文总数、命中数、各档数量分布、当天最热的关键词。
2. 精读推荐：打分最高的 3 到 5 篇，每篇带完整分析。
3. 扫读列表：打分中等的 8 到 12 篇，每篇一句话总结。
4. 跳过清单：打分低但命中了关键词的论文，只列标题，供快速扫一眼确认没漏。

这个结构的好处是，我早上花两分钟看概览和精读推荐，五分钟扫完扫读列表，跳过清单基本不看。整个流程控制在十分钟以内，信息获取效率比人肉刷列表高一个数量级。

3. 核心细节解析：订阅、抓取、打分、摘要的实操要点

3.1 订阅模块：兴趣画像怎么建才不跑偏

订阅不是填关键词那么简单。我踩过的最大坑是：一开始只填了“retrieval augmented generation”和“large language model”两个词，结果每天推来的论文里有一半是我不关心的，比如做 LLM 推理加速的、做 LLM 安全对齐的。这些方向本身很重要，但不是我的菜。

后来我把兴趣画像拆成了三层。

第一层是核心关键词，3 到 5 个，必须精确。比如我的核心词是“retrieval augmented generation”“dense retrieval”“knowledge grounded generation”。这些词一旦命中，相关性基础分就很高。

第二层是负向关键词，用来排除干扰。比如我加了“database”“SQL”“image retrieval”“recommendation”，因为这几个词经常和 retrieval 一起出现，但方向完全不同。负向词命中不直接淘汰，而是扣分。

第三层是种子论文，5 到 10 篇我读过且觉得代表性的论文标题。这些标题会被转成嵌入向量，作为语义相似度的锚点。一篇新论文如果和某个种子论文的相似度超过阈值，即使关键词没命中，也会被捞回来。这一层是防止漏掉“用词不同但方向相同”的论文。

三层结合起来，订阅的准确率和召回率都上来了。实测下来，每天命中数从最初的四五十篇降到了十几篇，但真正相关的比例从不到三成提到了七成以上。

3.2 抓取模块：arXiv API 的正确用法

arXiv 的 API 入口是http://export.arxiv.org/api/query，支持按分类、关键词、时间范围查询。几个关键参数必须搞清楚，不然抓回来的数据要么不全要么重复。

• search_query：查询表达式。按分类查用cat:cs.CL，按时间查用submittedDate:[202609230000 TO 202609240000]，多个条件用AND、OR连接。
• start和max_results：分页参数。单次最多返回 2000 条，但实际用的时候建议每次 100 条，分页拉，避免超时。
• sortBy：排序字段。我一般用submittedDate，按提交时间倒序。
• sortOrder：descending或ascending。

一个容易忽略的点是时区。arXiv 的提交时间用的是东部时间，而我的报告是按北京时间早上七点半生成的。如果不做时区转换，会漏掉当天凌晨提交的论文。我的做法是查询范围往前多取 12 小时，然后在本地按转换后的时间过滤。

另一个坑是重复提交。同一篇论文可能因为作者修改而多次出现在列表里，version 号不同但标题一样。我的去重策略是用 arXiv ID 去掉版本号后的部分作为唯一键，保留最新版本。

抓取频率也要注意。arXiv 官方建议不要高频请求，我设置的是每天一次，早上六点半跑，请求间隔 3 秒，避免给对方服务器造成压力。这既是礼貌，也是避免被封 IP 的自我保护。

3.3 打分模块：相关性分数怎么算才靠谱

打分是整条链路里最需要调参的部分。我的打分公式是加权求和：

score = 0.4 * keyword_score + 0.4 * semantic_score + 0.2 * recency_score - penalty

逐项解释。

keyword_score：核心关键词命中情况。命中一个核心词加 0.3，命中两个加 0.6，三个以上直接给 1.0。负向词每命中一个扣 0.2。这个分数是离散的，容易计算，但不够细腻。

semantic_score：语义相似度。把论文标题和摘要拼起来，用嵌入模型转成向量，和每个种子论文向量算余弦相似度，取最大值。这个分数是连续的，能捕捉到关键词没覆盖的相关性。我用的是本地部署的小型嵌入模型，速度快，不需要联网，隐私也好。

recency_score：新鲜度。当天提交的给 1.0，前一天给 0.8，两天前给 0.5，更早的给 0.2。这个分数是为了让报告偏向最新论文，毕竟旧论文我可能已经看过了。

penalty：惩罚项。除了负向关键词，还包括一些启发式规则，比如标题里带“survey”的扣 0.1（综述通常不是我最优先读的），带“workshop”的扣 0.2（workshop 论文质量参差），作者数超过 15 个的扣 0.1（大团队论文往往方向较泛）。

这套公式我调了大概两周，主要调的是权重和阈值。最终定下来的分档标准是：score ≥ 0.75 进精读推荐，0.45 到 0.75 进扫读列表，0.2 到 0.45 进跳过清单，低于 0.2 直接丢弃。

3.4 摘要模块：一句话说清论文贡献的模板

摘要生成是最容易做成“正确的废话”的环节。我见过很多工具生成的摘要就是“本文提出了一种新方法，在多个数据集上取得了良好效果”，这种摘要等于没说。

我的做法是用结构化模板 + 关键信息抽取。每篇论文的摘要固定包含四个部分：

• 做了什么：从标题和摘要里抽取动词短语，比如“提出了一种基于对比学习的检索器”。
• 怎么做的：抽取方法关键词，比如“对比学习”“负采样”“双塔结构”。
• 效果如何：抽取数据集和指标，比如“在 BEIR 上 nDCG@10 提升 3.2 个点”。
• 和我的关系：基于打分结果，说明为什么推荐，比如“和你的种子论文 X 方法相似，但改进了负采样策略”。

前三个部分用规则加正则抽取，第四个部分用模板填充。对于进入精读推荐的论文，我会额外调用一次大模型，让它基于这四个部分生成一段更自然的描述，但格式仍然受模板约束，避免跑偏。

这里有个实操心得：摘要里一定要保留具体数字。“效果提升明显”是废话，“提升 3.2 个点”才有信息量。所以我在抽取阶段会专门匹配数字加单位的模式，确保关键指标不被漏掉。

4. 实操过程：从零搭起这条流水线

4.1 环境准备与依赖安装

整套系统跑在一台常开的迷你主机上，系统是 Ubuntu 22.04，配置不高，4 核 8G 内存，足够用了。依赖分三块：Python 环境、嵌入模型、邮件发送。

Python 用 3.10，虚拟环境管理用 venv。核心依赖库：

pip install requests feedparser numpy scikit-learn sentence-transformers jinja2 python-dateutil

• requests：发 HTTP 请求调 arXiv API。
• feedparser：解析 Atom XML，比手写 XML 解析省事。
• numpy和scikit-learn：算余弦相似度、做归一化。
• sentence-transformers：加载本地嵌入模型。
• jinja2：渲染 Markdown 报告模板。
• python-dateutil：处理时区转换。

嵌入模型我选的是all-MiniLM-L6-v2，体积小（约 80MB），速度快，在 CPU 上跑几百篇论文的向量化也就几十秒。如果你的机器有 GPU，可以换更大的模型，效果会更好，但对我来说这个小模型够用了。

邮件发送用 SMTP，我用的是自己的邮箱服务，配置放在环境变量里，不写进代码。这一点很重要，密钥和密码绝对不能硬编码在脚本里，不然一旦代码泄露就麻烦了。

4.2 抓取脚本的完整实现

抓取脚本的核心逻辑是：构造查询表达式、分页拉取、解析 XML、去重、存成 JSON。下面是我实际用的代码骨架。

import requests import feedparser from datetime import datetime, timedelta from dateutil import tz ARXIV_API = "http://export.arxiv.org/api/query" CATEGORIES = ["cs.CL", "cs.IR", "cs.LG"] def build_query(categories, start_date, end_date): cat_query = " OR ".join([f"cat:{c}" for c in categories]) date_query = f"submittedDate:[{start_date} TO {end_date}]" return f"({cat_query}) AND {date_query}" def fetch_papers(query, max_results=500): papers = [] batch_size = 100 for start in range(0, max_results, batch_size): params = { "search_query": query, "start": start, "max_results": batch_size, "sortBy": "submittedDate", "sortOrder": "descending", } resp = requests.get(ARXIV_API, params=params, timeout=30) feed = feedparser.parse(resp.content) if not feed.entries: break for entry in feed.entries: papers.append(parse_entry(entry)) time.sleep(3) return papers def parse_entry(entry): arxiv_id = entry.id.split("/abs/")[-1] base_id = arxiv_id.split("v")[0] return { "id": base_id, "version": arxiv_id, "title": entry.title.strip().replace("\n", " "), "abstract": entry.summary.strip().replace("\n", " "), "authors": [a.name for a in entry.authors], "categories": [t["term"] for t in entry.tags], "published": entry.published, "pdf_url": entry.link.replace("/abs/", "/pdf/"), }

几个细节值得说。time.sleep(3)是必须的，不加的话连续请求容易被限流。base_id去掉版本号是为了去重，同一篇论文的 v1 和 v2 只保留最新的。标题和摘要里的换行符要清掉，不然渲染报告时格式会乱。

时区转换在查询之前做。我的报告是北京时间早上七点半生成，对应东部时间前一天晚上七点半。所以查询范围是东部时间前一天 00:00 到当天 00:00，换算成 arXiv 的格式就是202609230000 TO 202609240000。

4.3 打分与筛选的落地

打分脚本接收抓取到的论文列表，输出带分数的列表。核心是加载嵌入模型、算相似度、套公式。

from sentence_transformers import SentenceTransformer import numpy as np model = SentenceTransformer("all-MiniLM-L6-v2") CORE_KEYWORDS = ["retrieval augmented generation", "dense retrieval", "knowledge grounded generation"] NEGATIVE_KEYWORDS = ["database", "sql", "image retrieval", "recommendation"] SEED_TITLES = [ "Dense Passage Retrieval for Open-Domain Question Answering", "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks", # ... 更多种子论文 ] seed_embeddings = model.encode(SEED_TITLES, normalize_embeddings=True) def keyword_score(text): text_lower = text.lower() score = 0.0 for kw in CORE_KEYWORDS: if kw in text_lower: score += 0.3 score = min(score, 1.0) for nkw in NEGATIVE_KEYWORDS: if nkw in text_lower: score -= 0.2 return max(score, 0.0) def semantic_score(text): emb = model.encode([text], normalize_embeddings=True)[0] sims = np.dot(seed_embeddings, emb) return float(np.max(sims)) def recency_score(published_str): pub = datetime.strptime(published_str, "%Y-%m-%dT%H:%M:%SZ").replace(tzinfo=tz.UTC) now = datetime.now(tz.UTC) hours = (now - pub).total_seconds() / 3600 if hours <= 24: return 1.0 elif hours <= 48: return 0.8 elif hours <= 72: return 0.5 return 0.2 def compute_score(paper): text = paper["title"] + " " + paper["abstract"] ks = keyword_score(text) ss = semantic_score(text) rs = recency_score(paper["published"]) penalty = 0.0 if "survey" in paper["title"].lower(): penalty += 0.1 if "workshop" in paper["title"].lower(): penalty += 0.2 if len(paper["authors"]) > 15: penalty += 0.1 return 0.4 * ks + 0.4 * ss + 0.2 * rs - penalty

这段代码里，normalize_embeddings=True很关键，它让向量长度归一化，之后点积就等于余弦相似度，省去了手动除模长的步骤。semantic_score取的是和所有种子论文相似度的最大值，而不是平均值，因为一篇论文只要和某一个种子高度相关就够了，不需要和所有种子都相关。

分档逻辑很简单，按 score 排序后按阈值切分。但有个细节：精读推荐最多 5 篇，即使有 10 篇超过 0.75，也只取前 5。这是为了控制我的阅读负担，宁可漏掉几篇，也不能让报告变成新的信息过载源。

4.4 报告渲染与邮件推送

渲染用 Jinja2 模板，输出 Markdown。模板结构对应前面说的四块：概览、精读、扫读、跳过。概览部分统计各档数量、当天高频关键词、以及和前一天的数量对比。

from jinja2 import Template REPORT_TEMPLATE = """ ## 今日概览 - 新增论文总数：{{ total }} - 命中论文数：{{ hit_count }} - 精读推荐：{{ deep_count }} 篇 - 扫读列表：{{ scan_count }} 篇 - 跳过清单：{{ skip_count }} 篇 ## 精读推荐 {% for p in deep_papers %} ### {{ loop.index }}. {{ p.title }} - **相关性打分**：{{ "%.2f"|format(p.score) }} - **核心贡献**：{{ p.summary }} - **方法关键词**：{{ p.method_keywords|join("、") }} - **推荐理由**：{{ p.reason }} - **PDF**：{{ p.pdf_url }} {% endfor %} ## 扫读列表 {% for p in scan_papers %} - **{{ p.title }}**（{{ "%.2f"|format(p.score) }}）：{{ p.one_liner }} {% endfor %} ## 跳过清单 {% for p in skip_papers %} - {{ p.title }} {% endfor %} """

邮件发送用smtplib，把渲染好的 Markdown 转成 HTML 或者直接发纯文本都行。我选的是纯文本加 Markdown，因为我在手机和电脑上都是用 Markdown 阅读器看，格式清晰，复制到笔记软件里也方便。

发送时间设在早上七点半，用系统的 cron 定时任务触发。整个脚本从抓取到发送大概跑三到五分钟，主要时间花在嵌入模型编码上。如果嫌慢，可以把模型换成更小的，或者只对粗筛后的论文做编码，能省不少时间。

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

5.1 抓取不到当天论文怎么办

这是最常见的问题，原因通常有三个。第一是时区算错了，查询范围没覆盖到当天。排查方法是手动把查询范围放宽到前后各两天，看能不能抓到，如果能，就是时区问题。第二是 arXiv API 临时抽风，返回空结果或者超时。这种情况重试一次通常就好，我在代码里加了三次重试，每次间隔 10 秒。第三是分类选错了，比如你关注的方向其实在 cs.CL，但你只查了 cs.LG。排查方法是把分类放宽，看命中数是否正常。

5.2 相关性打分不准怎么调

打分不准分两种情况：该推的没推（漏报），不该推的推了（误报）。漏报通常是语义相似度阈值太高，或者种子论文太少。解决办法是增加种子论文数量，覆盖更多子方向，同时把 semantic_score 的权重调高。误报通常是负向关键词不够，或者核心关键词太宽泛。解决办法是补充负向词，把核心词写得更具体，比如把“retrieval”改成“dense retrieval”。

我自己的调参经验是：先保证召回，再优化准确。宁可多推几篇让我自己筛，也不要漏掉重要的。所以初期我把阈值设得比较低，等报告稳定运行两周后，再根据实际阅读情况逐步收紧。

5.3 嵌入模型太慢怎么优化

all-MiniLM-L6-v2在 CPU 上编码一篇论文大概 20 毫秒，几百篇就是十几秒，可以接受。但如果你的论文量上千，就会明显变慢。优化手段有三个：一是只对标题编码，不对摘要编码，速度能快一倍，但准确率会降一点；二是用更小的模型，比如paraphrase-MiniLM-L3-v2；三是把编码结果缓存起来，种子论文的向量只算一次，不用每次重算。

5.4 报告格式乱掉怎么排查

Markdown 渲染乱掉，九成是论文标题或摘要里有特殊字符没转义。比如标题里带|会破坏表格，带#会被当成标题，带*会被当成强调。解决办法是在渲染前对文本做转义，把|、#、*、_这些字符替换掉或者加反斜杠。我是在parse_entry阶段就做清洗，把换行、多余空格、特殊字符统一处理掉，后面渲染就省心了。

5.5 常见问题速查表

5.6 几个我踩过的坑

第一个坑是把 API key 写进了代码。早期图省事，直接把邮箱密码写在脚本里，后来把代码传到 Git 仓库，差点泄露。现在所有敏感信息都走环境变量，代码里只留占位符。

第二个坑是没有做去重。有段时间报告里同一篇论文出现两次，因为作者在当天提交了 v1 和 v2。后来加了基于 base_id 的去重，问题解决。

第三个坑是报告太长。一开始我把所有命中的论文都详细展开，结果报告有几十页，根本看不完。后来改成三档展示，精读详细、扫读一句话、跳过只列标题，阅读负担一下就降下来了。

第四个坑是过度依赖大模型。有段时间我让大模型给每篇论文写推荐理由，结果它经常编造论文里没有的内容，比如虚构数据集名称。后来改成模板填充加规则抽取，只在精读论文上让大模型润色，并且要求它只能基于给定信息改写，不能新增事实。

6. 报告之外：这套流水线还能怎么扩展

6.1 从日报到周报和月报

日报适合追踪最新动态，但有些趋势需要拉长时间看。我在日报的基础上加了周报和月报。周报把一周的精读推荐汇总，按主题聚类，看这一周哪个方向最活跃。月报做趋势分析，统计各关键词的出现频率变化，看哪个方向在升温、哪个在降温。实现上很简单，把每天的 JSON 结果存下来，周末和月末跑一次聚合脚本就行。

6.2 接入个人笔记系统

报告里的精读推荐，我希望能一键存进我的笔记软件。做法是在报告里给每篇论文加一个本地链接，点击后触发一个脚本，把论文元数据、我的打分、以及一个空的笔记模板写进笔记库。这样我读论文的时候，笔记框架已经搭好了，只需要填内容。这个功能用 Obsidian 或者 Logseq 的 URI 协议都能实现，不难。

6.3 反向订阅：让报告学习我的反馈

现在的打分是单向的，我调参、它执行。更理想的状态是它能从我的阅读行为里学习。比如我在报告里标记某篇论文为“已读且有用”，这个反馈可以存下来，用来调整种子论文的权重，或者微调嵌入模型。这一步我还没做，因为需要积累足够的反馈数据，但思路是清晰的：把每次阅读行为当成一次标注，让系统逐步逼近我的真实兴趣。

6.4 多方向并行

如果你同时关注好几个不相关的方向，比如既做 NLP 又做系统，可以给每个方向建一套独立的兴趣画像和打分参数，报告里分开展示。这样互不干扰，每个方向都能得到精准的推荐。实现上就是把配置抽成多个 profile，抓取和分析时按 profile 分别跑，最后合并成一份报告。

6.5 一个实用的小技巧

最后分享一个我在实际使用中觉得最省事的技巧：把报告的第一屏做成“三行摘要”。也就是在报告最开头，用三行字说清楚今天最值得看的一篇是什么、为什么、以及大概要花多久读。这三行是我早上最先看的内容，如果时间紧，看完这三行就可以关掉了。剩下的详细内容，等有空再翻。这个设计看起来简单，但极大提升了报告的实用性，因为它把“决策成本”降到了最低。

这套流水线我跑了快一年，中间迭代了十几版，从最初的手忙脚乱到现在每天早上十分钟搞定论文追踪，效率提升是实打实的。如果你也在被 arXiv 的信息量困扰，建议从最简单的抓取加关键词过滤开始，先跑起来，再逐步加语义打分和摘要生成。不要一上来就追求完美，能用的粗糙版本比不能用的完美版本有价值得多。