Markdown 没有过时：Obsidian 如何用纯文本构建个人知识库

Markdown 过时了吗？每隔一段时间，技术社区就会出现类似的声音：可视化编辑器越来越强，AI 可以直接生成文档，富文本工具一个比一个顺手，Markdown 这种"纯文本 + 符号"的格式是不是该退出历史舞台了？

我的答案很明确：Markdown 没有过时，而且正在成为个人知识管理的基础设施。 这不是情怀，而是我长期使用 Obsidian 之后得出的实际结论。Obsidian 恰恰是"Markdown 仍然重要"这个判断最有力的证明——它没有把 Markdown 当成一个简单的写作格式，而是把它做成了整个知识库的底层语言。

这篇文章会回答三个问题：为什么有人觉得 Markdown 过时（以及这种错觉从哪来）；Markdown 和 Obsidian 结合后到底解决了什么痛点；如果你现在想用 Obsidian 搭建自己的笔记体系，应该怎么配置、怎么写、遇到问题怎么排查。全程会覆盖图片路径处理、数学公式渲染、标签体系、表格操作等高频场景，这些也是新手最容易踩坑的地方。

1. 为什么会有"Markdown 过时"的错觉

先说说这种质疑是怎么来的。任何技术被讨论"过时"，通常有三个信号：语法层没有演进、使用场景被替代、新工具提供了更省力的方案。Markdown 看起来确实符合前两点。

从语法上看，Markdown 的核心语法十几年没有大变化，标题用 #，列表用 -，加粗用 **。它不像编程语言那样有版本迭代和特性更新，给人感觉"停滞了"。从替代方案上看，Notion 的块编辑器、飞书文档的富文本能力、各类 AI 写作工具，都能让用户在不接触任何标记符号的情况下完成排版。一个从来没有写过 Markdown 的新人，用 Notion 写完一篇带表格、带图片、带代码块的文档，可能全程不需要知道 ## 是什么。

但这恰恰是问题所在。Notion 和飞书文档类工具是把内容锁在私有格式里的，而 Markdown 锁不住。 你在 Notion 里写了一万条笔记，哪天不满意了想迁移，导出格式和数据结构都会让你头疼。而 Markdown 就是纯文本，一个 .md 文件放在任何设备上都能打开，cat 命令能读，记事本能读，GitHub 能渲染，VS Code 能编辑，Obsidian 能把它变成一个知识库。

所以"Markdown 过时"的错觉，根源在于视角错误：把 Markdown 当成一个"排版工具"来看，它确实不够炫；把它当成"内容存储格式"来看，它依然是最稳妥的选择之一。

从实际趋势看，Markdown 不仅没有过时，反而在持续渗透。GitHub 的 README、开源项目的文档、技术博客、AI 对话中的代码块、知识库软件，都在大量使用 Markdown。甚至很多新兴工具都把 Markdown 作为导入导出的中间格式，因为它是跨工具迁移成本最低的"通用语言"。Obsidian 只是把这个趋势推到了极致：整个软件不建私有数据库，你的每一篇笔记就是一个 Markdown 文件，文件夹结构就是你的知识分类结构。

2. Markdown 的核心能力拆解

要理解 Obsidian 为什么选择 Markdown，先要拆解 Markdown 到底提供了什么。很多教程直接把语法表列出来就完事，但更关键的是理解这几种能力背后的设计逻辑。

第一，纯文本可读性。 Markdown 文件的本质是带约定的纯文本，即使没有任何渲染器，你打开源文件也能看懂内容结构。这意味着它不依赖特定软件存活。十年后 Notion 可能不存在了，但你的 .md 文件依然可以用任意文本编辑器打开。

第二，极低的迁移成本。 你从一个 Markdown 编辑器换到另一个，几乎不用做格式转换。Typora 写的文件可以放进 Obsidian，Obsidian 的仓库可以直接推到 GitHub，GitHub 上的文档可以下载到本地用 VS Code 阅读。这种自由度在私有格式笔记软件里是看不到的。

第三，生态兼容性。 Markdown 之所以没有演进，不是因为它死了，而是因为它已经成为了"最小公约数"。GitHub、GitLab、npm、PyPI、各大代码托管平台都支持 Markdown 渲染；Jupyter Notebook 的 Markdown 单元格、知乎和 CSDN 的文章编辑器、飞书的导入功能，全部兼容 Markdown。

下面用表格对比一下主流方案的实际差异：

