基于DeepSeek的arXiv论文自动筛选：从抓取到邮箱推送的完整实践

每天早上一睁眼，arXiv 上都会多出两三百篇新论文。如果你只盯着某个细分方向，可能只有两三篇值得读，但为了这两三篇，你得翻几十个搜索页、点开一堆标题，最后大概率还是漏掉了更重要的。我花了几个晚上搭了一个基于 DeepSeek 的自动筛选系统，把“人肉刷 arXiv”变成“让模型帮我刷”，顺手还推送到邮箱。今天把这套方案从思路到代码完整拆一遍，给同样被论文淹没的科研党一个可以照抄的作业。

这个系统不挑方向，只要你在 prompt 里写清楚自己的研究兴趣，它每天早上都会自动把当天 arXiv 上相关度高的论文挑出来，附上评分和一句推荐理由，发到你的邮箱。如果你刚接触编程，照着代码改一改也能跑起来；如果你已经写过不少脚本，后面关于提示词工程和阈值调优的经验应该能帮你把筛选质量再拉高一个档次。

1. 整体设计与思路拆解

1.1 为什么选择DeepSeek做论文筛选

传统关键字筛选用正则表达式匹配标题和摘要，遇到同义词基本就废。比如你研究“多模态推理”，论文标题可能写“vision-language co-reasoning”，纯字符匹配根本抓不到。用 DeepSeek 这类大语言模型来做，本质上是把它当成一个“读过大量论文的助教”，给它看标题和摘要，让它判断这篇和你研究方向有没有关系，还顺带给出理由和标签。这种语义层面的筛选，比关键词规则灵活得多。

我把关键词过滤和 DeepSeek 筛选做过一次对比，结果很直观：

所以最后我采取的策略是两者结合：先用关键词把候选集缩小，再用 DeepSeek 做精排。这样省掉大量无效的模型调用，同时保留语义理解的优势。

DeepSeek 的 API 对中文支持很好。我的研究方向描述是用中文写的，模型也能准确理解，返回的推荐理由可以用中文解释，读起来非常顺。同样一篇英文摘要，它能用“这篇提出了一个跨模态的对比学习框架，和你的多模态推理方向高度相关”来总结，这不就是私人助教么。

1.2 系统架构模块划分

我把它分成四个模块：抓取、预筛、评分、通知。每个模块尽量独立，方便单独调。

抓取模块通过 arXiv 的 API 拉取当天更新的论文，拿到标题、摘要、作者、链接、分类号。这里用到的是官方提供的数据，不需要爬网页，稳定很多。拉下来的论文先存在内存里，不落库也行，因为每天处理完就完事了；如果要长期积累，可以接一个 SQLite。

预筛模块做两件事：一是排除明显不相关的分类，比如你只做 NLP，那定量生物学方向的论文就不看了；二是做关键词粗筛，把包含指定词组的论文捞出来。如果粗筛后数量还是太多，比如遇到某个方向当天井喷，可以把关键词匹配做成“必须命中标题”或“摘要中至少出现两次”。

评分模块把预筛后的论文逐条发给 DeepSeek，让它输出一个 0 到 100 的相关度评分，结构化成 JSON。这个模块是核心，后面我会专门讲提示词怎么写。

通知模块把得分超过阈值的论文，整理成 Markdown 格式的邮件正文，发送到你自己的邮箱。不想用邮件的话，也可以改成调用即时通讯工具的 webhook。

1.3 技术选型与关键取舍

整体实现我用 Python，因为第三方库最全。arXiv 的 API 用 urllib 就能调，没必要上 requests；模型调用用 OpenAI 兼容的 SDK，DeepSeek 提供同样的接口格式，设置 base_url 和 api_key 就行。定时任务直接写进脚本里，用系统的 cron 或计划任务触发，不依赖后台框架。

有一个让我纠结很久的点：要不要把所有论文都过一遍模型？从效果看，全量模型处理肯定召回最高，但成本也高。如果当天论文有 500 篇，每篇摘要平均 1500 token，一天就要处理 75 万 token，长期下来不是小数目。所以最终选了“规则预筛 + 模型精排”的漏斗结构。实测下来，预筛能过滤掉 70% 的不相关论文，剩下 30% 再让模型打分，成本和效果取得了不错的平衡。

