1. 项目概述：OpenResearch 到底是什么

OpenResearch 这个名字听起来很大，但说白了，它解决的是一个非常具体又让人头疼的问题：研究过程本身的不透明和不协作。

我在参与这个项目的过程中，最直观的感受是——过去做一份调研或者跑一个技术验证，从收集资料、整理数据、对比方案到最终输出结论，几乎全凭个人经验和本地文件堆砌。资料散落在浏览器收藏夹、本地 Word、微信聊天记录和 Excel 表格里，换个设备就断档，换个协作者就得重新讲一遍背景。OpenResearch 想做的，就是把整个研究链路搬到一套统一、开放、可追溯的协作体系里，让每个中间过程都被记录下来，每个结论都能找到依据，每个参与者都能在同一个上下文里工作。

这个项目适合谁？三类人最需要：一是做技术选型和竞品调研的研发团队，二是写行业报告、做数据分析的研究型岗位，三是高校里需要长期跟踪某个课题的学生和老师。甚至哪怕你只是一个人在做个人知识库的整理，OpenResearch 的这套思路也完全能降维使用。

从形态上看，OpenResearch 既不是一个简单的文档工具，也不是一个重型的项目管理软件。它更像是一套「研究操作系统」：底层用标准化的数据格式管理文献和资料，中间层用自动化的脚本处理采集、清洗和归档，上层用可协作的文档和看板承接人的思考和输出。换句话说，它把「输入—处理—输出」三个环节全部打通，并且每个环节都留下可复核的记录。

这篇文章我会从整体设计思路、核心模块拆解、实操搭建过程和常见问题几个方面完整复盘，内容偏向实际落地，不讲虚的，都是我验证过、踩过坑之后的东西。

2. 整体设计思路与选型拆解

2.1 核心痛点：研究过程为什么难管理

先聊一个基础问题：为什么常规工具管不好研究项目？

因为研究工作和普通执行类工作有本质区别。普通任务有明确的输入和输出，比如「把这份文档翻译成英文」「修复某个 bug」，过程是线性的，结果可验证。但研究工作充满了不确定性：你可能今天收集了 20 份资料，其中 15 份没用；你可能花了两天跑实验，最后发现方向错了需要推翻重来。这种非线性、高噪音、高返工率的过程，用传统的任务管理工具来管，只会得到一堆「已完成」「进行中」的空洞标签，过程中的思考链完全丢失。

另一个痛点是知识割裂。研究必然涉及大量外部信息——论文、技术文档、竞品页面、行业数据、论坛讨论。这些信息分散在不同平台，格式各异，甚至语言不同。如果只靠人工复制粘贴，不仅效率低，而且会丢失原始来源和上下文。一旦过了几个月想回看某个结论的依据，你往往想不起来当初是从哪里找到的。

OpenResearch 的设计出发点，就是围绕这两个痛点展开的：一是把过程记录下来，二是把外部信息结构化。

2.2 方案选型：为什么是「轻量自建」而非「买现成」

做这个项目之前，我们认真评估过市面上的现成方案。

第一类是学术工具，比如 Zotero、EndNote，它们管理文献确实强，但对「研究过程」的覆盖很窄，更不擅长团队协作和自定义工作流。第二类是通用协作工具，比如 Notion、Confluence，它们灵活，但所有内容都堆在页面里，缺少对文献、数据、结论之间关系的建模，研究深了会发现结构不够用。第三类是专业的洞察平台，这类产品功能全，但价格高、封闭，且很难根据自己团队的习惯做二次开发。

最终我们决定用「轻量自建 + 标准工具链」的路线：核心流程自己设计，底层基础设施用开源项目组合。这么做的好处有三个：第一，灵活性高，任何环节不满意都可以自己改；第二，数据完全在自己的控制范围内，不担心平台迁移或关闭；第三，成本低，整个系统跑在普通服务器上，技术栈也都是成熟稳定的开源方案。

这背后的逻辑其实很简单：研究管理这件事,每个团队的具体做法差异太大，标准产品很难完美覆盖你的工作习惯。与其削足适履去适应别人的流程，不如自己定义一套顺手的工作流。

2.3 技术架构与核心工作流

OpenResearch 的架构可以拆成四个层次：