这四项对比里，Markdown 最突出的就是"数据可控性"和"跨工具迁移"。它牺牲了即时排版可视化，换来了内容的所有权和长期可访问性。对一个想把笔记积累成知识资产的人来说，这个取舍非常划算。

3. Obsidian 为什么是 Markdown 的最佳答案

Obsidian 的出现，解答了一个此前 Markdown 用户长期纠结的问题：Markdown 适合存储，但怎么把零散的 .md 文件组织成知识体系？

早期 Markdown 用户面临一个尴尬局面：编辑器工具很多，但几乎没有"知识管理"能力。Typora 适合打字，VS Code 适合写技术文档，但它们都是编辑器，不是知识库。你的笔记分散在几十个文件里，文件之间没有联系，时间一长就找不到了。Obsidian 做对的关键事情，是把"文件夹 + 文件"这种传统结构升级成了"双向关联网络"。

核心概念有几个，每个都值得理解清楚。

Vault（仓库）。Obsidian 不创建数据库，它让你选择一个本地文件夹作为仓库，这个文件夹里的所有 .md 文件就是你的全部笔记。任何一个 Markdown 文件都可以直接拷进 Vault 中使用，也可以用系统文件管理器直接移动、删除、重命名。这意味着你的知识库没有"锁"，随时可以脱离 Obsidian 使用。

双向链接。普通笔记软件只能建目录树，而 Obsidian 允许你用 [[笔记名]] 的语法建立笔记之间的引用关系。最有价值的是"反向链接"：当你打开某篇笔记时，可以看到有哪些其他笔记引用了它。这种机制让知识从"存放"变成了"连接"，长期积累后会产生复利效应。

标签体系。Obsidian 中标签的写法和 Markdown 天然一致。在文首或正文任意位置输入 #标签名 即可。Obsidian 还支持子标签，例如 #技术/前端、#项目/博客，斜杠表示层级关系。很多新手会问"Obsidian 加标签怎么做"，其实核心就一句话：在 Markdown 里写 #标签，Obsidian 会自动识别并纳入标签面板。 但要注意，标签和标题里的 # 是有区别的：# 标题 后面有空格，#标签 后面没有空格，Obsidian 正是通过这个细节区分的。

插件生态。Obsidian 内置功能已经够用，真正让它强大的是社区插件系统。从表格增强、任务管理到 Dataview 数据查询，几乎每周都有新插件出现。但这也带来了一个问题：插件越多，配置越复杂，甚至可能因为主题和插件冲突导致界面异常。这也是后面要重点讲的排查场景。

4. 环境准备与基础配置

接下来进入实操部分。下面以 Obsidian 为例，演示从下载到完成基础配置的完整流程。本文不会写死具体版本号，因为 Obsidian 桌面端更新较快，功能位置可能略有差异，但核心配置思路是通用的。

4.1 安装 Obsidian

打开 Obsidian 官方网站，根据操作系统选择对应版本。Windows、macOS、Linux 均有桌面客户端，Android 和 iOS 也有移动端。安装过程没有特殊选项，下一步即可。

安全提示：建议只从官方网站或应用商店下载，不要使用来路不明的安装包。Obsidian 的仓库文件默认保存在本地，下载来源不正规时存在恶意代码风险。

4.2 创建 Vault

首次启动会显示创建仓库的界面。你可以选择"创建新仓库"，选择一个本地目录，也可以直接选择已有 Markdown 文件的文件夹作为仓库。

这里有一个关键判断：不要什么都塞进一个 Vault。 个人笔记、工作文档、项目资料最好分开建仓库，因为 Obsidian 的关系图谱、标签搜索、插件配置都是在 Vault 级别生效的。把完全无关的内容放在一个 Vault 里，图谱会变成一团乱麻。

4.3 文件与链接设置

打开"设置 → 文件与链接"，建议重点关注以下配置项：

• 新笔记的存放位置：建议选择"当前笔记所在的文件夹"，避免新笔记乱跑。
• 附件默认存放路径：这里是最容易踩坑的地方，下文重点展开。
• 链接格式：默认使用"基于当前笔记的相对路径"即可，便于整个仓库移动位置后链接依然有效。

很多人在 Obsidian 里插入图片后，换一台电脑或者移动文件夹就发现图片全部失效，问题几乎都出在附件路径配置上。Obsidian 的图片本质上也是文件，插入图片时只是写入了一条 Markdown 引用路径。如果图片被放在系统临时目录或者绝对路径下的某个角落，仓库一移动就找不到。

