Markdown过时了吗？用Obsidian构建本地知识库的完整实践

先给结论：Markdown 并没有过时，至少在多设备写作、知识积累和文档自动化这几类场景里，它依然是最稳定的文本格式。很多人觉得它过时，是因为最近的文档产品把编辑体验做得越来越像网页，表格、数据库、音视频块全塞进一个页面，普通用户完全不需要理解 Markdown 语法。但编辑体验更友好，不等于底层格式真的过时了。真正值得讨论的问题是：在 Markdown 之上，还需要什么工具，才能把它变成可持续维护的个人知识库？我的答案一直放在 Obsidian 里。

Obsidian 是一个本地优先的 Markdown 笔记工具，核心设计是把你所有的笔记保存成普通 .md 文件，一个仓库（Vault）就是一个文件夹。它没有把数据绑定到私有数据库，也没有要求你只能在自己的编辑器里写作，而是通过双链、标签、图谱、插件系统和全文搜索，把一堆原本扁平的 Markdown 文件变成一张可以互相连接的知识网络。这让它非常适合作为学习生产力工具和技术写作的前置编辑环境。

这篇文章会从“Markdown 过时”这个争议切入，把 Obsidian 的部署、Markdown 基础语法、数学公式、图片路径、表格处理、插件自动化、批量任务、资源占用和常见排错整体过一遍。无论你之前用的是 Typora、VS Code 还是云笔记，读完都可以在一个小时内搭出一个可用的本地知识库。

适合读这篇文章的人有三类：一是正在选择 Markdown 编辑器的 Windows、macOS 用户，二是想把笔记系统往结构化、自动化方向升级的长期记录者，三是需要在本地批量整理文档并输出到其他平台的技术从业者。

1. Obsidian 核心能力速览

在开始安装之前，先用一张表把 Obsidian 的能力边界框一下。这张表里没有夸大宣传，只写实际能落地的能力。有了它，后续配置和验收流程不容易跑偏。

表格里最值得记住的是“存储方式”。所有笔记都以 .md 文件存在本地，这是 Obsidian 和 Notion、印象笔记最本质的区别。下面的所有测试都建立在“一个 Vault 就是一个文件夹”这个前提下。

2. Markdown 过时了吗：先搞清楚 Markdown 解决什么问题

这个问题不能简单回答是或否。Markdown 本身是一种轻量标记语法，它解决的问题不是今天有多少人使用，而是内容写到十年后还能不能读、能不能转、能不能被脚本批量处理。

2.1 为什么经常有人说 Markdown 过时

最近几年，以 Notion、飞书文档为代表的一站式文档平台，把写作、数据库、多维表格、音视频、看板全部合并进同一个界面。用户点击按钮就能完成排版，不再需要为了一个加粗效果去记符号。对不接触代码的普通用户来说，看到 #、**、[[ ]] 这些标记确实有学习成本。

但要注意，这些人抗拒的只是语法外壳，不是 Markdown 的能力本身。编辑器变得更智能，不等于底层文本格式就过期了。相反，正因为越来越多的内容被生产出来以后还需要导出、归档、重新利用，Markdown 这种通用纯文本格式反而变得更重要。

2.2 Markdown 解决的真实问题

Markdown 解决的最大问题有三个。

第一是长期可读性。.md 文件就是纯文本，即使 Obsidian 明天停止维护，你依然可以用任意文本编辑器打开所有笔记，内容不会变成一段无法解析的私有数据。

第二是跨工具迁移。同一份文件可以放进 Typora、VS Code、Obsidian、Notion 或者 Linux 终端里阅读，格式不会出现重大偏移。你不需要因为某个云笔记关闭而被迫迁移整个资料库。

第三是程序化处理。纯文本意味着可以用脚本批量改标题、批量插入标签、批量导出结构化数据，这正是它能成为知识库底层格式的根本原因。

这三点叠加在一起，结论就很清晰：Markdown 没有过时，过时的只是“只会用某一个编辑器”的使用方式。语法本身十几年不变，不是落后，而是足够稳定。

2.3 Markdown 与 Typora、Notion 的关系

讨论 Obsidian 时，一定会牵扯出 Typora。Typora 把 Markdown 的编辑体验做成了所见即所得，适合快速写文章和本地排版。Obsidian 更偏向知识管理：除了编辑区，还提供双链、图谱、标签面板、反向链接面板和插件体系。如果只是偶尔写一篇文档，Typora 足够；如果想把日常积累变成长期可调用的知识库，Obsidian 更合适。

