企业官网建设流程全解析

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_Store

4.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} ], temperature=0.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", encoding="utf-8") as f: content = f.read() summary = summarize(content[:6000]) with open(path, "a", encoding="utf-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 查询列出所有孤立页面和超过三个月未修改的页面，逐个处理。这个过程有点枯燥，但坚持下来，知识库才能保持可用。

5.4 性能问题：大仓库变慢怎么办

当仓库里文件数量超过几千个时，Obsidian 的启动和搜索会变慢。我的优化经验是：关闭不必要的插件，特别是那些会实时扫描全库的插件；把大附件移出仓库，用链接引用；定期清理.obsidian下的缓存文件。

如果还是慢，可以考虑把仓库拆分成多个。比如把归档内容单独放一个仓库，主仓库只保留活跃内容。Obsidian 支持多仓库切换，用起来也不麻烦。

6. 我在这套体系上的一些个人体会

搭 Research Wiki 这件事，工具和技术只是一部分，更重要的是养成持续记录和整理的习惯。我见过很多人把 Obsidian 配置得花里胡哨，插件装了几十个，但笔记没写几篇。工具是为人服务的，不要本末倒置。

我的建议是从最简单的配置开始，先用起来，遇到问题再逐步加功能。LLM 和 Agent 确实能提升效率，但它们替代不了你自己的思考。模型可以帮你总结一篇论文，但论文对你研究的真正意义，只有你自己能判断。

最后分享一个我一直在用的小技巧：每周花半小时写一篇“本周研究日志”，记录这周读了什么、想了什么、有什么待验证的问题。这篇日志不需要很正式，但坚持下来，它会成为你回顾研究轨迹时最有价值的页面。