• 数据采集层：负责从各类来源（网页、PDF、API、数据库）抓取原始信息，统一转为标准格式。
• 数据存储层：用文件系统加数据库双重存储，原始文件保留原貌，结构化元数据入库供检索。
• 研究协作层：基于 Markdown 的文档体系，配合看板管理研究进度，支持多人评论、审阅、合并。
• 发布输出层：自动生成报告、数据可视化页面，支持导出为多种格式。

整个工作流的核心闭环是：收集 → 整理 → 分析 → 沉淀 → 输出。这个闭环中的每一步都在系统里留有痕迹，任何一环都可以回溯原始材料。

选型上，我们使用了以下几个关键组件：

这套组合谈不上炫酷，但每一样都能打，组合在一起几乎没有短板。

2.4 优势与避坑点

相比市面上的解决方案，OpenResearch 最大的优势是「全过程留痕」和「自定义工作流」。你看过一份资料、做了哪些批注、形成过什么结论、后来为什么又修正了——所有这些都在系统内有迹可循。这不是为了监控谁，而是为了研究质量的自我纠偏。很多时候，你回头看自己一个月前的判断，会发现当时的依据和思路有明显漏洞，能复盘出这些漏洞，就是研究能力的提升。

但这条路也有坑。最大的坑是「过度工程化」。我们早期花了很多时间折腾自动化采集，试图让系统自动完成所有资料整理，后来发现研究工作里人的判断永远无法被自动化替代。自动化适合做「脏活累活」——抓取、转码、归档、查重，但「哪些资料值得精读」「不同来源的信息如何交叉验证」这种判断，必须由人来做。把自动化定位成助理而非主力，这个心态摆正了，项目才不会跑偏。

3. 核心模块解析与实操要点

3.1 文献与资料的标准化采集

OpenResearch 的第一个核心模块，是文献和资料的标准化采集。这里说的「文献」是广义的，不只是学术论文，还包括行业报告、竞品页面、技术文档、对话记录、甚至一段视频的文字稿。

标准化采集要解决的关键问题是：不同来源的信息，如何变成统一的、可检索、可追溯的结构化数据。

我们设计了统一的元数据结构，包含以下字段：

• 唯一标识符（UUID）
• 标题
• 来源类型（网页 / PDF / 论文 / 数据库 / 对话等）
• 来源 URL 或 DOI
• 作者 / 机构
• 发布时间
• 访问时间
• 摘要或关键内容摘录
• 标签（多标签，支持层级）
• 关联条目（可以关联到其他文献、数据集、任务）

实际采集过程中，我建议不要完全依赖自动抓取的元数据，一定要加一层人工校验。自动抓取的标题经常残缺，作者名经常有拼写差异，发布时间也可能是爬虫抓错的。我们实践的流程是：自动化工具先把候选资料抓进来，打上「待审核」标记，每天固定时间由研究者批量审核一遍，确认或修正元数据后再进入正式库。这一道人工工序看起来费时，但能省掉后面所有环节的「脏数据」麻烦。

采集工具的选型，我们用的是 Zotero 加自研的同步脚本。Zotero 对网页快照、PDF 解析、DOI 元数据抓取的支持非常成熟，它的本地 SQLite 数据库也容易通过脚本访问。我们在 Zotero 里建了不同的分类文件夹对应不同的研究主题，然后用 Python 脚本定期把新增条目同步到统一的 PostgreSQL 数据库里，再补上自研的标签体系和关联关系。

3.2 数据清洗与去重

采集进来的原始数据，质量一定是参差不齐的。这部分的工作量和难度，说实话比很多人预想的大得多。

常见的脏数据问题有这么几类：

• 同一篇内容被不同渠道抓了多次，标题略有差异，导致重复。
• URL 是短链接或带追踪参数，无法直接判断真实来源。
• 元数据残缺，没有作者或时间，需要去源站补全。
• 抓取到的内容包含大量页眉页脚、导航噪音，需要清理正文。
• PDF 里的文字提取经常出现乱码、断行，尤其是双栏排版的老论文。