两者并不冲突，很多人的真实工作流是：先用 Obsidian 管理笔记素材、建立双链，最后导出 Markdown 到 Typora 或通过 Pandoc 转成 Word 做最终排版。Markdown 能活到今天，正是因为这种“编辑工具随意换、内容格式不换”的通用性。

3. Obsidian 适用场景与使用边界

不是所有内容都适合放进 Obsidian。在使用之前先判断场景，能少走很多弯路。

3.1 适合场景

从实际使用来看，Obsidian 最擅长处理三类内容。

第一类是学习笔记。每天阅读文献、看课程、记录心得，用标签做分类，用双链做内容关联，这是“obsidian 打造学习生产力”这个需求里最典型的使用方式。笔记数量多了以后，反向链接和图谱能把知识片段连成网络。

第二类是技术文档与技术博客草稿。Markdown 本来就是代码社区的标准语言，用 Obsidian 写接口文档、记 API、维护项目 README，后续可以直接平移到博客系统或代码仓库，不需要额外转换。

第三类是本地知识库与个人数据中心。例如把读书笔记、工作复盘、会议记录、项目资料统一放在一个 Vault 中，使用全文搜索和 Dataview 按条件提取。这个场景下，Obsidian 等于一个带双链和插件的本地 Markdown 数据库。

3.2 不适合场景

Obsidian 也有明显边界。多人实时协作不是它的强项，如果需要对同一份文档做高频率协同编辑，在线协作文档会更合适。复杂排版同样不适合，合同、红头文件、宣传海报这类对版式要求极高的内容，直接用 Word 或专业排版工具。另一个极端是，如果用户完全不了解 Markdown，也不愿意学习基础语法，那么 Obsidian 再强大，也不过是一个“不好用的记事本”。

3.3 使用边界与合规提醒

由于 Obsidian 是本地文件优先，它的隐私风险通常低于云笔记，而且不会主动采集、分析用户笔记内容。不过这并不代表可以毫无限制地把任何内容放进 Vault。无论是复制他人文章、保存他人截图，还是把开源项目文档导入私有知识库，都要确保来源合法并获得授权。涉及人脸、声音、版权素材的内容，更需要明确授权边界。批量导入第三方数据之前，先检查数据的来源和使用条款。

4. 本地部署环境准备与前置条件

Obsidian 的部署门槛很低，不需要配置 GPU、CUDA 或复杂运行环境。

4.1 操作系统与硬件要求

Obsidian 是跨平台桌面应用，支持 Windows、macOS、Linux，并提供 iOS、Android 移动端。桌面端基于 Electron，安装方式与常规软件一致。

硬件上，普通 CPU 即可满足要求，不需要独立显卡。内存建议系统有 8GB 以上空闲空间，这样浏览器、编辑器、插件同时运行时不会太紧张。磁盘方面推荐使用 SSD，原因是 Vault 打开时会扫描全部 .md 文件并建立索引，机械硬盘在仓库文件数量较多时，首次启动和搜索会有明显延迟。

4.2 软件与网络前置条件

软件层面只需要有操作系统图形界面。Windows 下载 exe 安装包，macOS 下载 dmg，Linux 桌面环境可以选择 AppImage 或 deb 包。移动端从应用商店安装即可，首次打开后选择创建新 Vault 或连接已有 Vault。

网络环境取决于你的使用方式：完全本地使用可以不联网；如果要用 Obsidian Sync 或第三方同步盘，需要设备能正常访问对应服务。安装完成后，建议先把安装程序、插件市场、同步服务这三条链路确认一遍，避免后续出现“软件能打开，但插件装不了”的问题。

5. 安装部署与启动：从下载到建立第一个知识库

这一章可以直接照着操作。整个过程不需要写代码，也不需要配置任何环境变量。

5.1 下载与安装

打开 Obsidian 官网，选择 Windows、macOS 或 Linux 版本下载。Windows 下安装 exe，macOS 下安装 dmg。安装过程没有额外选项，按默认提示下一步即可。安装完成后先不要导入旧笔记，先创建一个测试 Vault 验证功能。

5.2 创建第一个 Vault

