笔记越积越多之后，我最想知道的事情很具体：哪些笔记缺字段，哪些链接找不到目标，检查脚本有没有把正常文件判错。

我让 WorkBuddy 帮忙做了一个 Python 自检脚本。要求是只读扫描，报告放到知识库外，检查结果能和上次对比。真正费时间的地方，是核对报告的统计口径，以及检查器的匹配规则。

这篇记录以 2026 年 10 月 19 日保存的自检报告和当时的脚本为依据。文章里的文件名示例是演示用的，不展示笔记正文。

## 一、先把体检结果和统计口径放在一起

当前报告记录如下：

| 指标 | 报告结果 | 读数时的范围 |
|---|---:|---|
| Markdown 文件 | 263 篇 | 扫描器纳入的 Markdown 文件 |
| 全部文件 | 324 个 | 按脚本过滤规则纳入的文件 |
| wikilink 出现次数 | 671 次 | 同一链接重复出现会重复计数 |
| 未匹配到目标的链接 | 0 条 | 当前扫描器的匹配结果 |
| 缺少规定字段的文件 | 100 篇 | 仅计算指定治理范围 |
| 完全没有 frontmatter 的文件 | 32 篇 | 指定治理范围，包含在上一项中 |
| 孤立笔记 | 1 篇 | 治理范围内无入链、无出链 |

100 篇缺字段和 32 篇无 frontmatter 不能相加。没有 frontmatter 的文件，本来就缺少那些规定字段。

671 次链接出现，也不能直接叫作 671 条独立双链。要统计唯一目标、唯一引用关系或有效入链，需要另外去重，并说明去重键。

这些限定听上去啰嗦，却直接影响后面的判断。把不同口径的结果画成一条下降曲线，很容易让人误以为脚本修好了很多真实问题。

## 二、先说明允许读哪里、允许写哪里

我给 WorkBuddy 的需求可以压缩成下面这段：

> 检查指定的 Obsidian 知识库，输出规模、frontmatter、链接和结构四类结果。库内文件只读；报告写到库外指定目录。排除配置目录、版本库目录和回收站。每个指标注明范围；发现问题只给建议，不批量修复。

脚本里也要落实这些要求。比如输出路径解析后如果落在知识库内部，就直接拒绝。报告里列出问题，不等于允许脚本改名、补字段或合并笔记。

我会把“找出候选问题”和“执行修复”分成两步。第二步要依据具体清单，先确认哪个文件、哪一处引用应该变成什么。

## 三、文件名里的点号，不能随手剥掉

这次检查代码时，有一个细节很容易误用：Python 的 Path.stem 会去掉最后一个后缀。

例如，对完整文件名“模型 2.0.md”取 stem，得到“模型 2.0”，符合预期。但对链接目标“模型 2.0”直接取 stem，就会得到“模型 2”。后一个目标本来省略了 Markdown 后缀，2.0 是笔记名的一部分。

因此，文件端和链接端要分开处理。文件端知道自己拿到的是磁盘文件名；链接端需要先判断是不是显式写了 .md，不能把最后一个点号后面的内容都当作扩展名。

可以先用下面这个小函数验证“只去掉显式 .md 后缀”的行为：

```python
def note_name(target: str) -> str:
    target = target.strip()
    return target[:-3] if target.lower().endswith('.md') else target

assert note_name('模型 2.0') == '模型 2.0'
assert note_name('模型 2.0.md') == '模型 2.0'
assert note_name('复盘 2024.12') == '复盘 2024.12'
```

这个函数只演示文件名归一化，不承担完整链接解析。附件、标题锚点、同名笔记和路径匹配都需要单独处理。

## 四、报告写着零断链，还要看它怎么匹配

我检查了当前扫描器：它会检查完整文件名、去扩展名后的文件名以及相对路径，并对链接里的别名和标题部分作处理。

这里还有需要改进的边界。当前实现先按链接最后一段查全库同名文件，再检查路径。假设链接写的是“旧目录/方案”，而另一目录恰好存在“方案.md”，这种顺序可能让错误目录的引用通过检查。

所以报告里的“0 条”，准确含义是：按当前规则，没有发现匹配失败。它不能证明每个带目录的链接都指向作者原本想要的那个文件。

我会把带目录的目标优先按路径验证；无目录的简写目标再做全库匹配。同名候选多于一个时，报告应列为歧义，保留候选路径，供人确认。具体匹配行为还需要用 Obsidian 中的实际打开结果对照。

Obsidian 官方文档说明，内部链接可以指向笔记和附件，也支持标题与块引用。检查器需要交代自己覆盖了哪些形式。[内部链接文档](https://help.obsidian.md/links)

## 五、先给检查器几道已知答案的题

我建议用独立测试目录，放入少量人工文件，再检查这些情况：

| 测试 | 应有结果 |
|---|---|
| 指向“模型 2.0.md”的省略后缀链接 | 可以匹配，保留版本号 |
| 同名笔记分布在两个目录 | 无路径简写应提示歧义 |
| 链接带着错误目录，但别处存在同名文件 | 不应静默替换成别处文件 |
| 指向确实不存在的笔记 | 报告未匹配，并保留来源位置 |
| 指向存在的图片 | 按附件规则检查，不能直接忽略 |

还有代码围栏、行内代码、表格里的转义竖线。这些会影响“哪些文字算链接”。如果扫描器只做了简化的正则匹配，就应该把这点写进报告，避免读者把它当成完整 Markdown 解析器。

## 六、我会怎样把它变成周检查

手动检查稳定后，再接定时任务。每次保留报告日期、扫描范围和脚本版本；运行记录里保存开始时间、结束时间、退出状态及报告路径。

比较两份报告之前，先确认脚本版本和统计范围一致。检查器的规则变了，结果减少，可能只是排除了误报；结果增加，也可能只是覆盖范围扩大。

这次报告真正给我的下一步，是核对那 100 篇缺字段文件的治理范围，以及那 1 篇孤立笔记是否需要挂入索引。至于零断链，我会继续补上路径和重名测试，再判断它的可信程度。

参考：[Python pathlib 文档，stem 与 suffix](https://docs.python.org/3/library/pathlib.html#pathlib.PurePath.stem)。


笔记越积越多之后，我最想知道的事情很具体：哪些笔记缺字段，哪些链接找不到目标，检查脚本有没有把正常文件判错。

【征文】我用 WorkBuddy 给 263 篇 Obsidian 笔记做体检，先查检查器有没有误报

依据实际自检报告，拆解263篇笔记、671次链接出现和零断链的统计范围，说明带点号文件名、目录匹配及重名歧义如何影响检查结果，并给出只读检查和周检查的验收方法。

开发工具

测试

编程语言

基于2026年10月19日的自检报告，针对Obsidian知识库的Python只读扫描脚本，发现263篇Markdown文件，671次链接出现，0条断链，100篇缺字段，32篇无frontmatter，1篇孤立笔记。文件与链接处理需区分后缀，带目录链接应优先路径验证，报告统计口径需明确。

代码解释

WorkBuddy 

Markdown

Python

2026上云采购 | AI焕新·智启新局

workbuddy

lexiang

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

【征文】我用 WorkBuddy 给 263 篇 Obsidian 笔记做体检，先查检查器有没有误报-腾讯云开发者社区-腾讯云

【征文】我用 WorkBuddy 给 263 篇 Obsidian 笔记做体检，先查检查器有没有误报

【征文】我用 WorkBuddy 给 263 篇 Obsidian 笔记做体检，先查检查器有没有误报

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