Obsidian CLI 来了

如果说 Obsidian 过去最重要的价值，是把笔记变成本地 Markdown 文件和双向链接网络，那么 Obsidian CLI 的出现，就让这套知识库开始真正接入自动化流程。

CLI 是 Command Line Interface，也就是命令行界面。

过去操作 Obsidian，大多数动作都要打开软件，用鼠标和键盘完成。打开笔记、搜索资料、追加内容、查看反向链接、管理标签、统计任务，这些都发生在 Obsidian 的图形界面里。

Obsidian CLI 改变的是入口。

它允许用户在终端里控制 Obsidian。通过命令可以读取笔记、创建笔记、搜索 Vault(知识库文件夹)、追加内容、查看任务、列出标签、检查反向链接，也可以执行一些面向插件和主题开发的调试命令。

这听起来像是程序员功能，但它真正影响的是创作方式。

为什么创作者要关心 CLI

创作者最缺的不是一个更复杂的软件，而是一条更顺的内容生产链路。

一篇文章从想法到发布，中间其实有很多重复动作：

找以前写过的相关内容
把零散素材合并成草稿
给文章补摘要、标签和标题
检查引用和双向链接
把正文整理成适合发布的平台格式
记录这篇内容后续还能延展成哪些选题

这些动作手动做当然可以，但时间久了会很耗精力。Obsidian CLI 的意义，就是让这些动作可以被命令、脚本和 AI 工具接管一部分。

也就是说，Obsidian 不再只是一个打开来写字的软件。它开始变成一个可以被外部工具调用的本地知识工作台。

怎么开启 Obsidian CLI

现在建议直接使用最新版 Obsidian 安装器。官方文档要求使用 Obsidian 1.12 系列安装器，当前推荐使用 1.12.7 或更新版本；Windows 上则明确需要 1.12.7+ 安装器，因为新版安装器已经改进了 CLI 的二进制文件和终端交互速度。

开启方式很简单：

更新 Obsidian 到最新版安装器。

打开 Obsidian。
进入 Settings -> General。
开启 Command line interface。

完成 CLI 注册。

这里的"注册"不是注册账号，也不是登录 Obsidian 账号，而是让系统认识 obsidian 这个命令。

不同系统背后做的事情不一样：

Windows：Obsidian 1.12.7+ 安装器会在安装目录里提供 Obsidian.com 终端转发器。开启 CLI 后，Obsidian 会把它注册到当前用户的 PATH 里。注册完成后，一定要重新打开 PowerShell、Windows Terminal 或 CMD。
macOS：Obsidian 会在 /usr/local/bin/obsidian 创建一个软链接，指向 App 内置的 CLI 程序。这一步可能会弹出系统权限确认，需要输入管理员密码。
Linux：Obsidian 会把 CLI 程序复制到 ~/.local/bin/obsidian。如果终端还是找不到命令，要确认 ~/.local/bin 是否已经加入 PATH。

重启终端，让 PATH 配置生效。

然后在新的终端里先执行：

shell 复制代码

obsidian version

如果能看到版本号，再执行：

shell 复制代码

obsidian help

如果能看到命令列表，就说明 CLI 已经可用。

如果命令还是不可用，可以回到 Settings -> General，把 Command line interface 关掉再打开一次，让 Obsidian 重新注册。注册后仍然要重启终端。

这里有一个细节：Obsidian CLI 需要 Obsidian 桌面端运行。官方文档说明，如果 Obsidian 没有运行，第一次执行命令会先启动 Obsidian。它不是一个完全脱离桌面端的后台服务。

最常用的几个命令

刚开始不用记太多命令，先记住几类就够了。

1. 搜索知识库

shell 复制代码

obsidian search query="AI 工作流"

如果想看匹配行的上下文，可以用：

shell 复制代码

obsidian search:context query="AI 工作流"

这对写文章很有用。比如要写一篇关于 AI 创作系统的文章，可以先搜整个 Vault(知识库文件夹)里所有提到这个主题的笔记，再决定哪些内容可以复用。

2. 创建一篇新笔记

shell 复制代码