启动 Obsidian 后，按照下面的步骤建库。

1. 在起始界面选择 Create new vault。
2. 输入 Vault name，本文统一用 test-vault。
3. 选择存储位置，建议放在专门目录，例如 ~/Documents/KnowledgeBase/test-vault。
4. 点击 Create 进入主界面。

进入后界面主要有三个区域：左侧文件列表，中间笔记编辑区，右侧可以打开大纲和反向链接面板。到这里，一个最小可运行的 Obsidian 知识库已经建立完成。

5.3 打开已有 Markdown 文件

.md 文件怎么打开，取决于系统文件关联。最快的验证方法是把已有 .md 文件直接拖入 Obsidian 窗口；也可以手动选择 Open folder as vault，把包含 .md 文件的文件夹整体当作一个 Vault 打开。

如果之前系统默认没有关联 Obsidian，Windows 下可以通过右键 -> 打开方式 -> 选择 Obsidian，并勾选“始终使用”。设置完成后，双击 .md 文件会直接进入 Obsidian 编辑页。

如果你在 Linux 下使用，没有默认 .md 关联程序，可以用系统里的任意 Markdown 阅读器预览，也可以用 Obsidian 打开整个文件夹。在 Windows 10 上，除了 Obsidian，还有 Typora、VS Code 等多种 Markdown 编辑器可选，但它们的共同点是都处理同一个 .md 文件，所以不必担心被绑死在一个软件上。

5.4 初始化关键配置

建库后先做两个基础设置。

第一，在 Settings -> Files and Links 中设置默认附件目录。建议在 Vault 根目录下新建 assets 文件夹，并把附件默认路径指向它。这样之后粘贴截图、拖入图片时，所有文件都会集中存放，而不是散落在各笔记目录中。

第二，在 Settings -> Editor 中调整默认编辑模式。Obsidian 提供源码编辑模式和阅读模式。喜欢边写边看的用户可以选择阅读视图作为默认视图；需要精密控制 Markdown 源码时，再切回源码模式。

社区插件可以先不装，等核心功能稳定后再逐个加入。这样可以避免一上来就被插件兼容性问题干扰。

6. Markdown 核心语法与 Obsidian 功能实测

Obsidian 对 Markdown 的渲染遵循 CommonMark 风格，同时加入双链、数学公式、标签等扩展。下面按照实际测试顺序来演示。

6.1 基础语法：标题、列表、引用、粗体与换行

在 Vault 中新建一个 markdown-test.md 文件，输入以下内容。

markdown复制# 一级标题
## 二级标题

这是一个 **加粗** 和 *斜体* 的示例。

- 列表项 A
- 列表项 B

1. 步骤一
2. 步骤二

> 这是一条引用。

输入完成后，切换到阅读视图或打开实时预览，可以看到标题、列表、引用都按照预期渲染。判断标准是：标题字号有层级，列表有缩进，引用块左侧出现竖线。

这里需要重点提醒换行规则。Markdown 中直接按一次回车是软换行，多数场景下不会产生新的段落。CommonMark 要求在一行末尾加两个空格再回车，或者连续两次回车产生一个空行。Obsidian 的默认逻辑与 CommonMark 接近，因此写多段内容时，最稳妥的做法是一个段落结束后空一行，再写下一个段落。

6.2 数学公式：从行内公式到多行大括号公式

Obsidian 内置数学公式渲染能力，不需要额外安装“markdown数学公式插件”。搜索这个词的用户，往往会装一堆插件，其实核心公式渲染是默认自带的。

行内公式使用单个美元符号包裹：

markdown复制质能方程可以写作 $E = mc^2$。

独立公式使用双美元符号包裹：

markdown复制$$
\frac{\partial u}{\partial t} = \alpha \nabla^2 u
$$

多行大括号公式主要用 LaTeX 的 cases 环境。例如分段函数：

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

在 Obsidian 预览中，begin{cases} 会被渲染成左侧大括号、右侧两个条件分支的样式。判断公式渲染成功的方法是：阅读视图中公式不再是源码，而是有上下标、分数线和括号的数学排版。

如果公式没有渲染，优先检查美元符号是否成对，公式是否被包在代码块内部，以及 cases 环境是否写错。不要一遇到公式不显示就跑去装插件，大部分问题都出在语法细节上。

6.3 图片路径与附件管理

