从博客到技术平台的最小升级路径（二）：标签与专题的设计艺术

写作声明 本文基于笔者在博客内容组织过程中反复试错的经验。涉及的具体分类困境和解决方案均来自真实踩坑过程。

---

引子：当标签从 5 个变成 50 个，你发现什么也找不到了

完成专题化升级后，我信心满满地给文章打标签。

一开始很克制：rag、agent、deployment、testing——每个都是精准描述。但三个月后，我的标签列表变成了这样：

• python、javascript、typescript
• docker、kubernetes、github-actions
• openai、anthropic、langchain、llamaindex
• beginner、intermediate、advanced
• tutorial、guide、reference、opinion
• 2024、2025、2026…

50 多个标签，理论上应该让内容更容易被发现，实际上却让读者更迷茫。

一位读者问我：“我想找适合初学者的 RAG 部署文章，应该点哪个标签？”

我愣住了。这样的文章确实存在，但它被打上了 rag、deployment、beginner、docker、python 五个标签。读者需要猜中这五个中的哪一个，或者在五个标签页面之间来回跳转。

标签泛滥的问题不在于标签太多，而在于没有设计标签之间的关系。

---

误区一：把标签当成关键词的垃圾桶

为什么大家会这么想

很多博客平台（WordPress、Hexo）的默认设计暗示了一个简单逻辑：标签就是文章的关键词，打得越多越好。

SEO 教程也这么说：“多打标签有助于搜索引擎收录”。于是标签列表变成了：

tags:
  - python
  - flask
  - web
  - api
  - restful
  - backend
  - tutorial
  - 2025

一篇文章打了 8 个标签，看起来很丰富，但每个标签页面只展示这一篇文章——因为其他文章用的是不同组合。

为什么这个理解不对

标签的价值不在于”描述这篇文章的所有方面”，而在于建立文章之间的连接。

如果每个标签只关联 1-2 篇文章，那它就是个孤儿，没有导航价值。

更准确的理解是什么

标签应该对应读者的查询意图，而不是文章的内容清单。

问自己：读者会在什么情况下点击这个标签？他们期望看到什么？

• ❌ “这篇文章用了 Python” → 不是好的标签意图
• ✅ “我想看所有 Python 相关的实践” → 好的标签意图

只有当同一个标签能聚合 3 篇以上相关内容时，这个标签才有存在的意义。

---

误区二：把专题和标签当成一回事

为什么大家会这么想

很多 CMS 的 UI 设计把”分类”和”标签”并列展示，让人觉得它们是同一维度的不同叫法。

于是出现这样的混乱：

• 有些文章归在”AI 工程”专题，又打了”ai-engineering”标签
• 读者在专题页和标签页看到重复内容，不知道该走哪条路

为什么这个理解不对

专题（Topic）和标签（Tag）解决的是完全不同的问题：

维度	专题 (Topic)	标签 (Tag)
层级	高维聚合（领域）	低维特征（属性）
数量	少而稳定（5-10 个）	可多可少（20-50 个）
关系	互斥（一篇文章属一个专题）	多对多（一篇文章可多个标签）
用途	导航入口	内容关联
变化	相对稳定	随内容增长

关键设计原则：

• 专题回答”这是哪个领域”
• 标签回答”这篇有什么特点”

更准确的理解是什么

在我的博客里，一篇文章的组织方式是：必属一个专题，可选多个标签。

---
title: "RAG 生产部署的缓存策略"
topic: ai-engineering-delivery  # 必须，且唯一
tags:
  - rag          # 技术点
  - deployment   # 场景
  - caching      # 具体技术
  - production   # 环境
---

读者路径设计：

1. 从首页进入”AI 工程化实践”专题
2. 看到该专题下的所有文章
3. 发现文章上有”deployment”标签，点击
4. 看到所有部署相关的文章（跨专题）

专题是垂直深挖，标签是横向连接。

---

误区三：追求完美的分类体系

为什么大家会这么想

程序员的本能是追求完备性。设计分类时，会想：

• “前端、后端、AI、运维… 还有测试没地方放”
• “测试归后端还是独立专题？”
• “CI/CD 是运维还是工程实践？”

于是开始画复杂的分类树，试图覆盖所有可能。

为什么这个理解不对

分类不是为了完备，而是为了有用。

你的读者不会因为你少了一个”测试”专题而感到困惑，但他们会在你把 3 篇测试文章分散到不同专题时感到困惑。

完美的分类体系往往意味着：

• 层级太深（读者点 4 次才能看到内容）
• 边界模糊（一篇文章既像 A 又像 B）
• 维护困难（新增文章要考虑归属冲突）

更准确的理解是什么

采用**“实用优先，适度冗余”**的原则：

1. 当前内容导向：不是”我将来可能写什么”，而是”我现在有什么”
2. 读者视角检验：如果朋友来找 X 内容，他会先去哪个专题？
3. 允许模糊边界：少量跨领域内容选一个最相关的归属即可

