技术博客：VitePress 知识站如何先给资源巡检降噪再开始治理

当问题列表里混着太多误报时，治理很难真正开始

资源治理和标题治理不太一样。

标题缺失通常比较直接，列表里看到的基本都是真问题；但资源巡检如果误报太多，维护者看到列表后很难判断哪些值得先修，治理动作就会一直卡在“看不清问题”这一步。

为什么要先做降噪，而不是直接修资源

如果巡检结果本身不稳定，修一两个资源问题的价值其实很有限。

因为下一次生成报告时，误报仍然会把真实问题淹没，治理页也就无法成为可靠的入口。

所以 M12 先做了一件更基础的事：把资源提取从正则匹配切换到 Markdown Token 解析，让代码块、正则表达式和函数调用不再被错误识别成资源引用。

资源治理试点为什么要选小范围

资源问题天然更分散。

有些是图片路径写错，有些是历史文件丢失，还有些是目录迁移后没有同步改链接。如果一开始就做大范围治理，维护成本会很高，也不容易看清哪种问题最值得优先处理。

因此这一轮只选了两个边界清晰的范围：

• 乐理学习笔记中的历史图片命名问题
• 角色资料页中的首图引用问题

这样既能验证修复链路，也能把资源治理正式纳入里程碑视图。

治理页为什么要新增资源问题推荐页

如果资源问题只出现在明细列表里，下一轮规划仍然要重新人工筛选。

把资源问题页聚合成“下一批推荐资源问题页”之后，治理页就开始具备和标题治理类似的节奏：

• 先看当前轮次修了什么
• 再看下一批最值得继续推进的页面
• 最后决定下一轮范围

这会明显降低下一轮规划成本。

M12 真正补上的，不只是三张图片

这一轮真正补上的，是一条更完整的资源治理链路：

• 巡检先降噪
• 治理范围可配置
• 页面能表达本轮结果
• 下一轮入口可以直接复用

当这条链路跑通后，后面的资源治理就不再是零散修补，而是可以继续纳入里程碑节奏。