这里还有一个容易被忽略的细节：模型评分有随机性。同一篇论文跑两次，分数可能会波动 10 分左右。所以在设计时不能让模型直接决定“要不要”，而是让它输出连续分数，再配合下面的规则阈值来过滤。这样即使模型偶尔抽风，只要不是极端情况，结果基本稳定。

2. 核心细节解析与实操要点

2.1 从arXiv抓取论文元数据

arXiv 官方 API 的入口是export.arxiv.org/api/query。它支持按时间、分类、关键词查询，返回 Atom XML 格式。最常用的参数是search_query，比如cat:cs.CL筛选自然语言处理，all:transformer搜索标题和摘要。还有一个关键参数sortBy=submittedDate，能保证拿到的是当天新增论文。

实际请求时要注意，官方 API 有频率限制，如果抓太频繁会被拒绝访问。我的经验是每次请求之间至少间隔 3 秒，并且设置一个明确的 User-Agent 标明用途。另外，arXiv 的摘要里可能包含换行和特殊字符，解析后要清洗一下，否则喂给模型时容易让 prompt 结构错乱。

用 XML 解析时，要先处理命名空间。下面这段代码能提取出最基本的信息：

import urllib.request import xml.etree.ElementTree as ET ARXIV_API = "http://export.arxiv.org/api/query" NS = {"atom": "http://www.w3.org/2005/Atom", "arxiv": "http://arxiv.org/schemas/atom"} def fetch_papers(query: str, max_results: int = 50): url = f"{ARXIV_API}?search_query={query}&sortBy=submittedDate&sortOrder=descending&max_results={max_results}" req = urllib.request.Request(url, headers={"User-Agent": "PaperFilter/0.1"}) with urllib.request.urlopen(req) as resp: xml_text = resp.read().decode("utf-8") root = ET.fromstring(xml_text) papers = [] for entry in root.findall("atom:entry", NS): papers.append({ "title": entry.find("atom:title", NS).text.strip().replace("\n", " "), "abstract": entry.find("atom:summary", NS).text.strip(), "link": entry.find("atom:id", NS).text.strip(), "category": [c.attrib["term"] for c in entry.findall("atom:category", NS)], }) return papers

注意sortBy=submittedDate不一定百分之百只返回当天的，可能混着前一天没入库的，所以在后续脚本里要用解析出的发布日期再过滤一次。日期可以从<arxiv:published>标签里取，解析成 UTC 再比较：

from datetime import datetime, timezone published = entry.find("arxiv:published", NS).text.strip() pub_date = datetime.fromisoformat(published.replace("Z", "+00:00")) if pub_date.date() == datetime.now(timezone.utc).date(): # 只保留今天的论文 pass

另外，arXiv 的 API 接口是http，如果服务器环境要求更严格，可以走https，不过在大多数场景下都能直接访问。拉取结果后建议把标题和摘要里的多余空白压缩掉，正则替换连续空格为单个空格，这样模型请求时能省一点 token。

2.2 提示词工程：让DeepSeek明白“相关性”

论文筛选的核心不是代码，而是 prompt。我调试了很多版本，最后稳定下来的是一个带角色设定、评分标准和 few-shot 示例的模板。

先说角色设定：告诉模型“你是某课题组的研究助手”，比直接说“请你判断是否相关”效果更稳定。因为角色会给模型一个行为框架。然后是研究方向描述，这个描述不能太短，比如“自然语言处理”这种太笼统，模型会给你很多泛泛的分数。要把关键词、方法、目标都写进去，比如“多模态大模型中的视觉-语言对齐机制，尤其关注跨模态注意力”。

评分标准要明确：如果论文提出新方法或新数据集，且方法可复现，给 80 分以上；如果只是应用既有方法到新场景，给 50 到 70 分；如果完全不沾边，给 20 分以下。把评分维度和具体尺度写在 prompt 里，能显著降低模型乱打分的概率。

few-shot 示例特别重要。我会在 prompt 里给两个示例：一个高度相关但标题里没有关键词的论文，模型应该给高分；另一个看起来沾边但实际方向偏移的论文，模型应该给低分。这样模型就理解了“相关性不是单纯看字面词”。最后要求模型返回严格 JSON，字段包括 score、reason、tags。

下面是一个我实际在用的完整 prompt 模板：