图片是 Markdown 笔记中最容易翻车的部分。常见问题包括：从其他笔记软件复制 .md 文件后图片破碎；在 Obsidian 中插入截图后移动文件，图片链接失效。

先把根基打稳。在 Settings -> Files and Links 中设置默认附件目录为 assets，这样粘贴截屏、拖入图片时，文件都会自动保存到该目录，减少散落。接下来要理解图片链接的两种常见写法。

标准 Markdown 图片语法：

markdown复制![](assets/image.png)

Obsidian 原生双链语法：

markdown复制![[image.png]]

标准 Markdown 语法的优点是通用，文件移动到其他工具中也能识别；双链语法的优点是 Obsidian 内部使用体验好，重命名附件时链接会自动更新。如果需要把笔记导出到 Typora、Word 或博客系统，建议优先使用标准 Markdown 图片路径。

判断图片路径是否正确的标准有三个：阅读视图能看到图片；打开 Vault 文件夹，图片文件确实存在于 assets 目录；把整个 Vault 目录复制到另一台电脑后，图片仍然能正常显示。

6.4 标签、双链与图谱：从记录到知识网络

很多人搜索“obsidian 加标签怎么做”，这里给出最常用的两种方式。

第一种是在笔记顶部 frontmatter 中写标签。新建笔记时，在开头加入：

markdown复制---
title: 学习笔记
tags:
  - obsidian
  - markdown
---

第二种是在正文任意位置使用 #标签，例如：

markdown复制这是一条关于 #obsidian 的笔记。

标签的作用是横向分类，而双链的作用是纵向关联。双链语法非常简单：

markdown复制我需要深入理解 [[双向链接]] 的实现方式。