针对这些问题，我们在系统里做了一套清洗流程。先去重：对标题做归一化处理（统一大小写、去特殊字符、去掉尾部标点），用 SimHash 算法计算标题近似度，相似度超过阈值的就自动放入「疑似重复」队列，由人工确认是否合并。再清理正文：针对网页抓取，自定义了读取规则，自动剔除常见导航区和页脚的 DOM 元素；针对 PDF，先尝试直接提取文本，失败的再走 OCR 方案。

这里有一个实操心得：不要追求 100% 的去重和清洗自动化。有些内容是否重复，需要结合上下文判断。比如同一研究团队在不同时间发布的报告，标题可能相近但实质内容不同，如果被机器误判为重复就麻烦了。我们最后定的策略是「机器初筛、人工确认」：机器把疑似重复的挑出来，人看一眼最多十秒就能确认，准确率比纯自动化高得多。

3.3 研究过程记录与协作规范

OpenResearch 的另一个核心设计是「研究过程记录」。这个思路借鉴了科研领域的「开放实验笔记」理念：把研究过程中的每个步骤、每个判断、每次思路转变都记录下来，而不是只记录最终结论。

为什么这么做？因为研究结论本质上是一个「观点」，观点如果不附上推导过程和原始依据，就无法被验证和挑战。而验证和挑战，正是研究质量提升的源泉。我们团队内部有个硬性要求：每个阶段性结论必须挂接至少一个证据条目。证据可以是文献、数据表、实验结果或者一段采访记录。挂不上的结论，要么是猜想，要么是还不够成熟，需要明确标注状态。

在协作层面，我们用的是 Git 来管理所有 Markdown 研究文档。简洁地说，每篇研究文档就是一个「活文件」，研究员可以随时更新、追加、修正内容，所有历史版本都在 Git 提交记录里。协作者看到某段内容有疑问，可以直接在对应的 commit 上提评论，形成精确到行的讨论线。

这个方案还有个附带的好处：自动生成「研究日志」非常容易。每次 commit 的 message 就是当天的研究进展摘要，配合日期标签，就能生成一份按时间排列的进展日志。用来做周报、月报的素材，省事且真实。

3.4 数据可视化与报告输出

研究最终要给别人看，所以输出环节不能弱。

我们用 MkDocs 搭建了一个内部研究知识库站点，所有 Markdown 文档自动构建成静态网页，支持全文搜索、标签筛选和版本切换。数据分析和图表则用 Jupyter Notebook 完成，关键结论直接截图嵌入文档，数据表导出为 CSV 存放在统一的数据目录里，供其他模块调用。

报告输出方面，我们支持一键导出为 PDF、Word 和在线页面三种格式。得益于 Markdown 的通用性，这几种格式的转换工具链非常成熟，几乎不用额外维护。

输出环节的一个细节经验是：图表标题和图片说明一定要写清楚数据来源和时间范围。我见过太多研究报告，图表画得漂亮，但忘了标注数据口径，导致结论被质疑甚至推翻。在 OpenResearch 中，我们把「每个图表自带数据来源标注」设为了输出模板的强制字段，从流程上杜绝这个问题。

4. 实操过程：从零搭建一套 OpenResearch

4.1 环境准备与服务部署

下面进入实操部分。我会以一个干净的环境为例，演示如何完整搭起一套 OpenResearch。这个环境我假设是 Ubuntu 22.04 服务器，4 核 8G 内存，100G 磁盘，实际最低配置可以降到 2 核 4G，但如果要跑数据处理任务，内存还是建议至少 8G。

首先安装基础依赖：

# 更新系统并安装基础工具 sudo apt update && sudo apt upgrade -y sudo apt install -y git curl wget htop unzip build-essential python3 python3-pip python3-venv sqlite3 docker.io docker-compose # 启动 Docker 并设为开机自启 sudo systemctl enable docker --now # 将当前用户加入 docker 组，避免每条命令都加 sudo sudo usermod -aG docker $USER

这里特别提一句：Docker 在这套系统里不是必须的，但如果你要部署 Kanboard、PostgreSQL 这类带依赖的服务，用容器能省掉很多环境冲突的麻烦。我在实践中吃过不少本地安装的亏，后来统一改用 Docker Compose 编排所有服务，清爽很多。

注销重新登录后，创建项目目录结构：

