1. 为什么我要自己搭一套 Research Wiki做研究的人大概都有过这种体验读过的论文、收藏的博客、随手记的实验日志散落在浏览器书签、微信收藏、本地文件夹和某个云笔记里等到要写综述或者复现一个实验时翻找资料的时间比真正干活的时间还长。我从三年前开始认真折腾个人知识管理试过纯文件夹、试过在线文档、也试过各种笔记软件最后稳定下来的方案是一套以Obsidian为底座、用Markdown做统一格式、再挂上LLM和Agent做辅助的 Research Wiki。这套东西解决的核心问题就一个让知识以纯文本的形式沉淀在本地同时借助大模型的能力做检索、归纳和关联而不是把资料锁死在某个平台的数据库里。它适合做科研的学生、需要长期跟踪某个领域动态的从业者以及任何想把碎片信息变成可复用资产的人。哪怕你之前没用过 Obsidian只要会建文件夹、会写纯文本就能跟着搭起来。我把它叫 Research Wiki是因为它本质上是一个面向研究场景的轻量级维基每个主题一个页面页面之间用双向链接串起来再配上一套约定好的目录结构和命名规范。下面我按自己实际搭建和迭代的过程把整套方案的思路、细节、踩过的坑都摊开讲。2. 整体架构设计与技术选型思路2.1 为什么是 Obsidian 而不是别的笔记软件选工具这件事我踩过的坑最多。早期用过在线协作文档好处是同步方便坏处是数据不在自己手里而且一旦文档数量上去检索和关联能力就捉襟见肘。后来也试过一些主打数据库的笔记工具结构化能力强但导出格式不透明迁移成本高。最后落到 Obsidian主要看中三点。第一它的底层就是一堆 Markdown 文件存在本地文件夹里我用任何编辑器都能打开哪怕哪天 Obsidian 不维护了我的数据照样能用。第二双向链接和关系图谱是原生能力不需要额外插件就能把页面串起来这对构建知识网络很关键。第三插件生态足够丰富需要什么功能基本都能找到对应的社区插件而且插件本身也是开源的可控。Markdown 作为统一格式这一点也值得单独说。纯文本的好处是可版本控制、可 diff、可批量处理。我后来把整个 Wiki 用 Git 管起来每次改动都有记录误删了能回滚这一点是富文本格式给不了的。2.2 LLM 和 Agent 在这套体系里扮演什么角色很多人一上来就想让大模型帮自己写笔记我的经验是方向反了。LLM 在 Research Wiki 里最该干的是三件事检索、归纳、关联。检索是指用自然语言去问“我三个月前记的那篇关于注意力机制的笔记在哪”而不是靠关键词精确匹配。归纳是指把一篇长论文或者一堆零散笔记压缩成结构化摘要。关联是指发现两个看似无关的页面之间可能存在的联系提示我去建立链接。Agent 则是把这些能力串起来执行。比如我定义一个“文献整理 Agent”它的工作流是读取指定文件夹里的 PDF 转出来的 Markdown、提取核心贡献和方法、按照我预设的模板生成笔记页面、自动打上标签并建立与已有页面的链接。整个过程我不需要逐步操作只需要最后审核。这里要强调一个原则LLM 负责生成候选内容人负责最终确认。我见过太多人把大模型生成的内容直接塞进知识库结果几个月后自己都分不清哪些是原文、哪些是模型编的。我的做法是所有 LLM 生成的内容都放在单独的区块里用明确的标记区分审核通过后才合并到正文。2.3 目录结构怎么设计才不混乱目录结构是 Research Wiki 的骨架设计不好后期会非常痛苦。我前后调整过三次现在稳定下来的结构是这样的Research-Wiki/ ├── 00-Inbox/ 临时收集未分类的碎片 ├── 10-Topics/ 按研究主题划分的主目录 │ ├── Topic-A/ │ │ ├── _index.md 该主题的索引页 │ │ ├── papers/ 论文笔记 │ │ ├── notes/ 自己的思考记录 │ │ └── data/ 相关数据集说明 │ └── Topic-B/ ├── 20-Methods/ 方法论、工具、技术路线 ├── 30-Reviews/ 综述和阶段性总结 ├── 40-Archive/ 已完成或过期的内容 └── 90-Meta/ 模板、脚本、配置说明这个结构的关键在于数字前缀。Obsidian 的文件列表默认按名称排序加数字前缀能强制让文件夹按我想要的顺序排列Inbox 永远在最上面Archive 永远在最下面。另外每个主题目录下都有一个_index.md下划线开头同样是为了排序时置顶这个文件里维护该主题的概览、关键问题和页面链接。注意不要一开始就设计过于复杂的目录层级。我最初按“领域-子领域-方法-年份”分了四层结果大部分文件夹是空的找东西反而更慢。两层到三层足够了更多的分类交给标签和链接去做。3. 核心细节解析与实操要点3.1 Markdown 写作规范从随意到统一Markdown 语法本身很简单但多人协作或者长期积累时没有规范就会乱。我给自己定了一套写作约定写在90-Meta/style-guide.md里每次新建页面都对照检查。标题层级上页面内只用二级和三级标题一级标题留给页面本身的文件名。这样在 Obsidian 的大纲视图里结构清晰导出成其他格式时也不会出现层级错乱。列表统一用短横线不用星号因为星号在某些渲染器里会和加粗语法冲突。代码块必须标注语言类型哪怕只是纯文本也标上text这样语法高亮和后续处理都方便。关于Markdown 换行这里有个很多人踩过的坑。标准 Markdown 里单个换行符不会产生新段落需要空一行或者行尾加两个空格。我在 Obsidian 里开启了“严格换行”选项让单个换行就生效这样写起来更符合直觉。但要注意这个设置会影响导出效果如果之后要把文件转到其他平台可能需要批量处理。表格的使用也要克制。Markdown 表格适合做参数对比和问题排查清单但不适合放长文本。我见过有人把整篇笔记塞进一个表格里读起来非常累。表格里的内容尽量简短超过一句话的说明放到表格外面。3.2 双向链接与标签的配合使用双向链接是 Obsidian 的灵魂但滥用会让关系图谱变成一团乱麻。我的原则是链接表达“这个页面和那个页面有直接关系”标签表达“这个页面属于某个类别”。比如我写一篇关于某个模型的论文笔记会链接到它改进的基线模型页面、用到的数据集页面、以及我自己的相关思考页面。这些是直接关系。同时给它打上#模型/Transformer、#任务/文本分类、#年份/2024这样的标签表达分类归属。标签体系我也做了分层用斜杠表示层级。这样在标签面板里可以折叠展开不会一下子列出几百个平铺的标签。常用的顶层标签有#模型、#任务、#数据集、#工具、#待办这几类够用了。实操心得新建页面时先想清楚它和已有页面的关系主动建立至少两个链接。一个孤立的页面在知识库里几乎等于不存在因为你不会再找到它。3.3 模板设计让每次新建页面都省力Obsidian 的模板插件可以大幅减少重复劳动。我针对不同类型的页面做了不同模板放在90-Meta/templates/下。论文笔记模板包含这些字段标题、作者、年份、发表 venue、链接、一句话总结、核心贡献、方法细节、实验设置、个人评价、相关链接。每次读完论文填模板就行不会漏掉关键信息。思考笔记模板更简单日期、触发问题、当前理解、待验证点、相关链接。这种笔记重在记录思考过程不需要太重的结构。主题索引模板用来维护每个主题目录的_index.md主题描述、关键问题列表、核心论文链接、相关方法链接、最近更新记录。这个页面是我进入某个主题时的入口所以要保持更新。模板里我还会预置一些 Dataview 查询代码自动列出该主题下的所有页面和最近修改时间。Dataview 是 Obsidian 的一个查询插件能把笔记的元数据当成数据库来查非常实用。4. 实操过程与核心环节实现4.1 环境搭建从零到可用的完整步骤第一步是安装 Obsidian。官网下载对应系统的安装包Windows 和 macOS 都有Linux 也有社区维护的版本。安装完成后新建一个仓库Vault指向你准备好的文件夹。我建议仓库文件夹放在一个固定的、有备份的位置不要放在临时目录里。第二步是配置基础设置。在设置里开启“严格换行”关闭“智能引号”否则代码里的引号会被替换成弯引号导致复制出去无法运行把“新附件默认位置”设为一个固定的attachments文件夹避免图片散落在各个目录。第三步是安装核心插件。Obsidian 自带的核心插件里我开启了“模板”、“大纲”、“反向链接”、“标签面板”、“文件恢复”这几个。模板插件需要指定模板文件夹路径指向90-Meta/templates/。第四步是安装社区插件。我常用的有Dataview数据查询、Templater增强模板支持脚本、Git版本控制、Advanced Tables表格编辑辅助、Style Settings主题微调。安装社区插件需要在设置里关闭安全模式然后浏览安装。这里要提醒一句社区插件质量参差不齐尽量选下载量大、最近有更新的。第五步是配置 Git 同步。在仓库根目录初始化 Git 仓库添加.gitignore文件排除.obsidian/workspace.json这类记录窗口状态的临时文件。然后关联到你的远程仓库设置定时自动提交。我用的是 Obsidian Git 插件可以设置每隔一段时间自动 commit 和 push。# 在仓库根目录执行 git init git add . git commit -m init research wiki git remote add origin 你的仓库地址 git push -u origin main.gitignore内容参考.obsidian/workspace.json .obsidian/workspace-mobile.json .trash/ .DS_Store4.2 接入 LLM 做检索与归纳本地知识库接大模型有几种路线。一种是用现成的插件比如 Copilot、Text Generator 这类配置好 API 就能在 Obsidian 里直接调用。另一种是自己写脚本通过 API 批量处理文件。我两种都用日常问答用插件批量处理用脚本。插件方案的好处是即开即用选中一段文字就能让模型解释、总结、改写。配置时需要注意几个参数模型选择上做归纳总结用中等规模的模型就够做复杂推理再上大模型温度参数建议调低0.2 到 0.3 之间保证输出稳定最大 token 数根据你的笔记长度调整太短会截断太长浪费额度。脚本方案适合批量操作。比如我要把00-Inbox里积累的几十篇剪藏文章批量生成摘要就写一个 Python 脚本遍历文件夹调用 API把结果写回文件。import os from openai import OpenAI client OpenAI(api_key你的key, base_url你的接口地址) def summarize(text): resp client.chat.completions.create( model你的模型名, messages[ {role: system, content: 你是研究助理请用三句话总结以下内容的核心贡献和方法。}, {role: user, content: text} ], temperature0.2 ) return resp.choices[0].message.content inbox 00-Inbox for fname in os.listdir(inbox): if fname.endswith(.md): path os.path.join(inbox, fname) with open(path, r, encodingutf-8) as f: content f.read() summary summarize(content[:6000]) with open(path, a, encodingutf-8) as f: f.write(\n\n## LLM 摘要\n\n summary)这里有个细节要注意输入长度要控制。大模型的上下文窗口有限而且很多模型对超长输入的处理质量会下降。我的做法是只取正文前 6000 字符或者先按段落切分分段总结再合并。另外生成的内容一定要用单独的标题区块标记方便之后区分。4.3 用 Agent 自动化文献整理流程Agent 和普通脚本的区别在于它能根据中间结果动态决定下一步做什么。我搭了一个文献整理 Agent工作流程大致是监控一个指定文件夹发现新的 PDF 或 Markdown 文件后先判断类型然后调用相应的处理链。对于 PDF先用工具转成 Markdown然后让模型提取元数据标题、作者、年份再生成结构化笔记最后根据内容自动推荐标签和链接目标。对于已经是 Markdown 的剪藏文章跳过转换步骤直接进入提取和生成环节。Agent 的实现我用的是轻量级框架核心是一个循环观察当前状态、决定下一步动作、执行动作、检查结果、继续或结束。伪代码大概是这样def agent_loop(task): state observe(task) while not state.done: action decide(state) result execute(action) state update(state, result) return state.output实际落地时最关键的是给 Agent 设定清晰的边界和终止条件。我踩过的坑是早期没有限制循环次数Agent 遇到一个格式异常的文件时会反复尝试处理消耗大量额度。后来加了最大迭代次数和异常跳过机制稳定多了。注意Agent 自动生成的内容不要直接写入正式笔记目录。我的做法是先写到00-Inbox/agent-output/下人工审核后再移动到对应主题目录。这样即使 Agent 出错也不会污染已有的知识库。4.4 版本控制与备份策略知识库的价值随时间增长丢了会非常痛苦。我的备份策略是三层本地 Git 仓库、远程 Git 仓库、定期打包冷备。本地 Git 每次修改都提交Obsidian Git 插件设置每 10 分钟自动提交一次。远程仓库用来自不同设备的同步和异地备份。冷备是每个月把整个仓库打包成一个压缩文件存到移动硬盘或者对象存储里。这里有个容易忽略的点附件文件也要纳入版本控制。图片、PDF 这些二进制文件如果只靠 Git 管理仓库会迅速膨胀。我的做法是小文件直接进 Git大文件用 Git LFS 或者单独同步。如果附件特别多可以考虑把附件目录排除出 Git用其他方式同步。5. 常见问题与排查技巧实录5.1 同步冲突与文件损坏怎么处理多设备使用 Obsidian 时同步冲突是最常见的问题。表现是同一个文件出现多个副本或者内容被覆盖。根本原因是两个设备在离线状态下都修改了同一个文件同步时无法自动合并。我的应对方法是尽量保证同一时间只在一个设备上编辑切换设备前先同步。如果确实出现了冲突Obsidian Git 会保留冲突标记手动解决后提交即可。Markdown 是纯文本冲突解决起来比二进制文件容易得多这也是我选它的原因之一。文件损坏的情况我遇到过两次都是因为同步过程中断电。好在有 Git 历史直接回滚到上一个正常版本就行。所以再次强调版本控制不是可选项是必选项。5.2 LLM 输出不稳定怎么办大模型的输出有随机性同样的输入可能得到不同的结果。做知识管理时这种不确定性会带来困扰。我的处理方式是固定参数、多次采样、人工筛选。固定参数是指把温度调低并且记录下每次使用的模型版本和参数。多次采样是指对重要内容让模型生成两到三个版本对比后取最好的或者手动融合。人工筛选是最后一道关任何进入正式笔记的内容都要过一遍眼。还有一个技巧是给模型提供示例。在 prompt 里放一两个高质量的输入输出对模型会模仿示例的风格和结构输出稳定性明显提升。这个技巧在批量处理时特别有用。5.3 知识库越用越乱怎么破这是所有知识管理系统的通病。页面越来越多链接越来越密但真正有用的内容反而找不到了。我的经验是定期做“知识库维护”大概每个月一次。维护的内容包括清理 Inbox把临时内容归类或删除检查孤立页面要么建立链接要么归档更新主题索引把新页面纳入索引回顾标签体系合并重复标签删除不再使用的标签。维护时我会用 Dataview 查询列出所有孤立页面和超过三个月未修改的页面逐个处理。这个过程有点枯燥但坚持下来知识库才能保持可用。常见问题排查思路解决方法同步冲突检查多设备修改时间手动合并提交后统一同步文件损坏查看 Git 历史回滚到正常版本LLM 输出不稳定检查温度和模型版本降低温度提供示例知识库混乱统计孤立页面和旧页面定期维护归类归档附件丢失检查附件目录和 Git 记录恢复备份调整同步策略5.4 性能问题大仓库变慢怎么办当仓库里文件数量超过几千个时Obsidian 的启动和搜索会变慢。我的优化经验是关闭不必要的插件特别是那些会实时扫描全库的插件把大附件移出仓库用链接引用定期清理.obsidian下的缓存文件。如果还是慢可以考虑把仓库拆分成多个。比如把归档内容单独放一个仓库主仓库只保留活跃内容。Obsidian 支持多仓库切换用起来也不麻烦。6. 我在这套体系上的一些个人体会搭 Research Wiki 这件事工具和技术只是一部分更重要的是养成持续记录和整理的习惯。我见过很多人把 Obsidian 配置得花里胡哨插件装了几十个但笔记没写几篇。工具是为人服务的不要本末倒置。我的建议是从最简单的配置开始先用起来遇到问题再逐步加功能。LLM 和 Agent 确实能提升效率但它们替代不了你自己的思考。模型可以帮你总结一篇论文但论文对你研究的真正意义只有你自己能判断。最后分享一个我一直在用的小技巧每周花半小时写一篇“本周研究日志”记录这周读了什么、想了什么、有什么待验证的问题。这篇日志不需要很正式但坚持下来它会成为你回顾研究轨迹时最有价值的页面。