1. 从"信息坟场"到"第二大脑"：Research Wiki 到底要解决什么
做研究的人大概都有过这种体验：硬盘里躺着几百篇 PDF，浏览器书签栏塞满了"稍后阅读"，笔记软件里散落着各种半截的摘录和灵感，但真正要写东西、做汇报、回答一个具体问题时，却发现自己根本找不到那条关键信息。更糟的是，即便找到了，也记不清当初为什么把它标成重点，上下文全丢了。
这就是典型的"信息坟场"——收集了很多，消化为零。Research Wiki 这个项目，本质上就是冲着这个问题去的。它不是又一个笔记软件，而是一套以 Markdown 为底层格式、以 LLM 为加工引擎、以 Obsidian 为交互界面、以 Agent 为自动化抓手的研究知识库构建方法论。关键词里的 Research Wiki、LLM、Obsidian、Agent、Markdown 这五个词，恰好构成了它的完整技术栈：Markdown 负责存储的通用性和可迁移性，Obsidian 负责本地化的双向链接和可视化，LLM 负责把非结构化文本变成结构化知识，Agent 负责把重复劳动自动化，而 Research Wiki 就是这四者协同之后的产物。
这套东西适合谁？我认为有三类人收益最大。第一类是长期做文献综述的研究生和科研人员，需要把几十上百篇论文的核心论点、方法、结论沉淀成可检索、可对比的知识网络。第二类是做行业研究和竞品分析的产品、投资、咨询从业者，信息源杂、更新快，需要一套能快速消化并形成判断的系统。第三类是正在搭建个人知识库的技术人，对 Obsidian、LLM、Agent 这些工具有基础认知，但一直没跑通"从收集到产出"的完整链路。
需要提前说清楚的是，Research Wiki 不是一个开箱即用的软件产品，而是一套可以自己搭、可以自己改的工作流。它的门槛不在于技术难度，而在于你是否愿意花时间把"随手记"的习惯升级成"结构化沉淀"的习惯。下面我会把这套工作流拆成几个可以独立落地的模块，每个模块都讲清楚为什么这么设计、具体怎么操作、以及我在实操中踩过的坑。
2. 为什么底层格式必须锁定 Markdown
2.1 纯文本的长期主义：十年后还能打开的文件
很多人搭知识库第一步就选错了工具，直接上手某个云端笔记软件，结果用了两年发现导出格式一团糟，迁移成本高到想放弃。Research Wiki 的第一条铁律就是：所有核心内容必须以纯 Markdown 文件形式存在本地。
这个选择的理由很实在。Markdown 本质是纯文本，纯文本的寿命几乎等于人类文明的寿命——只要还有文本编辑器，它就能被打开。相比之下，专有格式的笔记软件一旦停止维护、服务器关停、或者你付不起订阅费，你的知识资产就可能变成一堆无法解析的二进制。我见过太多人把几年的研究笔记锁在某个 App 里，最后因为各种原因拿不出来。
从技术角度看，Markdown 的另一个优势是对 LLM 极其友好。大语言模型处理纯文本的效率远高于处理富文本或二进制格式，Markdown 的标题层级、列表、代码块这些结构标记，恰好能帮助模型理解文档的语义层次。当你把一篇 Markdown 笔记喂给 LLM 做摘要或问答时，模型能准确识别出哪些是标题、哪些是正文、哪些是引用，这在处理富文本时反而需要额外的解析步骤。
2.2 Markdown 语法里那些容易被忽略的细节
既然底层是 Markdown，就得把语法用对。这里挑几个在研究笔记场景下特别容易出问题的点。
换行问题是新手第一大坑。Markdown 里单个回车不会产生换行，必须行尾加两个空格，或者中间空一行。很多人从 Word 复制内容过来，发现段落全挤在一起，就是因为这个。我的建议是统一用"空一行"的方式分段，可读性最好，也不容易因为编辑器自动去除行尾空格而失效。
表格转换是研究场景的高频需求。整理文献对比时，Markdown 表格写起来清爽，但要转成 Excel 给同事看就麻烦了。实测下来，最稳的路径是先用 Markdown 表格整理，再通过 Pandoc 这类工具转成 docx 或 xlsx。命令很简单：
pandoc input.md -o output.xlsx不过要注意，Markdown 表格的列对齐语法（|:---|:---:|）在转换时会被 Pandoc 正确识别，但如果表格里有换行或复杂格式，转换结果可能会错位。我的经验是，表格单元格里尽量只放短文本，长内容用脚注或单独段落处理。
Mermaid 图表的支持也值得说一句。Obsidian 原生支持 Mermaid 语法渲染流程图、时序图，这对画研究框架、技术路线特别有用。但要注意，Mermaid 代码块在导出为 PDF 或分享给不支持的环境时会失效，所以关键图表建议同时保留一份图片版本。
2.3 文件命名与目录结构：让检索成本降到最低
Markdown 文件多了之后，命名和目录结构直接决定你找东西的效率。我试过几种方案，最后稳定下来的做法是：文件名用"日期-主题-类型"三段式，比如2024-03-15-Transformer架构-论文笔记.md。日期放最前面，天然按时间排序；主题用中文，方便肉眼扫；类型标注是笔记、摘录还是原创，一眼能区分。
目录结构上，我建议按"输入-加工-输出"三层来分：
research-wiki/ ├── 00-inbox/ # 临时收集，未整理 ├── 10-sources/ # 原始文献、网页剪藏 ├── 20-notes/ # 加工后的结构化笔记 ├── 30-topics/ # 按主题聚合的索引页 └── 40-output/ # 草稿、成稿、汇报材料这个结构的核心逻辑是让文件在生命周期里流动。一条信息从 inbox 进来，经过加工变成 notes，再被 topics 索引，最后在 output 里被消费。每个阶段的文件状态清晰，不会出现"这篇笔记到底整理没整理"的困惑。
3. Obsidian 作为研究前端的配置要点
3.1 双向链接不是花架子：构建知识网络的实操
Obsidian 最核心的能力是双向链接。很多人装了 Obsidian 却只当普通编辑器用，那就浪费了它最大的价值。双向链接的本质是让笔记之间产生语义关联，当你写"这个方法参考了 [[Transformer架构]] 的思路"时，Obsidian 会自动在 Transformer 那篇笔记里生成一条反向链接，告诉你"有哪些笔记引用了它"。
在研究场景下，这个机制的价值在于发现意外关联。你写了几十篇论文笔记，某天打开一篇关于注意力机制的笔记，发现反向链接里有一篇你半年前记的关于推荐系统的笔记也引用了它——这种跨领域的连接，往往就是新想法的来源。
实操上，我建议养成两个习惯。第一，每篇笔记开头写一段"一句话摘要"，用>引用块标注，这样在关系图谱和搜索预览里能快速判断这篇笔记讲什么。第二，主动创建"主题索引页"，比如建一个[[注意力机制]]的页面，里面用列表把所有相关笔记链接起来，并标注每篇的核心贡献。这个索引页会随着笔记增多自动变成该主题的知识地图。
3.2 插件选型：少即是多，只装真正提效的
Obsidian 插件生态极其丰富，但我的建议是克制。插件装多了会拖慢启动速度，还会互相冲突。研究场景下，我认为必装的插件不超过五个：
| 插件名称 | 解决什么问题 | 使用频率 |
|---|---|---|
| Dataview | 用类 SQL 语法查询笔记元数据，自动生成列表和表格 | 极高 |
| Templater | 模板自动化，新建笔记时自动填充结构 | 高 |
| Git | 版本控制，防止误删和追溯修改历史 | 高 |
| Advanced Tables | 表格编辑辅助，自动对齐和格式化 | 中 |
| Excalidraw | 手绘风格图表，画研究框架和思路图 | 中 |
Dataview 特别值得展开说。它让你可以用类似这样的查询，自动列出所有标记为"待读"的论文笔记：
TABLE status, rating, date FROM "10-sources" WHERE status = "待读" SORT date DESC这意味着你不需要手动维护阅读清单，只要在笔记的 frontmatter 里写好status: 待读，Dataview 就会自动聚合。这种"元数据驱动"的思路，是让知识库从静态文档变成动态系统的关键。
3.3 主题与阅读体验：长时间工作的舒适度
研究是长时间伏案工作，Obsidian 的默认主题看久了眼睛累。我试过不少主题，最后长期用的是 Minimal 和 Things 这两个。Minimal 的特点是极简、留白多、字体渲染清晰，适合长时间阅读；Things 则更接近任务管理软件的视觉风格，适合把笔记和待办混在一起管理的场景。
字体方面，中文笔记建议把正文字体设成"思源宋体"或"霞鹜文楷"，这两款开源字体在屏幕上的可读性都很好。行高调到 1.8 左右，段间距适当加大，能显著降低阅读疲劳。这些设置看起来是小事，但每天面对屏幕几小时，舒适度直接决定你愿不愿意持续用下去。
4. LLM 在知识库里的三个真实角色
4.1 角色一：从原始文献到结构化笔记的"翻译器"
LLM 在 Research Wiki 里最直接的价值，是把非结构化的原始材料加工成结构化笔记。一篇论文 PDF 动辄十几页，你不可能每次都从头读到尾。我的做法是：先把 PDF 转成 Markdown（用 Pandoc 或专门的转换工具），然后让 LLM 按固定模板提取信息。
这个模板我迭代了好几版，现在稳定用的是这个结构：
## 核心问题 （这篇论文试图解决什么问题） ## 方法概述 （用了什么方法，关键创新点是什么） ## 主要结论 （得到了什么结果，数据支撑是什么） ## 局限性 （作者自己承认的、或你判断的不足） ## 与我研究的关联 （这篇对你的工作有什么启发或可借鉴之处）让 LLM 按这个模板填充，输出的笔记质量比你自己随手记的要高得多，因为模板强制你思考"关联性"这一栏，而这恰恰是普通摘录最容易缺失的部分。
这里有个关键技巧：给 LLM 的提示词里要明确要求它标注不确定的地方。比如加上一句"如果原文没有明确说明，请标注'原文未提及'，不要自行推测"。这能有效减少模型幻觉，避免它编造论文里根本没有的结论。
4.2 角色二：跨笔记的语义检索与问答
当你的知识库积累到几百篇笔记后，传统的全文搜索就不够用了。你搜"注意力"，可能出来几十条结果，但真正相关的那几条淹没在噪音里。这时候 LLM 的语义检索能力就派上用场了。
实现路径有两条。轻量方案是用 Obsidian 的 Smart Connections 插件，它在本地对笔记做向量化，然后根据语义相似度推荐相关笔记。这个方案的好处是数据不出本地，隐私性好。重量方案是自建 RAG（检索增强生成）系统，把笔记向量化后存入向量数据库，查询时先检索再让 LLM 生成回答。
我实测下来，对于个人知识库这种规模（几百到几千篇笔记），轻量方案已经够用。Smart Connections 的"相关笔记"面板会实时显示当前笔记语义上最接近的其他笔记，经常能帮我发现一些自己都忘了写过的内容。
4.3 角色三：知识缺口检测与研究方向建议
这是 LLM 比较进阶的用法，也是我觉得最有想象力的部分。当你把某个主题下的所有笔记喂给 LLM，让它做一次"知识地图分析"，它能帮你识别出哪些问题你反复提到但从未深入、哪些概念你引用了但没有自己的笔记、哪些结论之间存在潜在矛盾。
具体操作是：用 Dataview 把某个主题下的所有笔记聚合到一个临时文件，然后给 LLM 这样的提示："以下是我关于 X 主题的全部笔记，请分析：1）我反复提及但缺乏深入论证的观点；2）笔记之间可能存在的矛盾或张力；3）基于现有笔记，值得进一步探索的三个方向。"
这个分析不能替代你自己的判断，但它能提供一个外部视角，帮你跳出思维惯性。我用这个方法发现过好几次自己研究中的盲区，效果比单纯自己复盘要好。
5. Agent 自动化：把重复劳动交给机器
5.1 什么该自动化，什么不该
Agent 是这两年最热的概念，但在知识库场景下，我的态度是谨慎乐观。不是所有环节都适合自动化，判断标准很简单：这个任务是否有明确的输入输出、是否重复、是否规则清晰。符合这三条的，交给 Agent；不符合的，老老实实手动做。
适合自动化的典型任务包括：网页文章剪藏后自动提取正文并转 Markdown、每天定时把 inbox 里的新文件按规则分类、批量给笔记补充 frontmatter 元数据、定期生成知识库统计报告。不适合自动化的包括：判断一篇论文的价值、决定笔记之间的关联、写原创性的分析——这些需要人的判断力，Agent 做不好反而添乱。
5.2 一个可落地的 Agent 工作流示例
我搭过一个比较实用的自动化流程，用来自动处理网页剪藏。流程是这样的：
- 用浏览器插件把网页保存为 Markdown 到
00-inbox/ - Agent 监听该目录，发现新文件后触发处理
- 调用 LLM 提取标题、作者、发布日期、核心摘要
- 自动重命名为规范格式，移动到
10-sources/ - 在对应的主题索引页里追加一条链接
这个流程用 Python 写大概一百多行，核心是文件监听加 LLM 调用。伪代码逻辑如下：
from watchdog.observers import Observer from watchdog.events import FileSystemEventHandler class InboxHandler(FileSystemEventHandler): def on_created(self, event): if event.src_path.endswith('.md'): content = read_file(event.src_path) metadata = llm_extract(content) # 调用 LLM 提取元数据 new_name = format_name(metadata) move_file(event.src_path, f"10-sources/{new_name}") update_topic_index(metadata)这里有个坑要提醒：Agent 处理失败时必须有兜底机制。LLM 调用可能超时、可能返回格式错误的结果，如果直接崩溃，文件可能丢失或损坏。我的做法是处理前先复制一份到备份目录，处理失败就保留原文件并记录日志，绝不覆盖原始数据。
5.3 Agent 的安全边界：别让它碰核心数据
Agent 自动化最大的风险是误操作。一个配置错误的脚本可能批量删除或覆盖你的笔记。所以我的原则是：Agent 只对 inbox 和 sources 目录有写权限，对 notes 和 output 目录只读。核心的加工笔记和产出材料，必须由人手动确认后才能修改。
另外，涉及 LLM API 调用的 Agent，要注意 token 消耗和成本控制。批量处理几百篇笔记时，如果不加限制，一次可能烧掉不少额度。我的做法是给 Agent 加一个每日处理上限，并且对长文档先做分块，避免单次请求过大。
6. 从笔记到产出：Research Wiki 的最终检验
6.1 写作时如何调用知识库
搭知识库的最终目的是产出，不管是论文、报告还是汇报材料。Research Wiki 在写作阶段的价值，是让素材调用变得极其高效。我的习惯是：写任何东西之前，先在 Obsidian 里建一个草稿文件，然后用 Dataview 把相关主题的笔记全部列出来，边写边从笔记里拖内容。
因为所有笔记都是 Markdown，复制粘贴到草稿里格式不会乱。更重要的是，每段引用的内容都能追溯到原始笔记，避免了"这句话哪来的"这种尴尬。写完后，我会用 LLM 做一次一致性检查，让它对比草稿和原始笔记，看有没有曲解或过度演绎的地方。
6.2 知识库的定期维护节奏
知识库不是搭完就一劳永逸的，它需要定期维护。我给自己定的节奏是：每周清理一次 inbox，每月做一次主题索引更新，每季度做一次全局复盘。每周清理是把 inbox 里的东西该归档归档、该删除删除；每月更新是检查各主题索引页有没有遗漏新笔记；每季度复盘是用 LLM 做一次知识地图分析，看看研究方向有没有偏。
这个节奏听起来简单，但坚持下来不容易。我的经验是把它变成固定日程，比如每周五下午留半小时专门做这件事，形成习惯后就不觉得是负担了。
6.3 我踩过的几个坑和对应的解法
最后分享几个实操中踩过的坑，都是真金白银换来的教训。
第一个坑是过度追求工具完美。刚开始我花了很多时间对比各种笔记软件、试各种插件，结果真正用来读文献和写笔记的时间反而少了。后来想明白了，工具够用就行，重要的是内容本身。现在我的原则是：遇到具体问题才去找工具，而不是为了用工具而找问题。
第二个坑是笔记颗粒度失控。有段时间我每读一段话就建一篇笔记，结果笔记数量爆炸，但每篇都只有一两句话，毫无价值。后来调整为以"一个完整的观点或方法"为最小单位，一篇笔记至少能独立说明白一件事，这样才有复用价值。
第三个坑是忽视备份。有次硬盘出问题，差点丢掉几个月的笔记。虽然 Obsidian Git 插件能自动提交到 Git 仓库，但我当时没配好，幸好有手动备份。现在我用了三重备份：本地 Git 仓库、移动硬盘、加密云盘，确保万无一失。
第四个坑是 LLM 输出不加验证直接用。早期我太信任模型，它提取的论文结论我直接放进笔记，后来发现有几处明显是模型自己编的。现在的做法是：LLM 的输出一律标记为"待验证"，人工核对后才转为正式笔记。这个习惯虽然多花点时间，但避免了知识库被污染。
这套 Research Wiki 的工作流我用了两年多，从最初的几十篇笔记到现在上千篇，最大的感受是：知识库的价值不在于收集了多少，而在于你真正消化和调用了多少。工具和自动化都是手段，核心还是持续地读、想、写。如果你也在搭自己的研究知识库，希望这些经验能帮你少走点弯路。
