一个运维人的第二大脑：用 Obsidian 管理技术知识库

为什么开始做知识库

做了 16 年运维，养成了一个习惯：所有操作都要留记录。

改个配置、装个依赖、遇到个报错——随手写一行。这个习惯在转型 AI 开发后救了我无数次。三个月前写的配置，回头完全不记得为什么那么设。翻一下笔记，三秒定位。

最开始用记事本，后来用 Notion，最后稳定在 Obsidian。选它的原因很简单：

本地 Markdown 文件 → 不依赖任何云服务 → 永远不会丢。

我的知识库长什么样

my-tech-wiki/
├── index.md           ← 总目录，所有页面在这里都能找到
├── schema.md          ← 规范文档（命名、标签、何时新建页面）
├── log.md             ← 所有操作的日志
│
├── entities/          ← 实体：项目、人、简历
│   ├── memoapp.md
│   ├── personal-rag-platform.md
│   ├── personal-website.md
│   └── ...
│
├── concepts/          ← 概念：架构、技术原理、修复记录
│   ├── rag-deployment-record.md
│   ├── llm-basics.md
│   ├── memoapp-crash-fixes.md
│   └── ...
│
├── plans/             ← 计划：学习路线、求职策略
│   ├── study-and-job-plan.md
│   └── qianhai-target-companies.md
│
└── raw/               ← 原始素材（不动它，只引用）
    └── articles/

两个核心原则

原则一：分类只有五类

很多知识库教程搞十几种分类，越分越乱。我用了半年，发现五个分类就够了：

分类	放什么	例子
实体	能摸到的东西	项目仓库、简历、手机 App
概念	抽象的东西	架构设计、技术原理、报错修复
计划	未来的事	学习路线、面试策略
对比	二选一或多选一	LLM 选型对比、部署方案对比
素材	原始数据	文章摘录、截图、日志输出

为什么五类够用？因为大多数东西不是实体就是概念，二选一就行了。纠结”这个该放哪”超过 3 秒，说明分类有问题。

原则二：双向链接是唯一的组织方式

不用文件夹嵌套、不用标签体系。所有页面之间靠 [[wikilink]] 连接。

# memoapp.md 里的片段

## 架构
详见 [[memoapp-architecture]]。

## 崩溃修复记录
上线华为应用市场时遇到 7 处崩溃，全部记录在 [[memoapp-crash-fixes]]。

## 相关技术栈
- 用到的 AI 辅助开发工具：[[hermes-agent-architecture]]
- 编译部署相关：[[harmonyos-dev-environment]]

这样写的效果：打开一个页面，所有相关页面都在里面，顺着链接就找到了，不用搜索、不用回忆。

Obsidian 的 图谱视图 还能可视化这种链接关系——但说实话，这个功能我几乎不用。链接的意义在于导航，不是画图。

三条硬规矩

1. 每页必须有 frontmatter

---
title: RAG 部署记录
created: 2026-07-05
updated: 2026-07-24
type: concept
tags: [rag, deployment, qdrant, ollama]
confidence: high
---

不写 frontmatter 的页面就像没有身份证的人——你知道它存在，但根本不知道它是什么、什么时候创建的、靠不靠谱。

confidence: high | medium | low 最重要。三个月后回来翻，一眼就能判断这个记录还可信不可信。

2. 改了东西必须记 log

[2026-07-24] update | RAG Reranker 修复
- 问题：CrossEncoder 初始化时跨墙访问 huggingface.co，120s 超时
- 修复：local_files_only=True，加载时间降到 2.4s
- 文件：concepts/rag-deployment-record.md 新增 Reranker 章节

不是 Git commit 那种技术日志，而是”我今天动了知识库的哪些页面”。万一改错了，看 log 能找到最后一版。

3. 不改原始素材

raw/ 目录里的东西是只读的——文档摘录、错误日志、API 响应、截图。永远不直接编辑它。

想加工？在 concepts/ 或 entities/ 里新建一页，用 [[raw/articles/xxx]] 引用原素材。

这样做的原因：原始数据是不可替代的。三个月后你可能发现之前的分析是错的——如果原素材还在，可以重新分析。如果把它删了，就没了。

什么时候新建页面 vs 追加到已有页面

这是我纠结最久的问题。后来定了一条硬规则：

情况	做法
新内容跟已有页面直接相关	追加到已有页面
新内容是个独立主题	新建页面，同时从相关页面加链接
一页超过 ~200 行	拆成子页面
只是顺带提一嘴	不新建页面，在当前页写一行

举例：Reranker 修复要不要新建页面？

不要。Reranker 是 RAG 部署的一部分，直接追加到 rag-deployment-record.md 里，加个小标题 ## Reranker 集成与修复。

什么不进知识库

这个更重要——知道什么不该放：

❌ Git 仓库的代码 — 去 GitHub 看就行
❌ 临时 TODO 清单 — 用 Hermes 的 todo 工具
❌ 聊天记录 — 除非是重要的技术讨论
❌ 网上随处可查的基础知识 — 比如 Python 的 if 语法
❌ 已经过时且不会再参考的旧方案

这套系统的实际效果

场景	多久找到
鸿蒙 MemoApp 崩溃修复上次怎么改的	10 秒
RAG 平台的 Qdrant 版本兼容问题	15 秒
我的简历最近更新了什么	5 秒
前海有哪些目标公司	3 秒
ICP 备案流程和材料清单	10 秒

和 AI 的结合

这套系统最爽的一点：可以直接喂给 RAG。

我的知识库全是被 Obsidian 管理的 Markdown 文件。用 RAG 平台的 python -m src.ingest docs/ 一键导入 Qdrant，接下来就能用自然语言提问：

“MemoApp 上次华为审核被拒是什么原因？"
"RAG 平台用的是什么 Embedding 模型？"
"有哪些前海的公司可以投简历？”

等于把”人工翻笔记”升级为”AI 直接回答”。

建议

如果你也想建一个：

从 3 个页面开始：index.md、一个项目实体页、一个遇到的问题页
先写 100 篇再优化分类 — 只有内容够多，才知道怎么分
规则写在 schema.md 里 — 三个月后你会感谢自己
别装插件 — Obsidian 原生就够用了，插件是分心的陷阱
工具不重要，习惯才重要 — 用记事本也行，关键是每次都记

一个运维人的本能反应：遇到问题先记下来，修好后再记下来，三个月后回头看——那就是你的技术成长史。