输入 [[ 后，Obsidian 会自动弹出笔记搜索列表，选择已有笔记即可建立链接。在反链面板中，系统会列出所有引用过当前笔记的文件。打开图谱视图后，每篇笔记变成节点，引用关系变成连线。这就是 Obsidian 双链笔记区分于普通 Markdown 编辑器的核心体验。

当双链和标签叠加起来，Obsidian 对“学习生产力”的提升就不只是界面好看，而是让每一篇新笔记都能被已有内容自动关联，形成越来越密的知识网络。

6.5 表格复制、转换与 Excel 联动

Markdown 表格写起来直观，但最常出现的问题是复制到 Excel 后带竖线，或者直接被拆成多列。原因在于 Excel 默认识别的是制表符，不是 Markdown 表格里的竖线和空格。

Markdown 表格示例：

markdown复制| 功能   | 支持情况 |
| ------ | -------- |
| 标题   | 支持     |
| 公式   | 支持     |
| 图片   | 支持     |

这里提供一个 Python 处理思路：读取 Markdown 文件，提取所有表格行，清理竖线分隔符后写出 CSV。这是知识库批量处理场景里很实用的脚本模板。

python复制import re
import csv

with open("note.md", encoding="utf-8") as f:
    lines = f.readlines()

rows = []
for line in lines:
    line = line.strip()
    if not line.startswith("|"):
        continue
    # 跳过分隔线行
    if re.match(r"^\|[\s:|-]+\|$", line):
        continue
    cells = [cell.strip() for cell in line.strip("|").split("|")]
    rows.append(cells)

with open("output.csv", "w", newline="", encoding="utf-8-sig") as f:
    writer = csv.writer(f)
    writer.writerows(rows)

代码的作用是把 note.md 中所有 Markdown 表格写入 output.csv。使用 utf-8-sig 编码，是为了让 Excel 打开 CSV 时中文不乱码。如果只需要转换某一个表格，可以在循环中增加表格编号过滤条件。

7. 插件生态与自动化工作流

Obsidian 的插件生态，是它从“Markdown 编辑器”变成“知识库平台”的关键。这里重点演示 Templater、Dataview 以及脚本批处理。

7.1 核心插件：Templater 与 Dataview

Templater 可以理解为“模板引擎”。新建笔记时自动插入日期、标题、以及根据条件生成的内容。一个最小模板长这样：

text复制---
date: <% tp.date.now("YYYY-MM-DD") %>
tags: [obsidian, 笔记]
---

# <% tp.file.title %>

套用这个模板创建笔记时，日期会被自动填成当前日期，文件名会替换到标题中。这种能力的价值在批量建笔记时最明显：每天开一篇日志、每读一本书建一个笔记页，都不用手动填写重复字段。

Dataview 则把 Markdown 文件里的 frontmatter 当成数据库字段来查询。例如，把所有带有 tags: [读书] 的笔记列出来：

dataview复制list from #读书

这条查询会根据标签自动生成笔记目录。Dataview 适合资源库管理，但重查询在大型 Vault 中会拖慢渲染速度，所以实际使用时要控制查询范围，不要在一个页面里嵌套多个全库查询。

7.2 批量任务：用脚本批量处理 Markdown 文件

先给结论：Obsidian 支持批量任务，但不是靠一个按钮，而是靠脚本把 .md 文件当作普通文本处理。内核思路是遍历 Vault 目录、读取文件、修改内容、写回原路径。

例如，批量给所有还没有 tags 字段的笔记加一个统一标签：

python复制import os
import glob

vault_dir = "./vault"
tag_to_add = "obsidian"

for path in glob.glob(os.path.join(vault_dir, "**/*.md"), recursive=True):
    with open(path, encoding="utf-8") as f:
        content = f.read()

    if "tags:" in content:
        continue

    new_content = f"---\ntags: [{tag_to_add}]\n---\n\n" + content

    with open(path, "w", encoding="utf-8") as f:
        f.write(new_content)

运行后，脚本会检查每个 .md 文件是否已经包含 tags: 字段，如果没有，就在文件开头插入 frontmatter。这一步会让普通笔记升级成可被 Dataview 查询的结构化文件。

另一个常见需求是把 CSV 数据批量导入 Vault。思路是读取 CSV 每一行，把标题和内容生成独立的 .md 文件。执行前，要先在临时目录测试脚本，确认文件命名、编码、目录结构都正确，再做全量操作。

批量任务有一个安全底线：先备份 Vault，再执行脚本；脚本要输出日志，记录成功和失败；遇到权限不足、文件占用、编码异常时立即停止，不要覆盖式写回。

7.3 与外部工具联动的自动化方向

本地 Markdown 的另一个优势是很容易被外部自动化流程读取。比如“Markdown 转 Word”这个需求，可以在 Obsidian 里完成内容写作，再把 .md 文件交给 Pandoc、在线转换工具或自动化平台做格式转换。Obsidian 负责内容，外部工具负责渲染，这个拆分比直接在一款编辑器里反复排版更适合频繁改稿的写作流程。

“飞书连接 Obsidian”这类需求也一样，常见的替代思路是：从 Obsidian 导出 Markdown，再通过脚本或平台导入能力写入飞书云文档；反过来，从飞书导出的文档可以转换成 .md 放回本地 Vault。由于 Obsidian 没有官方公开 API，接线方式完全取决于当前所用平台的能力，需要按具体接口调整。

更稳妥的做法是，不要强求两个平台实时同步，优先保证本地 .md 是唯一内容源，其他平台只做最终展示和分发。这样即使第三方平台接口发生变化，原始内容也不会受影响。

7.4 本地接口调用通用模板

如果你确实需要从外部程序写入 Obsidian，可以依赖社区插件提供的本地接口。不同插件的端口、鉴权、路径不统一，使用前先看插件文档。下面只给一个调用形式示例，假设本地接口地址为 127.0.0.1:27123。

bash复制curl -X PUT "http://127.0.0.1:27123/vault/notes/hello.md" \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -H "Content-Type: text/markdown" \
  -d "# Hello
由接口写入的笔记。"

这种接口适合做自动化脚本的最后一跳：比如把网页剪藏、CSV 数据、定时任务抓取的内容直接推进 Vault。但要注意，它不是官方统一 API，不同插件的实际路径和认证方式可能完全不同。批量写入时，先用一条测试数据验证接口的鉴权、目录路径和编码，再推全量数据。

8. 资源占用与性能观察

Markdown 文件本身极其轻量，几千行的文档也只有几十 KB 大小。真正影响 Obsidian 性能的因素有三个：Vault 内文件数量、插件数量、单次渲染内容大小。

文件数量影响启动时的索引时间和全文搜索速度。插件数量影响编辑时的实时计算成本，尤其是 Dataview 这类查询插件。单次渲染内容则与长笔记和大量大图相关，一篇几千行并插入几十张原图的笔记，滚动预览时可能出现卡顿。

观察资源占用的方法很简单：Windows 打开任务管理器，macOS 打开活动监视器，按 CPU 和内存排序。第一次打开大型 Vault 时，Obsidian 会扫描文件、建立反向链接索引，此时 CPU 和内存会出现一次峰值。峰值回落后保持稳定，说明索引已经完成。如果内存持续上涨且不回落，优先怀疑某个插件存在资源占用问题，或插件版本与当前 Obsidian 核心版本不兼容。

降低占用可以按以下顺序操作：

1. 关闭不用的第三方插件。
2. 减少 Dataview 的全库范围重查询。
3. 图片压缩后再放入 assets 目录。
4. 将大仓库按用途拆分为多个 Vault。
5. 保持 Obsidian 和插件版本相对最新，避开已知的老版本性能问题。

如果你完全使用本地文件、不开启云同步，Obsidian 的资源占用通常可以保持在一个较低水平。移动端同步大型仓库时，建议先清理附件和失效链接，降低索引消耗。

9. 常见问题与排查方法

下面这些问题，是 Markdown 用户和 Obsidian 用户最容易遇到的。按“现象、原因、排查、解决”四列整理。

排查 Obsidian 问题，第一步永远是看版本号。Help -> About 里的版本信息，能直接判断当前版本是否过旧。遇到插件崩溃，新建一个空 Vault，把原 Vault 的文件分批复制过去，可以定位到具体是哪个文件或配置导致问题。

10. 最佳实践与使用建议

如果准备从零开始使用 Obsidian，不要一上来就把所有旧笔记全部导入。先建一个测试 Vault，把基础语法、数学公式、图片路径、双链、标签、模板这几个功能跑一遍，确认稳定后再迁移存量资料。这样出问题时，业务数据不会受影响。

目录结构建议保持简单。过度分类会增加维护成本，文件夹适合粗粒度划分，细粒度关联交给标签和双链。一个常见的 Vault 结构如下：

text复制vault/
├─ assets/          # 图片和附件
├─ daily/           # 日记和日常记录
├─ notes/           # 独立笔记
├─ projects/        # 项目文件
└─ templates/       # Templater 模板

模板和元数据是知识库自动化的基础。每篇笔记尽量带 frontmatter，哪怕只有标题、日期、标签三个字段。这样后续用 Dataview 做筛选、用脚本做批量处理时，就有稳定的字段可以依赖。

备份是本地知识库最容易忽略也最重要的一环。推荐保留两处备份：一份本地同步目录，一份外部存储或云盘。如果使用 Git，要避免把敏感个人信息大量放进公开仓库，并注意 .md 文件里可能包含密钥、内部链接或隐私内容。

批量操作之前，先做逻辑检查和合规检查。脚本替换前，先在临时目录测试；加入统计和错误日志；遇到异常就停止。所有涉及他人内容的导入、导出和分享，都要确认授权。不要未经允许把他人未公开的截图、文章、人脸或声音素材放入知识库，更不要直接上传到公开网络。

同步方案也要提前考虑。使用 Obsidian Sync 或第三方同步盘时，多设备同时编辑一个 Vault 可能出现文件冲突。养成一个习惯：在切换设备前先完成当前设备上的修改，再等待同步完成；冲突文件出现后，优先保留手动合并版本。

11. 总结与下一步

回到开头的问题：Markdown 过时了吗？答案很明确：没有。Markdown 作为长期存储、跨工具迁移、程序化处理的文本格式，依旧是最适合个人知识库的底层格式之一；而 Obsidian 的存在，正是这套逻辑在双链、本地检索、插件扩展上的完整落地。

最值得先验证的三个点：内置数学公式能否满足日常需要；图片路径更换后链接是否依然稳定；双链和图谱能不能把散装笔记串成知识网络。最容易踩的坑是附件路径和插件版本兼容，建议先用空 Vault 测试再迁移旧数据。

后续可以沿着两个方向继续扩展。一是把 Templater、Dataview 和 Python 脚本组合起来，做日志自动生成、读书笔记汇总、批量标签清理等自动化任务；二是把 Obsidian 作为内容源，通过 Pandoc、自动化平台把 Markdown 转成 Word、PDF 或在线文档，形成一套“本地积累、按需发布”的知识工作流。建议收藏备用，真正上手时按文章顺序跑一遍。