def build_prompt(paper: dict) -> str: research_field = "多模态大语言模型中的视觉-语言对齐机制，尤其关注跨模态注意力、指令微调中的对齐策略、以及图文推理链" return f""" 你是某课题组的研究助手。你要根据下面的研究方向，判断一篇论文是否值得课题组成员精读。 研究方向：{research_field} 评分标准： - 90-100：提出了新方法、新模型或新数据集，且直接解决该方向的关键问题 - 70-89：将现有方法深度应用到该方向，有明确的参考价值 - 40-69：仅仅部分相关，例如使用了某个相似名词，但没有实质关联 - 0-39：基本不相关，只是 keywords 有巧合 输出要求： 只允许输出一个 JSON 对象，不要输出其他任何文字。 格式如下： {{"score": 0, "reason": "不超过30字的中文理由", "tags": ["标签"]}} tags 只能从 ["new_method", "new_dataset", "survey", "application"] 中选择，没有匹配的就给空列表。 示例1： 论文标题：Aligning Vision-Language Representations with Learnable Cross-Modal Tokens 论文摘要：本文提出一种可学习的跨模态 token 对齐方法，增强了视觉编码器与语言模型的交互。 正确输出：{{"score": 95, "reason": "直接提出新的对齐方法，针对性极强", "tags": ["new_method"]}} 示例2： 论文标题：ImageNet Classification with Visual Features 论文摘要：仅使用视觉特征进行图像分类，没有涉及任何语言模型或跨模态交互。 正确输出：{{"score": 12, "reason": "纯图像分类，方向完全不符", "tags": []}} 现在开始： 论文标题：{paper["title"]} 论文摘要：{paper["abstract"][:2000]} """

这个模板有几个细节是刻意设计的。首先，输出要求里明确“只允许输出一个 JSON 对象”，并且给了示例格式，模型基本不会跑偏。其次，标签候选只有 4 个，限制范围比放开让模型自由发挥要稳定得多。最后，摘要限制 2000 字符，因为论文摘要的后半段往往是实验设置和结论，对“相关性”判断的边际贡献不大，反而会拖慢响应速度。

这里有个坑：要求返回 “strict JSON” 还不够，模型偶尔会在前面加解释文字，或者用中文标点。所以在解析时不能只json.loads，要先做一层正则清理，提取{...}部分。后面常见问题里会细说。

2.3 评分规则与阈值设定

DeepSeek 输出的 0-100 分数是“软性”的，直接拿它和阈值比较之前，我建议先做一个“关键词加权”的二次校正。具体做法是，在 prompt 外自己再算一个关键词命中分：标题命中一个关键词 +10，摘要命中 +5，命中多个关键词累加。然后最终分数 = 0.8 * 模型分 + 0.2 * 关键词加权分。之所以保留关键词加权，是为了防止模型对某些过长摘要产生“注意力漂移”，把核心点漏掉。

阈值设定可以先无脑取 60 分，然后跑一周记录每天命中数量。如果每天都很多，说明阈值低了；如果三天打鱼两天晒网，说明阈值高了。我的经验是，宁可每周多筛出两篇读，也别漏掉真正重要的那篇。所以阈值不要定太高，65 分是个不错的起点。

另外，可以给论文打标签，比如“survey”“new_dataset”“SOTA”。这个标签不是筛选必需，但如果推送邮件里带了标签，你扫一眼就能决定要不要点开。DeepSeek 在这方面表现不错，给它列几个候选标签，它会照做。不过，模型对 “SOTA” 这类需要严谨验证的标签有时会误判，所以最后推送前我自己加了一道小检查：如果摘要里出现 “state-of-the-art”“ outperforms ” 这些字样，才允许打上 “SOTA” 标签。

3. 实操过程与核心环节实现

3.1 环境准备与依赖安装

需要 Python 3.9 以上，装两个库就够：requests用于调用模型接口，标准库里的urllib、xml、smtplib就能解决其他问题。我在虚拟环境里安装，避免污染全局：

python -m venv venv source venv/bin/activate pip install requests

DeepSeek 的 API 是 OpenAI 兼容的，所以也可以用openai这个库，把base_url指向 DeepSeek 的接口。但我试下来，直接用requests反而少一层依赖，出错更可控。下面是调用函数：

import requests import json API_KEY = "your_deepseek_api_key" BASE_URL = "https://api.deepseek.com/v1/chat/completions" MODEL_NAME = "deepseek-chat" def chat_json(prompt: str, temperature: float = 0.3): headers = { "Authorization": f"Bearer {API_KEY}", "Content-Type": "application/json", } payload = { "model": MODEL_NAME, "messages": [{"role": "user", "content": prompt}], "temperature": temperature, } resp = requests.post(BASE_URL, headers=headers, json=payload) data = resp.json() return data["choices"][0]["message"]["content"]