obsidian create name="Obsidian CLI 选题" content="# Obsidian CLI 选题\n\n这里记录文章思路。"

也可以指定路径：

shell 复制代码

obsidian create path="40 微信公众号/20 草稿/新文章草稿.md" content="# 新文章草稿"

如果已经有模板，还可以用模板创建：

shell 复制代码

obsidian create name="新文章草稿" template="文章模板"

这类命令适合把固定写作流程标准化。比如每次新建公众号草稿时，都自动带上标题、摘要、标签、状态和参考资料区。

3. 读取和追加内容

shell 复制代码

obsidian read file="从 Notion 到 Obsidian"

shell 复制代码

obsidian append file="从 Notion 到 Obsidian" content="\n\n这里补充一段新的想法。"

读取和追加是最适合接入 AI 工具的能力。AI 可以先读取文章草稿，再按写作要求补一个结尾、生成摘要、整理标题，或者把某一段改成更适合公众号阅读的表达。

4. 查看链接关系

这组命令最容易看懵，因为它们都和链接有关，但看的方向不一样。

先记住一句话：

backlinks 看谁指向我，links 看我指向谁，unresolved 看整个库里哪些链接还没有对应文件。

比如要检查这篇文章：

shell 复制代码

obsidian backlinks path="40 微信公众号/40 已发布/Obsidian CLI 来了.md" counts

这条命令看的不是文章里写了哪些链接，而是反过来看：知识库里有哪些笔记提到了 Obsidian CLI 来了。

backlinks 就是反向链接。它适合回答这个问题：

这篇文章有没有被其他笔记引用？

后面的 counts 表示把引用次数也带出来。如果同一篇笔记里多次链接到它，输出里能看到数量。

再看出链：

shell 复制代码

obsidian links path="40 微信公众号/40 已发布/Obsidian CLI 来了.md"

links 看的是这篇文章主动链接到了哪些笔记。

比如一篇文章里链接了 [[AI 工作流]]、[[写作素材]]、[[Obsidian CLI]] 这些笔记，它们就属于出链。

它适合回答这个问题：

这篇文章接到了哪些已有内容？

如果只想知道出链数量，可以加 total：

shell 复制代码

obsidian links path="40 微信公众号/40 已发布/Obsidian CLI 来了.md" total

最后看未解析链接：

shell 复制代码

obsidian unresolved counts

这条命令和前两条不一样。它不是检查某一篇文章，而是检查整个 Vault(知识库文件夹)。

unresolved 会列出那些已经写成 [[某个标题]]，但当前知识库里还没有对应 .md 文件的链接。

这类链接在 Obsidian 里通常会显示成还没创建的笔记。它不一定是错误，也可能是提前留下的选题或概念坑。

后面的 counts 表示统计每个未解析链接出现了多少次。如果想看这些未解析链接分别出现在哪些文件里，可以用：

shell 复制代码

obsidian unresolved counts verbose

如果终端输出是：

text 复制代码

No unresolved links found.

这反而是好结果，说明当前 Vault(知识库文件夹)里没有写了链接但还没创建文件的笔记。也就是说，现有的 [[双向链接]] 都能找到对应内容。

这条命令适合回答这个问题：

我的知识库里有哪些链接还没有变成真实笔记？

这几条命令对应的是 Obsidian 的核心优势：双向链接和知识网络。

写作时最怕内容孤立。文章写完了，但它和以前的笔记没有连接，后面就很难重新被用上。

所以这三条命令可以形成一个很实用的检查流程：

先用 links 看这篇文章有没有主动接到已有笔记。再用 backlinks 看有没有其他内容反过来引用它。最后用 unresolved counts verbose 看整个库里还有哪些链接只是占位，还没有真正沉淀成笔记。

这样一篇文章就不是孤零零地放在文件夹里，而是被接进了整个知识网络。

5. 管理任务和标签

shell 复制代码

obsidian tasks todo

如果输出是：

text 复制代码

No tasks found.

意思是当前 Vault(知识库文件夹)里没有未完成任务。这里的任务通常指 Markdown 里的待办项，比如 - [ ] 整理 Obsidian CLI 截图。如果笔记里没有写这种待办，看到这个结果很正常。

