知识库搭建系列讲了不少东西：架构设计、分类方式、自动采集、清洗管线、日常使用、搜索技巧、内容保鲜和三保险备份。分类那篇提了怎么给 5000 多篇文章做归档，标签只是顺带一笔。这篇专门聊标签。
> **分类帮你把文章放进正确的抽屉。标签负责在抽屉之间架桥。两者配合，才是完整的知识库玩法。**
## 分类的短板
分类的逻辑是互斥。一篇文章只能放一个类目下。我的知识库分了 60 多个子类目——技术开发、产品思考、AI 动态、商业分析。好处是结构清晰，坏处是一篇文章可能涉及多个主题。
比如一篇讲「用 AI 做自动化测试」的文章，既属于技术开发，也属于 AI 应用，还属于效率工具。放哪个类目都不太对。
标签就是来解决这个问题的。一篇文章打多个标签，不受分类的约束。
)
## 三类标签
用了两年多，我的标签一直分三种。
**领域标签**。标记文章涉及的主题。比如 `#AI` `#云计算` `#产品` `#管理`。分类只管大类，标签记的是文章具体涉及什么领域。一篇文章多个领域标签很正常。
**属性标签**。标记文章本身的特征。比如 `#案例`（有具体案例）、`#方法论`（有系统方法）、`#数据`（有数据支撑）、`#教程`（能跟着做）。想找实操步骤，搜 `#教程`。想看数据支撑的，搜 `#数据`。
**状态标签**。标记处理进度。比如 `#待读`（还没看）、`#已读`（看完了）、`#待归档`（还没分类）。这是最有用的一个。每天打开知识库先看 `#待读` 标签，处理完一批改成 `#已读`。
> **三类标签解决三类问题：找什么领域、有什么特征、处理到哪一步了。**
)
## 标签也得定期维护
标签体系不是设计一次就完事的。时间久了有三个问题。
**标签膨胀**。越打越多，后期可能有上百个标签，很多只用过一两次。每季度过一遍标签列表，把只出现过 1-2 次的合并或删除。比如 `#LLM` 和 `#大模型` 是一回事，合到 `#AI` 就行。
**标签漂移**。同一个意思，前期打 `#前端`，后期打 `#前端开发`。Obsidian 的搜索支持正则替换，一次搞定。
**标签冗余**。分类 A 下所有文章都打了 `#A`——那这个标签就没意义了。分类已经表达了信息。这类标签直接批量删掉。
)
## 配合 Dataview 做检索
标签的真正威力在搭配 Dataview 的时候才出来。
想看「AI 相关的、有具体案例的、还没读的文章」：
“`
TABLE title, tags
FROM “公众号文章”
WHERE contains(tags, “#AI”)
AND contains(tags, “#案例”)
AND contains(tags, “#待读”)
SORT created DESC
“`
一次查询就过滤出一个精确的目标清单。
每周做阅读计划时也用它：
“`
TABLE title, file.mtime AS “更新时间”
FROM “公众号文章”
WHERE contains(tags, “#待读”)
SORT file.mtime ASC
LIMIT 10
“`
把最久没打开的文章排在前面，一次处理 10 篇。
> **三条 Dataview 查询，就能把几千篇文章变成每天可操作的阅读清单。**
)
## 几个实操方向
刚起步建标签体系的话，给几个参考方向。
**数量控制在 30-50 个。** 太少覆盖不了，太多管不过来。领域标签 10 个 + 属性标签 5 个 + 状态标签 3 个，差不多起步。
**命名统一。** Obsidian 的标签大小写不敏感，但保持统一方便阅读。用 `#大驼峰` 或者 `#全小写`，选一个就行。
**新标签先观察。** 别一上来就创建正式标签。先在搜索里试一下这个关键词能不能命中其他文章。如果就一篇，那大概是个临时标签，不值得单独建。
**别追求完美。** 标签打得「差不多」比「完全正确」好得多。漏打了一个，下次搜到补上。打错了，季度维护时改过来就行。
前几篇讲了知识库从架构到日常使用的完整链路。这篇聊了标签这个容易被忽略的工具。加个好的标签体系，知识库用起来会更顺手。
系列暂时告一段落，后续有新心得再更新。