Obsidian×AI 产品化工作流库：7天把经历变成小红书模板知识库（01｜系统结构)

下面给你「01｜系统结构（壁垒1：Schema 标准）」模块的完整文档内容，可直接复制到 Obsidian 里使用。

这个模块是整套系统的"地基"，让用户理解为什么要用统一结构、怎么用、字段标准是什么。

01｜System（系统结构）

文档清单

1. 01-ARCH｜整套系统长什么样：Experience → Method → Asset
2. 01-RULES｜命名规则&标签体系：让资产永远找得回
3. 01-SCHEMA｜字段标准：哪些字段缺了就无法产品化（必填清单）

文档1：01-ARCH｜整套系统长什么样

Markdown

---
title: 01-ARCH｜整套系统长什么样：Experience → Method → Asset
type: system
priority: 1
---

# 整套系统长什么样：Experience → Method → Asset

## 一、为什么需要统一结构
大多数人用 Obsidian + AI 做不起来，问题不在工具，而在：
- **输入太散**：想到什么写什么，AI 每次都要猜
- **输出不稳**：同样的素材，今天输出 A，明天输出 B
- **无法复用**：写完就忘，找不回来，更无法变成产品

解决方案：**用统一的卡片结构（Schema）做"中间层"**
- 你的经历 → 先写成「经验卡」（结构化事实）
- 经验卡 → 提炼成「方法卡」（可复用规则）
- 方法卡 → 生成「资产卡」（可交付产品）

这样 AI 不用猜、你能找得回、产品能持续迭代。

---

## 二、三类核心卡片

### 1）ExperienceCard（经验卡）
**定义**：一次具体经历/踩坑/项目卡点的结构化记录

**核心字段**：
- 场景：什么情况下发生
- 目标：当时想达成什么
- 问题：卡在哪里
- 动作：你做了什么（步骤化）
- 结果：最终数据/状态（有证据更好）
- 规则：可提炼的结论（如果…就…）
- 边界：什么情况下不适用

**用途**：
- 作为"原始素材"喂给 AI
- 作为"证据"支撑你的方法和产品
- 作为"案例库"持续积累

---

### 2）MethodCard（方法卡）
**定义**：从多张经验卡中提炼出的可复用规则/框架/SOP

**核心字段**：
- 目标：这个方法解决什么问题
- 适用场景：什么时候用
- 步骤：1-2-3-4（可执行）
- 检查项：做完后如何自检
- 边界条件：什么时候不适用/会翻车
- 关联经验卡：证据来源

**用途**：
- 作为"内容生产"的输入（生成笔记/脚本/文案）
- 作为"产品化"的输入（生成清单/模板/知识库条目）
- 作为"可复用资产"持续调用

---

### 3）AssetCard（资产卡）
**定义**：最终可交付的产品单元（清单条目/模板/知识库条目）

**核心字段**：
- 资产名称
- 资产类型：清单条目 / 模板 / 知识库条目 / 其他
- 内容主体：实际交付内容
- 使用说明：买家怎么用
- 适用边界：什么情况下有效/无效
- 关联方法卡：来源
- 版本记录：更新历史

**用途**：
- 直接作为产品内容交付
- 汇总后打包成"可售卖产品"
- 持续迭代更新

---

## 三、三类卡片的关系（流程图）

┌─────────────────────────────────────────────────────────┐
│ 你的经历/踩坑/项目 │
└─────────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────┐
│ ExperienceCard（经验卡） │
│ 结构化事实 + 证据 + 边界 │
└─────────────────────────────┘
│
工作流A：提炼
▼
┌─────────────────────────────┐
│ MethodCard（方法卡） │
│ 可复用规则 + 步骤 + 边界 │
└─────────────────────────────┘
│
工作流B：产品化
▼
┌─────────────────────────────┐
│ AssetCard（资产卡） │
│ 可交付产品 + 说明 + 版本 │
└─────────────────────────────┘
│
工作流C：上架
▼
┌─────────────────────────────┐
│ 商品页 + 交付包 + 成交 │
└─────────────────────────────┘

text

---

## 四、为什么是"三层"而不是更多/更少

### 太少（只有笔记）的问题：
- 无法区分"事实"和"方法"
- AI 无法稳定调用（不知道输入是什么结构）
- 无法追溯"这个结论从哪来"

### 太多（五六层）的问题：
- 维护成本高，容易放弃
- 对新手不友好
- 过度分类反而找不到

### 三层刚刚好：
- 经验卡：记录事实（低门槛）
- 方法卡：提炼规则（核心资产）
- 资产卡：交付产品（变现出口）

---

## 五、这套结构的长期价值

### 1）越用越值钱
- 经验卡越多 → 方法卡越可靠 → 资产卡越丰富
- 形成"个人知识复利"

### 2）AI 调用更稳定
- 统一字段 = 稳定输入
- 稳定输入 = 稳定输出
- 不用每次重新"调教"AI

### 3）产品可持续迭代
- 新经验 → 更新方法卡 → 更新资产卡
- 版本记录清晰，买家信任度更高

### 4）可扩展到团队
- 多人用同一套 Schema
- 资产可合并、可协作

---

## 六、下一步
- 了解命名规则与标签体系：[[01-RULES｜命名规则&标签体系]]
- 了解每个字段的详细标准：[[01-SCHEMA｜字段标准]]

文档2：01-RULES｜命名规则&标签体系