注意这里我故意把temperature设成 0.3。论文筛选的任务需要一定的一致性，温度太高会随机打乱评分；设得太低又可能让模型拒绝输出。0.3 到 0.4 是性价比比较高的区间。

API Key 一定要通过环境变量或者配置文件读取，不要写死在代码里。我见过太多人把 key 发到公开博客，然后被拿去刷爆。用os.getenv("DEEPSEEK_API_KEY")取，既安全又方便换。

3.2 核心代码：采集、评分、推送

整体流程函数写成一个pipeline()，每天跑一次。采集部分用前面的fetch_papers；预筛部分简单判断目标关键词；评分部分组装 prompt 后调用chat_json；推送部分用smtplib发送邮件。

下面是一个可运行的骨架，我删掉了日志和异常处理的细节，只保留主线：

import os import re import json import smtplib from datetime import datetime, timezone from email.mime.text import MIMEText RESEARCH_FIELD = "多模态大语言模型中的视觉-语言对齐机制" KEYWORDS = ["vision-language", "multimodal", "cross-modal", "alignment"] THRESHOLD = 65 def pre_filter(papers): result = [] for p in papers: text = (p["title"] + " " + p["abstract"]).lower() if any(k.lower() in text for k in KEYWORDS): result.append(p) return result def parse_model_output(content: str) -> dict: # 提取第一个 { 到最后一个 } 之间的内容 start = content.find("{") end = content.rfind("}") if start == -1 or end == -1: raise ValueError("no json found") data = json.loads(content[start:end+1]) data["score"] = int(data["score"]) return data def score_paper(paper: dict) -> dict: prompt = build_prompt(paper) # 复用 2.2 节的模板 content = chat_json(prompt) parsed = parse_model_output(content) # 关键词加权 text = (paper["title"] + " " + paper["abstract"]).lower() kw_score = 0 for k in KEYWORDS: if k.lower() in paper["title"].lower(): kw_score += 10 elif k.lower() in text: kw_score += 5 final_score = int(0.8 * parsed["score"] + 0.2 * kw_score) parsed["final_score"] = final_score return parsed def send_mail(papers_with_meta: list): lines = ["# 今日论文推荐\n"] for item in papers_with_meta: lines.append(f"## {item['title']}") lines.append(f"相关度：{item['final_score']} 分") lines.append(f"理由：{item['reason']}") lines.append(f"链接：{item['link']}") if item.get("tags"): lines.append(f"标签：{', '.join(item['tags'])}") lines.append("") body = "\n".join(lines) msg = MIMEText(body, "markdown", "utf-8") msg["Subject"] = f"每日论文筛选 {datetime.now().strftime('%Y-%m-%d')}" msg["From"] = os.getenv("MAIL_FROM") msg["To"] = os.getenv("MAIL_TO") with smtplib.SMTP_SSL(os.getenv("SMTP_HOST"), int(os.getenv("SMTP_PORT"))) as server: server.login(os.getenv("SMTP_USER"), os.getenv("SMTP_PASS")) server.send_message(msg)

运行主流程时，我通常会把不合格的论文也存到一个 debug 文件里，方便回头检查是不是漏掉了好论文。这里有个细节：parse_model_output里的int(data["score"])必须加，因为模型偶尔返回字符串类型，你不强转，后续>= THRESHOLD时就会 TypeError。

3.3 定时运行与结果分析

脚本写好后，最省事的方式是配置 cron。比如每天早上八点跑一次：

0 8 * * * cd /path/to/project && /path/to/venv/bin/python pipeline.py >> run.log 2>&1

记住要用虚拟环境的解释器，不能用直接python，否则可能用到错误版本。跑一周之后，我建议做一个简单的结果分析：把每天推送论文的标题存下来，手动抽查 20 篇，看哪些被漏掉、哪些是误报。漏掉多的就降低阈值或增加关键词；误报多就反过来调整 prompt 或提高阈值。

这一步才是整个系统最有价值的部分。因为模型判断永远有瑕疵，人工闭环调整才是提升精度的关键。我自己的系统跑了两周之后，误报率从刚开始的 40% 降到了 15% 左右。

我每周会做一个表格记录效果：

