我如何构建并维护个人 Wiki

1) 起点：为什么我决定开始做这件事

最近我被 Andrej Karpathy 的一篇分享打动了。他在文中介绍了自己如何借助大模型搭建个人 Wiki，并把零散的信息逐步沉淀成可持续更新的知识系统：LLM Wiki

这件事对我的触动很直接：我们平时会读很多论文、文章、推文，也会记很多笔记，但这些内容往往分散在不同工具里，检索不难，复用却很难。很多时候不是“找不到”，而是“找到了也拼不起来”。

Karpathy 的思路让我意识到，个人 Wiki 不只是一个资料仓库，更像一个可以持续生长的“第二大脑”：新信息进来后，不是简单堆积，而是被整理、关联、更新，最终形成结构化认知。

所以我决定亲自实践一遍：用大模型作为知识整理与维护的引擎，搭建一个真正能长期迭代的个人 Wiki。这篇文章也会记录我从 0 到 1 的过程，包括架构选择、工作流设计、踩坑与改进。

2) 这篇文章的核心思想：让 Wiki 变成“可持续维护的系统”

这篇文章采用的不是传统“把资料丢进检索库”的思路，而是把个人知识管理拆成三层：

• 原始资料层（raw）：论文、网页、笔记等原始输入，尽量保持不可变；
• Wiki 内容层（wiki）：按主题、概念、项目等组织成可阅读、可链接的 Markdown 页面；
• 规则与索引层（schema/index/log）：定义文件结构、命名规范、更新流程，并记录每次变更。

对应到文件结构上，可以理解为：raw/ 负责“存证”，concepts/、entities/、projects/ 这类目录负责“组织认知”，index.md 和 log.md 负责“导航与追踪”。这样做的重点是让知识库从一开始就具备可扩展性，而不是等内容爆炸后再回头补结构。

大模型在这套流程里的作用，不只是“回答问题”，更关键是承担高频、枯燥、但对一致性要求很高的维护工作：

• 新资料进来后自动归档到合适位置，并生成摘要；
• 更新相关页面的交叉链接，减少信息孤岛；
• 对重复、冲突、过时内容做标记，提示需要人工判断的部分；
• 定期做“体检”（比如孤立页面、断链、待更新页面），维持 Wiki 健康。

原因很现实：人类通常很难长期、稳定地完成这种维护。前期内容少时还能手动整理，但当 Wiki 逐渐变大后，每天去补链接、查重复、做一致性检查，成本会迅速上升，最后系统往往就会失去维护。把这些流程交给大模型自动化，人的角色就可以回到更有价值的部分：选择信息源、判断重要性、做最终决策。

3) 我的工具选择：为什么是 WSL + Hermes + 分层模型 + Git/Obsidian

这一套搭建我最终选了一个很务实的组合：在 WSL 上运行 Hermes Agent；初始化阶段使用 GPT 5.4；后续日常整理使用 MiniMax2.7；通过 Git 同步到 Windows 侧，用 Obsidian 做可视化阅读与少量人工编辑。

3.1 为什么先选 WSL

我在 Windows 环境下实践时，首先遇到的是部署问题：Hermes 不能直接在原生 Windows 上按目标方式运行，需要依赖 WSL。这个限制反而让我更确定了选择。

WSL 的好处是“隔离但不割裂”：它像一个独立的 Linux 开发环境，不会把系统级依赖和配置污染到 Windows 本体；同时又能和 Windows 文件、编辑器、Git 工作流保持顺畅协作。对学生党或者个人开发者来说，不需要额外购买设备去部署更重的本地代理系统，也能低成本体验完整的 AI 工具链。

另外，WSL + 命令行的资源占用相对克制，适合长时间挂着跑自动化任务。对于这种“持续工作型”的 Wiki 维护流程，这点非常关键。

3.2 为什么用 Hermes Agent

我选择 Hermes 的核心原因是它比较贴合“长期维护型”知识工作流，而不只是一次性问答。

• 它内置了 llm-wiki 这类能力，初始化目录结构和流程定义会更快；
• 它支持定时任务，适合周期性做 Wiki 体检（例如检查断链、孤立页面、待更新内容）；
• 它能连接飞书、微信等外部渠道，日常看到值得保存的链接时，可以快速进入同一条整理链路。

