系列讲了怎么搭知识库、怎么采文章、怎么搜索、怎么用 AI 读笔记。番外 8 讲过体检，番外 9 讲过图片管理。今天换个角度——知识库搭好了之后，怎么不荒废。
我的 vault 现在两万五千多篇文件，每天还有新东西进来。按理说这么大的量，维护起来应该很费劲。但实际不是这样——每天花在维护上的时间平均不到十分钟。
不是勤快。是把大部分维护工作交给了系统。
先改个认知——维护不是打扫卫生
很多人理解的维护，就是定期翻一遍 vault，看看哪里乱了。这种思路让人越来越不愿意打开。维护应该是常态化的日常操作，不是周末大扫除。
原则很简单：能自动化的绝不手动。不能自动化的，简化到 30 秒以内。
第一层：全自动——设好就不用管
每日健康巡检
番外 8 讲过手动体检。但手动的事做不长久。把体检脚本写成 cron 定时任务，每天早上 6 点跑一次。
脚本检查四个东西：
• Syncthing 同步状态——有没有冲突文件、机器掉线
• 收集箱数量——超 20 篇就发通知
• 断链扫描——新产生的死链接
• 磁盘空间——图片目录占了多少
有问题系统直接发飞书消息。没问题就安安静静跑完，看都看不到。
自动化摘要
每天入库的公众号文章，隔夜自动跑一轮 AI 摘要。Hermes 的 notes bot 凌晨处理前一天的采集队列，每篇文章生成 3-5 句摘要，写到 frontmatter 里。
白天打开 vault，扫一遍摘要就知道是不是关心的内容。不用每篇点开读。
同步冲突自动清理
Syncthing 多设备同步，冲突文件难免。写了个小脚本，每天扫描临时文件和 .stversions 目录。超过 7 天的自动删，不堆积。
第二层：轻度介入——每周十分钟
全自动之外，还有些事需要人看一眼。每周五下午做一轮快速维护，三个动作。
清收集箱
收集箱是入口。所有不确定放哪的内容先进来。但不积压——超过两周没处理的，要么归档到笔记目录，要么删掉。
判断标准很直接：以后还会看吗？ 大概率不会的直接删。会但不知道放哪的，扔到对应目录里加个标签。搜索能找到就行。
标记已读
看完的文章，在 Dataview 视图里把 status 从 unread 改成 read。觉得值得保留的，加两句批注到文件开头。
不要求每篇都读，不要求每篇都批注。5 分钟处理 50 篇以上——扫标题就知道要不要看。
扫一眼健康报告
就是第一层的汇总。主要看断链、大文件异常增长。一般都没问题——有问题的已经发过飞书消息了。
第三层：按需维护——感觉不对劲的时候
前面两层覆盖了 95% 的维护场景。剩下 5% 是人觉得不舒服的时候做的事。
标签体系微调
用久了会发现某些标签太宽泛——#领域/AI 下有两千篇。某些标签又太细——某个只发了三篇的小号。
处理方式：不是一次性重构。发现一个改一个。今天拆成两个，明天把没用的合并。小步快跑比大动干戈好。
结构重组
出现过两次目录大改。一次是合并三个独立 vault，一次是把公众号文章迁到顶层。
这种操作一年一两次够了。平时不动。动了要更新 AGENTS.md 里的目录说明，还要通知所有访问 vault 的 Agent。代价不小。
几个原则
维护是为了阅读，不是为了维护本身。最容易跑偏的地方。花两小时整理标签，一篇笔记没读。整理得再漂亮不读等于白搭。
80 分就够了。 不追求完美的分类。文章能搜到就行，标签够用就好，目录结构大致合理比绝对精确有用。追求完美是维护最大的敌人。
让 Agent 分担。 以前每周手动跑脚本。现在全部交给 Hermes 的 yunwei agent——巡检、清理、通知一条龙。做的比人勤快，还不会忘。
知识库维护这件事，做过头是负担，不做是垃圾堆。中间的平衡：让系统干系统擅长的事，人只做机器做不了的决定。
系列前面讲了搭建和采集。今天是怎么让这些成果持续运转。搭好一个知识库不难，难的是五年后还在用。
前几篇讲了体检、图片管理、插件红黑榜。今天这个「低维护运营」方案把日常维护这件事串起来了。下回想到有意思的话题，再来聊聊。