Obsidian 三大核心 Skill 案例的完整实战报告
一只阿木木约 22 分钟——三大核心 Skill 案例的完整实战报告：阅读列表管理 + 知识网络可视化 + 两者组合
这篇文章写给谁： 已经安装了 Obsidian Bases Skill 或 Canvas Skill，但效果不如预期的用户；想在具体场景中看懂这两个工具如何配合 Agent 使用的知识工作者；有大量散落笔记、想建立可查询视图或可视化关系图的 Obsidian 中重度用户。
这篇文章不写给谁： 刚开始用 Obsidian 的新手（建议先读文章一和文章二）；Vault 里笔记不足 50 篇的用户（暂时用不到这些工具）。
开篇：一个普遍存在的误区，毁掉了 6 个月的效率
我在错误的场景用了 Bases 整整 6 个月。
不是因为 Bases 不好用——而是因为我从来没有真正搞清楚它解决的是哪类问题。
大多数人看到 Bases 和 Canvas，会产生一个直觉判断：「它们都是用来组织笔记的工具。」
这个判断，是对的——但精度不够。精度不够的判断，会让你在错误的场景用对的工具，最终什么都用不好。
来，先把这个判断校准一下：
Bases 是数据库视图层——它解决「找不到」的问题。Canvas 是关系可视化层——它解决「看不见关系」的问题。
这两个问题，表面上都和"笔记管理"有关，但本质上是截然不同的认知需求。用错工具的代价，是比不用工具更糟的结果：Bases 过度设计会让你淹没在维护成本里；Canvas 滥用会让你的 Vault 变成一面人人看不懂的贴纸墙。
通过两个实践案例可以证明 Obsidian Skills 的真实价值：通过 Bases Skill 管理阅读列表，以及通过 Canvas Skill 可视化知识网络——两者使 AI 成为知识管理中真正强大的助手。
但这两个案例能发挥价值的前提，是你先搞清楚"为什么选这个工具，而不是那个"。
这篇文章的核心任务，是帮你建立这个判断框架——然后通过三个完整案例，把框架落地到真实操作里。
第一章：先选工具，再选 Skill——一个必须前置的决策框架
在进入案例之前，先用一个清晰的决策框架校准认知：
text
你现在面对的核心问题是什么？
│
├── 「我有一堆笔记，我找不到我想要的那篇」
│ ├── 次级问题：找不到是因为太多？还是因为没有分类视图？
│ │ ├── 太多 + 缺乏过滤 → 你需要 Bases（+obsidian-bases Skill）
│ │ └── 缺乏全文搜索 → 你需要的是 obsidian-cli 的 search 命令
│ └── 前置条件：笔记有规范的 frontmatter 字段
│
├── 「我知道信息在哪里，但我看不清它们之间的关系」
│ ├── 次级问题：关系是层级关系？还是网络关系？
│ │ ├── 层级关系（步骤/流程） → 用 Markdown 列表或 Mermaid 图
│ │ └── 网络关系（概念/知识连接） → 你需要 Canvas（+json-canvas Skill）
│ └── 前置条件：笔记之间已有 wikilinks 连接
│
└── 「我两个问题都有」
→ 先解决 Bases（建立可查询视图），再做 Canvas（可视化关系）
→ 顺序很重要：Bases 是数据基础，Canvas 是展示层
Bases 是经典的 Obsidian 风格：「看起来像数据库，但本质上还是文件」。一个 .base 文件定义视图、筛选器、公式、汇总等，可以在 Obsidian 中以表格或卡片形式浏览笔记。若没有严格的格式规范，AI 倾向于搞错字段名称、嵌套或结构，Skill 的作用就是把它限定在正确轨道上。
Canvas 背后是开放的 JSON Canvas 格式（Obsidian 甚至发布了规范文档）。一个 .canvas 文件是带有固定 Schema 的 JSON，包含节点、连接和分组。没有规则约束，AI 会遗漏字段或嵌套错误——这个 Skill 教会 AI 遵循 Canvas 的 JSON Schema。
一个关键洞察：选错工具，比不用工具更糟。
原因是：Bases 有维护成本——它依赖笔记的 frontmatter 保持一致，一旦你的笔记结构发生变化，Base 视图可能失效。Canvas 有认知成本——一个超过 50 个节点的 Canvas 会变成认知负担，而不是认知工具。
用对了，它们是杠杆。用错了，它们是包袱。
第二章·案例 A：用 Bases Skill 管理 500 篇散落文章
这个案例写给： 有大量外部内容输入的用户——Readwise 用户、大量阅读文章的研究者、技术从业者。
不适合这个案例的场景： 你的 Vault 主要是自己写的笔记，而不是外部内容输入。
2.1 真实痛点：Readwise 把 500 篇文章同步进来，然后呢？
作为技术从业者，使用 Readwise 进行碎片化阅读，收集感兴趣的文章、推文和博客。Readwise 官方提供了 Obsidian 插件，自动将高亮和笔记同步到本地知识库。然而，同步的内容以独立的 Markdown 文件形式存在，缺乏用于管理和浏览的统一视图。
这是一个"内容进来了但找不到"的典型问题。
具体表现是这样的：
你想回顾上个月读过的某篇关于 AI Agent 的文章，你记得大概读过，但想不起来文件名 你打开 Obsidian，用搜索功能找，返回了 87 个结果 你翻了 10 分钟，没找到 你放弃了
这个体验反复出现，让你开始怀疑"记笔记有什么意义"。
但真正的问题不是笔记没用，而是：你没有一个支持过滤和排序的视图。
需求很清晰：想要创建一个"近期阅读文章"视图，以倒序显示所有读过的文章，方便回顾和管理。
这正是 Bases 的用武之地。
2.2 前置条件检查：Bases 能工作的先决要求
在安装 obsidian-bases Skill 并开始操作之前，必须先确认这一点：
如果笔记的 YAML frontmatter 结构不一致，Claude 只能猜测。
Obsidian Bases 不是一个常规的电子表格。它给你的是一张所有文件的表格，每个文件对应一行，列则是你在每个文件中定义的 frontmatter 字段。
用一个诚实的检查清单来评估你的 Vault 是否已经准备好：
text
Bases 前置条件检查
□ 你的笔记有 frontmatter 吗？
├── 大部分有（> 70%）→ 可以开始了
├── 一部分有（30-70%）→ 先用 obsidian-markdown Skill 批量补全
└── 几乎没有（< 30%）→ 先系统性地建立笔记模板，再来使用 Bases
□ frontmatter 字段名称一致吗？
├── 一致（type、date、status 等用法统一）→ 可以开始了
└── 不一致（有些用 "category"，有些用 "type"）→ 先统一字段命名
□ 你的文章笔记有 "type" 或类似的分类字段吗？
├── 有 → 可以直接用这个字段作为 Bases 的过滤条件
└── 没有 → 先让 AI 批量为文章笔记添加 type: article
如果你还没有规范的 frontmatter，正确的操作顺序是：
text
第一步：用 obsidian-markdown Skill 让 AI 为现有笔记补全 frontmatter
↓
第二步：确认核心字段（type、date、status）已在大部分笔记中统一
↓
第三步：再用 obsidian-bases Skill 创建视图
跳过前两步直接用 Bases，是 Bases Skill 使用效果差的最常见原因。
2.3 完整执行过程：从 Prompt 到 .base 文件生成
假设你的前置条件已经满足，现在开始正式操作。
Step 1：激活 obsidian-bases Skill
在 Claude Code 中运行：
text
/obsidian-bases
Step 2：给出一个精准的 Prompt
模糊的 Prompt 得到的是模糊的结果。精准的 Prompt 需要明确四件事：
text
使用 obsidian-bases Skill，为我的阅读笔记创建一个 Base 视图。
数据形状：
- 笔记的 frontmatter 中有 type、date、source、tags 字段
- type 为 "article" 的笔记是从 Readwise 同步来的文章
- date 字段格式是 YYYY-MM-DD
输出目标：生成一个有效的 .base 文件，保存在 /Views/ 文件夹
视图逻辑：
- 一个表格视图，按 date 降序排列，显示标题、source、date、tags
- 全局过滤器：只显示 type 为 "article" 的笔记
- 一个卡片视图，同样的过滤条件，按 source 分组
约束条件：
- 公式保持简单
- 如果 date 字段为空的笔记，排到最后显示
AI 自动识别并激活 Obsidian Bases Skill，生成一个符合 Base 格式规范的 .base 文件。
Step 3：生成的 .base 文件结构示例
YAML
# /Views/阅读列表.base
filters:
and:
- type.eq: article
views:
- type: table
name: 文章时间线
sort:
- property: date
direction: desc
columns:
- property: file.name
name: 标题
- property: source
name: 来源
- property: date
name: 阅读日期
- property: tags
name: 标签
- type: cards
name: 按来源分组
group:
property: source
sort:
- property: date
direction: desc
Step 4：在 Obsidian 中验证
打开生成的 .base 文件，确认：
过滤器是否正确只显示文章类型的笔记 排序是否按日期倒序 字段名称是否与你实际的 frontmatter 一致
如果有字段名称不匹配的问题，告诉 AI：「source 字段在我的笔记里实际叫做 url，请修正 Base 文件」——AI 会直接修改 .base 文件，不需要你手动调整 JSON。
2.4 效果量化：从"找不到"到"10 秒过滤"
这个功能对需要管理大量阅读材料的知识工作者特别有用——研究者、博主、学生都可以使用类似的方法管理他们的知识输入。
具体的前后对比：
status != "finished" 过滤器，即时可见 |
这不是在说"效率提升了 X 倍"这种模糊的描述——这是在说：一类之前根本无法完成的操作，现在变得可行了。
2.5 真实边界：Bases 在什么时候会失败
必须诚实说明以下几点：
边界一：Bases 不是全文搜索，它是属性过滤器。
你只能过滤 frontmatter 中已有的属性字段。如果你想根据笔记"正文里提到了什么"来过滤，Bases 做不到——你需要 obsidian search 命令。
边界二：Bases 依赖 frontmatter 一致性，一旦维护中断，视图就失效。
如果你某天停止给新文章笔记添加 type: article，这篇笔记就不会出现在 Base 视图里。Bases 的有效性，和你的 frontmatter 维护习惯直接挂钩。解决方案是：用 AI 创建一个「新文章入库」的流程类 Skill，让每篇新笔记自动获得完整的 frontmatter。
边界三：过多的 Base 文件本身会变成管理负担。
Bases 功能允许创建各种各样的 Base 文件，甚至 Base 的 Base，这会导致大量单独的 Base 文件分散在 Vault 各处。
建议：每个使用场景对应一个 Base 文件，不要为每个细分过滤条件都创建独立的 Base。 用视图（views）的切换来处理不同的展示方式，而不是创建多个 Base 文件。
边界四：Bases 不擅长处理层级关系。
如果你需要展示项目和子任务的父子关系，Canvas 比 Bases 更合适。Bases 的强项是"横向比较"，而不是"纵向层级"。
第三章·案例 B：用 Canvas Skill 可视化 Kubernetes 知识网络
这个案例写给： 在某个领域积累了大量分散笔记、需要建立全局视图的用户；需要向他人解释复杂知识体系的研究者、技术作者、教育者。
不适合这个案例的场景： 你的笔记还很少（< 20 篇）；你需要展示的是线性流程而不是网络关系。
3.1 真实痛点：知识在脑子里，但画不出来
一位技术作者在多年前写了多篇关于 Kubernetes 网络的博客文章，涵盖 CNI、Service Mesh、网络策略、Ingress 等主题，这些文章散落在"笔记"目录中，虽然相互引用，但缺乏一个展示它们之间关系的全局视图。需求是创建一个可视化思维导图，连接所有 Kubernetes 网络相关笔记，形成清晰的知识地图。
这是一个"信息在那里，但关系看不见"的典型问题。
更普遍的版本是这样的：
你积累了几十篇关于某个领域的笔记，每篇都写得不错，笔记之间也有 wikilinks 连接。但是，当你试图向别人解释这个领域的全貌，或者试图在这个领域找到自己的知识盲点时——你发现自己需要在大脑里把所有笔记"串联"起来，这个过程既费力又不可靠。
Obsidian Canvas 自动化是指通过 Claude Code 的 Agent 能力和 obsidian-skills 插件，利用自然语言指令自动研究材料、梳理逻辑关系并生成结构化 Canvas 知识图谱的工作流。这个工作流结合了 AI 搜索能力、逻辑推理和 Canvas 可视化，将"从想法到知识图谱"的时间从几小时缩短到几分钟。
3.2 前置条件检查：Canvas 能工作的先决要求
与 Bases 依赖 frontmatter 不同，Canvas 依赖的是另一个维度的数据质量：
text
Canvas 前置条件检查
□ 你的笔记之间有 wikilinks 连接吗？
├── 有（大部分相关笔记之间已经有 [[链接]]）→ 可以开始了
└── 没有或很少 → 先用 obsidian-markdown Skill 让 AI 补全 wikilinks
□ 你想要可视化的笔记数量在合理范围吗？
├── 5-30 篇 → 非常适合 Canvas
├── 30-50 篇 → 可以，但需要分组和分层
└── 50 篇以上 → 建议先用 Obsidian 内置图谱视图做全局探索，
然后聚焦某个子领域再生成 Canvas
□ 你需要展示的是"关系"还是"流程"？
├── 关系（概念之间的连接、引用、依赖）→ 适合 Canvas
└── 流程（步骤 1→2→3→完成）→ 用 Markdown 列表或 Mermaid 更合适
一个特别重要的提醒：
如果没有安装 Skills，Claude 不了解 Obsidian 的图谱关系或 Canvas 的空间布局。Skills 有帮助，但它们是基于指令的——Claude 读取这些概念的描述，它并不能"看到"可视化图谱本身。
这意味着：Canvas Skill 让 AI 学会了"写正确的 .canvas 文件"，但 AI 是通过读取你的笔记文本和 wikilinks 来理解关系的，而不是通过视觉感知。笔记内容越清晰、wikilinks 越完整，AI 生成的 Canvas 质量越高。
3.3 完整执行过程：从自然语言到可打开的 .canvas 文件
Step 1：激活 json-canvas Skill
在 Claude Code 中运行：
text
/json-canvas
Step 2：给出一个精准的 Prompt
一个过于模糊的指令（❌ 「生成 Kubernetes 知识图谱」）不如一个范围有限的指令（✅ 「生成前 5 个 Kubernetes 网络概念的关系图，只包含名称、核心功能和主要关联」）。也可以分阶段生成：先生成主框架，再逐步细化。
针对 Kubernetes 知识网络的完整 Prompt：
text
使用 json-canvas Skill，扫描我的 Notes/Kubernetes/ 目录下的所有笔记，
创建一个展示 Kubernetes 网络知识体系的知识地图 Canvas。
要求：
- 每篇笔记对应一个节点（使用 file 类型节点，直接引用 .md 文件）
- 根据笔记之间的 wikilinks 建立边连接
- 将关联紧密的笔记分组（如：CNI 相关、Service Mesh 相关、Ingress 相关）
- 核心概念节点使用较大尺寸（width: 300），次级节点使用标准尺寸（width: 200）
- 保存为 Views/Kubernetes-知识地图.canvas
布局提示：
- 核心概念放在中心区域
- 按主题分组排布在核心概念周围
- 同组内的节点相互靠近，不同组之间有明显间距
Step 3：观察 AI 的执行过程
AI 自动识别并激活 JSON Canvas Skill，生成一个符合 Canvas 格式规范的 .canvas 文件，包含完整的节点、分组和边的布局。
Agent 的工作步骤大致是：
读取指定目录下的所有 .md文件扫描每篇笔记的 wikilinks，建立关系图谱 根据主题词和标签将笔记分组 按照 JSON Canvas 的 Schema 生成节点、分组和边 写入 .canvas文件
Step 4：生成的 .canvas 文件结构示意
JSON
{
"nodes": [
{
"id": "g1",
"type": "group",
"label": "CNI 插件",
"x": -400, "y": -200,
"width": 500, "height": 400,
"color": "1"
},
{
"id": "n1",
"type": "file",
"file": "Notes/Kubernetes/Flannel 网络方案.md",
"x": -380, "y": -180,
"width": 220, "height": 120
},
{
"id": "n2",
"type": "file",
"file": "Notes/Kubernetes/Calico 策略控制.md",
"x": -140, "y": -180,
"width": 220, "height": 120
},
{
"id": "n_core",
"type": "text",
"text": "## Kubernetes 网络\n核心：Pod 间通信、Service 路由、外部访问",
"x": 0, "y": 0,
"width": 300, "height": 150,
"color": "3"
}
],
"edges": [
{
"id": "e1",
"fromNode": "n_core", "fromSide": "left",
"toNode": "n1", "toSide": "right",
"label": "网络插件之一"
},
{
"id": "e2",
"fromNode": "n1", "fromSide": "right",
"toNode": "n2", "toSide": "left",
"label": "功能互补"
}
]
}
Step 5：在 Obsidian 中打开和调整
AI 生成的 Canvas 只是起点，你可以在 Obsidian 中打开并手动调整它——AI 生成的是基础结构，你来做最终的精细化。
推荐的调整流程：
打开 .canvas文件，检查整体布局是否合理调整节点位置（拖拽），让分组更清晰 如果有遗漏的连接，在 Obsidian 里手动添加 根据重要性调整颜色和大小
3.4 一个更进阶的 Canvas Prompt：颜色编码 + 布局控制
你可以在 Prompt 中指定视觉元素：「不同类别使用不同颜色：蓝色代表人物，黄色代表事件，绿色代表地点。」也可以指定节点大小：「重要节点用大卡片，次要信息用小卡片。」
一个带完整视觉控制的进阶 Prompt：
text
使用 json-canvas Skill，为以下主题创建一个带颜色编码的知识地图：
主题：Agent Skills 生态系统
来源：我的 Notes/AI/ 目录下标签包含 #ai/agent 的所有笔记
布局规则：
- 核心概念节点（file.name 包含"规范"或"架构"）：居中，color: "6"（紫色），width: 280
- 工具类节点（file.name 包含"Skill"）：分布在左侧，color: "1"（红色），width: 200
- 案例类节点（file.name 包含"案例"或"实战"）：分布在右侧，color: "2"（橙色），width: 200
- 分组：将同类节点用 group 框起来，group 的 label 用中文
连接规则：
- 有直接 wikilink 引用的笔记之间绘制边
- 边的 label 使用被引用上下文的核心词（1-3个字）
保存为：Views/Agent-Skills-生态图.canvas
3.5 真实边界：Canvas 在什么时候会失败
边界一：Canvas 不适合超过 50 个节点的网络。
当节点数量突破这个阈值，Canvas 会变成一堆密集的方块，可读性急剧下降。大规模知识网络用 Obsidian 的内置图谱视图更合适；Canvas 的强项是「聚焦的、可打印的、可分享的」关系呈现。
边界二：Canvas 是静态快照，不自动同步。
AI 生成 Canvas 是基于当前笔记状态的快照。你下周新增了 5 篇笔记，Canvas 不会自动更新——你需要重新生成或手动补充节点。不要把 Canvas 当成实时的动态视图，把它当成"某一时刻的全局快照"，定期（每月/每季度）重新生成一次。
边界三：AI 只能读文字，不能感知视觉布局的优雅程度。
Claude 读取这些格式概念的描述，它并不能"看到"视觉图谱本身。
AI 生成的 Canvas 布局通常是功能正确但视觉粗糙的——节点排列是机械的，间距是默认的，不会有人类设计师的审美判断。把 AI 生成的 Canvas 当作 80% 完成的草稿，最后 20% 的视觉调整由你来完成。
边界四：过于模糊的范围会让 AI 无所适从。
「帮我画一个关于我所有笔记的知识图谱」——这会让 AI 尝试处理几百篇笔记，生成一个巨大的、无法阅读的 Canvas 文件。始终给 AI 一个明确的范围：特定目录、特定标签、特定主题词。
边界五：Canvas 节点的 ID 必须唯一，AI 偶尔会生成重复 ID。
如果生成的 .canvas 文件在 Obsidian 中打不开，用这个命令验证 JSON 是否合法：
Bash
cat your-file.canvas | python3 -m json.tool
如果报错，让 AI 修正：「这个 Canvas 文件的 JSON 有格式错误，请检查并修复」。
第四章·案例 C：Reading Queue Manager——Bases + Canvas 的真实组合
前两个案例是独立的。这个案例展示两者配合时，能做什么用单一工具做不到的事。
场景描述：
你是一个重度阅读者。你的 Vault 里有：
00-Inbox/：每天捕获的待读文章（通过 Readwise 自动同步或手动添加） 01-Read/：已读并整理过的文章笔记 02-Archived/：已完成、不再需要主动回顾的文章
你想要：
一个动态视图：随时查看还有多少篇待读，按优先级过滤 一个月度快照：每月底生成一个"本月阅读总结 Canvas"，回顾读了什么、形成了哪些洞见
4.1 第一层：用 Bases 建立"待读队列"动态视图
Prompt：
text
使用 obsidian-bases Skill，为我的阅读队列创建一个 Base 视图。
说明：
- 我的待读文章在 00-Inbox/ 目录
- frontmatter 字段：type（article/book/video）、priority（high/medium/low）、
added_date（YYYY-MM-DD）、estimated_minutes（预估阅读时长）
要求：
- 全局过滤器：只显示 00-Inbox/ 目录下的内容
- 视图一：按 priority 分组的卡片视图，每张卡片显示标题、来源、预估时长
- 视图二：按 added_date 升序的表格视图（最早加入的排在最前，防止遗忘）
- 添加一个 total_minutes 的汇总，显示待读内容的总预估时长
- 保存为 Views/阅读队列.base
obsidian-bases 教会 Agent 如何创建和管理 Bases——Obsidian 的结构化数据层，包含带类型化属性、过滤器、排序和视图的数据库。AI 可以自动生成 CRM 表格、Sprint 追踪器或研究数据库。
4.2 第二层：用 Canvas 生成月度阅读总结
Reading Queue Manager 对于使用 Obsidian 管理阅读清单的用户来说极具价值：它监控"待读"笔记，检查是否添加了 finished_date，将已完成条目移至阅读归档。附加功能：它还可以生成月度阅读报告 Canvas。
每月底执行一次的 Prompt：
text
使用 json-canvas Skill，为本月（2026年3月）阅读完成的文章生成一个月度总结 Canvas。
数据来源：
- 扫描 01-Read/ 目录下，frontmatter 中 finished_date 在 2026-03-01 到 2026-03-31 之间的所有笔记
Canvas 结构：
- 主节点：一个文本节点"2026年3月阅读总结"，放在中心
- 按 tags 将文章分组（group），每个主题一个分组
- 每篇文章创建一个 file 类型节点，连接到对应的主题分组
- 添加一个"洞见汇总"文本节点，让 AI 从所有文章中提炼 3-5 条主要洞见
视觉规范：
- 主节点：color: "6"（紫色），width: 300
- 主题分组框：color: "1"（红色）
- 各文章节点：默认颜色，width: 200
保存为 Monthly-Reviews/2026-03-阅读总结.canvas
4.3 为什么这个组合有意义：分工清晰，各司其职
技能擅长将信息从一种状态转化为另一种状态——它们是知识库的"工厂工人"，处理重复性工作，让你专注于思考。
在这个组合里，两个工具的分工非常清晰：
| Bases | ||
| Canvas |
两者不是替代关系，而是时间维度上的互补：Bases 管理日常流动（动态），Canvas 记录阶段性成果（静态）。
这个区分也是一个更普遍的设计原则：用 Bases 管理你需要实时操作的信息，用 Canvas 呈现你需要定期回顾或对外分享的信息。
第五章：三个常见踩坑场景，和对应的解法
这些不是理论上可能发生的问题，而是在真实使用过程中高频出现的坑。
踩坑一：Base 视图显示的笔记数量和预期不符
症状： 你的 Vault 里明明有 200 篇文章笔记，但 Base 视图只显示了 37 篇。
根本原因： 有 163 篇笔记没有 type: article 这个 frontmatter 字段，或者字段值拼写不一致（Article、articles、blog……）。
解法：
text
使用 obsidian-markdown Skill，扫描 Notes/Reading/ 目录下所有没有 type 字段的笔记，
为每篇笔记添加 type: article 到 frontmatter。
不要修改笔记的正文内容，只添加缺失的 frontmatter 字段。
执行前，先让 AI 只生成一个报告而不做修改：
text
扫描 Notes/Reading/ 目录，统计以下情况：
1. 有 type 字段且值为 "article" 的笔记数量
2. 有 type 字段但值不是 "article" 的笔记（列出所有不同的值）
3. 没有 type 字段的笔记数量
生成一份报告，不做任何修改。
先看清楚问题的规模，再决定如何批量修复。
踩坑二：Canvas 文件在 Obsidian 中无法打开
症状： AI 生成了 .canvas 文件，但双击打开只显示空白或报错。
根本原因： JSON 格式有问题——可能是节点 ID 重复、必要字段缺失，或者 JSON 语法错误（比如多了一个逗号）。
解法（三步走）：
第一步：在终端验证 JSON 是否合法：
Bash
cat Views/你的文件.canvas | python3 -m json.tool
如果输出报错，说明 JSON 本身有语法问题。
第二步：告诉 AI 修复：
text
这个 Canvas 文件无法在 Obsidian 中正常打开。
请检查以下常见问题：
1. 所有 id 字段是否唯一（不能有重复）
2. 所有节点是否有完整的必要字段（id、type、x、y、width、height）
3. 所有边是否有完整的必要字段（id、fromNode、toNode）
4. JSON 语法是否正确（括号匹配、逗号位置）
修复后重新写入文件。
第三步：如果问题持续出现，在 Prompt 里加入防御性约束：
text
在生成 Canvas 文件前，先检查：
- 所有节点 ID 是否唯一（用 node_1、node_2 这样简单的格式，避免重复）
- 生成完成后，再检查一遍 JSON 结构是否合法
踩坑三：Canvas 布局太乱，节点全部堆叠在一起
症状： Canvas 文件打开了，但所有节点都叠在同一个位置，完全无法阅读。
根本原因： AI 在没有明确布局指令的情况下，倾向于把所有节点的 x、y 坐标都设为 0 或非常接近的值。
解法： 在 Prompt 里明确指定坐标规则：
text
布局规则（请严格遵守）：
- 主节点：x: 0, y: 0（中心）
- 第一组节点：x 从 -800 到 -400，y 从 -300 到 300
- 第二组节点：x 从 400 到 800，y 从 -300 到 300
- 同组内的节点之间 x 或 y 间隔至少 180（防止重叠）
- 分组框（group）的 x、y 要比内部节点各小 40（留出边距）
或者，给 AI 一个更简单的布局规范：
text
布局要求：
- 使用网格布局，每行放 3 个节点
- 节点宽度统一为 200，高度统一为 120
- 节点之间水平间距 260（200 + 60 间隔），垂直间距 180（120 + 60 间隔）
- 从左上角 (-600, -300) 开始排列
行动建议：分三层，对应三种准备状态
🟢 今天（30 分钟内）
目标：用决策框架诊断你的 Vault，搞清楚你最需要哪个工具
打开你的 Vault，回答这两个问题： 「我最近一次因为找不到一篇笔记而花了 5 分钟以上，这个情况是否经常发生？」 「我是否有一个领域，在里面积累了 10 篇以上的笔记，但从来没有建立过全局视图？」 根据回答，做出第一个判断： 「找不到笔记」是你的主要痛点 → 今天的重点是 Bases Skill + frontmatter 质量检查 「看不见关系」是你的主要痛点 → 今天的重点是 Canvas Skill + wikilinks 完整性 执行"前置条件检查"（参考本文第二章和第三章的检查清单）
只做诊断，不要急着生成。知道自己的起点在哪里，比急于操作更重要。
🟡 本周（完成第一个真实场景）
目标：选择一个场景，完整执行一次，感受真实效果
路径 A——选择 Bases 场景（如果你的主要痛点是"找不到"）：
确认你有规范 frontmatter 的笔记（至少 20 篇） 如果没有：先用 obsidian-markdown Skill 批量补全 frontmatter 用本文案例 A 的完整 Prompt 模板，生成第一个阅读列表 Base 在 Base 视图里执行一次真实查询（找到上个月读过的某篇文章） 记录：这比手动搜索节省了多少时间？
路径 B——选择 Canvas 场景（如果你的主要痛点是"看不见关系"）：
选择一个你积累了 10-20 篇笔记的领域 确认这些笔记之间已有 wikilinks 连接（如果没有，先补全） 用本文案例 B 的完整 Prompt 模板，生成第一个知识地图 Canvas 在 Obsidian 里打开 Canvas，手动调整 2-3 个节点的位置 记录：这个视图是否帮你发现了一个之前没意识到的知识盲点？
🔵 本月（建立组合工作流）
目标：让 Bases 和 Canvas 形成真正的协作机制
完成案例 C 的 Reading Queue Manager 的第一层（Bases 阅读队列视图） 在月底执行一次月度总结 Canvas 生成 对比两个工具的效果：哪一个对你来说价值更高？ 根据一个月的使用体验，写出你的第一个流程类 Skill： 如果 Bases 价值更高：写一个「新文章入库」Skill，让每篇新文章自动获得标准化 frontmatter 如果 Canvas 价值更高：写一个「月度知识地图」Skill，把月度 Canvas 生成变成一个可复用的工作流
结语：选对工具 > 会用工具
回到开篇的那个问题：我为什么用错了 Bases 整整 6 个月？
Obsidian Bases 不是我原先想象中的那种常规电子表格——它是一张所有文件的表格，每个文件对应一行，列是你在每个文件中定义的 frontmatter 字4段。
我原先以为 Bases 能解决的问题，其实是"笔记组织不清晰"——但这个问题，Bases 没有能力解决，因为它是视图层，不是组织层。
我用 Bases 创建了很多视图，但视图的底层数据（frontmatter）从来没有认真维护。结果是：一个过滤器什么都过滤不出来，一个排序永远是乱的，然后我得出了"Bases 没用"的结论。
后来我才意识到：Bases 是一面镜子，它能照出来的，只有你放进去的东西。如果数据结构混乱，镜子里只有混乱的倒影。
Canvas 的误区是另一个方向——很多人把它用成了"炫技工具"：画出一个看起来很复杂的知识图谱，然后发现它除了好看以外没有实际价值，因为没有人真的会去阅读那张图。
真正的稀缺不是工具，而是将知识组织得足够清晰、让 AI 真正能使用的能力。大多数人的 Obsidian Vault 都是数字堆肥堆。与其安装这个列表上的每一个插件，不如花一个下午整理你的笔记——这会带来更多的实际价7值。
工具从来不是问题的答案——工具是你把问题想清楚之后，用来执行的手段。
你需要识别工作流中的摩擦点，然后自己构建解决方案。这种能力本身就很有价值——远比又下载一个插件更有价9值。
Bases 和 Canvas 的 Skill，给了 AI 说 Obsidian 语言的能力。
但哪个问题值得解决，怎么定义"有用的视图"，哪些笔记之间的关系值得可视化——这些判断，仍然需要你来做。
AI 是工具，你是系统的设计者。 只有在这个角色分配清晰的前提下，Bases 才真的有用，Canvas 才真的有价值。
下一篇预告：
你已经知道了「Bases 管什么」「Canvas 管什么」「怎么组合使用」。
但所有这些，都只是知识管理的局部自动化。
下一篇，我们进入最终形态：如何用 Claude Code + Obsidian 构建一个完整的自动化知识工作系统——从 Vault 急救、Inbox 处理、反向链接自动化，到 Session 记忆机制和云端部署，一套从零到系统的完整工作流，以及在这个过程中，哪些环节 AI 真的能帮到你，哪些环节只能靠你自己。
→ 文章四：你的 Obsidian 知识库是一座金矿，但你一直在用手挖——Claude Code 是挖掘机
AII
松花酿酒，春水煎茶。
眉上风止，见字如晤。
一只阿木木