Obsidian 内容资产化工作流

这套工作流的核心目标是：

把“公众号文章”从普通 Markdown 文件，升级为“可管理、可查询、可自动化”的长期内容资产。

它解决的问题包括：

• 文件命名混乱

• 已发布状态难维护

• 手动创建 metadata 麻烦

• 文件夹管理混乱

• 文章数量增长后难检索

• AI 后续难以 ingest 与自动化

• 内容 schema 不统一

• Dataview 查询出现脏数据

• AI 无法稳定理解知识结构

---

一、核心思想：文章不是“文件”，而是“内容对象”

传统 Markdown 工作流：

新建文件
→ 写文章
→ 手动改名字
→ 手动放文件夹
→ 手动记忆是否发布

这会随着文章数量增长迅速失控。

新的工作流则是：

创建结构化文章对象
→ metadata 驱动
→ Base 管理
→ 自动生成
→ AI 可读取

重点不再是“存文件”，而是“维护内容对象”。

---

二、为什么不用“文件夹”管理状态

以前常见方式：

草稿/
已发布/
归档/

问题包括：

• 需要频繁移动文件

• 链接容易断

• Git history 混乱

• AI ingest 路径不稳定

• 状态维度有限

现代内容系统的核心思想是：

状态属于 metadata，而不是目录。

例如：

status: published

而不是：

Published/

---

三、Properties（Frontmatter）体系

每篇文章顶部维护结构化 metadata：

---
fileClass: article
status: draft
publish_date:
publish_title:
tags:
series:
created: 2026-05-22
---

这些字段本质上就是：

内容对象的 schema。

---

四、推荐字段设计

1. fileClass

文件类型：

fileClass: article

用于定义：

“这是哪类内容”

例如：

article
clipping
prompt
workflow
journal

不同 fileClass：

拥有不同 schema。

---

2. status

文章状态：

status: draft

推荐固定枚举：

draft
reviewed
published
archived
idea

不要自由输入。

否则容易出现：

Published
publish
published
done

这种脏数据。

---

3. publish_date

真正发布日期：

publish_date: 2026-05-22

建议统一 ISO 格式：

YYYY-MM-DD

不要：

2026/05/22

避免 Dataview 与 AI 兼容问题。

---

4. publish_title

公众号真正展示标题：

publish_title: 为什么我越来越反对 AI 直接连接生产数据库？

文件名 ≠ 传播标题

文件名强调：

稳定性

传播标题强调：

点击率 / 情绪 / SEO

必须解耦。

---

5. tags

主题标签：

tags:
  - ai
  - agent
  - philosophy

建议长期维护统一词汇体系。

---

6. series

文章系列：

series:
  - AI文明三部曲

例如：

• AI文明三部曲

• Agent治理

• 职业重构

---

五、Dataview 与 Base 的区别

Dataview

本质是：

查询引擎

类似：

• SQL

• Elasticsearch

• BI Query

特点：

• 查询能力极强

• 可聚合

• 可统计

• 可动态计算

• 偏工程化

适合：

Dashboard
统计
AI Query
知识聚合

不适合作为主要 UI。

---

官方 Base

本质是：

内容管理 UI

类似：

• Notion Database

• Airtable

特点：

• 好看

• 直观

• 易维护

• 学习成本低

适合：

内容运营
状态维护
筛选
排序
分组

---

当前最佳实践

Base 负责：

日常管理

Dataview 负责：

Dashboard
统计
聚合
自动查询

---

六、为什么最终选择 Base 作为主工作流

因为当前核心需求是：

维护文章发布状态

而不是：

复杂 Query

Base 更适合：

• 长期维护

• 日常使用

• 低心智负担

---

七、Metadata Menu：给 Properties 增加强类型系统

仅靠 Obsidian 原生 Properties：

虽然已经可以维护 metadata。

但依然存在问题：

status:

可能会被写成：

published
Published
publish
done
已发布

这会导致：

• Base 难筛选

• Dataview 查询混乱

• AI ingest 出现脏数据

• 长期 schema 崩坏

因此：

需要 Metadata Menu。

---

Metadata Menu 的核心作用：

给 YAML 建立 schema。

---

status

定义为：

Select

固定值：

draft
reviewed
published
archived

于是：

status 不再允许随便乱写。

而是：

下拉菜单单选。

---

publish_date

定义为：

Date / DateTime

于是：

• 自动日期选择器

• 日期格式统一

• Dataview 更稳定

• AI 更容易 ingest

---

tags

定义为：

Multi

支持：

tags:
  - ai
  - agent

---

series

定义为：

Multi

支持：

series:
  - AI文明三部曲
  - Agent治理

---

publish_title

定义为：

Input

用于：

公众号真实传播标题。

---

Metadata Menu 本质上已经开始接近：

数据库 schema 系统。

---

八、Preset Fields 与 FileClass Fields 的区别

Metadata Menu 里：

有两个容易混淆的部分。

