最近, Obsidian 的 CEO Steph Ango(也就是大家熟悉的 kepano)干了一件非常「Obsidian」的事,他没有像很多SaaS 或 App 那样在产品界面里塞一个「ask AI」的按钮,而是发布了一个开源仓库「Obsidian Skills」,专门教 AI 怎么更好的操作 Obsidian。
为什么说这件事让火箭君非常兴奋,因为这恰恰是我一直提倡「工具链」理念的最好实践。工具各司其职,实现配合,而不要把工作全都塞进一个「超级App」。 Obsidian 一直在贯彻这个理念,最早坚持本地 Markdown 和开放的格式,就是希望自己融于工具链,而不是独占所有环节。
下面请让我介绍一下 Skills 概念以及 我们如何使用 Obsidian Skills, 对很多非专科的人来说,这可能有点门槛,但目前这是我个人觉得最理想的接入时机了,我之前都一直在观望,而没有去安装那些莫名其妙的 Obsidian 第三方 AI 插件。
Skills 到底是什么?
这里 Skills 指的是 Claude Code 的 Agent Skills 机制:我们把一组带有指定格式(貌似是YAML?) 操作说明的文本文件放进指定目录,Claude 会先加载「名字 + 描述」,当你的请求命中描述关键词时,会启用该 Skill,并把按照Skill文件描述执行,后续操作。最早,Skills 可能用于开发人员,但实际上远远不止于此,我觉得知识工作者都能受益。
比方说,我有一个写某种标准网页界面的 Skill 描述,然后 对AI 说,帮我设计一个登录页面,AI 会先去看一下 Skills,就像先读一下说明书,然后再去按照规定标准设计页面。
重点在于:Skills 不是插件,不要求我们把数据或笔记迁移到某个专用的App数据库里。它本质上是「可移植的规则包」,或者称之为「说明书」。这本身就非常符合 Obsidian 的底色:可读的文本文件在我们手上、格式开放、工具按规则互相配合。
Obsidian Skills 里有什么:三个最容易被 AI 写错的文件类型
kepano (Obsidian CEO) 的 Skills 开源仓库 叫 kepano/obsidian-skills,MIT 协议。

安装很简单,把仓库内容放到你 vault 根目录的 /.claude 文件夹(或给 Claude Code 使用的工作目录)里。
目前 Obsidian 包含三类 Skill,对应三种主流的Obsidian文件:
- Obsidian Flavored Markdown(.md)
AI 最常见的翻车点是「把 Obsidian 当成普通 Markdown 编辑器」:写成普通链接、漏掉[[wikilink]]、embed 语法不对、properties / frontmatter 混用等等。这个 Skill 的目标就是让 AI 输出「Obsidian 特色」的 Markdown 文本。 - Obsidian Bases(.base)
我们知道,Bases 属于「看起来像数据库,其实还是文件」的经典 Obsidian 路线:.base文件描述视图、过滤、公式、汇总等,让我们在 Obsidian 里用表格 / 卡片的方式浏览笔记。对 AI 来说,这类结构化文件如果没有规范,特别容易写错字段名或层级。 - JSON Canvas(.canvas)
Canvas 背后是 JSON Canvas 这种开放格式(Obsidian 还专门写过公告)。.canvas文件是 JSON 结构,节点、连线、分组都有固定 schema。没有规则提示的话,AI 不是少字段就是乱嵌套。
顺带一提:这个仓库在 2026-01-02 开始提交(最早两条 commit 就是 Obsidian Markdown 和 Bases),之后又补了 JSON Canvas、插件信息、目录结构修复等。
我们可以怎么用?
我们先看结果,比方说, 只要对 AI 说: 帮我生成一个 Obsidian Canvas 用来简单描述一下 MCP 概念。AI 就会调用 Skills 正确生成出画布,Obsidian 里面瞬间见可见。

又比方说, 让 AI 列出 世界10大名画的简介表格,立刻存入我们的 Obsidian Bases。

