实战知识库迁移 01：盘点知识源并设计分类体系

先理解：知识库迁移不是搬文件 ​

企业知识库迁移真正难的不是脚本，而是治理。哪些文档还有效、谁负责维护、哪些人能看、多久更新一次，这些问题如果迁移前不回答，迁移后都会变成线上事故。

本篇先做盘点表和分类体系。它们看起来像文档工作，但决定了后续清洗、权限、同步、验收能不能做下去。

为什么先做三层分类 ​

分类太浅，后面检索过滤不够用；分类太深，维护者不知道该放哪里。推荐先用“领域 / 主题 / 文档类型”三层，既能支撑检索，又不会让使用者被目录树劝退。

迁移优先级 ​

第一批迁移应该选高频、高价值、低争议的知识，例如客服 FAQ、产品手册、标准流程。聊天记录、个人笔记、过期会议纪要可以先暂缓。知识库第一版要可验收，不要追求大而全。

本系列会完成一个企业文档迁移方案。最终成品是可维护的 AI 知识库目录、元数据规范、权限版本策略和验收流程。

本篇成品 ​

kb-migration/
  inventory/sources.csv
  inventory/taxonomy.yml
  inventory/migration-plan.md

创建目录 ​

mkdir -p kb-migration/inventory kb-migration/docs kb-migration/processed
cd kb-migration

知识源盘点表 ​

inventory/sources.csv：

source_id,name,owner,system,permission,update_cycle,first_batch,notes
src_001,售后政策,客服运营,飞书,internal,monthly,yes,高频客服问答依赖
src_002,产品手册,产品团队,Git,internal,per_release,yes,需要按版本区分
src_003,历史工单,客服系统,API,restricted,daily,no,需要脱敏和抽样清洗
src_004,财务制度,财务部,飞书,department,quarterly,no,权限复杂

字段要求：

• owner 是内容负责人，不是技术负责人。
• permission 是迁移后的默认权限。
• first_batch 决定第一批是否入库。
• update_cycle 决定后续同步方式。

三层分类体系 ​

inventory/taxonomy.yml：

domains:
  business:
    label: 业务知识
    topics:
      after_sales: 售后
      invoice: 发票
      product: 产品
  engineering:
    label: 技术知识
    topics:
      api: 接口
      deployment: 部署
  policy:
    label: 制度流程
    topics:
      finance: 财务
      hr: 人事
tags:
  product_line: [headphone, speaker, all]
  region: [cn, global]
  lifecycle: [current, deprecated]

第一批迁移计划 ​

inventory/migration-plan.md：

# 第一批迁移范围

## 入库

- 售后政策：当前有效版本，客服运营确认
- 产品手册：当前销售产品，产品团队确认

## 暂缓

- 历史工单：需要脱敏和去除客服个人备注
- 财务制度：权限复杂，第二批单独接入

## 成功标准

- 第一批文档 100% 有 owner
- 第一批文档 100% 有 permission
- 第一批文档能映射到 taxonomy

验收 ​

检查：

• 每个知识源都有负责人。
• 第一批只包含高价值、低风险内容。
• 每份文档都能落到一个 domain/topic。

第一批不要追求全量。迁移项目最常见失败原因，是把所有历史文档同时搬进知识库。