首页 > 专题 > Obsidian知识库 > 文章详情
返回 Obsidian知识库

3、SCHEMA.md 设计规范与 Tag Taxonomy

2026年05月05日 35 阅读 Obsidian知识库

第3篇｜SCHEMA.md 设计规范与 Tag Taxonomy

预计阅读时间：20分钟
核心目标：让 Wiki 有一套「宪法」，约束 Agent 和人的行为，防止知识库腐烂

3.1 SCHEMA.md 的本质

SCHEMA.md 是整个 LLM Wiki 的元规范文件——它不是给人类随手翻阅的说明文档，而是给 AI Agent 的系统提示词。

打个比方：

  • 没有 SCHEMA.md 的 Wiki，就像一个没有法律的创业公司——早期跑得快，但随着人员增长、文档增多，各种命名风格、标签体系、页面结构互相打架，最终变成无人敢动的技术债务。
  • 有 SCHEMA.md 的 Wiki，就像一个运转良好的开源项目——所有人（包括 Agent）都遵守 CONTRIBUTING.md 里的规范，即使人员更替，仓库依然整洁有序。

3.2 完整 SCHEMA.md 模板

以下是针对 AI/ML 研究领域的完整示例，你可以直接复制到自己的 Wiki 中修改：

# Wiki Schema

## Domain
AI/ML 研究：涵盖大语言模型、深度学习架构、训练方法、行业动态。

## Conventions

### 文件命名
- 所有文件名：**全小写**，中划线分隔，无空格
- ✅ `transformer-architecture.md`
- ✅ `openai-gpt4.md`
- ❌ `Transformer Architecture.md`
- ❌ `openai_gpt4.md`

### Wiki 页面结构
- 每个 Wiki 页面**必须包含 YAML frontmatter**
- 每个 Wiki 页面**至少包含 2 个出站 `[[wikilinks]]`**
- 更新页面时必须更新 `updated` 日期
- 新页面必须添加到 `index.md` 对应 section

### 目录结构规则
- `raw/` 下的文件**永不修改**（Immutable）
- `entities/` 存放实体页（人/公司/产品/模型）
- `concepts/` 存放概念页（技术/方法/理论）
- `comparisons/` 存放对比分析页
- `queries/` 存放有价值的问答存档

### 操作日志
- 每次 ingest / create / update / archive 操作必须追加到 `log.md`
- 日志格式：`## [YYYY-MM-DD] action | subject`

## Frontmatter

所有 Wiki 页面必须使用以下 frontmatter：

