Codex 使用 Obsidian CLI

AI 帮你写 Obsidian 草稿时，真正卡人的不是生成正文。

更常见的问题是：AI 读不到你的历史笔记、旧文章、素材目录和链接关系。你只能手动复制一堆资料给它，再把生成结果复制回 Obsidian。

Obsidian CLI 解决的就是这个入口问题。

GUI 是 Graphical User Interface，也就是图形界面。它适合人用鼠标和键盘打开、阅读和编辑。

CLI 是 Command Line Interface，也就是命令行接口。它更适合 AI 和脚本按稳定命令调用。

以前 Obsidian 主要通过 GUI 服务人。人打开窗口、点目录、看链接、写内容。

有了 CLI 后，Codex 这类 AI 工具可以用命令搜索笔记、读取文件、创建新文件、追加内容、检查链接和查看任务。

这件事真正有意思的地方，不是多了几条给人敲的命令，而是 AI 可以开始使用 Obsidian 里的本地知识库。

过去让 AI 辅助写作，常见流程是这样：

1
2
3
4
5
6

打开 Obsidian
找到相关笔记
复制内容给 AI
AI 输出草稿
复制回 Obsidian
再整理标题、标签、链接和目录

这套流程能用，但中间要靠人工搬资料。你要自己把相关笔记、历史文章、写作要求、标题、标签和链接关系复制给 AI。

资料少的时候问题不大。笔记多了以后，成本会迅速上来。目录越深，链接越多，越容易漏掉相关材料。

Obsidian CLI 接入 Codex 后，流程变了。

把 Obsidian CLI 做成 Skill 后，流程应该变成这样：

1
2
3
4
5
6
7
8

告诉 Codex 目标、资料范围、输出物，以及哪些事可以直接做、哪些事必须先问你
Codex 加载 Obsidian CLI Skill
Codex 确认当前 Vault，也就是知识库文件夹
Codex 搜索草稿目录和已发布目录
Codex 读取相关笔记和历史文章
Codex 生成大纲、素材清单或草稿
Codex 按规则写回 Obsidian
人工通读、判断观点并发布

两套流程最大的差别是：过去由人负责找资料和搬资料；现在由人负责目标、判断和发布责任，Codex 负责搜索、读取、写回和检查。

Codex 可以先搜索 Obsidian 的 Vault，也就是知识库文件夹。这个文件夹里包括笔记、附件、链接关系和属性信息。

找到相关材料后，Codex 再读取关键笔记，理解已有内容。接着创建草稿、追加段落、补充属性、检查链接，最后把结果写回 Obsidian。

也就是说，AI 不再只是站在知识库外面给建议。

它可以进入本地知识库，按文件结构和知识网络一起工作。

不是插件，而是一条通道

很多人听到“Codex 使用 Obsidian”，第一反应是要装插件。

重点不在插件。

重点是 Obsidian 已经有了官方 CLI，也就是官方命令行接口。只要系统里能执行 obsidian 命令，Codex 就可以像调用其他命令一样调用它。

这条通道对人和 AI 的意义不一样。

对人来说，GUI，也就是图形界面，已经足够好用。人可以点目录、看预览、拖文件、改标题。

对 AI 来说，直接操作 GUI 不稳定，也不适合长期自动化。AI 更适合调用清晰、可重复、可记录的命令。CLI，也就是命令行接口，正好把 Obsidian 的搜索、读取、写入和检查能力暴露出来。

所以这篇文章里说 Obsidian CLI，不是让读者改成命令行用户。

它真正解决的是：让 Codex 能稳定调用 Obsidian。

开始前先确认 4 件事。

如果 obsidian help 提示找不到 Obsidian，先打开 Obsidian 桌面端，再回到终端重试。

先看几个基础命令。

确认当前打开的是哪个 Vault，也就是当前知识库文件夹：

1

obsidian vault

下面三条命令只演示三件事：看目录、搜主题、读文章。先把占位词换成自己的目录，再复制命令。

复制命令时，重点改引号里的内容。先不用记所有参数。

第一条命令，用来确认草稿目录里有多少文件。这里的 folder 表示只填写目录，不需要写具体文件名。

1

obsidian files folder="草稿目录" total

这条命令返回的是文件数量。数量本身不重要，重要的是 Codex 可以先确认目标目录里有没有可用资料。

第二条命令，用来在草稿目录里搜索一个主题。query 表示搜索词，path 表示搜索范围，limit=10 表示最多返回 10 条结果。

1

obsidian search query="AI 工作流" path="草稿目录" limit=10

这条命令能让 Codex 先找到相关内容，而不是直接从空白处生成。

第三条命令，用来读取一篇已发布文章。这里的 path 要写到具体文件，也就是 目录/文件名.md。