在我的博客里，“Agent 系统构建”和”AI 工程化实践”的边界并不绝对清晰。但我不会为此纠结——如果一篇文章两边都像，我就根据它主要解决的问题来选。

---

三层标签体系：一个实用的设计方法

经过试错，我设计了”三层标签体系”，每层解决不同维度的问题：

第一层：技术点标签（What）

描述文章涉及的具体技术、工具或概念。

示例：

• rag、agent、llm、vector-db
• docker、k8s、github-actions
• react、vue、astro

设计原则：

• 用技术圈的通用叫法（不要自创缩写）
• 单数形式（用 rag 而不是 rags）
• 控制在 20 个以内，定期合并相近标签

第二层：场景标签（When/Where）

描述文章适用的场景、阶段或环境。

示例：

• prototyping（原型阶段）
• production（生产环境）
• migration（迁移场景）
• troubleshooting（排障）

设计原则：

• 场景比技术更稳定（生产环境总是生产环境）
• 帮助读者判断”这篇文章现在对我有用吗”
• 数量控制在 10 个以内

第三层：类型标签（How）

描述文章的内容形态和阅读预期。

示例：

• tutorial（手把手教程）
• guide（实践指南）
• interpretation（解读分析）
• reference（参考资料）
• opinion（观点思考）

设计原则：

• 帮助读者设定阅读预期（教程 vs 观点，读法完全不同）
• 控制数量，不要过于细分
• 每篇文章只打一个类型标签

---

实战配置：Astro 中的标签实现

标签数据聚合

// src/lib/taxonomy.ts
export function collectTagCounts(posts: Post[]) {
  const counts = new Map<string, number>();

  posts.forEach(post => {
    post.data.tags?.forEach(tag => {
      counts.set(tag, (counts.get(tag) || 0) + 1);
    });
  });

  // 只保留有 2 篇以上文章的标签
  return Array.from(counts.entries())
    .filter(([_, count]) => count >= 2)
    .sort((a, b) => b[1] - a[1]);  // 按数量倒序
}

标签页面实现

---
// src/pages/tags/[tag].astro
export async function getStaticPaths() {
  const posts = await getCollection('blog');
  const tagCounts = collectTagCounts(posts);

  return tagCounts.map(([tag]) => ({
    params: { tag },
    props: {
      tag,
      posts: posts.filter(p => p.data.tags?.includes(tag))
    },
  }));
}

const { tag, posts } = Astro.props;
---

<h1>标签：{formatTagLabel(tag)}</h1>
<p>共 {posts.length} 篇文章</p>

{posts.map(post => (
  <article>
    <h2><a href={`/blog/${post.slug}`}>{post.data.title}</a></h2>
    <p>{post.data.description}</p>
  </article>
))}

标签云组件（只展示有价值的标签）

---
// src/components/TagCloud.astro
const posts = await getCollection('blog');
const tagCounts = collectTagCounts(posts);

// 只展示前 15 个高频标签
const topTags = tagCounts.slice(0, 15);
---

<div class="tag-cloud">
  {topTags.map(([tag, count]) => (
    <a href={`/tags/${tag}`} class="tag">
      {formatTagLabel(tag)}
      <span class="count">{count}</span>
    </a>
  ))}
</div>

---

标签治理：定期清理与合并

标签是需要维护的。我的做法是每月做一次”标签治理”：

1. 合并相近标签

# 发现这些标签其实是一回事
- "docker" 和 "containers" → 合并为 docker
- "testing" 和 "test" → 合并为 testing
- "ai" 和 "artificial-intelligence" → 合并为 ai

2. 删除孤儿标签

只关联 1 篇文章的标签，考虑：

• 是否有其他文章可以打上这个标签？
• 如果没有，删除标签，改为在文章中用文字描述

3. 检查标签层级混淆

发现标签和专题重叠时（如专题是”AI 工程”，标签也有”ai-engineering”），果断删除标签，保持专题的唯一导航地位。

---

结语：好的分类是读者不用思考的分类

完成标签体系重构后，我做了个简单测试：让一位朋友在不熟悉我博客的情况下，找一篇”关于 RAG 部署的生产实践”。

他的路径是：

1. 首页看到”AI 工程化实践”专题 → 点击进入
2. 浏览文章列表，发现一篇标题含”RAG 部署”
3. 文章上有”production”标签 → 点击查看所有生产环境相关文章
4. 筛选出 RAG + production 的内容

整个过程中，他没有疑惑”该点哪里”，也没有在重复内容中迷失。

这就是好的分类体系的标准：读者凭直觉就能找到想要的内容，而不需要理解你复杂的分类哲学。

在下一篇文章中，我会分享如何设计平台型首页——把专题、标签、最新内容整合成一个让读者”发现”而非”浏览”的入口。

---

系列文章

1. 从”文件堆”到”专题化”——博客内容组织的第一性原理
2. 标签与专题的设计艺术 ← 本文
3. 构建平台型首页——让读者从”看到”到”发现”
4. Astro + Content Collections 实战指南

---

参考资源

• 信息架构经典：《How to Make Sense of Any Mess》 by Abby Covert