换句话说，Hermes 更像一个“可编排的知识维护代理”，而不是单轮聊天工具。

3.3 为什么模型要分阶段用

初始化阶段我倾向于用更强模型（这里用 GPT 5.4），因为开局要做很多高质量决策：目录怎么分层、命名规范如何约束、索引和日志怎样设计、哪些信息该入库、哪些只做引用。开局质量越高，后面维护成本越低。

而进入日常维护后，大量任务其实是流程化、重复性较高的整理工作：摘要、归档、更新链接、按规则写入。这类任务用过程模型（如 MiniMax2.7）通常也能稳定胜任，同时能显著控制成本。

简单说：把“高质量决策”留给强模型，把“高频执行”交给更经济的模型。

3.4 Git + Obsidian：保持简单、可靠、可见

同步层我没有做复杂设计，直接用 Git 管版本与跨环境同步；阅读与结构浏览交给 Obsidian。这个组合很常规，但足够可靠：既有历史记录和回滚能力，也有图谱化、链接化的可视界面，适合长期演进。

4) 我的具体实践方式（进行中）

4.1 初始化：先把“骨架”搭好，再把“规则”说清楚

我自己的起手式很固定：先新建一个用于存放 Wiki 的目录，然后在 Hermes 里调用 /llm-wiki，直接让 Agent 帮我初始化个人 Wiki 仓库。初始化完成后，Agent 通常会把基础目录结构、索引文件和写入规则一并生成好，并询问是否要导入第一份内容。

下面这段 prompt 我建议读者可以直接复制使用（按自己的路径替换即可）：

请使用 /llm-wiki skill 帮我初始化一个个人 wiki。

我的 wiki 根目录是：~/path/to/my-wiki
主题方向是：个人研究与长期知识管理

请你完成以下事项：
1) 创建初始目录结构（raw、concepts、entities、projects、daily_record 等）；
2) 生成索引与日志文件（例如 index.md、log.md）；
3) 给出可执行的写入与更新规则（命名、链接、更新频率、冲突处理）；
4) 按“可持续维护”原则，提供一版默认工作流（摄取、整理、查询、体检）；
5) 初始化完成后，先不要批量导入资料，先让我审阅结构与规则。

这里我个人的做法是：初始化之后不会立刻开跑，而是先逐条检查它生成的结构和规则，再按自己的目标做二次定制。因为我不只是想收集阅读材料，还希望把“每天的研究进展”也纳入同一个系统。

所以我会继续补充需求，让 Agent 设计一套日更记录模块（例如 daily_record 的组织方式、每天记录字段、每周汇总方式），确保后续写入有一致的格式约束。这个阶段我的体会是：规则写在文档里还不够，最好进一步沉淀成可调用的 skill。这样后面不在电脑前时，也能通过飞书等入口把当天进展投喂给同一套流程，而不是依赖手工整理。

最初它给我的交互模板偏机械，大概是“你先描述今天做了什么，我再问阻塞和明天计划”。这能用，但不够好。既然已经有个人 Wiki 作为上下文，我更希望 Agent 不只是记录，还能基于当前 Wiki 内容给出有针对性的建议。于是我又提出了下一步需求：把这个记录 skill 升级为“先结合 Wiki 给建议，再完成事实写入”的模式。

再往后，我开始关注“输入是怎么被整理进 Wiki 的”。有了基础结构之后，真正决定质量的其实是摄取流程：一条链接进来后，先落原始卡片还是先做摘要？怎么做去重？哪些信息进入实体页，哪些只放在来源记录里？这些细节会直接影响后续可维护性和 token 成本。

所以我专门去追问了 /llm-wiki 目前默认的资料整理路径，先把现有机制看明白，再基于自己的需求做改造。虽然我已经在考虑进一步优化多源数据处理以节省 token（这部分还在实验中），但我先落地了三套更实用的 skill：

• daily-record-writer：把“日报记录”标准化为固定结构（今日进展 / 问题与阻塞 / 明日下一步），并要求先读 Wiki 再给建议；建议保留在对话里，写入文件的只保留事实。这样既能保证记录质量，又不会把临时想法污染到长期档案。
• paper-ingest：专门处理论文来源（PDF、arXiv、项目页），先创建 raw/papers/ 的 source card，再按 raw-only / summary / full-ingest 三档深度处理，避免一上来就重度解析；只有在确实需要时才做全量整合，兼顾质量和成本。
• article-ingest：专门处理博客/网页链接（含从 X/Twitter 发现的外链），同样先落 raw/articles/ 的 source card，再按三档策略决定是“先存档”“给摘要”还是“正式纳入 Wiki 页面”。

