M12 详细设计：资源检测精度与治理视图扩展

这份详细设计文档用于描述 M12 的核心设计：如何先把资源巡检从“高噪声”调整为“可用数据”，再让治理页承接资源问题的试点修复结果。

设计目标

M12 主要解决三个问题：

• 如何降低资源巡检中的误报比例
• 如何把资源治理纳入现有治理配置与里程碑视图
• 如何让治理页给出可执行的资源问题推荐入口

一、巡检规则调整设计

旧的资源检测逻辑基于正则匹配 []() 结构，它能快速抓到 Markdown 图片与链接，但也会把下面这些内容误判为资源引用：

• 代码块中的函数调用
• 正则表达式中的分组和字符类
• 源码分析中的参数列表

因此本轮改为基于 Markdown Token 的方式提取资源目标：

• 解析标准 Markdown 图片 token
• 解析 HTML img / source 标签中的 src 或 srcset
• 继续过滤外链、锚点和 .md 文档链接

这样可以保留真正的资源引用，同时明显降低代码片段误报。

二、治理配置扩展设计

在 M7 到 M11 中，remediationConfigs 只表达标题治理范围。

M12 起，这个配置继续作为治理单一数据源，但增加 issueType 字段：

• missingTitle
• missingAsset

这样可以继续复用：

• 累计治理清单
• 本轮已治理范围
• 治理里程碑视图

同时让治理页开始兼容多种问题类型，而不是只围绕标题缺失。

三、资源试点选择设计

本轮选择：

• 07四艺/1琴/音乐RE0学习
• 10其他/wuxia/team/飞雪

原因：

• 两处问题边界清晰，便于小范围验证资源治理流程
• 一处是学习笔记目录，一处是单页图片资料，可覆盖两类典型资源问题
• 修复成本低，适合先验证流程，再考虑更大范围扩面

四、治理页表达设计

治理页新增“下一批推荐资源问题页”区块。

这一块基于当前 missingAssets 聚合结果生成，表达目标是：

• 让资源问题不再只出现在明细列表中
• 让下一轮治理更容易直接选页推进
• 让资源治理和标题治理形成相似的运转方式

同时，本轮已治理范围中的卡片元信息改为按问题类型展示：

• 当前标题缺失 X
• 当前资源缺失 X

这样同一个治理面板就能同时承载多问题类型。

五、自测与验收设计

本轮验收按下面顺序执行：

1. 运行 npm run docs:sync
2. 运行 npm run build
3. 运行 npm run docs:check
4. 检查治理页中的资源视图是否更新
5. 确认资源缺失数量下降且误报列表收敛

通过标准：

• 构建成功
• 巡检成功
• 本轮修复范围中的资源问题归零
• 资源问题推荐区块正常生成