技术博客：VitePress 知识站为什么要补“站点治理”视图
文档站做大之后，问题不再只是“能不能展示”
知识库型仓库在前期最常见的目标，是把内容先展示出来。
但当站点逐渐稳定后，新的问题会出现：
- 哪些文档其实没有规范标题
- 哪些页面只是占位页
- 哪些图片链接已经失效
- 哪些标题重复到会影响搜索和阅读
这些问题如果只靠人偶然发现，治理会非常慢。
为什么要把治理信息做成站内页面
很多项目会把巡检结果只停留在 CLI 输出里，但这有两个问题：
- 结果不容易被持续关注
- 结果不容易形成长期治理入口
把巡检结果做成一个站内页面的好处是：
- 维护者进入站点就能看到问题概览
- 问题开始有“页面级入口”而不是只是一串日志
- 后续做分阶段治理会更自然
站点治理页的价值，不是“好看”，而是“可持续”
治理页本质上是一个维护面板。
它不是为了让读者更愿意浏览，而是为了让维护者更容易判断：
- 现在问题量有多少
- 应该优先清理哪一类问题
- 本轮治理有没有让问题减少
这是一种把文档站从“静态展示物”继续推进成“可运维知识资产”的思路。
docs:check 为什么值得单独存在
很多时候，npm run build 通过就会给人一种“已经没问题”的错觉。
但构建通过只能说明：
- 站点能产出
- 渲染没有崩
并不能说明：
- 标题规范没问题
- 历史空文件被处理了
- 资源链接没有缺失
所以把 docs:check 单独做出来，是为了让“能构建”和“可治理”成为两个清晰层次。
结语
如果说前几轮是在搭建知识站的展示和导览能力，那么这一轮其实是在开始给知识站补“维护视角”。
当一个 Markdown 仓库开始拥有：
- 站点入口
- 专题阅读路径
- 搜索与发布能力
- 质量巡检与治理视图
它就不再只是一个资料堆，而是在逐步成为一个真正可持续演进的知识系统。