推荐的规范是：在 Vault 根目录下建一个统一附件文件夹，让所有图片、PDF、音视频都落到这里。 具体可以在"文件与链接 → 附件默认存放路径"中选择一个固定文件夹。这样写出来的 Markdown 路径会保持稳定，导出和备份也方便。

4.4 编辑器设置

在"设置 → 编辑器"中，建议打开以下选项：

• 严格换行：关闭。这样在编辑器中按回车即可换行，不会影响渲染。
• 显示行号：根据个人习惯开启，对定位大段笔记有帮助。
• 数学公式默认渲染：开启。Obsidian 使用 KaTeX 渲染 LaTeX 数学公式，开启后公式会实时显示在编辑模式中，而不是退出到阅读模式才生效。

需要说明的是，Obsidian 不是 Markdown 编辑器中排版能力最强的，但它把"编辑"和"知识管理"做在了同一个界面里。如果你更看重打字体验，可以配合 Typora 使用：Typora 负责长时间书写，Obsidian 负责组织和管理。两个工具都直接读写本地 Markdown 文件，完全可以共用同一个 Vault 目录。

5. 一个真实场景：搭建学习笔记工作流

下面用一个实际场景串联整个工作流。假设你在学习机器学习，需要记录课程笔记，整理公式，积累论文摘要，还要统一管理图片和标签。这个场景几乎覆盖了热词里出现的大部分高频问题。

先看目标文件结构：

text复制ml-notes/
├── 00-Inbox/                # 收集箱
│   └── 临时想法.md
├── 01-Projects/             # 项目笔记
│   └── 房价预测项目.md
├── 10-Areas/                # 领域笔记
│   ├── 线性回归.md
│   ├── 损失函数.md
│   └── 梯度下降.md
├── 90-Attachments/          # 附件统一存放处
│   └── 损失函数对比图.png
└── 99-Meta/                 # 元知识
    └── 学习路线.md

这种目录结构很常见，核心思想是：收集箱放临时内容，领域笔记放沉淀后的知识，附件统一管理，避免在正文目录里混入大量图片文件。 这比单纯按日期建文件夹更符合知识管理的逻辑。

写一篇线性回归的学习笔记，内容可以这样组织：

markdown复制---
tags: [AI/机器学习, AI/线性回归]
date: 2025-01-10
---

# 线性回归学习笔记

## 一、核心概念

线性回归假设目标值 $y$ 与特征 $x$ 之间存在线性关系：

$$
y = wx + b
$$

其中 $w$ 是权重，$b$ 是偏置。

## 二、损失函数推导

常用的损失函数是均方误差（MSE）：

$$
L(w, b) = \frac{1}{n} \sum_{i=1}^{n} (y_i - (w x_i + b))^2
$$

求导后得到梯度更新公式：

$$
w := w - \alpha \frac{\partial L}{\partial w}
$$

## 三、评价指标

| 指标 | 公式 | 含义 |
| --- | --- | --- |
| MSE | $\frac{1}{n}\sum(y_i-\hat{y}_i)^2$ | 预测值与真实值差的平方均值 |
| R² | $1 - \frac{SS_{res}}{SS_{tot}}$ | 模型解释了多少方差 |

## 四、代码实现

