从工具清单到决策框架，一篇读懂 Obsidian 官方 Skills 套件的真实指南
一只阿木木约 22 分钟——从工具清单到决策框架，一篇读懂 Obsidian 官方 Skills 套件的真实指南
这篇文章写给谁： 已经安装了 kepano/obsidian-skills 但不确定"装了然后呢"的用户；想在使用官方 Skill 之外，进一步构建自己定制化 Skills 的 Obsidian 进阶用户；想搞清楚"工具类 Skill"和"流程类 Skill"本质区别的人。
这篇文章不写给谁： 完全没有用过 Obsidian 的新手（建议先读文章一）；不使用 AI Agent 操控笔记，只用 Obsidian 写手动笔记的用户。
开篇：安装了 Skills，然后呢？
你也许已经克隆了 kepano/obsidian-skills，把它放进了 Vault，在 Claude Code 里激活了一个斜杠命令。
然后……什么感觉？
可能有点茫然。5 个 Skill 摆在那里，你不太确定哪个今天就要用，哪个对你根本没意义，也不知道什么时候该自己写一个。
这篇文章想解决的，就是这个"安装完成之后的空白"。
先说结论：
这 5 个官方 Skill，并不是让你全部安装的。它们是一个菜单，你需要根据自己的实际场景做选择。 更重要的是，官方套件只解决了问题的一半——它教会 AI 说 Obsidian 的格式语言，但它不知道你的 Vault 长什么样、你的工作流是什么。那一半，必须由你自己来定义。
但在这一切之前，有一个概念区分必须先讲清楚——否则你的整套系统搭建在错误的基础上。
关键前置：两种 Skill，两种逻辑——先搞清楚，再做选择
很多人在使用 Obsidian Skills 时会犯一个根本性的错误：把别人的「流程类 Skill」直接复制进自己的 Vault。
这个错误的后果是：Skill 激活了，但 AI 做的事情完全不符合你的预期——因为那个 Skill 里的文件夹结构、命名规范、标签体系，是别人的，不是你的。
自定义技能无限优于别人的技能，因为它们是按照你自己的需求和流程量身定制的。使用别人创建的技能，可能并不适合你的工作流和 Vault 结构。1
这不是在说别人的 Skill 质量差——而是说，Skill 分为两种完全不同的类型，两者的使用逻辑截然不同：
工具类 Skill（Tool Skills）——复制官方的，越稳定越好
定义： 教 AI 正确使用某个工具的文件格式和语法规范。
特点： 与具体用户的 Vault 结构无关，所有人都适用同一套规范。
官方的 5 个 Skill 都属于这一类。 它们教 AI 的是：.md 文件里的 wikilinks 怎么写、.base 文件的 Schema 是什么、.canvas 的 JSON 结构是什么。
这些规范是客观的，不因人而异。所以直接复制官方的工具类 Skill，是正确的选择。
流程类 Skill（Process Skills）——只能自己写，不能照搬别人的
定义： 教 AI 遵循你个人特定的工作流程和 Vault 约定。
特点： 深度依赖你的文件夹结构、命名习惯、标签体系、笔记模板。换一个人，整个 Skill 就失效。
这类 Skill 必须你自己写。
kepano 仓库中的核心技能赋予了 Claude 在 Obsidian 内工作的能力。超出这个范围的一切，都需要你自己来定义。2
举两个例子对比感受：
工具类 Skill 的典型内容： "在 Obsidian 中，内部笔记链接使用
[[wikilinks]]格式，外部 URL 使用标准 Markdown 链接。" → 这是客观事实，对所有人一样有效。
流程类 Skill 的典型内容： "我的 Projects 文件夹只存放有截止日期的主动项目。Areas 文件夹放持续负责的领域。Archive 文件夹放已完成和非活跃内容。遇到不确定分类的笔记，先放 Inbox 并标注
status: unclear，等待我手动确认。" → 这是你的 Vault 独有的逻辑，别人的 Vault 不适用。
用一张表格总结这个区分：
| 来源 | ||
| 内容 | ||
| 适用性 | ||
| 更新触发 | ||
| 官方示例 |
这个区分是整篇文章最核心的洞察。 理解了这个，你就知道：官方套件只是起点，不是终点。
使用决策图：先选择你需要什么，再决定安装哪个
在逐一拆解每个 Skill 之前，先帮你完成一个最重要的选择：你今天面临的具体问题是什么？
text
你现在主要用 Agent 做什么？
│
├── 让 AI 帮我写或编辑 .md 笔记
│ → 必须安装：obsidian-markdown ⭐ 最高优先级
│
├── 让 AI 帮我创建结构化数据视图（项目列表、阅读清单、任务看板）
│ → 需要：obsidian-bases
│ → 前置条件：你的笔记已经有规范的 frontmatter
│
├── 让 AI 帮我可视化概念关系或知识地图
│ → 需要：json-canvas
│ → 前置条件：你的笔记之间已经有 wikilinks 连接
│
├── 让 AI 从终端直接操控 Vault（不打开 Obsidian GUI）
│ → 需要：obsidian-cli
│ → 前置条件：你有终端使用基础 + Obsidian v1.12+
│
└── 让 AI 帮我从网页提取干净内容存入 Vault
→ 需要：defuddle
→ 最适合：重度网页内容输入用户（研究者 / Readwise 用户）
如果你不确定从哪里开始：先只安装 obsidian-markdown。 它是所有其他 Skill 的基础，也是格式问题最普遍的来源。把它用顺了，再根据实际需要添加其他 Skill。
Skill ①：obsidian-markdown——所有人都需要的那个
中心论点：这不只是一个格式修正工具，它是整个 Vault 数据质量的守门人。
它解决的是什么问题
obsidian-markdown 教会 Agent 完整的 Obsidian Flavored Markdown 规范——Obsidian 在标准 Markdown 基础上添加的语法扩展。没有这个 Skill，Agent 生成的是标准 Markdown，在文本编辑器里看起来没问题，但会破坏 Obsidian 的链接、知识图谱和嵌入功能。
这是一个"几乎正确"的问题，不是"明显错误"的问题。AI 生成的笔记在纯文本编辑器里看起来完全正常——只有当你把它放进 Obsidian 时，问题才会暴露：链接图谱没有建立、callout 格式错误、frontmatter 字段缺失。
每次手动修正看起来只是 5 分钟，但如果 AI 每次都做这件事，你永远都在进行这个修正循环。
它具体教 AI 什么
写内容时使用标准 Markdown 作为结构基础，配合 Obsidian 特有语法。使用 wikilinks（[[Note]]）链接相关笔记实现 Vault 内部连接，外部 URL 使用标准 Markdown 链接。使用 ![[embed]] 语法嵌入其他笔记、图片或 PDF 的内容。
核心规范覆盖四个维度：
① Wikilinks 系统（最关键）
在 wikilinks 和 Markdown 链接之间的选择原则：Vault 内部的笔记用 [[wikilinks]]（Obsidian 会自动跟踪重命名），外部 URL 只用 [text](url)。
这一条规则单独拎出来，因为它是 AI 最常犯错的地方。一旦内部笔记用了标准 Markdown 链接，Obsidian 就无法识别和追踪该链接，重命名文件后链接会直接断掉，知识图谱也随之碎掉。
Wikilinks 的完整语法体系：
Markdown
[[笔记名称]] → 基础笔记链接
[[笔记名称|显示文字]] → 自定义显示文字
[[笔记名称#标题]] → 链接到特定标题
[[笔记名称#^block-id]] → 链接到特定段落块
[[#同一笔记内的标题]] → 同笔记内跳转
② Callout 系统（13+ 种类型）
Obsidian 的 callout 是 AI 最容易写错的语法之一。正确格式：
Markdown
> [!note] 这是笔记类型
> 内容在这里
> [!warning] 注意事项
> 可折叠的内容
> [!faq]- 默认折叠
> 点击展开才能看到
> [!tip]+ 默认展开可折叠
> 内容可见但能收起
13+ 种类型包括：note、info、tip、warning、danger、success、question、faq、bug、example、quote、abstract、summary。
如果你在 .canvas 里保存架构地图，专门的 Skill 能防止 Schema 漂移（字段缺失、ID 重复、边无效）。5同样的逻辑适用于 callouts：没有规范约束，AI 会生成格式上接近但实际无效的 callout 语法。
③ Frontmatter 属性（machine-readable 的基础）
每篇笔记顶部的 YAML frontmatter 块是最重要的设计选择。它将 Markdown 文件从无结构文本转变为可查询数据，这是构建机器可读知识库的前提。
规范示例：
YAML
---
title: 深度工作方法论
date: 2026-04-08
tags:
- 工作方法
- 专注力
type: note
status: in-progress
---
④ 嵌入系统
Markdown
![[另一篇笔记]] → 嵌入完整笔记
![[笔记#某个标题]] → 嵌入笔记特定章节
![[图片.png]] → 嵌入图片
![[图片.png|300]] → 嵌入并指定宽度
![[图片.png|640x480]] → 嵌入并指定尺寸
这个 Skill 不教 AI 什么
Obsidian 在 CommonMark 和 GFM 基础上扩展了 wikilinks、嵌入、callouts、属性、注释等语法。这个 Skill 只覆盖 Obsidian 特有扩展——标准 Markdown 语法（标题、加粗、斜体、列表、引用、代码块、表格）视为已知前提。
这个设计决策非常克制：只教差异，不重复已知。这既节省了上下文 Token，也避免了信息噪音。
一个完整的"正确输出"示例
安装 obsidian-markdown Skill 后，一篇标准的 AI 生成笔记应该是这样的：
Markdown
---
title: Claude Code 与 Obsidian 集成实践
date: 2026-04-08
tags:
- ai/agent
- obsidian/skills
- 工具链
type: note
status: in-progress
---
# Claude Code 与 Obsidian 集成实践
这篇笔记记录了使用 [[kepano/obsidian-skills]] 的实践心得。
> [!warning] 前置要求
> 开始之前，请确认你已完成 [[基础环境配置]] 中描述的所有步骤。
## 核心工作流
整体架构参考了 [[个人工作流系统]] 中的框架，结合了以下几个关键点：
![[工作流概览图]]
更多细节见 [[会议记录模板#自动化处理]]。
这不是一篇"差不多对"的笔记，这是一篇完全正确的 Obsidian 笔记——frontmatter 完整、wikilinks 规范、callout 格式正确、嵌入语法合法。
这个 Skill 的真实局限
Obsidian 常用的约定在 Obsidian 内有效，但容易被通用 Markdown 工具破坏：wikilinks [[Note Name]]、嵌入 ![[image.png]]、callouts > [!note]、frontmatter YAML 元数据块。如果 Claude 在没有这些规则的情况下编辑，会出现"几乎正确"的改动：链接断裂、frontmatter 格式错误、Schema 漂移。
但有一个局限需要诚实说明：这个 Skill 教的是格式规范，不是内容质量。
如果你的笔记本来就思路混乱，AI 用正确的 Obsidian 格式把混乱的内容写出来——你得到的是一篇"格式正确但内容混乱"的笔记。格式规范是前提，不是内容质量的替代品。
一个额外的使用建议
obsidian-markdown Skill 是你指定"除非被明确要求，否则不要重写 wikilinks"的地方。定义一套属性约定（status、priority、due_date……），让 Claude 以受控的方式调整你的视图定义。
这意味着你可以在这个 Skill 的基础上，叠加你自己的 Vault 特有规则——这就是从"工具类 Skill"向"流程类 Skill"过渡的第一步。
Skill ②：obsidian-bases——不是所有人都需要，但需要的人离不开它
中心论点：Bases Skill 解决的是"查询和过滤"问题，不是"组织和整理"问题——选错了，它会变成负担。
什么是 Obsidian Bases，为什么需要专门的 Skill
Base 文件（.base 扩展名）是动态查询视图，从知识库内容中自动填充数据。它们保持更新，因为它们查询知识库而不是列出静态内容。
简单说：你有 500 篇笔记，每篇都有 frontmatter 属性。Base 就是一个能实时过滤和展示这些笔记的动态视图——按状态过滤、按日期排序、以表格或卡片的形式呈现。
为什么需要专门的 Skill？
一般的 Prompt 可以从概念上描述一个 Base，但 obsidian-bases Skill 是针对实际文件结构调优的：有效的 YAML、全局过滤器、按 Base 计算的公式、属性配置、汇总，以及多视图设置。实际优势是减少关于 Schema 形状的猜测，以及减少需要手动修复的格式错误的 .base 输出。7
没有这个 Skill，AI 生成的 .base 文件"看起来像 YAML"，但字段名称、过滤器语法、视图类型的写法都可能出错——导致文件无法在 Obsidian 中正常渲染。
什么情况下需要它
Obsidian Bases 提供纯文本结构化数据格式，适合需要数据库功能的场景，如项目管理、联系人管理、库存管理等。
这个 Skill 支持定义多种视图，包括表格、卡片和列表格式，配合全局过滤器、自定义公式和属性配置。用户可以在需要将笔记组织成结构化、类数据库表示形式时使用，实现高效的数据分析和检索。
具体场景：
有 100+ 篇文章笔记，想要一个「按日期倒序的阅读清单」视图 有多个进行中的项目，想要一个「按优先级过滤的任务看板」 有一批研究文献笔记，想要一个「按作者/年份排序的文献数据库」
它的真实前置条件（这是最常被忽视的部分）
如果你已经了解基本的 Obsidian 属性，这个 Skill 是可用的。obsidian-bases Skill 减少了 Schema 猜测，但它不能替代你对笔记内容的了解。
这句话的实际含义：Bases 完全依赖你的笔记有一致的 frontmatter。
如果你的 Vault 里有 500 篇笔记，其中 300 篇没有 frontmatter、或者 frontmatter 字段名称不统一，Bases 的过滤器就无法正常工作。
没有结构或 frontmatter 的笔记无法被轻松查询或解析。模板强加了刚好足够的结构，让知识库中的每篇笔记都能被机器读取，同时在每个章节内为人类表达留出足够的空间。
正确的操作顺序：
text
第一步：用 obsidian-markdown Skill 让 AI 为现有笔记补全 frontmatter
↓
第二步：确认核心字段（type、date、status 等）已在大部分笔记中统一
↓
第三步：再用 obsidian-bases Skill 创建视图
跳过第一步直接用 Bases，是 Bases Skill 使用效果差的最常见原因。
如何给 AI 写一个好的 Bases Prompt
为了获得更好的 obsidian-bases 使用效果，写 Prompt 时需要明确四件事：数据形状——"frontmatter 字段是 status、priority、owner"；输出目标——"返回一个有效的 .base YAML 文件"；视图逻辑——"包含一个表格视图和一个卡片视图"；约束条件——"公式保持简单，只在共享时使用全局过滤器"。
一个具体的完整 Prompt 示例：
text
使用 obsidian-bases Skill，为我的项目知识库创建一个有效的 .base 文件。
所有笔记都有 status、deadline、area 和 effort 字段。
需要：
- 一个全局过滤器，排除 status 为 "archived" 的笔记
- 一个按 deadline 升序排列的表格视图
- 一个按 area 分组的卡片视图
- 一个显示平均 effort 的汇总
这比「帮我创建一个项目 Base」的效果好得多——模糊指令得到的是模糊输出。
什么情况下不需要它
如果你只需要普通的笔记写作，这个 Skill 是过度设计。
判断标准很简单：
你的 Vault 笔记数量不足 50 篇 → 手动管理更高效，暂时不需要 你的笔记没有规范的 frontmatter → 先解决前置条件 你想要的是"理解关系"而不是"过滤数据" → 你需要的是 Canvas，不是 Bases
Skill ③：json-canvas——把想法"画出来"的 AI 能力
中心论点：Canvas Skill 解决的是"关系可视化"问题，不是"信息组织"问题——它适合呈现连接，不适合呈现清单。
什么是 JSON Canvas，为什么需要专门的 Skill
json-canvas Skill 覆盖 JSON Canvas 格式的视觉白板。Agent 可以创建节点、边、分组和空间布局，Obsidian 将其渲染为交互式画布，适合架构图、思维导图、项目概览。
Canvas 文件的底层是 JSON——一个带有固定 Schema 的结构化文件，包含节点（nodes）、连接（edges）、分组（groups）。
不安装这个 Skill，AI 生成 Canvas 文件时会犯两类错误：
- Schema 错误
：缺失必要字段（如节点的 type、width、height），文件无法在 Obsidian 中打开 - 逻辑错误
：节点 ID 重复，导致连接关系混乱
如果你在 .canvas 里保存架构地图，专门的 Skill 能防止 Schema 漂移（字段缺失、ID 重复、边无效）。
它具体能做什么
场景一：概念关系图
Prompt：「创建一个 Canvas，解释 MCP（Model Context Protocol）的核心组件和它们之间的关系」
Agent 激活 json-canvas Skill，理解节点、分组和边的正确 Schema，生成一个可直接在 Obsidian 中打开的 .canvas 文件：
JSON
{
"nodes": [
{
"id": "n1",
"type": "text",
"x": 0, "y": 0,
"width": 280, "height": 120,
"text": "## MCP Host\n用户的 AI 应用程序（如 Claude Code）"
},
{
"id": "n2",
"type": "text",
"x": 400, "y": 0,
"width": 280, "height": 120,
"text": "## MCP Server\n暴露工具和资源的服务"
}
],
"edges": [
{
"id": "e1",
"fromNode": "n1", "fromSide": "right",
"toNode": "n2", "toSide": "left",
"label": "请求工具调用"
}
]
}
场景二：Vault 知识地图
Prompt：「扫描我所有标记为 #ai/agent 的笔记，创建一个展示它们之间关系的知识地图 Canvas」
Agent 读取笔记，识别 wikilinks 关系，将相关笔记转化为 Canvas 节点，在有链接关系的节点之间绘制边。这是一个"从 Vault 内容生成可视化"的真实场景。
场景三：项目复盘可视化
Prompt：「根据本月的会议记录，创建一个展示所有决策和行动项关系的 Canvas」
它监控你的「待读」笔记，检查你是否添加了 finished_date，并将完成的条目移至阅读归档。此外，它还可以生成月度阅读报告 Canvas。
Canvas 的真实边界（必须说清楚）
边界一：Canvas 不适合超过 50 个节点的网络。
当节点数量超过一定规模，Canvas 会变成一堆密集的方块，失去可读性。大规模知识网络用 Obsidian 的图谱视图，Canvas 适合聚焦的、小规模的关系呈现。
边界二：Canvas 是静态快照，不自动更新。
AI 生成的 Canvas 是基于当前笔记状态的一张快照。笔记更新后，Canvas 不会自动同步——你需要重新生成或手动更新。不要把 Canvas 当成实时的动态视图。
边界三：Canvas 不适合线性内容。
如果你想展示的是一个步骤清单或时间线，用 Markdown 列表或 Bases 更合适。Canvas 的强项在于「关系」和「空间布局」，而不是「顺序」和「层级」。
一个有价值的使用判断标准
用这个问题做决策：「我需要展示的是'顺序'还是'关系'？」
需要展示顺序 → 用 Markdown 列表 / Bases 视图 需要展示关系 → 用 Canvas（+json-canvas Skill）
如果你不确定，从写一篇笔记开始，在你发现"光写文字说不清楚这些东西的关系"的那一刻，就是该用 Canvas 的时候。
Skill ④：obsidian-cli——给有终端习惯的用户的自动化引擎
中心论点：CLI Skill 是 5 个 Skill 中门槛最高、潜力也最大的一个——它是"真正后台自动化"的入口，但不是每个人都应该优先安装它。
它能做什么
这是一个面向 AI Coding Agent 的技能，通过官方 Obsidian CLI（v1.12+）实现对 Obsidian Vault 的完整控制。安装后，你的 AI Agent 将能通过 CLI 与 Obsidian Vault 交互——读取、创建、编辑笔记、管理日记、运行全文搜索、查询任务、标签、链接和属性、管理插件和同步，以及运行开发者工具。
核心命令的真实样貌：
Bash
# 读取笔记
obsidian read file="My Note"
# 创建笔记（使用模板）
obsidian create name="New Note" content="# Hello" template="Template" silent
# 追加内容到当前日记
obsidian daily:append content="- [ ] 完成设计稿审阅"
# 全库搜索
obsidian search query="会议记录" limit=10
# 查看指定笔记的反向链接
obsidian backlinks file="My Note"
# 查看所有孤立笔记（没有任何链接的笔记）
obsidian orphans
# 查看所有损坏的 wikilinks
obsidian unresolved
# 设置笔记属性
obsidian property:set name="status" value="done" file="My Note"
有开发者构建了基于 Obsidian CLI 的技能，把 Vault 变成了一个开发者大脑：记录决策、捕获 Bug 修复、保存代码片段、搜索整个知识库，并接入 Claude hooks 实现完全自动化的文档管理。
最有价值的两个 CLI 场景
场景一：孤立笔记清理
运行 obsidian orphans，AI 返回所有没有任何链接的笔记列表，然后批量为它们添加 wikilinks 连接到相关笔记——这是 Vault 维护中最枯燥但最重要的工作之一。
场景二：属性批量更新
有 200 篇笔记需要把 status: draft 批量改为 status: published？一条 CLI 命令配合 obsidian property:set，AI 自动批量处理，不需要你一篇一篇打开。
必须提前知道的前置条件和限制
前置条件 ①：Obsidian v1.12+
Obsidian v1.12 向所有用户开放——不需要 Early Access 版本或 Catalyst 授权。macOS / Linux 上，启用 CLI 设置后，obsidian 命令会自动添加到 PATH。
前置条件 ②：Obsidian 必须处于运行状态
通过 Obsidian CLI 与一个正在运行的 Obsidian 实例交互。需要 Obsidian 处于打开状态。
这是一个经常被忽视的限制：CLI Skill 不是完全无头（headless）运行的。你无法在 Obsidian 未打开的情况下用 CLI 操控 Vault。这影响了它在"纯后台定时任务"场景下的适用性。
前置条件 ③：你需要终端基础知识
Skills 机制理解起来容易，但让它正常运行涉及一系列实际操作步骤，可能会让新手望而却步——尤其是不能或不想直接使用 Claude Code 的用户。
这不是在劝退你，而是在设定正确预期。如果你从未在终端里运行过命令，CLI Skill 应该排在最后安装，不是第一个。
Windows 特有注意事项：
Windows 需要一个放在 Obsidian.exe 旁边的 Obsidian.com 重定向文件。必须从普通权限终端运行——管理员权限终端会导致静默失败。
谁应该优先安装，谁可以暂时跳过
优先安装：
已经习惯在终端工作的开发者 想要实现"每日 Inbox 自动处理"等定时工作流的用户 需要批量操作大量笔记属性的用户
可以暂时跳过：
主要通过 Obsidian GUI 操作的用户 刚开始构建 Obsidian + AI 工作流的用户（先把 obsidian-markdown 用顺再说） Windows 用户（配置复杂度更高，建议先从 Mac/Linux 环境验证）
Skill ⑤：defuddle——输入管道的第一道过滤器
中心论点：Defuddle 的价值不在于它能做多少事，而在于它让后续所有处理的质量更高。
它解决什么问题
你有没有试过把一个网页 URL 丢给 AI，让它帮你整理内容？
结果通常是一堆广告文字、导航栏链接、页脚版权信息夹在真正有用的文章内容里——AI 要么把这些都当成"内容"处理，要么在清理噪音上浪费大量 Token。
Defuddle 从杂乱的网页提取干净的 Markdown 内容，无缝导入 Obsidian Vault。
它把"一个网页"变成"只包含正文内容的干净 Markdown"——去掉导航栏、广告、评论区、页脚，保留真正有价值的内容。
何时真的需要它
需要 Defuddle 的典型场景：
你用 Readwise 或 Instapaper 大量阅读网页文章，并同步到 Obsidian 你是研究者，经常把学术博客或技术文章保存进 Vault 你的主要内容输入来源是网页，而不是自己写的笔记
不太需要 Defuddle 的场景：
你的 Vault 主要是自己写的笔记 你的网页内容输入量很少（每周不到 5 篇） 你已经有其他工具（如 MarkDownload 插件）在做网页清理
推荐的使用顺序
Defuddle 的最大价值不是独立使用，而是作为输入管道的第一个环节：
text
① Defuddle 提取 → ② obsidian-markdown 格式化 → ③ 存入 Vault
在需要使用网页内容之前，先运行 /defuddle 对页面进行清洗，再进行保存。把这个顺序变成习惯，你的 Vault 内容质量会有系统性的提升——不是偶尔整理，而是从输入环节就开始把关。
第五章：你的第一个流程类 Skill——从官方套件出发，走向个人定制
安装了官方 5 个工具类 Skill，你完成了 50% 的工作。
剩下的 50%，需要你来完成。
使这套设置脱颖而出的，是直接存放在 Vault 内部的情境化 Skills 和 Claude 指令的组合。这正是让 Claude 从通用助手变成理解你的特定系统并遵循你的个人约定的东西，让它感觉像是一个真正的个性化私人助手。
为什么你的流程类 Skill 比任何官方 Skill 都有价值
为什么你应该考虑自己创建 Skills？自定义 Skills 无限地更有用和可靠，因为它们是按照你的需求和流程量身定制的。1
官方的工具类 Skill 解决的是所有 Obsidian 用户共同的问题（格式语言）。流程类 Skill 解决的是只有你才有的问题（你的工作方式）。
这里有一个清晰的模式——Skills 擅长将信息从一种状态转化为另一种状态。它们是你知识库的"工厂工人"，处理重复性工作，让你专注于思考。
三个真实的流程类 Skill 案例，帮你找到自己的起点
案例 A：会议记录处理 Skill
会议记录转换器：接收原始会议记录（通常比较杂乱），对其进行结构化处理。它提取行动项（带有"TODO"或"ACTION"的行）、识别已作出的决策，并为后续跟进创建链接笔记。一位用户表示，这将他的会议处理时间从 15 分钟缩短到了 2 分钟。
这个 Skill 的流程类部分（你需要自定义的部分）：
行动项提取后放在哪个文件夹？ 决策笔记使用什么命名格式？ 会议笔记应该链接到哪些 People 笔记？
案例 B：Context 加载 Skill
context Skill 在会话开始时将你当前的生活状态加载到 Claude：活跃的项目、当前的优先级、个人偏好，以及你当前的专注点。没有它，每次 Claude Code 会话都从零开始。Claude 通过 CLAUDE.md 了解你的 Vault 结构，但它不知道你现在实际在做什么、这周什么最重要、你决定暂时放弃什么。Context Skill 通过读取相关笔记并呈现一切所依赖的状态来填补这个空白。
案例 C：Spark（模式识别）Skill
开发者构建了这个 Skill，因为他注意到自己最有价值的想法并不是作为"想法"开始的——它们以每日笔记中的一个反复出现的短语开始，或者以不同对话中不断出现的主题开始，或者以在三个不同情境中写下但没有关联的同一个问题开始。Spark Skill 读取最近一段时间窗口内的笔记，浮现出开始感觉连贯的主题群。
写第一个流程类 Skill 的实操步骤
Step 1：用 Skill Creator 工具作为起点
在你自己创建 Skills 之前，我推荐使用 Claude 的 skill-creator Skill，因为它包含了编写高质量 Skill 定义的具体指导。在 Claude Code 中输入 /plugins，然后选择 skill-creator。一旦配置好，你就可以用对话的方式描述你想要 Skill 做什么，它会在你本地的 .claude/skills/ 文件夹中生成 Skill 定义。
Step 2：找到你最想自动化的那个重复动作
从这个问题开始：「在我的 Vault 工作中，什么事情我每次都要重复说同样的指令？」
不要从复杂的工作流开始。从一件小事开始：
识别一个小烦恼。也许你讨厌手动添加创建日期。也许你想让会议记录有一致的格式。选择一件小事。
Step 3：用这个模板写 SKILL.md 的框架
一个最小可用的流程类 Skill 结构：
Markdown
---
name: meeting-note-processor
description: |
当用户粘贴会议转录稿或要求处理会议记录时使用。
会从原始文字中提取结构化会议笔记，包括
参会者、决策、行动项和后续跟进链接。
---
# 会议记录处理 Skill
## 我的 Vault 约定
- 会议笔记放在 `02_Areas/Meetings/` 文件夹
- 命名格式：`YYYY-MM-DD 会议主题`
- 行动项用 `- [ ]` 格式，并 @提到负责人的 wikilink
- 每篇会议笔记必须链接到 `[[人员索引]]` 对应的人员笔记
## 处理流程
1. 识别所有参会者，在 `People/` 文件夹查找对应笔记
2. 提取所有决策（以"决定"/"同意"/"确认"开头的句子）
3. 提取所有行动项（以"需要"/"TODO"/"ACTION"开头的项目）
4. 用以下模板创建结构化会议笔记
5. 在每位参会者的笔记中追加本次会议的反向链接
## 输出模板
[你的标准会议笔记模板]
## 注意事项（Gotchas）
- 如果会议记录里有人名但找不到对应的 People 笔记，先创建空白笔记再链接
- 行动项的负责人必须用 [[wikilink]] 格式，不能只写名字
Step 4：用真实任务测试，把失败记录进 Skill
你越是通过 CLAUDE.md 和自定义 Skills 来完善它，它就越能反映你实际的思考和工作方式。让它以我想要的方式运行花了我一些时间，但它确实从根本上改变了我日常使用 Obsidian 的方式。
每次 AI 的输出和你的预期不符，把那个不符之处加进 Skill 的「注意事项」部分。这个迭代过程，就是 Skill 变得越来越有价值的过程。
Step 5：多 Vault 用户的特别说明
如果你有多个 Vault，可以利用 Claude Code 的架构，在父级目录定义通用的 Obsidian Skills，使其在所有子 Vault 中都可调用。
具体做法：将 Skills 放在 .claude/skills 目录（比你的 Vault 路径高一级），这样无需将这些 Skills 复制到每个 Vault 中。
行动建议：分三层，对应三种准备状态
🟢 今天（30 分钟内）
目标：验证 obsidian-markdown 的实际效果
确认 kepano/obsidian-skills 已克隆并安装（参考文章一的安装指南） 在 Claude Code 中运行 /obsidian-markdown激活 Skill给 AI 一个具体任务：「帮我为今天的工作写一篇 Obsidian 日记笔记，要有 frontmatter、至少一个 callout、至少两个 wikilinks」 对比输出：它是否生成了正确格式？frontmatter 完整吗？wikilinks 用的是 [[]]而不是[]()？
只做这一步。感受格式差异，确认它对你有价值，再继续。
🟡 本周（根据场景选择性安装）
目标：选择 1-2 个适合你场景的 Skill，完成第一次真实任务
根据你的主要使用场景，从以下路径中选一条：
如果你有大量笔记需要查询和过滤： → 检查你的笔记是否有规范 frontmatter → 安装 obsidian-bases，用真实阅读列表或项目创建第一个 Base 视图
如果你需要可视化概念关系： → 确认相关笔记之间已有 wikilinks → 安装 json-canvas，让 AI 生成一个你正在思考的知识领域的 Canvas
如果你习惯终端操作： → 确认 Obsidian v1.12+ 已安装并启用 CLI → 安装 obsidian-cli，用 obsidian orphans 找出你 Vault 里的孤立笔记
如果你有大量网页内容输入： → 安装 defuddle，处理下一篇要存入 Vault 的文章，感受噪音减少的效果
🔵 本月（构建你的第一个流程类 Skill）
目标：写出第一个属于你自己的 Skill，覆盖你最高频的重复操作
按照本文第五章的五个步骤进行：
打开 Claude Code，运行 /plugins安装 skill-creator识别你最想自动化的那个重复动作（从小事开始） 用对话方式告诉 skill-creator 你要做什么 用真实任务测试，把每一次修正加进 Skill 的「注意事项」 使用 2 周后，评估：这个 Skill 是否减少了你需要对 AI 重复说明的内容？
结语：官方套件是地基，你的工作流才是建筑
kepano 的仓库不是一个完成品，它是一个催化剂。它给社区提供了一种共同语言和起点。
这句话是对的。5 个官方 Skill 给了你和 AI 说话的共同语言——它们消除了格式鸿沟，让 AI 终于能写出"真正的 Obsidian 笔记"。
但语言只是工具。你用这个语言说什么，取决于你自己的思维方式、工作流程和知识结构。
2026 年最强大的 Obsidian 设置，不会是拥有最多插件的那些，而是拥有最经过深思熟虑的 Skills 的那些——那些让工具弯曲适应用户思维的微型自动化，而不是反过来。
官方 5 个 Skill 告诉 AI：「这是 Obsidian 的语法。」
你的流程类 Skill 告诉 AI：「这是我思考和工作的方式。」
两者组合在一起，才是一个真正理解你的 Agent。
下一篇预告：
现在你知道了 5 个官方 Skill 各自的用途和边界，也有了写第一个流程类 Skill 的基础框架。下一篇，我们进入最具代入感的场景实战：用 Bases Skill 管理 500 篇散落文章、用 Canvas Skill 可视化你的知识网络——完整的执行过程、真实的 Prompt、踩坑记录和效果量化，全部在一篇里。
→ 文章三：我用错了 6 个月：Obsidian Bases 和 Canvas 解决的根本不是同一个问题
AII
松花酿酒，春水煎茶。
眉上风止，见字如晤。
一只阿木木