如果说 Obsidian 过去最重要的价值，是把笔记变成本地 Markdown 文件和双向链接网络，那么 Obsidian CLI 的出现，就让这套知识库开始真正接入自动化流程。
CLI 是 Command Line Interface，也就是命令行界面。
过去操作 Obsidian，大多数动作都要打开软件，用鼠标和键盘完成。打开笔记、搜索资料、追加内容、查看反向链接、管理标签、统计任务，这些都发生在 Obsidian 的图形界面里。
Obsidian CLI 改变的是入口。
它允许用户在终端里控制 Obsidian。通过命令可以读取笔记、创建笔记、搜索 Vault(知识库文件夹)、追加内容、查看任务、列出标签、检查反向链接，也可以执行一些面向插件和主题开发的调试命令。
这听起来像是程序员功能，但它真正影响的是创作方式。
创作者最缺的不是一个更复杂的软件，而是一条更顺的内容生产链路。
一篇文章从想法到发布，中间其实有很多重复动作：
这些动作手动做当然可以，但时间久了会很耗精力。Obsidian CLI 的意义，就是让这些动作可以被命令、脚本和 AI 工具接管一部分。
也就是说，Obsidian 不再只是一个打开来写字的软件。它开始变成一个可以被外部工具调用的本地知识工作台。
现在建议直接使用最新版 Obsidian 安装器。官方文档要求使用 Obsidian 1.12 系列安装器，当前推荐使用 1.12.7 或更新版本；Windows 上则明确需要 1.12.7+ 安装器，因为新版安装器已经改进了 CLI 的二进制文件和终端交互速度。
开启方式很简单：
Settings -> General。Command line interface。
这里的“注册”不是注册账号，也不是登录 Obsidian 账号，而是让系统认识 obsidian 这个命令。
不同系统背后做的事情不一样：
Obsidian.com 终端转发器。开启 CLI 后，Obsidian 会把它注册到当前用户的 PATH 里。注册完成后，一定要重新打开 PowerShell、Windows Terminal 或 CMD。/usr/local/bin/obsidian 创建一个软链接，指向 App 内置的 CLI 程序。这一步可能会弹出系统权限确认，需要输入管理员密码。~/.local/bin/obsidian。如果终端还是找不到命令，要确认 ~/.local/bin 是否已经加入 PATH。然后在新的终端里先执行：
obsidian version
如果能看到版本号，再执行：
obsidian help
如果能看到命令列表，就说明 CLI 已经可用。
如果命令还是不可用，可以回到 Settings -> General，把 Command line interface 关掉再打开一次，让 Obsidian 重新注册。注册后仍然要重启终端。
这里有一个细节：Obsidian CLI 需要 Obsidian 桌面端运行。官方文档说明，如果 Obsidian 没有运行，第一次执行命令会先启动 Obsidian。它不是一个完全脱离桌面端的后台服务。
刚开始不用记太多命令，先记住几类就够了。
obsidian search query="AI 工作流"
如果想看匹配行的上下文，可以用：
obsidian search:context query="AI 工作流"
这对写文章很有用。比如要写一篇关于 AI 创作系统的文章，可以先搜整个 Vault(知识库文件夹)里所有提到这个主题的笔记，再决定哪些内容可以复用。
obsidian create name="Obsidian CLI 选题" content="# Obsidian CLI 选题\n\n这里记录文章思路。"
也可以指定路径：
obsidian create path="40 微信公众号/20 草稿/新文章草稿.md" content="# 新文章草稿"
如果已经有模板，还可以用模板创建：
obsidian create name="新文章草稿" template="文章模板"
这类命令适合把固定写作流程标准化。比如每次新建公众号草稿时，都自动带上标题、摘要、标签、状态和参考资料区。
obsidian read file="从 Notion 到 Obsidian"
obsidian append file="从 Notion 到 Obsidian" content="\n\n这里补充一段新的想法。"
读取和追加是最适合接入 AI 工具的能力。AI 可以先读取文章草稿，再按写作要求补一个结尾、生成摘要、整理标题，或者把某一段改成更适合公众号阅读的表达。
这组命令最容易看懵，因为它们都和链接有关，但看的方向不一样。
先记住一句话：
backlinks 看谁指向我，links 看我指向谁，unresolved 看整个库里哪些链接还没有对应文件。
比如要检查这篇文章：
obsidian backlinks path="40 微信公众号/40 已发布/Obsidian CLI 来了.md" counts
这条命令看的不是文章里写了哪些链接，而是反过来看：知识库里有哪些笔记提到了 Obsidian CLI 来了。
backlinks 就是反向链接。它适合回答这个问题：
这篇文章有没有被其他笔记引用？
后面的 counts 表示把引用次数也带出来。如果同一篇笔记里多次链接到它，输出里能看到数量。
再看出链：
obsidian links path="40 微信公众号/40 已发布/Obsidian CLI 来了.md"
links 看的是这篇文章主动链接到了哪些笔记。
比如一篇文章里链接了 [[AI 工作流]]、[[写作素材]]、[[Obsidian CLI]] 这些笔记，它们就属于出链。
它适合回答这个问题：
这篇文章接到了哪些已有内容？
如果只想知道出链数量，可以加 total：
obsidian links path="40 微信公众号/40 已发布/Obsidian CLI 来了.md" total
最后看未解析链接：
obsidian unresolved counts
这条命令和前两条不一样。它不是检查某一篇文章，而是检查整个 Vault(知识库文件夹)。
unresolved 会列出那些已经写成 [[某个标题]]，但当前知识库里还没有对应 .md 文件的链接。
这类链接在 Obsidian 里通常会显示成还没创建的笔记。它不一定是错误，也可能是提前留下的选题或概念坑。
后面的 counts 表示统计每个未解析链接出现了多少次。如果想看这些未解析链接分别出现在哪些文件里，可以用：
obsidian unresolved counts verbose
如果终端输出是：
No unresolved links found.
这反而是好结果，说明当前 Vault(知识库文件夹)里没有写了链接但还没创建文件的笔记。也就是说，现有的 [[双向链接]] 都能找到对应内容。
这条命令适合回答这个问题：
我的知识库里有哪些链接还没有变成真实笔记？
这几条命令对应的是 Obsidian 的核心优势：双向链接和知识网络。
写作时最怕内容孤立。文章写完了，但它和以前的笔记没有连接，后面就很难重新被用上。
所以这三条命令可以形成一个很实用的检查流程：
先用 links 看这篇文章有没有主动接到已有笔记。再用 backlinks 看有没有其他内容反过来引用它。最后用 unresolved counts verbose 看整个库里还有哪些链接只是占位，还没有真正沉淀成笔记。
这样一篇文章就不是孤零零地放在文件夹里，而是被接进了整个知识网络。
obsidian tasks todo
如果输出是：
No tasks found.
意思是当前 Vault(知识库文件夹)里没有未完成任务。这里的任务通常指 Markdown 里的待办项，比如 - [ ] 整理 Obsidian CLI 截图。如果笔记里没有写这种待办，看到这个结果很正常。
obsidian tags counts
tags counts 会统计每个标签出现了多少次。比如下面这组结果里，#知识管理 和 #Obsidian 出现次数最多，说明当前知识库的内容重心主要集中在这两个方向。
#知识管理 9
#Obsidian 9
#demo 3
#Markdown 3
#AI 2
#Codex 2
这个命令适合用来判断内容池的主题分布。写公众号时，它能显示哪些方向已经有素材，哪些标签只是偶尔出现，还没有形成稳定主线。
如果选题、写作计划、发布状态都放在 Obsidian 里，tasks todo 能看出还有哪些任务没做，tags counts 能看出哪些主题最常被记录。
Obsidian CLI 真正有想象力的地方，是它可以和 Codex 这类本地 AI 编程/写作助手配合。
以前让 AI 辅助写文章，通常要先把内容复制给它。写完以后，再复制回来。这个流程很割裂。
如果资料本来就在 Obsidian 里，而 Obsidian 又能被 CLI 调用，流程就会自然很多：
这个过程中，AI 不只是站在知识库外面给建议，而是在本地文件结构里协作。
比如继续写 Obsidian CLI 相关内容时，Codex 可以先搜索知识库里和 AI 工作流、写作素材、双向链接相关的笔记，再把新文章接到这些已有主题上。读者看到的是一篇文章，背后其实是一整套本地素材网络在支撑。
这就是本地 Markdown 的价值。
资料不是被锁在某个在线产品里，而是可以被终端、脚本、Git、Obsidian 和 AI 工具共同处理。
Obsidian CLI 很强，但它不是魔法。
它能提高效率，不能替创作者判断什么内容值得写。它能创建笔记，不能替创作者决定一篇文章的观点是否成立。它能检查链接，不能保证知识结构本身就有价值。
更重要的是，CLI 可以改文件、移动文件、删除文件。越是自动化，越要注意备份。
我的建议是：
Obsidian CLI 的重点不在于多了几个命令。
它真正带来的变化，是把 Obsidian 从“写作软件”往“本地知识操作系统”推进了一步。
过去，知识库主要解决保存问题：资料放在哪里，怎么分类，怎么搜索。
现在，知识库还要解决流动问题：资料能不能被自动化流程调用，能不能被 AI 理解和重组，能不能在下一篇文章、下一个项目、下一次复盘里继续发挥作用。
这也是 Obsidian 值得被更认真看待的原因。
它不是 Notion 的平替，也不是单纯的 Markdown 编辑器。它的价值在于，把本地文件、双向链接、图谱、插件、CLI、AI 工具连接到一起，形成一套更长期、更开放的创作系统。
对于普通用户，Obsidian CLI 可能暂时不是每天都要用的功能。
但对于长期写作、做内容、做知识管理、做 AI 工作流的人来说，它是一个很重要的信号：
以后的个人知识库，不应该只是给人看的页面。
它还应该是能被工具调用、能被自动化处理、能和 AI 一起工作的本地资产。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。