这三套流程配合起来后，输入路径就比较清晰了：日常进展走 daily record，论文走 paper ingest，博客走 article ingest。每类信息都有自己稳定的入口和处理深度，后续维护成本会低很多。

4.2 第一次 ingest：把第一篇论文真正放进系统

基础框架搭好之后，我做的第一件事就是找一篇论文，按既定流程把它放进知识库。实际执行时，AI 会调用相应工具去解析 PDF、提取关键信息，再把内容整理为结构化笔记，并同步更新到 Wiki 的相关页面。

这个过程的关键不只是“生成一段摘要”，而是把论文中的问题定义、方法要点、实验结论和与我当前研究方向的关联，放到可持续维护的结构里。这样后续再读到同主题论文时，就可以在已有页面上持续累积，而不是每次从零开始。

到这一步，整个 Wiki 就算真正跑起来了：不仅完成了初始化，还成功导入了第一份可复用的知识内容。

4.3 批量导入旧论文：用“优先级分层”控制质量与成本

完成第一次 ingest 后，我把自己以前下载的论文也逐步交给 AI 导入 Wiki。这里我没有采用“一刀切”的处理方式，而是先做了优先级分层，再决定每篇论文的处理深度。

第一层是必须优先、且要求精读的基础与核心材料：例如 3DGS、NeRF、SMPL-X、Diffusion 这些基础方向，以及和我当前研究直接相关的论文。这一层的目标是尽快搭出一个稳定的知识底座，所以我会要求 AI 做完整整理：不仅记录来源，还要提炼关键机制、方法脉络和与现有项目的具体关联。

第二层是其余待处理论文。对这部分，我会先让 AI 记录 raw 信息（来源、基本元数据、初步备注），再根据重要性决定是否进入精读流程。判断标准也比较直接：如果它属于基础知识、能补齐关键短板，或者对我当前项目有明确帮助，就升级为精读并写入更具体的 Wiki 页面；否则先保留在 raw 层，等后续需要时再深入。

这种分层策略对我很重要：它避免了前期在低优先级材料上过度消耗时间和 token，同时保证关键论文能被优先打磨成真正可复用的知识资产。

更关键的是，导入过程并不是把论文一篇篇“孤立地塞进去”。如果只停留在 raw 层，那只是完成了原始数据归档。真正让 Wiki 变得有价值的，是 AI 在 ingest 之后会做“全局更新”：它会把新论文中的关键信息回填到已有概念页/项目页，补充关联关系，并把新旧页面通过链接组织成可追踪的知识网络。

参考 /llm-wiki 的思路，这个更新过程通常包括几步：先读取当前 schema、index 和近期 log 来理解现有结构；再判断新内容应该“更新旧页”还是“创建新页”；随后补上交叉引用（尽量形成双向可导航）；最后同步更新 index 与 log，保证后续检索和维护仍然可控。这样做的结果是：每次 ingest 都会让已有知识结构更完整，而不是让页面数量无序增长。

4.4 后续检查与问题修复：先把同步链路打通

到这里，Wiki 已经可以稳定产出内容了。接下来我做的是“运维侧”的收尾：检查同步是否顺畅，以及跨平台使用时容易出现的问题。

由于我的导入 skill 在每次 ingest 完成后会自动提交 Git，我就可以很方便地把内容同步到 Windows 侧，再用 Obsidian 做日常查看和轻量修改。这套链路很实用，但有两个细节一定要提前处理：

1) 跨平台换行符统一 在仓库根目录准备 .gitattributes，加入：

* text=auto

这样可以减少 Windows/WSL 来回编辑时的无意义 diff。

2) 忽略 Obsidian 的本地工作区状态 在 .gitignore 里忽略：

.obsidian/workspace.json

这个文件通常是本地视图状态，不属于知识内容本身，纳入版本控制很容易造成噪音冲突。

把这两个点处理好后，Git 同步会顺畅很多。接着在 Obsidian 里就能直接浏览 Wiki 的各个模块，利用双向链接快速跳转上下文；同时也可以打开关系图谱，从可视化层面检查知识点之间是否形成了连通结构。