实操步骤
重点来了,Skills 机制其实很容易理解,但是投入使用涉及到很多具体操作,对不少新手来说直接就劝退了,最关键的是,根本用不了 Claude Code。 而 Obsidian Skills 就是按照 Claude Code 标准设计的。
我觉得这和 Claude Code 背后 AI 公司 Anthropic 的思路有关,Skills(还有之前很火的 MCP) 都是 Anthropic 提出的开放标准。 虽然我觉得 开放标准很好,但是 Anthropic 的上层思路和他工程师的开放思路就截然不同,显得很狭隘。下层在开放标准,上层貌似希望将用户锁定在他们自己平台上, 恰好最近另一条新闻就是关于 OpenCode(不是OpenAI,而是一个开源版的 Claude Code 替代品)被 Anthropic 限制。 要我说,被 Anthropic 针对限制不是一个两个了, 我反正不喜欢自己的重要工具被捏在单一公司手里。 熟悉火箭君的都知道,有选择余地的工具才是好工具,想一把独占用户的工具,都是我们工作流上重大的风险。
下面是一个简略的方案, 考虑到具体操作会有很多坑, 搞不好会有人出收费教程,或收费手把手辅导也说不定。
1. 我们需要一个 Claude Code 平替
其实有很多选择,国内外的产品都有,我个人建议:可以考虑开源版本。 防止本地数据或内容被无端窥视。 恰好最近开源的 OpenCode 被 Anthropic 针对, 那么就用 OpenCode 来举例,实际上 Goose 也是不错的,和 Claude Code 兼容得很好。

安装完,可以对接一个自己喜欢的 AI 模型 (而不是 Anthoropic 那种自己的模型,这就是开放的含义)。 OpenCode 甚至也支持 国内一些优秀的模型。 如果用户没有碰过 AI 的话,单单选择模型就是长篇大论了,恕我这里就不赘述了。
Claude Code 也好,OpenCode 也好,最初都是AI开发辅助工具,所以用于 Obsidian 有些过重了,很多命令我们都是用不上的,不过我们就简单举例,讲一个思路。
2. 加载 Skills
安装完OpenCode,或任何类似的客户端(或 CLI 工具), 从 Github 取下 Obsidian Skills, 复制到我们的 Obsidian Vault 目录下 类似 /.claude/ 这样。 其实 大多 AI 工具都很先进,可以直接和AI 说,帮我把哪个开源库的SKILLS安装到哪里,AI 会自动执行。 但一样的是,我们需要提供准确来源和目标的路径,实际上和自己动手已经差不多了, 大家按自己喜好来就行。
3. 指定工作目录
OpenCode 可能需要我们指定 工作目录。 或者在提示词提及 Obsidian 目录,对啊,否则 AI 怎么知道在哪个 Obsidian 库里面生成什么规则的内容? 最简单的就是, 在 库目录下执行OpenCode,默认就在当前路径下。 可以做成带参数的 快捷方式或脚本,将来可以一键打开。
4. 直接开干
好了,现在都有了,直接输入要求吧,例如:「在Drafts目录下 用 Obsidian canvas skill 生成 太阳系 主要行星和卫星的介绍」

最后
kepano 这次发布的有趣之处在于:它不是一个「把 AI 绑进产品」的功能更新,而是一个「把 Obsidian 的文件语法讲清楚」的技能包。Obsidian 继续坚持开放格式(Markdown、.base、JSON Canvas),而 AI 只是读写这些格式的一个可选工具。我们可以做自己选择平台,也可以选择模型,这就是我说的有「选择余地」的方案。
这周是让火箭君兴奋的一周,Obsidian 的动作意味着 让 AI 离开发者以外的知识工作者又近了一步。大家为什么还要用那些花哨但平庸的云端 套壳 SaaS AI 工具呢? AI 新鲜劲早就退潮了,现在是实用为王的时候了。 要么特别创新和专精,像一些专门方向的在线 AI 工具;要么把自己打造成 一个工具链上的环节,像 Obsidian 这样。 除此以外,靠噱头营销的 大而全 AI 工具还有什么价值呢?


