把知识库健康分从0救到10：一周OpenClaw与LLM-Wiki实战复盘

事情是这样的。

周一上午我刚打开 Telegram，就看到一句话：健康分 0/10，总问题 395，断链 33，孤岛 362。

这种感觉特别像什么呢？像你跑了一套单测，啪一下红了一整屏，但你甚至不知道红的是代码问题，还是测试框架本身在胡扯。

于是这一周我干了三件事：

第一，把那份健康报告从「吓人」变成「可用」。 第二，把修复过程沉淀成一套可复用的脚本和 skill。 第三，顺手把这套知识库编译链路的几个坑彻底填平。

这篇文章我按可发布的公众号长文来写：我做了什么、怎么做的、以及我现在对这套东西的真实感受。

1. 先交付一个结果：健康分回到10/10

我现在的健康报告长这样（时间是 2026-05-25 18:15）：

• 总文件：3939
• 总问题：0
• 健康分：10/10
• 断链：0
• 孤岛：0
• 缺摘要：0
• 索引不一致：0

报告在这里：71-Wiki/71-02-wiki/HEALTH-REPORT.md

但我要强调一句：这个 10/10 的价值，不在于数字好看，而在于这套指标终于开始反映真实世界了。

因为我后来发现，之前的「孤岛 362」里，有一大坨是误报。

2. 误报是怎么来的：你以为是内容问题，其实是统计口径问题

当时的 wiki-lint 做了两件事：

• 用 wikilink 去统计互链
• 用同样的 wikilink 去统计入链（backlinks）

问题是：我们的 INDEX.md 里大量使用的是标准 Markdown 链接：[标题](articles/xxx.md)。

这就导致一个非常尴尬的结果：

索引里明明列出了所有文章，但 lint 看不见这些链接，于是它会说：这些文章没有入链，所以全是孤岛。

你想想看，这不是内容烂，这是统计口径烂。

所以这周最关键的一步其实是：让 lint 认可 Markdown 链接也算入链。

对应修复在：71-Wiki/71-04-scripts/wiki-lint.py

3. 我是怎么把它修干净的：从一份报告倒推整条编译链路

我这次修复没有走那种「看见一个错误改一个」的方式。

我用的是 LLM-Wiki 这套体系里最舒服的一种工作姿势：把所有问题当成编译产物的可验证指标，然后倒推上游。

具体来说我做了这几步：

3.1 先用健康报告把问题分类

健康报告里主要是两类问题：

• 断链：典型是 display 这种写法，target 找不到
• 孤岛：大量来自 index 统计口径不一致

这个时候我其实已经不太关心「具体是哪一个文件断了」。 我关心的是：这些断链有没有共性？是不是同一种写法导致的一批问题？

说真的，只要你能把问题从「395 个点」抽象成「两三个类型」，这事就已经好做一半了。

3.2 让解析规则更像人

我给 lint 加了几条非常朴素的规则：

• 既认 wikilink，也认 [text](path.md) 这种 Markdown 链接
• 遇到 display，target 失败时尝试用 display 去解析一次
• 把解析过程变快：先建索引，再批量解析，避免每个链接都全盘扫描一次

这样做完以后，孤岛数一下子就归零了。

3.3 全量编译要先清产物，不然你永远在跟幽灵打架

这是一个很工程但也很现实的点。

当时我发现一个现象：我已经把脚本逻辑修对了，但 lint 里仍然会冒出一些非常离谱的断链。 后来才反应过来：是旧产物残留在 71-Wiki/71-02-wiki/articles/ 和 concepts/ 里。

这些旧文件不是这次编译产生的，但 lint 会照样扫到。

所以我在全量编译时加了一个动作：先清空产物目录，再重建。

对应修复在：71-Wiki/71-04-scripts/wiki-compile.py

我现在对「编译产物只读」这条原则更信了：你只要允许自己手改产物一次，下次编译就会把你干过的活全部覆盖掉，然后你还会以为是工具不稳定。

