作者 汤圆键盘坏了不能写论文

个人主页：https://modelscope.cn/profile/HongMingfeng

我把自己日常检索文献的过程，做成了一个固定的自动化流程，并把它开源了。

身边的人在找文献时常常遇到这样的情况：

关键词放宽一点，结果列表瞬间膨胀成几千条；收窄一点，又怕错过不同命名体系下真正核心的研究。搜了一下午，根本不知道自己到底是搜全了，还是只碰巧搜到了自己熟悉的几个词。

这就引出了一个普遍痛点：

| “文献检索遇到的问题往往不是搜不到，而是无法验证自己检索的准确性与全面性。”

为了解决这个问题，我开始尝试把人类模糊的检索意图，转化为可执行、可回看、可调整的动作。

最早的版本很朴素：把需求喂给 AI，让它写好检索式，再扔进 Web of Science。后来朋友把这套粗糙但有效的操作整理成了《汤圆检索法.pdf》，在圈子里流传。大家觉得好用，是因为它理清了从“意图”到“操作”的映射路径。

大多数检索都依赖关键词检索，简单便捷，可是成也关键词，败也关键词。比如找“开放式创新与数字平台治理”，如果直接用：

"open innovation" AND "digital platform"

立刻会遇到几个问题：

• 同义词替换：platform 可能被写成 ecosystem、infrastructure、marketplace。
• 层级差异：治理可能涉及制度、算法、边界资源、参与规则。
• 跨学科术语壁垒：regulation 的治理和 governance 的治理，语义并不完全相同。

关键词检索容易把复杂问题压缩成离散的词块，但学术界的命名系统并不统一。最终，我认为，一个好用的检索工具，第一步得是理解问题背后的概念结构。

从自然语言到可执行检索式

PaperSeek 的第一步，是让 AI 先扮演检索式构建器，拆解出用户问题中的核心概念，再根据不同数据库的接口规则生成对应的检索式。

例如用户输入：

我想找关于用户创新和数字平台治理关系的文献

系统不会直接把这句话丢给数据库，而是先拆解出类似这样的概念结构：

• user innovation
• open innovation
• digital platform
• platform governance
• innovation ecosystem

然后再把这些概念转成数据库能够执行的表达。

| 自然语言检索的核心，不是让数据库学人话，而是让模型把人话翻译成机器语言。

然而，一次生成的检索式很少完美。结果太少，说明太窄；结果太多，说明太宽；主题漂移，则意味着概念边界找错了。所以系统里必须有一个朴素的反馈环：

1. 先生成检索式。
2. 去数据源里试搜一轮。
3. 看返回数量和文献类型。
4. 再让模型根据反馈决定是放宽、收窄，还是换一组表达。

模型在这里不是一次性给答案的机器，而是一个会试错的检索助理，通过反复校准来逼近更合适的文献池。这样我们就不用期待文献检索可以直接一次命中，而是通过一次一次地校准确保它的检索质量。

不是所有检索结果都是你需要的文献

数据库返回的结果只是候选池，不是最终阅读清单。模型需要判断：在一堆看似相关的文献里，哪些最值得先读？

PaperSeek 会结合多种元数据进行评估：

• 标题是否匹配研究问题。
• 摘要和关键词是否支持研究目标。
• 概念边界是否一致。
• 年份是否符合研究语境。
• 被引量是否显示出领域影响力。
• 期刊或会议是否具有一定权威性。

高被引但不相关的论文不该排在前面，高度相关的新文章也不该因为引用数低而被埋没。因此，系统会让模型给每篇候选文献一个相关性判断，并生成简短的评分理由。这样用户看到的不只是一个排序结果，也能看到排序依据。

从关键词相似到知识结构相邻

单纯的关键词检索只能找到“表述相似”的内容，但学术知识是靠引用关系连接的。

有些关键节点论文，标题里可能没有踩中你的关键词，却被相关论文反复引用；有些理论源头，可能处在另一个学科传统里，但通过引用网络和你的问题高度相关。

因此，PaperSeek 接入了 OpenAlex 的引用扩展能力：

• 后向引用：这篇文章引用了谁？
• 前向引用：谁引用了这篇文章？

这一步让检索从“文本相似”跨越到“知识结构相邻”。

关键词检索找到的是表层相似，引用扩展找到的是知识关系。

过程必须可见

在打磨工具的过程中，我一直坚持不能把过程藏起来。

我非常反感 AI 憋半天只给一个最终答案。除了后台一直跑、前台看不见进度会让人很难受，更重要的是：文献检索需要严谨的审查。

用户需要知道：

• 当前正在查哪个数据源。
• 当前生成了什么检索式。
• 返回了多少条记录。
• 是否修正了检索逻辑。
• 是否进入引用扩展。
• 最终排序依据是什么。

所以 PaperSeek 会把检索过程可视化，每跑完一步就显示阶段性结果。

学术研究真正需要信任的，不只是最终答案，而是得到这个答案的路径。

结果要能交给下一个工具

文献检索不是终点，它只是阅读、综述、写作和研究设计的起点。

因此，导出的结果必须是结构化的 CSV 或 JSON 数据，而不是一段难以继续处理的聊天记录。

CSV 适合直接进入 Excel、Zotero、Notion 或其他表格工具，常见字段包括：

rank
title
authors
year
venue
doi
url
citation_count
relevance_score
relevance_reason

JSON 则更适合保留完整结构，包括检索历史、候选池、引用图和模型评分理由，方便继续交给其他 AI 工具处理。

一个工具是否真的能够进入研究流程，取决于它能不能把结果交给下一个工具。

为什么做成 Web UI