1

obsidian read path="已发布目录/Obsidian CLI 来了.md"

这条命令能把完整文章读出来。Codex 读到原文后，才知道你的表达方式、已有观点和前后关联资料。

这三条命令对应的是 Codex 的三个基础动作。

所以这些命令的价值，不在于让人少敲几行命令。

真正的价值是，Codex 不需要猜知识库里有什么，也不需要等人手动粘贴资料。它可以先查、再读、再判断下一步怎么写。

这比把一大段资料复制给 AI，更接近真实工作流。

真正使用时，怎么指挥 Codex

真正使用时，不是让你打开终端一条条敲命令。

推荐做法是直接做一个 Obsidian CLI Skill。

Skill 不是 Obsidian 插件。它是一包给 Codex 看的工作规则。

这个 Skill 要告诉 Codex 三件事。

• • 进入这个知识库后，先确认当前 Vault，也就是知识库文件夹。
• • 搜索、读取、创建、追加和检查，优先调用 Obsidian CLI，也就是命令行接口。
• • 搜索、读取和列目录可以直接做；创建和追加只有在本次任务明确授权时才直接做；删除、移动和覆盖永远先问人。

这样以后每次给 Codex 下任务，就不用反复写“优先使用 Obsidian CLI”。你只要把目标、资料范围、输出物说清楚，再说明哪些事可以直接做、哪些事必须先问你。Codex 会加载 Obsidian CLI Skill，再按规则完成搜索、读取、创建、追加和检查。

一个最小可用的 Obsidian CLI Skill，至少要固定 5 条规则。

可以把任务这样交给 Codex：

1
2
3
4
5
6
7
8
9

请在当前 Obsidian 知识库里帮我整理一篇公众号草稿。
按 Obsidian CLI Skill 执行。
 
目标：写一篇关于「AI 工作流」的文章。
资料范围：先搜索草稿目录和已发布目录。
执行顺序：先确认当前 Vault，也就是当前知识库文件夹，再搜索相关内容，再读取最相关的 3 篇笔记。
输出物：先给我文章大纲和可用素材清单。
可直接做：搜索、读取、整理大纲、列素材清单。
必须先问我：创建、追加、删除、移动或覆盖文件。需要写入文件前，先说明目标路径和写入内容。

这段指令里，最关键的不是“帮我写文章”。

关键是分清两类东西：长期规则放进 Obsidian CLI Skill；单次任务只说这次要做什么。

所以每次任务最少要把 4 件事说清楚。

如果已经确定要新建草稿，可以这样说：

1
2
3
4
5
6

请按 Obsidian CLI Skill 创建一篇公众号草稿。
 
目标路径：草稿目录/Codex 使用 Obsidian CLI.md
模板：公众号文章模板。
要求：先检查目标路径是否已有同名文件。没有再创建；如果已有，先读取内容并询问是否追加。
创建后：检查 frontmatter、封面字段和正文第一行封面图。

这里的 目标路径 仍然写知识库文件夹内部路径。读者实际使用时，把 草稿目录 换成自己的草稿目录。

如果是修改已有草稿，可以这样说：

1
2
3
4
5
6

请按 Obsidian CLI Skill 读取这篇草稿：草稿目录/Codex 使用 Obsidian CLI.md。
 
先找出文章结构问题，不要直接改。
确认后，再把新增内容追加到对应小节。
修改后，检查出链、反向链接和未解析链接。
删除、移动和覆盖文件前必须先询问。

这样写，Codex 才会按 Obsidian CLI Skill 调用命令行接口，而不是只在聊天框里凭空生成一段文字。

后面这些命令，就是 Codex 在背后可以调用的能力。

Codex 能做什么

Codex 接入 Obsidian CLI 后，最实用的是五类能力。

找资料

写文章之前，经常要先确认一个问题：以前有没有写过这个主题？

以前靠人工翻目录。现在可以让 Codex 先搜。

1

obsidian search query="AI 工作流" path="草稿目录" limit=10

如果需要查看匹配内容前后的几行文字，可以用：

1

obsidian search:context query="AI 工作流" path="草稿目录" limit=10

这一步让 Codex 先判断哪些笔记和当前选题有关，而不是从空白处开始生成。

长期写作的人会反复遇到同一个现象：很多观点并不是第一次出现。

以前写过的段落、项目复盘、技术笔记和会议记录，都可能变成新文章的素材。搜索这一步，就是把沉下去的内容重新捞出来。

读草稿

找到资料后，Codex 可以直接读取文件。

1

obsidian read path="已发布目录/从 Notion 到 Obsidian.md"

这一步解决的是材料不完整的问题。