mkdir -p ~/openresearch/{data,scripts,docs,backups} mkdir -p ~/openresearch/docs/{research,reports,meetings} mkdir -p ~/openresearch/data/{raw,processed,output} mkdir -p ~/openresearch/scripts/{crawler,sync,clean}

这个目录结构对应前文说的四个层次：data 对应存储层，scripts 对应采集和清洗层，docs 对应协作层，backups 用于放定时备份。

4.2 数据库初始化与数据模型设计

OpenResearch 的元数据存储用 PostgreSQL。原因很简单：关系型数据库对结构化元数据的查询效率远高于文件型方案，而且 PostgreSQL 的 JSONB 字段能灵活容纳各种来源类型的附加属性。

用 Docker Compose 启动数据库：

version: "3.9" services: db: image: postgres:15 container_name: openresearch-db restart: always environment: POSTGRES_USER: research POSTGRES_PASSWORD: research_pass_2024 POSTGRES_DB: openresearch volumes: - ./data/postgres:/var/lib/postgresql/data ports: - "5432:5432" kanboard: image: kanboard/kanboard:latest container_name: openresearch-kanboard restart: always ports: - "8081:80" environment: DATABASE_DRIVER: postgres DATABASE_HOST: db DATABASE_NAME: openresearch DATABASE_USERNAME: research DATABASE_PASSWORD: research_pass_2024

然后初始化核心数据表。这个 SQL 是精简过的项目版本，重点是 metadata 表的设计：

CREATE TABLE sources ( id UUID PRIMARY KEY DEFAULT gen_random_uuid(), title TEXT NOT NULL, source_type VARCHAR(30) NOT NULL, url TEXT, doi TEXT, authors TEXT[], institution TEXT, published_date DATE, accessed_date DATE DEFAULT CURRENT_DATE, abstract TEXT, tags TEXT[], raw_file_path TEXT, status VARCHAR(20) DEFAULT 'pending', created_at TIMESTAMP DEFAULT NOW(), updated_at TIMESTAMP DEFAULT NOW() ); CREATE TABLE research_notes ( id UUID PRIMARY KEY DEFAULT gen_random_uuid(), title TEXT NOT NULL, content_md TEXT NOT NULL, source_ids UUID[], tags TEXT[], status VARCHAR(20) DEFAULT 'draft', created_at TIMESTAMP DEFAULT NOW(), updated_at TIMESTAMP DEFAULT NOW() ); CREATE INDEX idx_sources_title ON sources (title); CREATE INDEX idx_sources_tags ON sources USING GIN (tags); CREATE INDEX idx_sources_status ON sources (status);

注意source_ids字段用了UUID[]数组类型，这在我们这个场景下比单独建关联表更好用，从一篇研究笔记可以直接看到它引用了哪些原始资料，查询时一条 SQL 就能搞定。

4.3 文献导入与元数据标准化脚本

数据库准备好之后，写自动化和半自动化的文献导入脚本。这里展示一个简化版，核心思路是读入本地 PDF 文件名、自动查询 DOI 元数据、写入数据库：

import os import re import psycopg2 import requests from pathlib import Path PDF_DIR = Path.home() / "openresearch/data/raw/pdfs" DB_DSN = "postgresql://research:research_pass_2024@localhost:5432/openresearch" def normalize_title(filename): """清理文件名，去掉 pdf 后缀、下划线等，得到粗略标题""" stem = filename.replace(".pdf", "") stem = re.sub(r"[_\-]+", " ", stem).strip() return stem def fetch_crossref(title): """使用 Crossref API 查询元数据""" url = "https://api.crossref.org/works" params = {"query.title": title, "rows": 3} resp = requests.get(url, params=params, timeout=10) if resp.status_code != 200: return None for item in resp.json().get("message", {}).get("items", []): return { "title": item.get("title", [title])[0], "doi": item.get("DOI", ""), "authors": [f"{a.get('given', '')} {a.get('family', '')}".strip() for a in item.get("author", [])], "published_date": item.get("issued", {}).get("date-parts", [[None]])[0][0], } return None def import_pdfs(): conn = psycopg2.connect(DB_DSN) cur = conn.cursor() for file in PDF_DIR.glob("*.pdf"): title_rough = normalize_title(file.name) meta = fetch_crossref(title_rough) if meta is None: print(f"[SKIP] 无法获取元数据: {file.name}") continue cur.execute(""" INSERT INTO sources (title, source_type, url, doi, authors, published_date, abstract, raw_file_path, status) VALUES (%s, 'pdf', '', %s, %s, %s, '', %s, 'verified') ON CONFLICT DO NOTHING """, (meta["title"], meta["doi"], meta["authors"], meta["published_date"], str(file))) print(f"[OK] {meta['title']}") conn.commit() cur.close() conn.close() if __name__ == "__main__": import_pdfs()

