Vault doctor
大多数 Obsidian 仓库没有 git 也没有撤销功能，许多通过 iCloud、OneDrive 或 Dropbox 实时同步。将每次写入视为不可逆操作。在触及任何内容之前确认仓库的实际备份情况，覆盖前先读取，优先进行精准编辑而非重写整个文件，绝不要执行快速写入循环 —— 在同步文件夹上会产生冲突副本。
扫描
遍历 .md 文件，跳过 node_modules、.git、.obsidian 以及仓库中积累的任何构建或临时目录。从每个文件的基础名（包括附件，不仅仅是 .md）构建链接目标集合，然后提取 [[目标]]，去除 |别名、#标题 和 ^块 后缀。
记录基线 —— 笔记数量、不同断链目标数量、总断链引用数、重复的基础名 —— 以便后续运行可以显示变化，而不是重复相同的统计。
分类后再修复
原始断链数量并非缺陷列表。将每个命中分类到四个桶中之一：
1. 跨系统引用 —— 不要“修复”。 有些目标根本不是仓库笔记：代理内存 ID、工单键或来自其他工具的标识符，恰好以 wikilink 语法书写。它们永远不会解析。将其转换为纯文本是合理的；创建桩笔记来满足它们则不可取。
2. 有意为之的断链 —— 绝不触碰。 有些笔记故意引用一个断链，作为示例或练习的真实依据（“如果你的工具找不到这个，那你的工具有问题”）。编辑这些内容会破坏它们所教授的东西。在散文中引用的 wikilink 语法属于同一类别。
3. 名称漂移 —— 修复目标，而非源头。 当许多引用指向一个短名称，而笔记却存放在一个较长名称下时，优先在目标的 frontmatter 中添加 aliases: [短名称]，而不是编辑每个引用文件。 一次编辑，原生 Obsidian 机制，没有破坏周围上下文的风险。
4. 真正缺失的笔记。 目标从未存在过。报告它；不要自动创建。空的桩笔记比断链更糟糕，因为它看起来像是已回答了。
禁止查找并替换
切勿使用无范围的查找并替换来修复链接。 在仓库中盲目替换会破坏恰好包含搜索字符串的文件夹名称、URL、代码块和标签词汇 —— 而且因为没有撤销功能，损害是永久的。逐个文件修复，先读取周围行。
其他检查
-
重复的基础名 会使链接在整个仓库范围内变得模糊，因为 Obsidian 通过文件名在整个仓库中解析
[[链接]]。常见的罪魁祸首是仓库中的代码项目或依赖树，贡献了数千个虚假的.md文件。标记它；修复方法是将项目移出仓库或添加排除项。未经询问不要删除任何内容。 -
Frontmatter 必须实际可解析。 对每个块运行真正的 YAML 解析器 —— 不要靠目测。主要的失败原因是未加引号的纯标量包含
:（冒号-空格），它在该字符处失败，并将其下面的每个键都一同拖垮，使整个块对 Obsidian 的 Properties 面板和 Dataview 都不可见。第二个常见失败原因：以|或>开头的未加引号的值会打开 YAML 块标量。修复意味着引用值，对于一个负载巨大的笔记，可能涉及数百个键 —— 先提出建议，绝不要擅自执行，并首先备份文件。在修复完成之前，遵循现有的（损坏的）约定，而不是引入第二种风格；无效块中的孤立有效键毫无用处。
-
标签 应以 YAML 列表形式存在，而非内联标签 —— 对照仓库的实际词汇表进行检查，而非理想化的词汇表。报告漂移；不要单方面重新打标签。
-
过时状态 —— 带有
PAUSED/STALLED/TODO标记但其项目后续已有进展的笔记。报告它们；不要自行解决。 -
冷却中心笔记 —— 中心笔记的最新状态节早于其项目最近活动，说明已过时。报告差距。
输出
一份按分类排序的报告，包含计数和精确的 文件:行号 引用。提出修复建议；只执行用户批准的那些修复。
清晰说明哪些发现是已验证的，哪些是基于命名推断的 —— 看起来像漂移的目标可能是用户打算撰写的笔记。