```yaml
---
title: Page Title
created: YYYY-MM-DD
updated: YYYY-MM-DD
type: entity | concept | comparison | query
tags: [tag1, tag2]
sources: [raw/articles/source-name.md, raw/papers/paper-name.md]
# 可选字段：
confidence: high | medium | low
contested: true
contradictions: [other-page-slug]
---

type 字段说明

| type | 适用场景 | 示例 |
|------|---------|------|
| entity | 实体（人/公司/产品/模型/数据集） | openai.md, bert.md |
| concept | 概念/技术/方法/理论 | attention机制.md, rlhf.md |
| comparison | 对比分析（多实体或多概念） | llama2-vs-gpt4.md |
| query | 有价值的问答结果存档 | 2025-rag架构总结.md |

可选字段说明

| 字段 | 何时使用 |
|------|---------|
| confidence: high | claims 有多个独立来源支撑 |
| confidence: medium | 单来源 OR 快速演进中的话题 |
| confidence: low | 个人推测 OR 未经充分验证 |
| contested: true | 存在未解决的事实性争议 |
| contradictions: [slug] | 与哪些页面存在矛盾 |

Tag Taxonomy

规则：所有标签必须出现在以下列表中。使用新标签前必须先追加到此列表。

层级结构

Models（模型相关）
├── model          # 模型本身（架构、发布）
├── architecture   # 模型架构设计
├── benchmark      # 评测基准 / 排名
└── training       # 训练相关（数据、策略）

People & Orgs（人与机构）
├── person         # 个人（研究者、工程师）
├── company        # 公司 / 组织
├── lab            # 研究实验室
└── open-source    # 开源项目 / 社区

Techniques（技术方法）
├── nlp            # 自然语言处理
├── cv              # 计算机视觉
├── multimodal      # 多模态
├── optimization   # 优化方法
├── fine-tuning     # 微调技术
├── alignment      # 对齐技术
└── inference      # 推理加速

Applications（应用场景）
├── chatbot        # 对话系统
├── code-gen       # 代码生成
└── search         # 搜索 / 检索

Meta（元信息）
├── comparison     # 对比分析
├── timeline       # 时间线 / 编年史
├── controversy    # 争议性话题
├── prediction     # 预测 / 展望
└── meta          # 关于 Wiki 本身的页面

标签使用规则：

  • 每页至少 1 个标签，最多 5 个
  • 优先使用已有的通用标签，避免重复造词
  • meta 只用于 Wiki 本身的页面（如 index.md、log.md）

Page Thresholds（建页门槛）

必须建页

  • 实体（公司/人/产品）在 2 个以上来源中被提及
  • 概念被 1 个以上来源深度解释（超过 3 段）
  • 多实体/多概念的对比分析值得建 comparison 页

不建页

  • 仅在正文中一句话带过的实体或概念
  • 过于宽泛的通用词（如「AI」「Machine Learning」本身不适合建页）
  • 纯个人观点且无可验证来源

合并与分裂

  • 单一页面超过 200 行 → 拆分成子页面，父页保留摘要 + 链接
  • 两个页面讨论高度重叠的主题 → 合并，用 ## 分节

归档

  • 内容被完全取代 → 移至 _archive/，从 index.md 删除，通知引用方

Update Policy（更新策略）

信息冲突处理

  1. 查看来源日期——新来源一般优先于旧来源
  2. 如果两个来源事实性冲突，两端并存，注明来源和日期
  3. 在 frontmatter 标记 contested: true + contradictions: [other-slug]
  4. 在 log.md 记录冲突，供后续 lint 检查

页面更新频率

  • updated 日期超过 90 天且领域有新进展 → 标记为 stale，优先更新
  • 纯历史记录页面（如某模型的 initial release 介绍）→ 保留历史版本，不强制更新

删除策略

  • 删除页面之前必须检查 index.md 和所有 wikilinks——确保无其他页面引用
  • 删除操作记录到 log.md

Source Drift Detection（来源变动检测）

Raw 层的每个文件都存储一份 sha256 哈希：

---
source_url: https://example.com/article
ingested: 2026-01-15
sha256: a3f5e8d2c1b9...
---

定期重新计算哈希：

  • 哈希相同 → 内容无变化，跳过
  • 哈希不同 → 来源已更新，触发 re-ingest 流程

3.3 Tag Taxonomy 设计原则

Tag Taxonomy（标签分类体系）是 SCHEMA.md 中最容易出错的部分。下面是设计原则：

3.3.1 从实际需求出发，不要过度设计

反面案例：一开始就定义 50 个标签，结果实际使用时只有 10 个在用。

正确做法：先定义 10-15 个核心标签，随着 Wiki 增长再逐步追加。

3.3.2 标签层级要扁平

Dataview 查询时，多级标签（如 Models/LLM/GPT4）会导致查询复杂化。建议用前缀约定代替层级：

# 好用
models.llm, models.vision, techniques.training

# 不好用（层级太深）
models
  └── llm
       └── gpt4

3.3.3 每个标签必须有明确含义

| 标签 | ✅ 明确 | ❌ 模糊 |
|------|--------|--------|
| nlp | 自然语言处理 | ai（太宽泛）|
| alignment | 对齐技术（RLHF/DPO等） | hot-topic |
| benchmark | 评测基准 | important |

3.3.4 标签要平衡粒度

太粗 → 无法区分内容（如 tech）；太细 → 标签爆炸（如 transformer.attention.multi-head.ablation）。

建议每页 2-4 个标签最佳。

3.4 实际示例：一个完整的 entity 页面

---
title: GPT-4
created: 2026-03-01
updated: 2026-05-04
type: entity
tags: [models.llm, openai, benchmark]
sources: [raw/articles/openai-gpt4-launch.md, raw/papers/gpt4-technical-report.md]
confidence: high
---

# GPT-4

## 基本信息

| 字段 | 值 |
|------|-----|
| 发布方 | [[openai]] |
| 发布日期 | 2023-03-14 |
| 参数量 | 未公开（估计 1.8T） |
| 多模态 | 是（支持图像输入） |
| API 可用 | 是（ChatGPT Plus / API） |

## 核心能力

- **复杂推理**：在 BARL、MAWPS 等 benchmark 上显著超越 GPT-3.5
- **多模态理解**：支持图像输入，能够描述图片内容
- **长上下文**：128K token 上下文窗口
- **可控输出**：更强的 system prompt following

## 与前代对比

| 能力 | GPT-3.5 | GPT-4 |
|------|---------|-------|
| 复杂推理 | 中等 | 显著提升 |
| 多模态 | ❌ | ✅ |
| 代码生成 | 中等 | 强 |
| 长文本理解 | 4K | 128K |

## 相关链接

- 官方网站：https://openai.com/gpt-4
- 技术报告：[[openai-gpt4-technical-report]]
- 与 [[claude-2]] 的对比：[[gpt4-vs-claude2]]

## 来源

^[raw/articles/openai-gpt4-launch.md] 关于发布的描述
^[raw/papers/gpt4-technical-report.md] 技术细节

3.5 给不同领域的 SCHEMA 设计建议

3.5.1 AI/ML 研究领域

## Domain
AI/ML 前沿研究：模型架构、训练方法、行业动态

标签侧重：models.*、techniques.*、benchmarks、alignment

3.5.2 开发者知识库

## Domain
全栈开发知识库：语言特性、框架、中间件、工程实践

标签侧重：language、framework、backend、frontend、devops、security

3.5.3 商业/创业研究

## Domain
科技行业与创业：赛道分析、公司研究、投资动态

标签侧重：market、company、product、founding、funding、ipo

3.6 小结

  • SCHEMA.md 是 AI Agent 的「系统提示词」——约束行为、防止混乱
  • 核心模块：Conventions（命名/页面结构）、Frontmatter（字段规范）、Tag Taxonomy（标签体系）、Page Thresholds（建页门槛）、Update Policy（更新策略）
  • Tag 设计原则：扁平前缀、明确含义、平衡粒度、从少到多
  • Schema 不是一次定稿的——随着 Wiki 增长，Schema 需要持续迭代

下一篇预告：第4篇我们将深入讲解 wikilinks 的使用艺术——如何用 [[wikilinks]] 构建知识网络，以及 Dataview 查询的实战技巧（找孤立页面、发现隐藏关联）。

Obsidian