AI 写得好不好，不只取决于模型能力，也取决于它有没有读到正确材料。

Codex 先读现有文章，就能知道文章的表达方式、段落节奏、常用概念和前后观点。继续写下一篇时，风格不容易突然断开。

创建草稿

确定选题后，可以让 Codex 直接创建新文件。

1

obsidian create path="草稿目录/Codex 使用 Obsidian CLI.md" template="公众号文章模板"

这里推荐先用模板创建。模板能一次放好标题、摘要、封面、状态和正文开头结构。

这一步的价值不是省下新建文件的时间。

真正的价值是标准化。

比如每篇公众号文章都要有标题、创建时间、标签、摘要、朋友圈文案、封面和状态字段。手工写容易漏。让 Codex 按模板创建，就能保证每篇文章进入同一套内容管理规则。

这里的 --- 区域叫 frontmatter。frontmatter 是 Markdown 文件开头的属性区，常用来放标题、标签、摘要、封面和状态。

这里有一个前提：模板必须放在 Obsidian 设置中指定的模板目录里。可以先用 obsidian templates 查看 CLI 能识别哪些模板。

新建公众号草稿时，不要只告诉 CLI“文件叫什么”。还要告诉它“文件放到哪里”。

path 表示保存路径。保存路径由文件夹和文件名组成。下面用我的公众号内容目录演示。

我这里的草稿目录叫 40 微信公众号/20 草稿/，所以新建草稿命令是：

1

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

实际使用时，把 40 微信公众号/20 草稿/ 换成自己的草稿目录即可。后面的 新文章草稿.md 是文件名。

name 只表示文件名，比如 新文章草稿。如果只写 name="新文章草稿"，CLI 会按 Obsidian 的默认新建位置创建文件，不一定进入想要的草稿目录。

这就是为什么创建公众号文章时优先写 path。它能把文章直接放进目标草稿目录，后续按草稿、发布和素材流程管理时才不会乱。

追加内容

有时候不是新建文章，而是在已有笔记后面补一段。

1

obsidian append path="草稿目录/Codex 使用 Obsidian CLI.md" content="\n\n## 补充说明\n\n这里追加新的段落。"

如果直接复制这条命令后看到 File "草稿目录/Codex 使用 Obsidian CLI.md" not found，通常是因为 草稿目录 还没有替换成真实目录。

这里的 path 写的是知识库文件夹内部路径，不是 Windows 里从盘符开始的完整路径。比如我的这篇草稿，本地复现时要写成：

1

obsidian append path="40 微信公众号/20 草稿/Codex 使用 Obsidian CLI.md" content="\n\n## 补充说明\n\n这里追加新的段落。"

这适合做日常积累。

一个选题还没有想完整时，可以先让 Codex 把搜索到的素材、可用观点和待确认问题追加到草稿底部。真正写作时，草稿里已经有了可用材料。

检查链接

Obsidian 的核心不只是文件夹，而是链接网络。

文章写完以后，可以让 Codex 检查这篇内容有没有接入知识库。

1

obsidian links path="草稿目录/Codex 使用 Obsidian CLI.md"

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

再看反向链接：

1

obsidian backlinks path="草稿目录/Codex 使用 Obsidian CLI.md" counts

反向链接指的是哪些笔记反过来提到了这篇文章。

最后检查整个 Vault，也就是整个知识库文件夹，有没有未解析链接：

1

obsidian unresolved counts verbose

未解析链接指的是已经写成 [[双向链接]]，但还没有对应真实文件的链接。它不一定是错误，也可能是提前留下的选题坑。

这三步对内容管理很有用。

一篇文章写完后，如果没有任何链接，很容易变成孤立文件。过几个月以后，除非记得标题，否则很难再次利用。

链接检查可以提醒写作者：这篇文章应该连到哪些主题？哪些概念已经写成双向链接，但还没有建立对应笔记？

这类检查机械、重复，又需要耐心，正适合交给 Codex。

一条完整流程

Codex 加 Obsidian CLI 的写作流程，可以收口成这样：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

一次性准备 Obsidian CLI Skill
  ↓
确定选题
  ↓
向 Codex 说明目标、资料范围、输出物，以及哪些事可以直接做、哪些事必须先问你
  ↓
Codex 加载 Obsidian CLI Skill
  ↓
Codex 确认当前知识库文件夹
  ↓
Codex 搜索相关素材
  ↓
Codex 读取关键笔记
  ↓
生成文章结构
  ↓
按授权创建或追加草稿
  ↓
补齐 frontmatter
  ↓
检查链接关系
  ↓
人工通读和发布

这里的 frontmatter 仍然是文章开头的属性区。它负责记录标题、摘要、标签、封面和状态。

