知识库也会腐烂：AI Skill 的定期盘点实践

有一段时间我发现一个奇怪的现象：我的 AI 工具效率并没有随着 skills 积累而线性提升，有时候反而变得更慢、更容易出错。

排查下来，原因很简单：skills 堆多了但没有治理。一些引用了过时 CLI flag 的 skill 还在生效；两个功能高度重叠的 skill 让 AI 不知道该触发哪个；某些已经废弃的工作流对应的 skill 还在消耗上下文预算。知识库的问题和代码库的问题是一样的——不维护，它就腐烂。

代码有 lint，知识库也需要

代码有静态分析、有 CI、有 code review。但 AI 知识库通常没有任何质量门禁，完全依赖「新建时认真写、写完就不管」的一次性投入。这个模式在 skills 数量少的时候还好，一旦积累到几十个，就会出现：

• 时效性失效：某个 API 的 endpoint 变了，某个工具升级了接口，skill 里的命令执行报错
• 内容重叠：相似功能拆成两个 skill，触发条件模糊，AI 每次都要「猜」该用哪个
• 范围漂移：一个 skill 最初只处理 A 场景，后来不断加料变成了大而全的怪物，trigger 和内容不匹配
• 孤岛 skill：当初「以后会用到」但实际从未触发过的 skill，安静地占着上下文预算

这四种问题不会自己暴露，只会在某次任务里悄悄拖慢执行、制造困惑。

盘点的两个节奏

我现在用两种粒度来维护：快速扫描和完整盘点。

快速扫描针对最近改动过的 skills，每次有新 skill 写完或旧 skill 改完之后跑一遍。逻辑很简单：把上次盘点结果缓存下来，diff 出有变动的文件，只重新评估这些文件，其余沿用旧结论。整个过程 5 到 10 分钟，不打断工作节奏。

完整盘点是周期性的深度审查，把所有 skills 过一遍。这个模式成本高，但能发现快速扫描发现不了的问题——比如两个 skill 分别小步演进，逐渐高度重叠，但各自的单次改动都不足以触发警觉。

两种模式结合起来，维护成本是可控的。

评估的四个维度

每个 skill 的评估我用四个维度，缺一不可：

可操作性：读完之后能不能立刻行动？好的 skill 里有代码示例、有命令、有步骤，而不是一段原则宣言。AI 需要程序性知识，不是声明性知识。

范围匹配：名字、触发条件、实际内容是否三点一线？名字叫「代码审查」但内容塞了一半部署流程，或者触发条件太宽导致 AI 在不该用的场景也调用——这类问题在盘点时最容易发现。

独特性：这个 skill 的价值能不能被 CLAUDE.md、另一个 skill、或者模型自身知识替代？替代度越高，保留的优先级越低。

时效性：skill 里引用的工具版本、API endpoint、配置格式在当前环境里还有效吗？这个维度最容易被忽略，因为 skill 写的时候完全正确，只是环境在悄悄变。

结论要能「自我解释」

盘点里最容易踩的坑是写了结论但没写理由，或者理由是「重复了」这三个字。几个月后再看，完全不知道当时在说什么。

有效的理由必须能独立决策：

• Retire 的理由要说清楚「发现了什么具体问题」加「哪个现有资源能覆盖同样需求」
• Merge 的理由要说清楚「合并到哪里」加「具体把哪段内容整合进去」
• Improve 的理由要说清楚「改哪个部分、做什么具体改动、改完大概多长」

这个要求看起来啰嗦，但它保证了盘点结论是真正可执行的，而不是一堆没有后续的评语。

一句话心法

知识库的价值不是靠积累建立的，而是靠持续治理维持的——定期清理比不断新增更重要。