当你连续记录半个月，就能看出阈值和关键词设置是否合理了。如果某天预筛论文数异常高，很可能是某篇热门论文霸占了多个分类，去重逻辑没生效。如果连续两天推送数为 0，先别急着降阈值，大概率是 arXiv API 没抓到新数据，而不是真的没有好论文。

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

4.1 请求被限流或超时

arXiv 的 API 不会给明确的 429，但会出现连接超时或者返回一段比较少见的 XML。解决办法是添加重试和退避逻辑。我写了一个简单的retry装饰器，三次重试，每次等待时间递增。另外把max_results拆小，比如一次拉 20 篇，分批次拉，避免一次拉几百篇被服务器拒绝。

还有一次我遇到urlopen error [Errno 110] Connection timed out，排查后发现是网络代理环境太复杂。后来在服务器上直接清空代理变量，才恢复正常。如果你也用了代理，记得在脚本里显式清除HTTP_PROXY和HTTPS_PROXY，不然很隐蔽。

DeepSeek API 偶尔也会返回 503 或者 429，这类状态码意味着服务端过载。我的处理逻辑是：遇到 5xx 就退避重试，遇到 429 就等待更长的时间再试一次。不要在重试逻辑里直接 sleep 60，那样会把整个 pipeline 卡住，最好给每次重试抛出一个异常，让主流程跳过这篇论文，最后把失败列表打印出来。

4.2 模型输出不稳定与JSON解析失败

这是最常遇到的问题。DeepSeek 返回的内容偶尔会在 JSON 前后加一句废话，比如“好的，为你生成结果：”，导致json.loads直接抛异常。我的处理方法是先找第一个{和最后一个}，截取中间部分再解析；如果还是失败，就重新调用一次。因为温度不高，重试后输出基本会正常。

还有一个很隐蔽的问题：模型给出的 score 可能是字符串"75"而不是数字 75。所以解析后要用int()强制转换，否则后面比较时会报错。

解析代码可以封装成一个小函数，并且支持容错：

def safe_parse_json(content: str): try: return json.loads(content) except json.JSONDecodeError: start = content.find("{") end = content.rfind("}") if start == -1 or end == -1: return None try: return json.loads(content[start:end+1]) except json.JSONDecodeError: return None

如果safe_parse_json返回 None，我会把这篇文章标记为“待处理”，不去重试也是可以的。因为提示词里的示例已经把输出格式规定得很严，偶尔一次失败不影响整体效果。但你一定要在日志里保留原文，方便事后分析是不是某些特殊论文触发了模型异常。

4.3 筛选结果漂移与阈值调优

有时候同一个研究方向，上周跑得很好，这周突然推了一堆不太相关的论文。原因可能是 arXiv 这周的新论文里恰好有大批擦边球，或者模型在长上下文中的注意力被稀释。我的经验是，把研究方向描述拆分得更细，加上“不需要泛泛的综述性工作”这样的负面约束。同时，阈值不要固定死，可以根据近三天推送数量做动态调整，比如平均超过 10 篇就上调 5 分，少于 3 篇就下调 5 分。

还有一种情况：研究方向本身在演进。比如你从“多模态对齐”细化到“细粒度视觉定位”，那么方向描述里要同步加一句“当前最后关注细粒度区域定位与语言引导的交互”。我经常忘了更新 prompt，导致系统还在推旧方向的内容，那时候就会觉得“这系统怎么越跑越偏”。其实不是系统变笨了，而是你的研究方向变了。

4.4 成本控制与性能优化

如果预筛后每天还有 200 篇论文，意味着要调用 200 次模型 API，每次等待 1-3 秒，整体跑下来要 10 分钟以上。性能瓶颈主要在串行等待。解决办法是用线程池并发调用，把并发数控制在 5 左右，能提速 3-4 倍且不容易触发限流。另外，可以把论文抽象出前 2000 字符，因为后面基本都是 related work，对判断相关性帮助不大。

使用 ThreadPoolExecutor 的时候，要保证每个线程都有独立的 prompt，没有共享状态：

from concurrent.futures import ThreadPoolExecutor, as_completed def batch_score(papers: list, max_workers: int = 5): results = [] with ThreadPoolExecutor(max_workers=max_workers) as executor: future_map = {executor.submit(score_paper, p): p for p in papers} for future in as_completed(future_map): paper = future_map[future] try: parsed = future.result() parsed["link"] = paper["link"] parsed["title"] = paper["title"] results.append(parsed) except Exception as e: print(f"failed: {paper['title']} -> {e}") return results

