02-系统设计
来源
- 触发点:使用系统的科学设计开发过程,设计出 Obsidian 为主体的知识流系统,本篇是系统设计部分。
- 首次记录:2025-11-08
- 作者:huan
详情
一、系统架构总览
拟采用“三层架构 + 双循环机制”模型:
┌──────────────────────┐
│ 输出层-Output │ ← 高质量文章 / 博客 / 分享
└──────────┬───────────┘
↓
┌──────────────────────┐
│ 处理层-Processing │ ← 笔记整理 / 关联 / 提炼 / 模板化
└──────────┬───────────┘
↓
┌──────────────────────┐
│ 输入层-Input │ ← 闪念 / 剪藏 / 读书 / 代码片段
└──────────────────────┘
🔄 内循环:输入 → 处理 → 输出(单次创作)
🔁 外循环:输出 → 反馈 → 回顾 → 再次作为输入 → 迭代(持续进化)二、核心模块设计
| 模块 | 职责 | 实现方式(Obsidian 插件/功能) | 文件路径 | 备注 |
|---|---|---|---|---|
| 1. 闪念捕获 | 快速记录灵感、问题、想法 | Templater 模板插件 | 1.Acquire | 子级文件夹按照日期分类,如:1.Acquire/Acquire-20251108 |
| 2. 内容剪藏 | 保存网页/视频/文档精华 | Raindrop 插件、滴答清单 | 1.Acquire | 含原文链接、摘要 |
| 3. 知识原子化 | 将输入转化为结构化笔记 | 手动提炼 Templater 模板插件 | 4.Atom | 含 Frontmatter(id、状态、标签、日期)等完整要素信息 |
| 4. 知识网络 | 关联建立知识网络 | - 双链 [[ ]] - Dataview 动态聚合 - Graph View 可视化 | 4.Atom | 与已有的知识建立关联 |
| 5. 创作输出 | 整合多笔记生成文章 | Templater 插件 | 5.Apply | 可以用于发布 |
| 6. 回顾迭代 | 主动维护知识库笔记进行迭代 | - Dataview 查询“待回顾”笔记 - Spaced Repetition(可选) |
三、数据模型设计(Frontmatter 规范)
所有正式笔记(非 Inbox)需包含统一 Frontmatter,便于自动化处理:
# === 基础元信息 ===
id: # 唯一标识符,格式:YYYYMMDDHHmmss(由 Templater 自动生成)
title: # 笔记标题
summary: # 内容摘要(Hexo 发布博客用到)
author: # 作者,默认 "huan"
createdBy: # 创建者(同 author,冗余)
# === 时间戳 ===
created: # 首次创建时间,格式:YYYY-MM-DD HH:mm:ss(Templater 自动填充,用于本地)
updated: # 最后修改时间(博客与花园使用)
modified: # 文件最后修改时间(obsidian自身用的参数,与上面的updated冗余了)
date: # 公开发布时间(用于 Hexo博客、Quartz数字花园)
# === 内容分类与标签 ===
tags: # 多标签数组,如 ["Java", "Obsidian"]
categories: # 分类(比标签更粗粒度,Hexo 博客必须),如 ["知识管理", "编程"]
stage: # 内容阶段:inbox / draft / atom / apply / archives (感觉与文件夹含义重复,尚未使用该属性)
# === 发布控制(面向 Quartz / Hexo 等静态站点)===
publish: # 是否公开发布?true / false - Quartz 用
permalink: # 自定义 URL 路径,如 /post/20251108120000/ - Hexo、Quartz 兼容
top: # 是否置顶?true / false - Hexo 用
toc: # 是否显示目录?true / false - Hexo 用
cover: # 是否启用封面图?true / false - Hexo 用
coverImg: # 封面图片 URL(本地路径或 CDN)- 没啥用
img: # 卡片图 - Hexo 用
password: # 密码 - Hexo 用
# === 知识网络关系 ===
parents: # 上级主题或父笔记,可用于构建层级结构
# === 迭代与回顾系统 ===
lastReview: # 上次回顾时间,格式 YYYY-MM-DD HH:mm:ss
nextReview: # 计划下次回顾时间(可由间隔重复算法计算)
version: # 内容版本号,如 v0.1, v1.0(便于追踪演进)
# === 其他 ===
status: # 自定义状态字段(如 Done / Todo ),与 stage 互补使用
通过Templater 在新建笔记时自动插入模板。
四、关键工作流设计
一、整体工作流
graph TD
A[闪念] -->|Templater| B(Acquire)
C[Raindrop 剪藏] -->|导入| B
D[滴答清单任务] -->|同步| B
B --> E{是否需行动?}
E -->|是| F[Action]
E -->|否| G[Draft]
F --> G
G --> H{不断生长}
H -->|成熟| I[Atom 原子笔记]
I --> J{整合多篇 Atom}
J --> K[Apply: 高质量文章/输出]
I --> L1{长期未用 or 过时?}
L1 -->|是| M[Archives]
L1 -->|否| I
%% === 回顾机制:同时作用于 Atom 和 Apply ===
O[定期回顾] --> P{查询: nextReview < today}
P -->|Dataview 列表| Q[阅读并更新 lastReview / nextReview]
Q --> I
Q --> K
二、流程说明
- 采集层(Acquire):所有原始输入(闪念、剪藏、任务)统一归入
Acquire,作为“信息暂存池”。 - 分流处理:
- 需行动项 →
Action(待办导向) - 其他内容 →
Draft(迅速形成草稿)
- 需行动项 →
- 沉淀层(Atom):
Draft经反复修改、结构化、打标签后,升格为原子笔记(单一主题、可复用、有上下文)。 - 输出层(Apply):多篇 Atom 笔记交叉整合,产出博客等高价值高密度的输出。
- 归档机制:过时或低活跃度 Atom 笔记移入
Archives/,保持主知识库精简。 - 回顾循环:通过
lastReview/nextReview字段 + Dataview,主动触发复习,实现知识回顾。(简单解决方案,具体实践再看)
三、优势分析
| 优势 | 说明 |
|---|---|
| 入口统一 | 所有输入先入 Acquire,避免信息散落 |
| 角色清晰 | Acquire(原始)、Draft(草稿)、Atom(成品)、Apply(输出)四阶段职责分明 |
| 输出驱动 | 强调从 Atom 到 Apply 的整合,防止“只收藏不创造” |
| 回顾可操作 | 基于字段的回顾机制,比主观“定期看”更可持续 |
四、相关注意事项
1. Acquire → Draft 的判断标准
- ❓ 问题:如何判断一条 Acquire 内容该进
Draft还是直接丢弃? - ✅ 想法:Acquire 子文件夹按照日期归类,一定时间内(比如一周、两周)要么舍弃,要不升为 Draft。
2. Draft → Atom 的判断标准
- ❓ 问题:“反复修改”到什么程度才算 Atom?
- ✅ 想法:定义 Atom 特征(满足以下即可升格):
- 结构完整(有来源、详情、演化日志等必要信息),语句通顺
- Frontmatter 完整
- 有可联想的其他知识笔记内容,而非知识孤岛
- 每月清理
Draft中超过 60 天未修改的文件,强制决策(升格 / 归档 / 删除)。
五、技术选型与插件清单
| 功能 | 推荐插件 | 说明 |
|---|---|---|
| 模板管理 | Templater | 动态模板(日期、路径等) |
| 数据查询 | Dataview | 构建动态列表、回顾面板 |
| 网页剪藏 | Raindrop、Web Clipper (官方) 或 Markdownload | 保留干净 HTML |
| 发布数字花园 | Quartz(推荐) | 笔记生成公开数字花园 |
| 发布博客 | Hexo | 笔记生成可发布的博客文章 |
原则:插件总数 ≤ 10 个,避免臃肿;优先选择社区活跃、长期维护的插件。
六、文件夹体系设计
📁 0.Atlas # 知识地图层:用于组织高阶认知结构,不存放具体内容,而是“指向”内容
├── Dataviews # 存放常用 Dataview 查询模板(如待办、标签、回顾)
├── Mocs (Map of Contents) # 主题总览笔记,聚合某一领域下的所有 Atom 笔记(如 [[Moc-Python]])
├── Question # 持续追问的问题库,深度思考驱动实践
├── Task # 全局任务看板(可由 Dataview 聚合 2.Action/project 中的任务)
├── View # 全局视图(由 Dataview 聚合查询)
📁 1.Acquire # 信息采集池:所有原始输入的暂存区(闪念、剪藏、任务草稿)
└── Acquire-20251108 # 按日期分组,便于批量处理和清理(避免单文件夹过大)
📁 2.Action # 行动管理区:需执行的具体任务或项目
└── project # 项目级任务文件夹(每个项目可为一个笔记或子文件夹)
📁 3.Draft # 创作草稿区:正在打磨但未结构化的半成品笔记
📁 4.Atom # 原子知识库:已完成结构化、可独立复用、带标签与链接的核心知识单元
📁 5.Apply # 应用输出区:整合多篇 Atom 形成的高质量文章、博客等
📁 6.Archives # 归档区:已过时、低活跃度或完成使命的内容(非删除,保留历史)
├── 1.resources # 静态资源(代码片段、模板等)
│ ├── Js
│ └── Template
└── 2.backup # 归档文件夹
📁 9.TempInbox # 临时收件箱:短期使用,后期有可能删除
📄 关于我 # 个人简介、系统使用指南
📄 友链 # 外部优质知识源链接
📄 index # 系统首页/导航页,汇总各模块入口七、双链设计
可产生的双链大致有以下几种:
- 正文中自然引用的,不做管理,顺其自然。
- 父级节点,使用 Yaml 中 parents 属性进行管理。
- 同级笔记:横向对比/延伸出去的笔记链接,统一放置在二级标题“关联网络”中。
- 子级笔记:可放置在二级标题“关联网络”中。
- 跨主题、自然联想到的笔记:统一放置在二级标题“关联网络”中。
那么通过 parents 属性编写脚本,直接生成笔记大纲。已初步完成,详见 渲染大纲。
关联网络
演化日志
- v0.1 (2025-11-08):初始版本完成
- v0.2 (2025-11-29):补充Frontmatter 规范设计、文件夹设计。
复习回顾
📈 轮次: 1 🕒 lastReview: 2025-11-29 10:08:41 📅 nextReview: 2025-12-06 00:00:00
待办事项
- 使用 Templater 创建“回顾模板”,一键更新
lastReview = today并计算nextReview = today + 30d - 有些地方还是不太满意,应用中需要逐步优化。比如核心模块设计以及文件夹体系设计等等