4. 这周我顺手做了哪些沉淀：让经验变成技能，而不是聊天记录

除了把健康分救回来，这周我还刻意做了一件事：把踩坑经验写进技能里。

因为我越来越确定一件事：在 AI 协作里，最贵的不是模型调用费，是你每次都像第一次那样重新踩坑。

这里我也用了一次很朴素的 LLM-Wiki 搜索，把本周的主题从知识库里「捞」出来：比如我搜 CodeGraph、搜 Health Score，就能快速定位到对应概念页和相关文章，然后再回到 01-Articles/ 去确认哪些内容已经沉淀、哪些还只是聊天记录。

4.1 Mermaid 语法报错这块，我单独做了一个护栏 skill

你如果经常写 Mermaid flowchart，会遇到那种很烦的报错：解析器指着某一行说 Parse error，然后你盯半天也不知道它到底在气什么。

我把这一套排错规则整理成了一个技能：

• 70-System/70.02-Skills/mermaid-syntax-guard/SKILL.md

它的核心就一条：复杂文本一律用安全写法，别把所有说明都塞到边标签上。

我现在写 Mermaid 的心态就是：先让它稳定渲染，再谈美观。

4.2 本周输出的几篇长文

这周我落盘到 01-Articles/ 的内容，比较能代表我现在的工作主线：

• 01-Articles/2026-05-24-CodeGraph-vs-Graphify-vs-code-review-graph-vs-GitNexus-怎么选.md
• 01-Articles/2026-05-24-CodeGraph-让AI编码代理少读文件更省Token.md
• 01-Articles/2026-05-24-Obsidian-完整配置与启动优化指南.md
• 01-Articles/2026-05-23-Codex-Goals-持久目标指南.md
• 01-Articles/2026-05-20-abtop、CodeBurn、Tokscale、CodexBar：终端 Token 监控-审计工具详解与对比.md
• 01-Articles/2026-05-18-CodeBurn-把AI编程烧钱账单摊开给你看.md

我这周写这些文章的时候，有一个很强的感觉：内容写作和工程交付，开始变成同一件事了。

你写文章，其实是在给自己做一份可复用的操作手册。 你写 wiki，其实是在给下一次提问做索引和证据链。

5. 我这周最大的感想：知识库健康分，本质上是你和AI的协作质量分

以前我会把知识库当成一个仓库：东西放进去就行。

但 LLM-Wiki 这套东西跑起来之后，我开始把它当成一个系统：

• 有编译流程
• 有索引
• 有体检报告
• 有增量状态
• 有可复用的技能

当你有了这些东西，你就会自然地开始追问：

为什么会断链？ 为什么会孤岛？ 为什么索引里有，实际却找不到？ 为什么今天这条规则能用，下周就不灵了？

这些问题听起来像在修知识库，其实是在修你和 AI 的合作方式。

因为 AI 最怕的就是两件事：

• 规则不一致
• 产物不可验证

而这两件事，恰好就是健康分为 0 时最明显的症状。

6. 下周我准备怎么继续：让周报从一条消息，变成一篇可发布的文章

最后我也说点不那么爽的：我原本还想把这份周度体检报告自动推送到 Telegram。

结果 push 脚本打到了一个不存在的 endpoint，直接 404。

这件事也挺有意思：你会发现自动化最难的不是写脚本，而是保证系统边界稳定。

所以我下周准备做两件事：

第一，周报不再只是健康指标，而是补上本周真正发生的事情：做过的事、踩过的坑、以及我对这些坑的看法。

第二，把周报模板做成一个写作型 skill，让它能稳定产出可发布的公众号文章，而不是一条看完就过去的消息。

如果你也在折腾类似的系统，我真心建议你从一个很小的动作开始：

先给你的知识库加一份体检报告。

只要你能看到断链、孤岛、索引一致性这些指标，你就会开始把很多原本靠感觉的事情，变成可验证的工程问题。

这玩意一旦开始滚，就会有复利。