如何为 obsidian-skills 写测试用例5 个技能从验证到排障的完整指南【免费下载链接】obsidian-skillsAgent skills for Obsidian. Teach your agent to use Obsidian CLI and open formats including Markdown, Bases, JSON Canvas.项目地址: https://gitcode.com/GitHub_Trending/ob/obsidian-skills代理跟你说画布文件已生成你打开那个.canvas——一块白布一个节点都没有。检查内容发现edges里的toNode指向了一个从未创建的节点 ID。语法本身没毛病错的是引用关系而这类错误只有跑一遍验证流程才能抓到。这篇文章以 obsidian-skills 为例带你走完一套完整的测试生命周期搭环境、写用例、跑起来、看结果、排故障。obsidian-skills 是一组给 AI 代理用的 Obsidian 技能覆盖 Flavored Markdown、Bases 数据库视图、JSON Canvas 画布、Obsidian CLI 以及用 Defuddle 从网页提取正文。下面每个技能我都会给一个最小可运行的验证示例和一个真实踩过的坑。为什么值得花时间先看三次典型翻车这节解决的问题是让你相信多花十分钟验证比事后返工便宜。案例一Bases 公式写了但没定义。代理在.base视图的order里引用了formula.word_count但formulas段落里没有这个 key。文件是合法 YAMLYAML 解析器不报任何错Obsidian 里这一列就是空的。验证点应该是order里出现的每个formula.X都能在formulas里找到对应定义。案例二Canvas 换行写成了字面量。文本节点里想换行JSON 里写成了\\n。Obsidian 会老老实实把\和n两个字符画出来。正确写法是 JSON 字符串里的\n。这个坑在 skills/json-canvas/ 的说明里专门标了出来但只有拿一个真实最小文件去解析验证你才知道代理生成时会不会犯。案例三CLI 命令成功了结果落到了别的保险库。obsidian命令默认作用于最近聚焦的保险库。测试环境里开过两个 vaultcreate 之后去 A 库找文件文件其实在 B 库。验证时必须带上vault名字显式指定再把产物读回来比对。动手前先把最小测试环境搭起来这节解决的问题是用最少的准备让五类技能都有东西可测。# 1. 拿到技能定义每个技能就是一个 SKILL.md 加参考资料 git clone https://gitcode.com/GitHub_Trending/ob/obsidian-skills # 2. 装 defuddle网页提取技能才有东西可调 npm install -g defuddle再准备三样测试素材各花几分钟一个空保险库里面放 3~5 条普通笔记其中一条带status、tags属性——这是 obsidian-bases 过滤器和 obsidian-cli 搜索的靶子一个含各种写法的网页 URL带目录、广告、标题描述齐全的长文留给 defuddle 做提取对照一个已有的.canvas文件含两个节点一条边用来测往已有画布里加东西而不是每次从零生成。环境上有一个绕不开的前提obsidian-cli 的所有命令都要求Obsidian 正在运行这一类用例属于集成测试无法在无 GUI 的机器上跑其余四类markdown、bases、canvas、defuddle的产物都可以离线用解析器验证这是后面执行策略的基础。用例怎么写才算对语法、结构、功能每个技能验一件事这节解决的问题是给每个技能定一条最小验证线一条不过就重写而不是列几十项 checklist。用一条 wikilink 和一块 callout 验 obsidian-markdown语法类技能最怕看起来对。最小用例让代理生成一条包含[[笔记名#标题]]内部链接、一个 [!warning]标注框、一处![[图片.png|300]]嵌入的笔记然后检查三件事链接指向的笔记真实存在、标注框类型在 skills/obsidian-markdown/references/CALLOUTS.md 列出的合法类型里、嵌入语法带了!前缀。踩坑点wikilink 指向不存在的笔记时编辑器不会报错只是渲染成红色断链——所以验证项里要包含链接目标存在性而不是只看括号配对。用 10 行 .base 文件验 obsidian-bases结构类技能看的是引用闭合。最小用例filters: and: - status active views: - type: table name: 进行中 order: - file.name - status跑起来后看两点过滤器命中的笔记和你在保险库里手工筛选的一致order里的属性在笔记 frontmatter 里都能找到。踩坑点YAML 里含、(之类的字符串必须加引号代理图省事写裸字符串时要么解析失败要么行为诡异这类问题用任何 YAML 解析器一跑就现形。用 2 节点 1 边的小画布验 json-canvas这是五个技能里结构性最强的一个最小用例就两个节点一条边{ nodes: [ { id: 6f0ad84f44ce9c17, type: text, x: 0, y: 0, width: 400, height: 200, text: 起点 }, { id: a1b2c3d4e5f67890, type: text, x: 500, y: 0, width: 400, height: 200, text: 终点 } ], edges: [ { id: b2c3d4e5f6071829, fromNode: 6f0ad84f44ce9c17, toNode: a1b2c3d4e5f67890, fromSide: right, toSide: left } ] }验证写成一个动作序列JSON 能解析 → 节点 ID 是 16 位十六进制且互不重复 →fromNode/toNode都能在 nodes 里找到 →fromSide/toSide取值在 top/right/bottom/left 之内。skills/json-canvas/references/EXAMPLES.md 里有可直接对照的完整示例。踩坑点往已有画布加节点时新生成的 ID 必须和现存 ID 不冲突这是增量修改场景下最容易翻车的一步所以前面环境准备里特意留了那个已有.canvas。用一次 create read 闭环验 obsidian-cli功能类技能验的是命令产生预期副作用。最小用例两条命令obsidian vaultTestVault create name冒烟测试 content# 测试 silent obsidian vaultTestVault read file冒烟测试预期第二条命令的输出包含# 测试。这个写入→读回闭环能同时验证命令语法、vault 指向、silent 标志三个点。踩坑点参数值带空格必须整体加引号多行内容用\n表示换行另外所有 CLI 用例都依赖 Obsidian 进程存活跑之前先确认应用开着否则失败信息会指向一个根本不存在的错误。用一篇长文页验 defuddle提取类技能验的是干净程度。最小用例defuddle parse 长文URL --md defuddle parse 长文URL -p title预期--md输出的正文里看不到导航菜单、cookie 弹窗之类的杂质标题层级完整-p title的输出和页面title一致。踩坑点defuddle 对以.md结尾的 URL 不适用那本来就是 markdown直接抓取即可如果你的测试语料里混了 markdown 原文站先把它们剔除否则会误判提取质量。跑起来之后怎么组织执行结果怎么算过这节解决的问题是同样的用例什么时候跑、到什么程度算通过。按依赖强度把用例分三档节奏跟着走档位内容什么时候跑离线快测markdown / bases / canvas 产物交给解析器验证JSON.parse、YAML 解析、引用闭合检查每次改完技能说明或代理配置后秒级返回单命令功能测defuddle 对固定 URL 的输出比对每天或依赖升级后集成闭环测obsidian-cli 的 create→read、搜索、property:set 全链路提交前且必须在有 Obsidian 的机器上判断算过的标准建议统一成两条机器可判定的部分不靠眼睛。canvas 用脚本解析检查引用defuddle 的输出和一份人工校对过的基准文件做 diffBases 的过滤结果和手工筛选结果逐条比对。人眼看 markdown 渲染留给最后一步只看不判。预期输出要固定。给每个用例指定固定的输入固定的测试笔记、固定的 URL、固定的旧画布这样两次运行之间出现的差异一定是技能的行为变化而不是输入变了。用例卡住时先查这三处这节解决的问题是失败信息五花八门但 90% 的卡壳集中在这三个层面按顺序排除不用满仓库找原因。第一处产物到底落盘了没有。先ls看文件在不在、是不是被overwrite类标志影响、路径是不是你想的那个 vault。CLI 类失败有一半停在这里——命令成功了文件在别的保险库。第二处语法本身过不过解析。不急着打开 Obsidian先离线跑一遍python -c import json,sys; json.load(open(x.canvas))验 JSON用任意 YAML 解析器验.base。解析都过不了后面全不用看解析过了还报错说明问题在语义层。第三处引用是否闭合。JSON 解析通过后依然白屏、YAML 解析通过后列是空的几乎都是这一层edge 指向了不存在的节点、formula.X没在formulas里定义、wikilink 指向了不存在的笔记。写一个小脚本遍历检查引用目标是否存在比反复打开 Obsidian 重启快得多。三处都排除了还没好再怀疑环境Obsidian 版本是否支持 Bases、CLI 是否连上了正确实例、defuddle 版本是否过旧。环境问题是最后查的因为它最贵也最不像bug。今天就落地的三步建一个 5 条笔记的 TestVault按第二节的清单备齐三样素材成本大约十分钟给 canvas 和 bases 各写一条最小用例第二节的 10 行.base和 2 节点画布可以直接抄跑通生成→解析→引用闭合的完整验证链把 create→read 闭环加上 defuddle 的 title 比对凑齐五个技能各一条冒烟用例以后每次改动先跑这一轮全绿再谈别的。测试用例的价值不在数量在那条最小验证线能不能拦住真实翻车。先把五个技能的冒烟线跑绿再逐步往边界场景加深度。【免费下载链接】obsidian-skillsAgent skills for Obsidian. Teach your agent to use Obsidian CLI and open formats including Markdown, Bases, JSON Canvas.项目地址: https://gitcode.com/GitHub_Trending/ob/obsidian-skills创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
如何为 obsidian-skills 写测试用例：5 个技能从验证到排障的完整指南
如何为 obsidian-skills 写测试用例5 个技能从验证到排障的完整指南【免费下载链接】obsidian-skillsAgent skills for Obsidian. Teach your agent to use Obsidian CLI and open formats including Markdown, Bases, JSON Canvas.项目地址: https://gitcode.com/GitHub_Trending/ob/obsidian-skills代理跟你说画布文件已生成你打开那个.canvas——一块白布一个节点都没有。检查内容发现edges里的toNode指向了一个从未创建的节点 ID。语法本身没毛病错的是引用关系而这类错误只有跑一遍验证流程才能抓到。这篇文章以 obsidian-skills 为例带你走完一套完整的测试生命周期搭环境、写用例、跑起来、看结果、排故障。obsidian-skills 是一组给 AI 代理用的 Obsidian 技能覆盖 Flavored Markdown、Bases 数据库视图、JSON Canvas 画布、Obsidian CLI 以及用 Defuddle 从网页提取正文。下面每个技能我都会给一个最小可运行的验证示例和一个真实踩过的坑。为什么值得花时间先看三次典型翻车这节解决的问题是让你相信多花十分钟验证比事后返工便宜。案例一Bases 公式写了但没定义。代理在.base视图的order里引用了formula.word_count但formulas段落里没有这个 key。文件是合法 YAMLYAML 解析器不报任何错Obsidian 里这一列就是空的。验证点应该是order里出现的每个formula.X都能在formulas里找到对应定义。案例二Canvas 换行写成了字面量。文本节点里想换行JSON 里写成了\\n。Obsidian 会老老实实把\和n两个字符画出来。正确写法是 JSON 字符串里的\n。这个坑在 skills/json-canvas/ 的说明里专门标了出来但只有拿一个真实最小文件去解析验证你才知道代理生成时会不会犯。案例三CLI 命令成功了结果落到了别的保险库。obsidian命令默认作用于最近聚焦的保险库。测试环境里开过两个 vaultcreate 之后去 A 库找文件文件其实在 B 库。验证时必须带上vault名字显式指定再把产物读回来比对。动手前先把最小测试环境搭起来这节解决的问题是用最少的准备让五类技能都有东西可测。# 1. 拿到技能定义每个技能就是一个 SKILL.md 加参考资料 git clone https://gitcode.com/GitHub_Trending/ob/obsidian-skills # 2. 装 defuddle网页提取技能才有东西可调 npm install -g defuddle再准备三样测试素材各花几分钟一个空保险库里面放 3~5 条普通笔记其中一条带status、tags属性——这是 obsidian-bases 过滤器和 obsidian-cli 搜索的靶子一个含各种写法的网页 URL带目录、广告、标题描述齐全的长文留给 defuddle 做提取对照一个已有的.canvas文件含两个节点一条边用来测往已有画布里加东西而不是每次从零生成。环境上有一个绕不开的前提obsidian-cli 的所有命令都要求Obsidian 正在运行这一类用例属于集成测试无法在无 GUI 的机器上跑其余四类markdown、bases、canvas、defuddle的产物都可以离线用解析器验证这是后面执行策略的基础。用例怎么写才算对语法、结构、功能每个技能验一件事这节解决的问题是给每个技能定一条最小验证线一条不过就重写而不是列几十项 checklist。用一条 wikilink 和一块 callout 验 obsidian-markdown语法类技能最怕看起来对。最小用例让代理生成一条包含[[笔记名#标题]]内部链接、一个 [!warning]标注框、一处![[图片.png|300]]嵌入的笔记然后检查三件事链接指向的笔记真实存在、标注框类型在 skills/obsidian-markdown/references/CALLOUTS.md 列出的合法类型里、嵌入语法带了!前缀。踩坑点wikilink 指向不存在的笔记时编辑器不会报错只是渲染成红色断链——所以验证项里要包含链接目标存在性而不是只看括号配对。用 10 行 .base 文件验 obsidian-bases结构类技能看的是引用闭合。最小用例filters: and: - status active views: - type: table name: 进行中 order: - file.name - status跑起来后看两点过滤器命中的笔记和你在保险库里手工筛选的一致order里的属性在笔记 frontmatter 里都能找到。踩坑点YAML 里含、(之类的字符串必须加引号代理图省事写裸字符串时要么解析失败要么行为诡异这类问题用任何 YAML 解析器一跑就现形。用 2 节点 1 边的小画布验 json-canvas这是五个技能里结构性最强的一个最小用例就两个节点一条边{ nodes: [ { id: 6f0ad84f44ce9c17, type: text, x: 0, y: 0, width: 400, height: 200, text: 起点 }, { id: a1b2c3d4e5f67890, type: text, x: 500, y: 0, width: 400, height: 200, text: 终点 } ], edges: [ { id: b2c3d4e5f6071829, fromNode: 6f0ad84f44ce9c17, toNode: a1b2c3d4e5f67890, fromSide: right, toSide: left } ] }验证写成一个动作序列JSON 能解析 → 节点 ID 是 16 位十六进制且互不重复 →fromNode/toNode都能在 nodes 里找到 →fromSide/toSide取值在 top/right/bottom/left 之内。skills/json-canvas/references/EXAMPLES.md 里有可直接对照的完整示例。踩坑点往已有画布加节点时新生成的 ID 必须和现存 ID 不冲突这是增量修改场景下最容易翻车的一步所以前面环境准备里特意留了那个已有.canvas。用一次 create read 闭环验 obsidian-cli功能类技能验的是命令产生预期副作用。最小用例两条命令obsidian vaultTestVault create name冒烟测试 content# 测试 silent obsidian vaultTestVault read file冒烟测试预期第二条命令的输出包含# 测试。这个写入→读回闭环能同时验证命令语法、vault 指向、silent 标志三个点。踩坑点参数值带空格必须整体加引号多行内容用\n表示换行另外所有 CLI 用例都依赖 Obsidian 进程存活跑之前先确认应用开着否则失败信息会指向一个根本不存在的错误。用一篇长文页验 defuddle提取类技能验的是干净程度。最小用例defuddle parse 长文URL --md defuddle parse 长文URL -p title预期--md输出的正文里看不到导航菜单、cookie 弹窗之类的杂质标题层级完整-p title的输出和页面title一致。踩坑点defuddle 对以.md结尾的 URL 不适用那本来就是 markdown直接抓取即可如果你的测试语料里混了 markdown 原文站先把它们剔除否则会误判提取质量。跑起来之后怎么组织执行结果怎么算过这节解决的问题是同样的用例什么时候跑、到什么程度算通过。按依赖强度把用例分三档节奏跟着走档位内容什么时候跑离线快测markdown / bases / canvas 产物交给解析器验证JSON.parse、YAML 解析、引用闭合检查每次改完技能说明或代理配置后秒级返回单命令功能测defuddle 对固定 URL 的输出比对每天或依赖升级后集成闭环测obsidian-cli 的 create→read、搜索、property:set 全链路提交前且必须在有 Obsidian 的机器上判断算过的标准建议统一成两条机器可判定的部分不靠眼睛。canvas 用脚本解析检查引用defuddle 的输出和一份人工校对过的基准文件做 diffBases 的过滤结果和手工筛选结果逐条比对。人眼看 markdown 渲染留给最后一步只看不判。预期输出要固定。给每个用例指定固定的输入固定的测试笔记、固定的 URL、固定的旧画布这样两次运行之间出现的差异一定是技能的行为变化而不是输入变了。用例卡住时先查这三处这节解决的问题是失败信息五花八门但 90% 的卡壳集中在这三个层面按顺序排除不用满仓库找原因。第一处产物到底落盘了没有。先ls看文件在不在、是不是被overwrite类标志影响、路径是不是你想的那个 vault。CLI 类失败有一半停在这里——命令成功了文件在别的保险库。第二处语法本身过不过解析。不急着打开 Obsidian先离线跑一遍python -c import json,sys; json.load(open(x.canvas))验 JSON用任意 YAML 解析器验.base。解析都过不了后面全不用看解析过了还报错说明问题在语义层。第三处引用是否闭合。JSON 解析通过后依然白屏、YAML 解析通过后列是空的几乎都是这一层edge 指向了不存在的节点、formula.X没在formulas里定义、wikilink 指向了不存在的笔记。写一个小脚本遍历检查引用目标是否存在比反复打开 Obsidian 重启快得多。三处都排除了还没好再怀疑环境Obsidian 版本是否支持 Bases、CLI 是否连上了正确实例、defuddle 版本是否过旧。环境问题是最后查的因为它最贵也最不像bug。今天就落地的三步建一个 5 条笔记的 TestVault按第二节的清单备齐三样素材成本大约十分钟给 canvas 和 bases 各写一条最小用例第二节的 10 行.base和 2 节点画布可以直接抄跑通生成→解析→引用闭合的完整验证链把 create→read 闭环加上 defuddle 的 title 比对凑齐五个技能各一条冒烟用例以后每次改动先跑这一轮全绿再谈别的。测试用例的价值不在数量在那条最小验证线能不能拦住真实翻车。先把五个技能的冒烟线跑绿再逐步往边界场景加深度。【免费下载链接】obsidian-skillsAgent skills for Obsidian. Teach your agent to use Obsidian CLI and open formats including Markdown, Bases, JSON Canvas.项目地址: https://gitcode.com/GitHub_Trending/ob/obsidian-skills创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