在这一步，我还通过快速浏览现有页面发现了一个很典型、也很影响后续质量的问题：中英文混用且缺乏统一规范。有些页面主体是中文，有些是英文，甚至同一页内也出现混杂。这不仅降低我自己阅读和检索的效率，也会影响 AI 基于 Wiki 做知识调用与总结时的一致性。

所以我做了两件事：

1) 先让 AI 对当前内容做一次语言统一修复（至少先把高频使用页面统一到同一种主语言）； 2) 再把“语言规范”写进 Wiki 规则层，明确页面主语言、术语保留策略和中英文边界，避免后续再次漂移。

另外，前面提到过用 AI 搭 Wiki 的一个重要优势，就是可以做周期性健康检查。除了人工抽查外，也可以在 Hermes 里直接执行类似：

/llm-wiki 检查目前wiki的健康程度

它会按严重程度列出现有问题（例如结构一致性、链接完整性、页面孤立、规则漂移等），并给出对应修复建议。对高优先级问题，可以直接让 AI 先修复，先把 Wiki 的“可用性底线”稳住。

5) 进阶使用与后续升级

当 Wiki 进入稳定运行后，我更建议把“维护动作”也自动化。一个直接可用的方法是：在 Hermes 里设置定时任务，定期触发健康检查。例如：

设置一个定时任务，每周日10:00，使用 /llm-wiki 为我检查 wiki 的健康状态。

这样做的价值是把“想起来才检查”变成“系统自动检查”。更进一步，最好让它把检查结果主动推送到你常用的社交平台，这样你不用专门打开终端，也能及时知道 Wiki 是否出现了高优先级问题。我自己是把 Hermes 连接到飞书来接收这类通知，配置方法可以参考 Hermes 官方文档（飞书接入）。

连接消息渠道后，输入链路也会更顺滑：例如睡前刷到一条有价值的推文，我可以直接在飞书里给 AI 发消息，让它把链接按既定流程写入 Wiki，而不必回到电脑前手动处理。

有趣的是，我在搭完这套系统当天就刷到了一条相关升级讨论：有人把 Karpathy 的 LLM Wiki 进一步演进成了“LLM Wiki v2”。从我当前笔记里的总结看，它的改进重点包括：

• 给知识增加置信度与时效管理（不是所有结论都永久等权）；
• 引入分层记忆（工作记忆、情节记忆、语义记忆、流程记忆）；
• 从“纯页面链接”走向更结构化的知识图谱与混合检索（关键词 + 语义 + 图遍历）；
• 增加自动化钩子与遗忘机制，让长期维护成本进一步下降；
• 对矛盾信息不只标注，还尝试基于证据做优先级判断。

我目前还没有把这套 v2 思路完整迁移到自己的 Wiki。等后续内容规模再上来、结构更复杂时，我大概率会让 AI 逐步把这些机制吸收进现有系统。

6) 总结与建议

回看这次实践，我最大的感受是：个人 Wiki 真正难的不是“搭起来”，而是“持续维护”。如果没有自动化流程，再好的结构也很容易在一两周后失去更新节奏。把 AI 引入后，价值不只在于省时间，更在于把原本难以长期坚持的整理、链接、校验工作变成了可重复执行的系统。

如果你也准备从 0 开始，我建议优先把这几件事做对：

1) 先定结构，再导入内容。先把目录、命名、写入规则讲清楚，后续会省掉大量返工。 2) 输入分层处理。不要所有资料都精读；先 raw 记录，再按价值升级 summary / full-ingest。 3) 把高频动作沉淀成 skill。尤其是 paper/blog ingest 和 daily record，这会明显提高稳定性。 4) 尽早处理同步细节。跨平台时统一换行符、忽略本地工作区噪音文件，能减少很多无效冲突。 5) 维护要“定时化”。把健康检查做成周期任务，并推送到你常用消息渠道，避免 Wiki 失修。

最后，这套方法并不要求一开始就很“重”。你可以先用最小可用版本跑起来：一个清晰结构 + 一条稳定 ingest 流程 + 一次每周健康检查。只要它能持续运转，Wiki 就会像复利一样逐步变强。

提醒：AI 与工具链发展很快，本文部分方法和配置具有时效性。建议你在实践前结合最新官方文档做一次快速校验。