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
 

二、流程说明

  1. 采集层(Acquire):所有原始输入(闪念、剪藏、任务)统一归入 Acquire,作为“信息暂存池”。
  2. 分流处理:
    • 需行动项 → Action(待办导向)
    • 其他内容 → Draft(迅速形成草稿)
  3. 沉淀层(Atom):Draft 经反复修改、结构化、打标签后,升格为原子笔记(单一主题、可复用、有上下文)。
  4. 输出层(Apply):多篇 Atom 笔记交叉整合,产出博客等高价值高密度的输出。
  5. 归档机制:过时或低活跃度 Atom 笔记移入 Archives/,保持主知识库精简。
  6. 回顾循环:通过 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
  • 有些地方还是不太满意,应用中需要逐步优化。比如核心模块设计以及文件夹体系设计等等