\```python
import numpy as np

def linear_regression(X, y, lr=0.01, epochs=1000):
    w = np.zeros(X.shape[1])
    b = 0.0
    for _ in range(epochs):
        y_pred = X @ w + b
        error = y_pred - y
        w -= lr * (X.T @ error) / len(y)
        b -= lr * error.mean()
    return w, b
\```

## 五、延伸阅读

- 看 [[损失函数]] 了解更多损失函数设计
- 对比 [[梯度下降]] 的优化过程
- 相关课程：[Andrew Ng 机器学习](https://www.coursera.org/)

## 六、待办事项

- [ ] 完成练习题 3.2
- [ ] 整理梯度下降的可视化笔记
- [ ] 补充正则化方法对比

注意上面代码块中我用了 \```python 的转义，实际上在 Vault 里直接写三个反引号即可。这个示例包含的知识点非常多，拆开来看：

文首 metadata 区块。用两组三短线包裹的键值对，Obsidian 会把它解析为笔记属性，方便后续用 Dataview 插件查询和筛选。这里的 tags 字段是 YAML 格式的数组，等价于在正文里写 #AI/机器学习，但更规范，便于统一管理。

数学公式。单美元符号 $...$ 表示行内公式，双美元符号 $$...$$ 表示独立行公式。Obsidian 默认支持 KaTeX 数学公式渲染方式。如果公式不显示，通常是语法错误，比如大括号没有配对、反斜杠命令拼写错误，或者公式中有中文标点。需要仔细检查 $$ 是否成对出现。

大括号多行公式。这是另一个高频热词。Markdown 本身没有公式能力，公式渲染靠 LaTeX 语法。多行情况通常用 \begin{cases} 实现，例如：

markdown复制$$
f(x)=
\begin{cases}
1, & x > 0 \\
0, & x = 0 \\
-1, & x < 0
\end{cases}
$$

在 Obsidian 里写好之后，公式会直接渲染成带大括号的分段函数样式。

表格。Markdown 表格用 | 分隔列，:--- 控制对齐，表格本身不支持复杂的合并单元格、单元格内换行。如果你需要把表格复制到 Excel 或 Word，最稳妥的方式是先在 Obsidian 阅读模式中正常显示，然后用浏览器插件导出 HTML，或手动转换为 CSV 格式。直接在编辑模式全选复制，粘贴到 Excel 很容易变成一列。这一点在热词中出现比例很高，说明确实是普遍痛点。

图片引用。假如你插入一张 损失函数对比图.png，Obsidian 在编辑模式下会自动写出行内图片语法：

markdown复制![[损失函数对比图.png]]

这种双链语法是 Obsidian 特有的，Typora 和 GitHub 不认识。为了保证最大兼容性，也可以在设置中把链接格式改为相对路径的 Markdown 语法：

markdown复制![损失函数对比图](../90-Attachments/损失函数对比图.png)

两种方式各有取舍：双链语法在 Obsidian 内使用体验好，会自动维护路径；标准 Markdown 语法在外部工具中兼容性更好。如果图片一直无法显示，优先检查路径是否正确、文件名是否包含特殊空格或中文字符、文件是否真的存在。

双链和标签。笔记中写 [[损失函数]] 可以链接到同仓库的另一篇笔记，即使那篇笔记还不存在，Obsidian 也会创建占位链接。标签写在 metadata 区块或正文中均可。这里需要强调：双链的价值不是笔记软件的一个功能，而是一种写作习惯。 每当你在笔记中提到一个概念，就应该考虑它是否值得单独成为一篇笔记，然后用 [[...]] 链接起来。久而久之，你的知识库会长出一张网络结构，而不是一堆孤立文件。

6. 运行验证与效果检查

把上面这篇笔记保存到 Obsidian 的 Vault 后，需要验证几件事。

第一，公式是否渲染成功。 切换到阅读模式，检查 $$ ... $$ 内容是否显示为数学公式，而不是代码样式。如果公式原样展示，说明 KaTeX 解析失败。第一步可以双击进入源码模式，确认公式块闭合符号没有缺失。

第二，图片是否正常显示。 图片显示为空白或出现"无法加载"提示时，右键检查图片路径，确认附件文件夹的位置是否和仓库设置一致。最有效的排查方法是用系统文件管理器去访问 Vault 目录，确认图片文件真实存在于指定位置。

第三，双链是否跳转。 点击笔记中的 [[损失函数]] 链接，Obsidian 应该能跳到对应笔记。如果点击无效，检查目标笔记的文件名是否完全一致（包括空格和大小写），Obsidian 默认启用了"未创建笔记"的自动处理，但文件名不匹配时仍然会断开。

第四，打开关系图谱。 在左侧边栏打开图谱视图，如果能从"线性回归"节点看到指向"损失函数"和"梯度下降"的连线，说明双链生效。图谱不是必须使用的功能，但它是判断知识网络是否建立起来的直观指标。如果图谱里只有孤立的点，通常是因为你还不习惯在笔记内部写双链。

判定一套工作流是否有效，不应该只看笔记软件用了多少插件，而应该看三个问题：写一条笔记要多少额外操作、找一条旧笔记要多久、离开 Obsidian 之后数据是否依然完全可用。 如果答案是"操作少、检索快、数据裸文件可用"，这套工作流就是健康的。

7. 常见问题与排查思路

下面是 Obsidian + Markdown 实践中出现频率最高的问题，按"现象 → 原因 → 排查 → 解决"给出清单。

其中主题安装失败是 Obsidian 社区里提问量很大的问题。文章热词里提到的 anuppuccin 主题，本身就是社区热门主题之一，下载失败通常不是软件的问题，而是安装渠道不稳定。手动安装的通用步骤是：从主题作者的 GitHub 仓库下载主题压缩包 → 解压到 Vault 根目录下的 .obsidian/themes/主题名/ 文件夹 → 在设置 → 外观 → 主题中切换即可。如果你所在环境无法打开 GitHub，可以尝试更换网络或让朋友帮忙下载后拷贝文件，但不要从不明网盘下载，主题文件本质上是一段可执行的 CSS/JS，来源不可信会带来安全风险。

8. 最佳实践与工程建议

工具用得久不久，不取决于功能列表，而取决于你是否有长期维护的规则。以下建议均来自实际使用经验，适合大多数 Markdown 知识库场景。

第一，用收集箱保护写作流程。 在 Vault 里建一个 00-Inbox 文件夹，任何灵感、碎片、临时摘录先放进去，等有空时再整理到正式目录。不要试图在写笔记的瞬间就规划好它的最终位置，那样会打断思路。Obsidian 的优势是文件可以随时移动，整理可以推迟到"批量处理时间"。

第二，命名规范越早定越好。 笔记文件名会直接显示在链接和关系图谱中，建议统一格式，例如 YYYY-MM-DD-标题.md 或 主题-子主题.md。后一种方式更适合长期知识管理。文件名尽量避免特殊字符，尤其在需要和 GitHub 同步时，?、/、# 等字符会引发路径解析问题。

第三，附件和正文分离。 不要在每篇笔记的同级目录里散落图片，统一使用附件文件夹。设置好 Obsidian 的附件默认路径后，日常拖拽插入图片几乎不需要手动调整路径。如果图片比较多，可以按年份或主题分子目录管理，但不要随意嵌套太深。

第四，标签宁缺毋滥。 新手常见的问题是给每篇笔记打七八个标签，最后标签和文件夹完全重复。更合理的做法是：文件夹承担"分类"职责，标签承担"状态或属性"职责，例如 #待整理、#已完成、#重点。开始阶段保持少量标签，用 Obsidian 自带的搜索功能查询关键词，比强行设计一套复杂标签体系更实用。

第五，同步和备份分开考虑。 Obsidian 官方提供了多端同步服务，也支持通过第三方云盘同步整个 Vault 文件夹。无论用哪种方式，都要注意同步冲突问题：在手机和电脑上同时修改同一篇笔记，可能会产生冲突副本。更稳妥的方案是把同步和备份分开：Vault 本地文件夹用 Git 或云盘做增量备份，多端编辑时避免短时间内在两台设备上改同一篇文件。如果你有一定的编程能力，用 Git 管理 Vault 是一个性价比很高的方案，可以保留每次修改的历史记录，出问题随时回滚。

第六，Markdown 是你的枢纽格式，不是唯一工具。 用 Obsidian 做知识管理，不意味着所有内容都必须写在 Markdown 里。PDF 可以放附件文件夹，Excel 表格可以从 CSV 导入，思维导图可以用插件或单独工具打开。实践中的正确姿势是：让 Markdown 承担"组织和索引"的职责，其他格式作为附件挂在笔记上。 这样既有格式自由，又不破坏知识库的统一性。

9. 总结与后续学习方向

回到最初的问题：Markdown 过时了吗？答案已经很清楚。它不是一种新潮的技术，也未必会让你眼前一亮，但它恰恰因为"朴素"而拥有了极强的生命力。Obsidian 用它的产品形态说明了一件事：当一个工具尊重内容的底层格式，而不是试图把内容锁进自己的私有格式时，这个工具反而更能承载用户长期的知识资产。

如果你现在准备开始搭建自己的 Markdown 工作流，建议从最小闭环做起：先下载 Obsidian，建一个 Vault，写下第一篇带标签和双链的笔记。不要一开始就安装几十个插件，不要沉迷于美化主题。先用两到三周体会"纯文本笔记 + 本地仓库 + 双向链接"这套组合是否适合自己，再把图片管理、公式渲染、表格处理这些细节逐步优化。

下一步值得深入的方向有四个：Obsidian 的模板系统用于统一新笔记结构、Dataview 插件用于从笔记中动态查询数据、Git 同步用于给知识库加版本管理、发布插件用于把部分笔记渲染成网页分享。这四个方向分别对应输入效率、检索效率、安全性和输出效率，是按需进阶，不需要一次性学完。

最后给你一个实用建议：工具始终是辅助，真正有价值的是你持续积累的笔记内容和连接。不要在 Markdown 语法和 Obsidian 插件里消耗过多精力，尽早把时间花在写笔记、整理知识、建立连接上，才是这笔投入回报最高的方式。