这段代码覆盖了前文说的「自动化初筛，人工确认」中的自动化部分：脚本自动抓取元数据并写入库，状态直接标记为verified。为什么这里可以直接标记？因为 Crossref API 返回的数据本身来自 DOI 注册机构，可信度较高，如果查询失败则保持跳过，不会被误标。

4.4 数据清洗与去重脚本

去重脚本是日常用得最频繁的工具。我们采用标题归一化加 SimHash 近似匹配的方案：

from simhash import Simhash import psycopg2 from difflib import SequenceMatcher DB_DSN = "postgresql://research:research_pass_2024@localhost:5432/openresearch" def normalize_for_dedup(text): """归一化处理：去特殊字符、统一大小写、去尾部标点""" text = re.sub(r"[^\w\s\u4e00-\u9fff]", "", text.lower()) text = re.sub(r"\s+", " ", text).strip() return text.strip(".") def find_duplicates(threshold=0.88): conn = psycopg2.connect(DB_DSN) cur = conn.cursor() cur.execute("SELECT id, title FROM sources WHERE status != 'duplicate' ORDER BY created_at") rows = cur.fetchall() groups = {} for i in range(len(rows)): for j in range(i + 1, len(rows)): t1 = normalize_for_dedup(rows[i][1]) t2 = normalize_for_dedup(rows[j][1]) if not t1 or not t2: continue ratio = SequenceMatcher(None, t1, t2).ratio() if ratio >= threshold: sim = Simhash(t1).distance(Simhash(t2)) if sim < 4: groups.setdefault(rows[i][0], []).append(rows[j][0]) print(f"[可能重复] {rows[i][1]} | {rows[j][1]} 相似度 {ratio:.2f}") conn.close() return groups if __name__ == "__main__": dup_groups = find_duplicates()

这里用difflib的相似度和 SimHash 双重校验，是为了平衡准确率和召回率。单独用 SimHash 容易误判短标题，单独用序列相似度在长标题上又会因为噪音产生误差，两个条件叠加之后，误报率大幅下降。

实际使用中，脚本产出的疑似重复清单会推送到一个待审核队列，由人工确认后批量合并或标记为伪重复。这个流程虽然多了一步人工，但避免了很多「机器觉得重复但其实内容有差异」的误杀。

4.5 协作空间配置与权限管理

研究团队协作这块，我们是用 Git 加自建的 Kanboard 看板来组织。Git 管理内容，看板管理进度。

初始化 Git 仓库：

cd ~/openresearch/docs git init git add . git commit -m "初始化研究文档仓库" # 创建远程裸仓库，方便多人协作 mkdir -p ~/git-repos/openresearch-docs.git cd ~/git-repos/openresearch-docs.git git init --bare # 在本地设置远程并推送 cd ~/openresearch/docs git remote add origin ~/git-repos/openresearch-docs.git git push -u origin master

权限管理上，Git 本身不提供细粒度权限控制，所以我们在服务器上用 SSH 访问控制来限制仓库访问。具体做法是给每位协作者创建单独的系统账号，然后用~/.ssh/authorized_keys限制他们只能访问指定的 Git 仓库。

看板用来跟踪研究任务的六种状态：待调研、资料收集中、分析中、初稿完成、评审中、已发布。每个看板卡片关联到对应文档的 Git 分支名，从看板可以一键跳转到文档内容。

这里有一个很关键的实操要点：不要试图让看板替代文档。看板只记录状态和责任人，研究内容永远以 Git 仓库里的 Markdown 文档为准。状态会变，但内容有历史沉淀，两者职责分离才不会乱。