PaperSeek 最早只是一个手动流程：AI 写检索式，人再去数据库里搜。后来它变成了 CLI 脚本和可复用的自动化工作流。对技术用户来说，这样已经能用。但对很多文社科或非技术背景的研究者来说，命令行有天然门槛。

后来，它被做成一个 skill。这个 skill 现在还内置在仓库里，你可以去仓库中找到这个 skill 并安装在你的 Harness 工具里。

按理来说这个工具到这里就可以用了，毕竟Skill似乎成了这个时代大部分工作流的终极形态。但我不希望这个工具做成这样就结束。我们自己日常用 Skill 用的行云流水，用得早已忘记配置 Skill 并非易事。主流的 Harness 工具要么你有办法不封号，要么通过繁琐的步骤来配置国产模型。

可其实身边很多人都和我一样是文社科专业，大家做质性、跑回归，甚至翻史料做考证，学科传统和方法论都不需要他们去接触终端和命令行。对绝大多数非工科学生而言，Skill形态的工具使用和自己的日常工作是有壁的，终端和命令行对大家来说没有“感知可供性”。他们需要的是他们熟悉的、点一下就能用的交互界面，而不是花里胡哨的cli或者Skill。

|这就是为什么在Skill满天飞的时代，我们最后还是Vibe Coding了一个前端交互界 面。感知、易用、采纳。这就是 STS 学科一直强调的“可供性”（Affordance）。

现在怎么用

你只需要输入一句大白话，比如：

我想找关于用户创新和数字平台治理关系的文献

系统会自动帮你完成：

1. 概念抽取。
2. 检索式生成。
3. 试搜校准。
4. 候选文献拉取。
5. 相关性排序。
6. 引用扩展。
7. 结果导出。

工具接管的是机械的检索劳动，研究者仍然需要判断真正重要的问题：这些文献是否构成了一个问题域？它们之间的理论分歧是什么？自己真正要读的是哪一条线索？

在线试用与开源地址

• 魔搭创空间在线版：

https://modelscope.cn/studios/HongMingfeng/PaperSeek

在魔搭创空间中，登录魔搭账号即可在云端保存检索历史，并直接使用魔搭账号中的 LLM API Inference 免费额度用于文献检索。如果只想试用 PaperSeek，直接打开上面的创空间链接即可，不需要自己部署。

• 开源代码在GitHub：https://github.com/MingfengHong/paperseek%EF%BC%8C%E6%AC%A2%E8%BF%8E star 或提 issue ！

如何在魔搭创空间创建类似应用

把自己的工作流部署在魔搭其实很容易。按正常的流程写好做成 Docker 就好，或者直接使用 Streamlit 这种轻量化的方案。

如果你想把自己的研究工作流也发布成一个魔搭创空间，可以按下面的思路准备。

官方文档可以参考：

• 创建创空间：https://modelscope.cn/docs/studios/create
• 快速创建：https://modelscope.cn/docs/studios/quick-create
• Docker 部署：https://modelscope.cn/docs/studios/docker

1. 准备一个可以独立运行的项目

项目里通常需要包含：

• 应用入口文件，例如 app.py。
• 依赖文件，例如 requirements.txt 或 pyproject.toml。
• 前端或后端源码目录。
• README.md，说明项目用途和使用方式。
• 如果使用 Docker 部署，还需要 Dockerfile。

对于 Web 应用，服务需要监听：

0.0.0.0:7860

这是创空间 Web 服务默认采用的端口约定。

2. 创建创空间

进入魔搭后，可以在创空间入口中新建空间，填写：

• 空间名称
• 简介
• 可见性
• 运行环境
• SDK 或 Docker 类型

如果项目依赖比较复杂，或者需要完整控制 Python 版本、系统依赖和启动命令，建议选择 Docker 方式。

3. 用 Git 推送代码

创空间创建后，可以通过 Git 管理代码。一般流程是：

git clone https://www.modelscope.cn/studios/<你的用户名>/<你的创空间名>.git
cd <你的创空间名>

# 放入你的项目文件
git add .
git commit -m "Initial commit"
git push
推送完成后，创空间会基于仓库内容构建并启动应用。

4. 配置环境变量

如果应用需要 API Key、数据库地址或 OAuth 配置，不要写死在代码里，而应该放在创空间的环境变量或密钥配置中。

例如，像我这这个使用 Supabase 管理用户数据的文献检索应用可能需要：

SUPABASE_URL
SUPABASE_PUBLISHABLE_KEY
OPENALEX_API_KEYS

如果应用需要用户登录后调用第三方服务，最好通过登录用户自己的授权信息完成请求，而不是把个人 API Key 写进项目代码。

5. 编写面向用户的 README

创空间的 README 不只是给开发者看的，也是在告诉第一次打开应用的人：

• 这个工具解决什么问题。
• 用户应该输入什么。
• 运行结果是什么。
• 是否需要登录。
• 数据会不会被保存。
• 如何导出结果。

对研究工具来说，README 里最好也说明工作流边界：它可以帮助构建候选文献池和排序，但不能替代研究者对理论脉络、研究问题和文献质量的最终判断。

结语

PaperSeek 还不完美。

不同数据源字段不统一，摘要偶尔缺失，模型有时也会误判，引用扩展也可能带来噪音。但我仍然觉得值得把它分享出来。

原本散落在脑海、临时笔记、浏览器标签页和 Excel 表格里的检索经验，现在至少变成了一个可复查、可修改的具象化流程。

如果你也经常在文献海里迷路，希望这个开源工作流能帮你少绕一点路。

欢迎试用、反馈、提 issue，或者给一个 star。