Markdown

---
title: 01-RULES｜命名规则&标签体系：让资产永远找得回
type: system
priority: 2
---

# 命名规则&标签体系：让资产永远找得回

## 一、为什么命名和标签很重要
你的知识库会越来越大。如果命名混乱、标签随意：
- 3个月后你自己都找不到
- AI 无法按规则批量处理
- 无法做成"可筛选"的知识库产品

解决方案：**固定命名规则 + 三维标签体系**

---

## 二、文件命名规则

### 总原则

[类型前缀]-[日期/编号]-[核心描述]

text

### 各类卡片命名示例

| 卡片类型 | 命名格式 | 示例 |
|---------|---------|------|
| 经验卡 | `EXP-YYYYMMDD-描述` | `EXP-20240115-封面改三层后CTR提升` |
| 方法卡 | `MTD-编号-描述` | `MTD-001-封面三层信息设计法` |
| 资产卡 | `AST-编号-描述` | `AST-001-封面设计检查清单` |
| 案例 | `CASE-编号-描述` | `CASE-001-从踩坑到清单产品全流程` |
| 产品规格 | `SPEC-编号-产品名` | `SPEC-001-CTR提升清单产品` |

### 命名注意事项
- 描述用"结果/动作"而非"感受"（❌ 很棒的经验 ✅ 封面改后CTR翻倍）
- 避免特殊字符（`/ \ : * ? " < > |`）
- 长度控制在 50 字符以内
- 编号从 001 开始，方便排序

---

## 三、标签体系（三维结构）

### 为什么用"三维"
单一标签容易混乱（太多/太少都不好用）。
三维标签 = 从三个角度定位一张卡片，交叉筛选时最高效。

### 三维标签定义

#### 维度1：场景标签（在哪用）
描述这张卡片适用于什么场景/领域。

| 标签 | 含义 |
|-----|------|
| `#scene/xiaohongshu` | 小红书相关 |
| `#scene/content` | 内容创作相关 |
| `#scene/product` | 产品化相关 |
| `#scene/workflow` | 工作流/效率相关 |
| `#scene/career` | 职场/求职相关 |
| `#scene/ai` | AI工具/提效相关 |

#### 维度2：问题标签（解决什么）
描述这张卡片解决什么问题/痛点。

| 标签 | 含义 |
|-----|------|
| `#problem/ctr-low` | 点击率低 |
| `#problem/impression-low` | 曝光低 |
| `#problem/save-low` | 收藏率低 |
| `#problem/conversion-low` | 转化低 |
| `#problem/output-empty` | AI输出空泛 |
| `#problem/structure-messy` | 结构混乱 |
| `#problem/cant-reuse` | 无法复用 |

#### 维度3：资产标签（产出什么）
描述这张卡片能产出/沉淀什么类型的资产。

| 标签 | 含义 |
|-----|------|
| `#asset/checklist` | 清单 |
| `#asset/template` | 模板 |
| `#asset/sop` | SOP/流程 |
| `#asset/prompt` | 提示词 |
| `#asset/case` | 案例 |
| `#asset/framework` | 框架/方法论 |

---

## 四、标签使用示例

### 示例1：一张经验卡的标签
```yaml
tags:
  - scene/xiaohongshu
  - problem/ctr-low
  - asset/checklist

含义：小红书场景 + 解决CTR低 + 可沉淀为清单

示例2：一张方法卡的标签

YAML

tags:
  - scene/content
  - scene/xiaohongshu
  - problem/structure-messy
  - asset/sop
  - asset/template

含义：内容创作+小红书场景 + 解决结构混乱 + 可沉淀为SOP和模板

五、标签使用原则

1）每张卡片至少打 3 个标签

• 至少 1 个场景标签
• 至少 1 个问题标签
• 至少 1 个资产标签

2）标签用小写英文

• 便于 Dataview 查询
• 避免中英文混用导致的检索问题
• 如需中文，可在标签后加注释

3）新增标签要谨慎

• 先检查是否已有类似标签
• 新增前问自己：这个标签会被用 5 次以上吗？
• 定期清理低频标签（合并或删除）

4）层级用 / 分隔

• 便于按层级筛选（如 #scene/ 开头的所有标签）
• 保持一致性

六、文件夹结构与标签的配合

文件夹用于"大类归档"

text

├── 00_Start_Here
├── 01_System
├── 02_Templates
├── 03_Workflows
├── 04_Cases
├── 05_Boundaries
├── 06_Index
├── 07_Changelog
└── 99_Inbox

标签用于"跨文件夹检索"

例如：你想找"所有解决 CTR 低的内容"

• 用标签 #problem/ctr-low 检索
• Dataview 会跨文件夹汇总所有相关卡片

两者配合原则

• 文件夹：按"卡片类型"分（经验/方法/资产/案例）
• 标签：按"内容属性"分（场景/问题/资产类型）

七、Dataview 快速检索示例

查询所有"解决CTR低"的方法卡

dataview

TABLE file.name AS "方法卡", tags
FROM "03_Workflows" OR "02_Templates"
WHERE contains(tags, "problem/ctr-low")
SORT file.mtime DESC

查询所有"可生成清单"的经验卡

dataview

LIST
FROM "04_Cases"
WHERE contains(tags, "asset/checklist")

查询"小红书 + AI"交叉场景

dataview

TABLE file.name, tags
FROM ""