这个流程里，人没有消失。人的职责更清楚了。

人负责选题判断、观点取舍、最终表达和发布责任。Codex 负责搜索、读取、整理、格式化、补链接和检查结构。

为什么不直接改 Markdown 文件

Codex 本来就能读写本地文件，为什么还要经过 Obsidian CLI？

直接改 Markdown 文件当然可以，而且很多时候更快。

但 Obsidian CLI 多了一层 Obsidian 语义。

比如：

• • obsidian search 会在 Vault，也就是知识库文件夹中搜索。
• • obsidian read file="标题" 可以像 Obsidian 链接一样按文件名解析。
• • obsidian backlinks 可以查看反向链接。
• • obsidian unresolved 可以检查未解析链接。
• • obsidian properties 可以读取属性统计。
• • obsidian tasks 可以读取 Markdown 待办。

这些能力不是普通文件系统天然提供的。

直接读写文件，看到的是文件。

通过 Obsidian CLI，看到的是整个知识库：链接、属性、任务和前后关联信息会一起出现。

这就是差别。

对 Codex 来说，文件系统能力负责改内容。Obsidian CLI 负责理解内容在知识库里的位置。

两者应该配合，而不是互相替代。

使用边界

这套流程很顺，但需要边界。

Obsidian CLI 依赖 Obsidian 桌面端。很多命令需要 Obsidian 正在运行，或者至少能被 CLI 唤起。

用模板创建中文 Markdown 后，要检查文件编码。CLI 生成的文件可能是 UTF-8 无 BOM，在 Windows PowerShell 里默认读取时容易显示乱码。团队或个人知识库如果约定使用 UTF-8 with BOM，创建后要统一转换。

路径里有空格和中文时，要加引号。

1

obsidian read path="草稿目录/Codex 使用 Obsidian CLI.md"

删除、移动、覆盖这类命令要谨慎。

1
2
3

obsidian delete path="某篇文章.md"
obsidian move path="旧路径.md" to="新路径.md"
obsidian create path="已有文章.md" content="正文内容" overwrite

这些命令会改变真实文件。适合先约定规则：搜索、读取和列目录可以直接做；创建和追加只有在本次任务明确授权时才直接做；删除、移动和覆盖永远要人工确认。

重要的 Vault，也就是知识库文件夹，一定要做版本管理。

用 Git 也好，用同步工具的历史版本也好，至少要能回退。AI 进入知识库以后，效率会变高，出错速度也会变快。

最终发布前仍然要人工通读。

Obsidian CLI 能把内容放到正确位置。Codex 能生成更完整的稿子。但文章是否成立，观点是否准确，表达是否适合读者，仍然要由人负责。

适合哪些人

这套工作流不一定适合所有人。

如果只是偶尔记几条备忘，打开 Obsidian 手写就够了。没必要上 CLI，也没必要让 Codex 介入。

如果长期写公众号、博客和长文，这套流程会更有价值。

如果项目资料、Markdown 笔记和写作素材很多，也会更有价值。

如果希望 AI 能复用历史素材，而不是每次都从零开始，它会更有价值。

这时 Obsidian 不只是笔记软件。

它会变成一个本地知识资产库。

Codex 也不只是写代码的工具。

它会变成一个能进入本地知识库、按规则协作的工作助手。

真正的变化

Codex 使用 Obsidian CLI，表面上只是多了几条命令。

背后真正变化的是工作方式。

过去的 Obsidian，更像一个人打开来阅读和编辑的 GUI，也就是图形界面。

有了 CLI，也就是命令行接口以后，它开始多出一层 AI 可以调用的入口。

个人知识库开始从“人打开来阅读和编辑的地方”，变成“人和 AI 都能调用的工作环境”。

AI 时代的内容生产，不只是让模型写得更快。

更重要的是，让模型接触到个人长期积累。

公开模型知道的是通用知识。

Obsidian 里存的是个人经验、项目资料、历史文章、未完成想法和正在推进的事情。

当 Codex 能通过 Obsidian CLI 搜索、读取、创建和检查这些内容时，AI 才真正进入个人工作系统。

它不再只是聊天框。

它开始变成知识库协作者。

最后的判断仍然属于人。

工具负责提高流动性，人负责建立判断力。

这就是 Obsidian CLI 和 Codex 组合起来最值得期待的地方。

参考资料

• • Obsidian CLI 官方文档：https://help.obsidian.md/cli
• • Obsidian 官网：https://obsidian.md

我是一名 数字创作者 · 独立开发者 · 技术博主，专注成长，拓展技术边界，持续突破自我。

关注 「程序员NEO」，我会持续分享 AI 编程、工程实践和效率提升相关内容。