shell 复制代码

obsidian tags counts

tags counts 会统计每个标签出现了多少次。比如下面这组结果里，#知识管理 和 #Obsidian 出现次数最多，说明当前知识库的内容重心主要集中在这两个方向。

text 复制代码

#知识管理       9
#Obsidian       9
#demo           3
#Markdown       3
#AI             2
#Codex          2

这个命令适合用来判断内容池的主题分布。写公众号时，它能显示哪些方向已经有素材，哪些标签只是偶尔出现，还没有形成稳定主线。

如果选题、写作计划、发布状态都放在 Obsidian 里，tasks todo 能看出还有哪些任务没做，tags counts 能看出哪些主题最常被记录。

它和 Codex 能怎么配合

Obsidian CLI 真正有想象力的地方，是它可以和 Codex 这类本地 AI 编程/写作助手配合。

以前让 AI 辅助写文章，通常要先把内容复制给它。写完以后，再复制回来。这个流程很割裂。

如果资料本来就在 Obsidian 里，而 Obsidian 又能被 CLI 调用，流程就会自然很多：

Codex 先搜索 Vault(知识库文件夹)，找到相关笔记。
读取文章草稿和关联素材。
根据写作要求补正文、改标题、写摘要。
创建新的概念卡片或 demo 文件。
检查哪些双向链接没有落到真实文件。
最后把文章整理成适合发布的平台格式。

这个过程中，AI 不只是站在知识库外面给建议，而是在本地文件结构里协作。

比如继续写 Obsidian CLI 相关内容时，Codex 可以先搜索知识库里和 AI 工作流、写作素材、双向链接相关的笔记，再把新文章接到这些已有主题上。读者看到的是一篇文章，背后其实是一整套本地素材网络在支撑。

这就是本地 Markdown 的价值。

资料不是被锁在某个在线产品里，而是可以被终端、脚本、Git、Obsidian 和 AI 工具共同处理。

不要把判断交给工具

Obsidian CLI 很强，但它不是魔法。

它能提高效率，不能替创作者判断什么内容值得写。它能创建笔记，不能替创作者决定一篇文章的观点是否成立。它能检查链接，不能保证知识结构本身就有价值。

更重要的是，CLI 可以改文件、移动文件、删除文件。越是自动化，越要注意备份。

我的建议是：

重要 Vault(知识库文件夹) 用 Git 管理版本。
大批量操作前先提交一次。
不熟悉的命令先用测试笔记验证。
删除、移动、覆盖这类动作不要直接交给陌生脚本。
AI 可以辅助整理，但最终发布前一定自己通读一遍。

为什么这是一个重要变化

Obsidian CLI 的重点不在于多了几个命令。

它真正带来的变化，是把 Obsidian 从"写作软件"往"本地知识操作系统"推进了一步。

过去，知识库主要解决保存问题：资料放在哪里，怎么分类，怎么搜索。

现在，知识库还要解决流动问题：资料能不能被自动化流程调用，能不能被 AI 理解和重组，能不能在下一篇文章、下一个项目、下一次复盘里继续发挥作用。

这也是 Obsidian 值得被更认真看待的原因。

它不是 Notion 的平替，也不是单纯的 Markdown 编辑器。它的价值在于，把本地文件、双向链接、图谱、插件、CLI、AI 工具连接到一起，形成一套更长期、更开放的创作系统。

对于普通用户，Obsidian CLI 可能暂时不是每天都要用的功能。

但对于长期写作、做内容、做知识管理、做 AI 工作流的人来说，它是一个很重要的信号：

以后的个人知识库，不应该只是给人看的页面。

它还应该是能被工具调用、能被自动化处理、能和 AI 一起工作的本地资产。

参考资料

Obsidian CLI 官方文档：https://obsidian.md/help/cli
Obsidian 1.12 Desktop 发布记录：https://obsidian.md/changelog/2026-02-27-desktop-v1.12.4/
Obsidian 1.12.7 Desktop 发布记录：https://obsidian.md/changelog/2026-03-23-desktop-v1.12.7/