---

Preset Fields

位置：

Metadata Menu
→ Preset Fields

作用：

全局字段定义

类似：

父类默认 schema

例如：

全 Vault 都共享：

status
publish_date
tags

定义。

---

FileClass Fields

位置：

fileClass/article
→ FileClass fields

作用：

某类文件的专属 schema

类似：

子类 override

例如：

article：

status
publish_date
publish_title
series

clipping：

source_url
author
website
captured_at

---

不同内容对象：

拥有不同 schema。

这已经非常接近：

面向对象设计。

---

九、FileClass：内容对象系统

FileClass 本质上是：

“某类内容的结构定义”

例如：

fileClass: article

意味着：

这篇文件属于：

article

类型。

---

而：

article FileClass：

内部又定义：

status
publish_date
publish_title
series
tags

等等。

于是：

所有：

fileClass: article

文件：

都会自动继承：

• Select 下拉

• Date 选择器

• Multi 标签

• Input 输入

• schema 约束

---

十、为什么 FileClass 比单纯 Template 更高级

很多人会误解：

Template 就够了

其实不是。

---

Template 负责：

“创建文件时长什么样”

---

FileClass 负责：

“这类文件允许什么结构”

---

两者关系：

Template
负责初始化

↓

FileClass
负责长期 schema 管理

例如：

Template：

fileClass: article
status: draft
series: 微信公众号

只是：

初始值。

---

真正让：

status

变成：

Select 下拉菜单

的是：

Metadata Menu + FileClass

不是 Template。

---

十一、目录结构建议

推荐：

写作/文思泉涌 - 自作诗文/
├── 随感分享/
├── 小说/
├── 诗词/
├── 散文/
├── Dashboard/
├── Templates/
└── _system/
    └── fileClasses/

---

十二、Template 系统

使用：

• Templater

• QuickAdd

实现：

一键创建结构化文章

---

十三、Templater 配置

安装插件：

Templater

设置：

Settings
→ Templater
→ Template folder location

指定：

Templates

---

十四、公众号模板文件

创建：

Templates/公众号文章模板.md

内容：

---
fileClass: article
status: draft
publish_date:
publish_title:
tags:
  - article
series:
  - 微信公众号
created: <% tp.date.now("YYYY-MM-DD") %>
---

# <% tp.file.title %>

---

十五、QuickAdd 工作流

QuickAdd 用于：

自动创建文章文件

包括：

• 自动目录

• 自动命名

• 自动套模板

• 自动 metadata

---

十六、QuickAdd Capture 配置

创建：

新建公众号文章

Choice 类型：

Capture

不是 Template。

---

十七、File path / format

填写：

写作/文思泉涌 - 自作诗文/随感分享/{{DATE:YYYYMMDD}}-{{NAME}}

作用：

自动生成：

20260522-AI-Agent-Governance.md

---

十八、为什么用 {{NAME}} 而不是 {{VALUE:title}}

因为：

{{VALUE:title}}

会额外触发输入框。

而：

{{NAME}}

直接复用 Capture 主输入。

最终只弹一次窗口。

---

十九、Create file with given template

必须开启：

Create file with given template

Template path：

Templates/公众号文章模板.md

---

二十、Enable Choice（关键坑点）

QuickAdd 配置完成后：

必须点击：

⚡ 小闪电

否则：

Command Palette 里搜不到

因为：

Choice 没被注册成命令。

---

二十一、最终工作流

现在：

按：

Cmd + P

搜索：

QuickAdd: 新建公众号文章

输入：

AI-Agent-Governance

系统自动：

---

1. 创建文件

20260522-AI-Agent-Governance.md

---

2. 放进目录

随感分享/

---

3. 自动 metadata

fileClass: article
status: draft

---

4. 自动继承 schema

包括：

• Select

• Multi

• Date

• Input

---

5. Base 自动显示

包括：

• draft

• published

• tags

• series

---

二十二、后续升级方向

未来可继续扩展：

---

AI 自动 tags

Hermes 自动：

读取文章
→ 自动打标签

---

自动标题建议

AI 生成：

publish_title:

---

自动发布状态流转

发布后：

status: published
publish_date: today

---

Dataview Dashboard

例如：

• 最近30天输出

• AI类文章

• 系列统计

• 输出频率

---

AI 内容运营

未来甚至可以：

AI 自动分析：
哪些标题点击率更高
哪些系列更受欢迎
哪些主题输出频率下降

---

二十三、最终形态

这套系统最终不是：

“Markdown 文件夹”

而是：

AI 友好的结构化内容资产系统

特点：

• Markdown 底层

• Git 友好

• AI 可 ingest

• Base 可运营

• Dataview 可查询

• Metadata Menu 可 schema 化

• FileClass 可对象化

• Hermes 可自动化

• 长期可扩展

---

最终：

你维护的将不再只是：

文章

而是：

“可被 AI 理解、查询、操作、运营”的长期知识资产。