成本方面，可以用一个简单的统计函数，定期记录每天调用 token 数。一个月下来你心里就有底了。我的实际体验是，预筛加并发之后，每天大概消耗 30 万 token，不是一个大数字，但如果不做预筛，会多出三四倍。

4.5 安全与隐私提醒

这个系统本身不涉及敏感数据，但有几点容易忽视。第一，API Key 和邮箱密码必须用环境变量管理，不要把配置文件丢到公开仓库。第二，论文摘要属于公开数据，但如果你后续要对推送结果做二次处理，比如训练自己的模型，要留意 arXiv 的使用条款。第三，定时任务跑出来的日志可能包含论文标题和个人邮箱，不要在公开空间随意粘贴完整日志。

还有一点：如果你把系统交给别人维护，一定不要把研究方向描述和个人偏好写得过于私人化。这个文件可能会流传出去，尽量保持学术化的表达。

5. 扩展玩法：让系统更像你的私人学术助理

5.1 接入即时通知

邮件虽然稳定，但不是所有人都习惯每天看邮箱。可以把推送结果转成 markdown 发到即时通讯工具，或者生成一个简单的 HTML 页面放到本地。我目前用邮件，因为设置简单、不受设备限制。如果你想要更及时的通知，可以用即时通讯工具的 webhook，调用方式也就是一次 POST 请求，比邮件还容易。

下面是一个极其简单的 webhook 发送函数：

import requests def send_webhook(webhook_url: str, text: str): resp = requests.post(webhook_url, json={"text": text}, timeout=10) resp.raise_for_status()

这个方法唯一的隐患是 webhook 地址泄露后容易被别人盗刷，所以不要把 webhook 地址放在公开仓库里。如果平台支持关键字过滤，也可以先做一层脱敏再发送。

5.2 增量更新与去重

arXiv 上同一篇论文可能在多个分类里出现，抓取时会造成重复。我的做法是用论文 ID 的前几位（去掉版本号）作为去重键，在内存里维护一个集合。这样既不会重复推送，也能追踪论文是否有更新版本。

seen = set() def is_duplicate(paper: dict) -> bool: # 例如 arxiv.org/abs/2401.00123v2 -> 2401.00123 paper_id = paper["link"].split("/")[-1].split("v")[0] if paper_id in seen: return True seen.add(paper_id) return False

这个去重逻辑对“同 ID 不同版本”也有效。我之前没做去重时，一天收到过两封完全重复的邮件，排查了半天才发现是不同分类入口抓到了同一篇论文。

5.3 多主题并行筛选

如果你的研究方向有两个，不想每天看两份邮件，可以让一个脚本同时跑多个 prompt，把不同主题的结果合并到同一封邮件里。这里要注意各主题的分数不能直接比较，因为 prompt 的评分标准可能不一样，所以邮件里要明确标注主题名。

实现上不用把文件拆成多份，只要把RESEARCH_FIELD、KEYWORDS和THRESHOLD做成参数，循环调用即可。我遇到过一个小问题：两个主题的关键词有交叉，导致同一条论文被两个主题都推了一次。解决办法是在同一个去重集合里增加“主题名 + 论文ID”的复合键，或者按主题的优先级去重。

这些扩展都不复杂，核心还是抓取、评分、通知这个链路。系统真正跑起来以后，你就会发现它省下来的不只是刷论文的时间，还有你注意力切换的隐性成本。每天花 3 分钟扫一眼邮件，比在 arXiv 上漫无目的地刷一小时要高效得多。

我个人在实际操作中最深的一点体会是：这类自动筛选系统，效果好坏 80% 取决于那一段研究方向描述怎么写，代码反而是最不费脑的地方。你不需要把方向写得多学术，要把你自己看论文时的直觉描述出来，比如“我关心方法不是任务”“我更在意可复现性”，模型才能真正理解你的偏好。另外，不要追求一个永远不变的参数，论文领域的热点在变，你的研究兴趣也会微调，每两三个星期回头看看筛选结果，顺手改几句 prompt、动一下阈值，系统才能一直好用。

最后再分享一个小技巧：如果你打算长期用这套系统，记得把每天推送的论文链接和评分存成一个历史文件。哪天想找一篇之前读过但忘了收藏的论文，一份包含摘要和评分的本地索引，比 arXiv 站内搜索好用太多。这就是“论文筛选”之外意外收获的额外价值。