4.6 自动化发布链路

最后是自动化输出。我们配置了一个每日定时任务，自动从数据库拉取最新数据、更新图表、重新构建 MkDocs 站点。

发布脚本的核心逻辑：

#!/bin/bash # ~/openresearch/scripts/publish.sh set -e cd ~/openresearch/docs # 1. 从数据库导出最新元数据为 JSON 文件 python3 ~/openresearch/scripts/sync/export_metadata.py # 2. 重新生成数据图表 python3 ~/openresearch/scripts/sync/update_charts.py # 3. 构建 MkDocs 静态站点 mkdocs build --clean # 4. 同步到 Web 目录 rsync -av --delete site/ ~/openresearch/web-root/ # 5. 提交文档仓库的变化 git add -A git commit -m "自动发布: $(date +'%Y-%m-%d %H:%M')" || true git push origin master

配合 crontab 设定每日凌晨两点执行：

crontab -e # 添加以下内容 0 2 * * * /home/user/openresearch/scripts/publish.sh >> /home/user/openresearch/logs/publish.log 2>&1

这套链路搭好之后，研究团队每天早上到公司打开内部站点，看到的就是前一天同步更新过的最新版本。谁前一天加了什么资料、哪份分析文档更新了，一目了然，完全不需要有人专门去通知大家。

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

5.1 元数据抓取失败或残缺怎么办

这是最常遇到的问题。Crossref 搜不到、Zotero 抓取的信息缺作者、网页标题乱码……多种多样。

我的处理经验分三步：第一步，确认来源类型是不是特殊类型——如果是 Preprint、专利、政府报告这类特殊文献，通用元数据 API 很容易失手，可以手动录入或走专业数据库的导入插件。第二步，检查 URL 是否完整，短链接和带追踪参数的地址经常导致抓取失败，想办法拿到原始地址再试一次。第三步，实在不行的，转为「弱元数据」条目，只保留标题和访问日期，标注状态为incomplete，在后续人工整理时手动补全。

切忌让缺元数据的条目阻塞整个流程，研究工作不能因为一份资料信息不全就停下来。弱元数据条目先进库，后续随时可以补，这才是合理的节奏。

5.2 多人协作时 Git 冲突频繁

多人同时编辑同一篇 Markdown 文档，冲突几乎是必然的。尤其研究报告这种多人共同修订的场景，几乎每周都有几次冲突。

Git 冲突的常规解决方式对于 Markdown 文档来说，其实还算友好，因为 Markdown 是纯文本，冲突往往局限在小范围，手动合并几行就行。但更推荐的做法是从工作流上减少冲突：

• 一份文档指定唯一主编辑人，其他协作者通过评论而非直接修改来提意见。
• 按章节拆分文件，不同人负责不同章节，冲突概率大幅下降。
• 约定编辑前先git pull，编辑完立即git push，避免长时间占用文件。

我们团队内部还有个约定：大改动尽量在独立分支上做，稳定之后合并回主分支。这虽然听起来麻烦一点，但配合 Pull Request 的评审流程，研究质量会明显提升。一份报告没人审查就发出去，出错的概率实在太高了。

5.3 自动同步任务失败

定时任务最让人头疼的问题是「悄悄失败」。脚本跑挂了，但 crontab 不会发通知，你可能半个月后才发现数据一直没更新。

我们做了一套简单的自愈机制：

• 所有脚本统一输出结构化日志，格式为时间 | 级别 | 脚本名 | 消息。
• 写一个 watchdog 脚本，每个小时检查一次最近任务的执行时间和退出码，超过预期时间还没有成功记录就发通知。
• 通知渠道用企业微信机器人或者钉钉机器人，几十行代码就能接入。

import requests import sqlite3 import datetime # 检查数据库中最近一次同步时间 conn = sqlite3.connect("~/openresearch/data/status.db") last_sync = conn.execute("SELECT MAX(timestamp) FROM sync_log WHERE status='success'").fetchone()[0] conn.close() delta = datetime.datetime.now() - datetime.datetime.fromisoformat(last_sync) if delta.total_seconds() > 12 * 3600: # 超过12小时未成功同步 requests.post( "https://your-webhook-url", json={"msgtype": "text", "text": {"content": "[OpenResearch] 数据同步超过12小时未成功，请检查任务日志"}} )

这套方案成本极低，但能避免「静默故障」这种最阴险的问题。研究系统里的数据时效性很重要，你引用的数据如果是一个月前的，结论可能已经完全失效了。

5.4 检索性能与存储膨胀

随着资料不断积累，数据库体积和检索速度会逐渐成为问题。我们实测下来，几万条元数据时 PostgreSQL 的性能完全无压力，但如果存了大量全文快照，数据量会迅速膨胀。

应对策略是分级存储：元数据在 PostgreSQL，值得长期保存的原始文件放对象存储或本地磁盘，临时抓取的原始 HTML 快照保留 30 天后自动清理。全文搜索引擎方面，如果数据量到了十万级以上，可以引入 OpenSearch 或 Typesense，但在那之前 PostgreSQL 的全文索引完全够用，不要过早引入复杂组件。

存储的优化要点是：数据清理一定要自动化。我们早期因为手动清理总是忘，导致磁盘频繁报警。后来写了一个每月自动执行的清理脚本，一切数据按保留策略执行，再没为磁盘空间烦过。

6. 后续扩展与生态整合

OpenResearch 这套系统跑顺之后，可以往多个方向扩展。这里分享几个我觉得有价值的方向。

第一个方向是接入更多数据源。目前主要靠手动补充和 Crossref API，如果研究的领域有专门的数据库或行业 API，可以开发对应的适配器。比如做金融研究就接入行情数据接口，做专利分析就接专利数据库，每次接入新的数据源，系统的研究覆盖面就扩大一圈。

第二个方向是增强数据分析和可视化能力。目前图表主要靠 Jupyter Notebook 静态生成，如果团队有数据科学需求，可以进一步集成 Superset 这类开源 BI 工具，让非技术成员也能自助式探索数据。我们团队后来就把 Superset 接入进来，研究报告里需要的数据洞察直接由业务人员拖拽生成图表，研发不再成为瓶颈。

第三个方向是和 AI 能力结合。这个方向非常火，但我想提醒的是：注意边界。AI 适合做摘要、初筛、翻译这类任务，比如自动给每篇文献生成一段摘要草稿，能节省大量阅读时间。但研究的核心结论、判断、优先级决策，依然要靠人。把 AI 定位为「研究助理」而非「研究员」，这个原则不能变。

第四个方向是外部知识共享。如果研究的成果希望开放给外部社区，可以基于已有的 MkDocs 站点再套一层公开访问的域名和访问控制，形成「内部使用 + 外部发布」的双层结构。这也是「OpenResearch」这个名字最初的含义——研究成果向更多人开放，研究的可信度也因透明而提升。

最后分享几点个人体会

做 OpenResearch 这个项目的过程，让我对「研究」这件事本身有了很多反思。

第一个体会是：研究工具的价值不在于存储，而在于可追溯。一个结论如果找不到它是怎么来的，它的可信度就存疑。工具应该帮助研究者建立完整、可验证的推理链，而不是仅仅充当一个容量更大的硬盘。

第二个体会是：研究流程的事后整理没有意义，必须实时记录。你不可能在一份调研结束后靠回忆补齐过程笔记，细节会在不知不觉中流失。只有把过程记录嵌入日常工作流，让它成为肌肉记忆，才能留下真正完整的研究轨迹。这也是 OpenResearch 把「过程记录」设计为强制功能的原因。

第三个体会是：不要为了用工具而用工具。如果只是一个人做短期调研，一套文件夹加一个表格也许就够了。OpenResearch 适合的是长期、持续、多人参与的研究场景。工具应该为研究服务，而不是研究被工具绑架。

最后再分享一个细节技巧：每次研究项目结束时，花十分钟写一个「复盘摘要」，记录这次研究最大的收获、最大的失误和最值得复用的一招。这个摘要存放在研究仓库的根目录，每次开启新项目前先翻一下过去的复盘摘要，会让你少走很多弯路。这个习惯的成本极低，收益却远超你的想象。

OpenResearch 的搭建不是目的，搭建之后如何让研究变得更高效、更可靠，才是这个项目真正的意义所在。