# Obsidian 知识库治理蓝皮书
序言 知识管理是一项长期且复杂的工程，只有通过清晰的规范，才能确保信息在收集、整理、使用和传承的每一个阶段都能高效发挥价值。 本蓝皮书即是为此目标而制定的一套统一标准，并以PARA 模型、生命周期视角与演进式治理为指导思想，致力于构建一个既灵活又严谨的知识管理体系。 宗旨 本规范旨在解决以下核心问题： 可发现性：所有笔记都能通过一致的命名、标签和索引被快速找到，无论是近期创建还是多年沉淀。 ...

2025年11月03日37分钟阅读

## 序言

知识管理是一项长期且复杂的工程，只有通过清晰的规范，才能确保信息在收集、整理、使用和传承的每一个阶段都能高效发挥价值。

本蓝皮书即是为此目标而制定的一套统一标准，并以PARA 模型、生命周期视角与演进式治理为指导思想，致力于构建一个既灵活又严谨的知识管理体系。

### 宗旨

本规范旨在解决以下核心问题：

1. 可发现性：所有笔记都能通过一致的命名、标签和索引被快速找到，无论是近期创建还是多年沉淀。
2. 可重用性：每条信息都经过清晰的分类与关联，方便在不同项目、主题、领域中反复引用、复用。
3. 可演化性：知识随着时间更新演进，笔记的状态、版本、上下文都能被追溯和完善，避免信息孤岛与遗忘。
4. 可协作性：既支持个人第二大脑的高效使用，也支持团队共享与多角色参与，通过元数据、版本控制、权限管理保障协同质量。

通过统一规范，既保障个人使用的简洁高效，也支持团队场景的协作和长期维护。

### 指导思想

本蓝皮书在设计上，秉持以下三大原则：

1. 框架先行，细节渐进：先确立清晰的分区与命名逻辑（PARA 模型），再通过实践逐步丰富标签、元数据和模板。先搭好骨架，再养成肌肉。
2. 生命周期视角：所有信息都视为从收集（Capture）—整理（Curate）—创造（Create）—连接（Connect）—归档（Archive） 的流动过程，避免写完即弃。
3. 可验证与可改进：所有规范应当具备可衡量的执行标准（如清理率、分类率、链接密度），并在使用中迭代优化。

### 适用范围

本蓝皮书适用于以下 Obsidian 知识库核心组件与工作流：

- Markdown 笔记：所有日常记录、项目文档、读书笔记、会议纪要、研究备忘等。
- YAML 元数据：用于描述笔记属性（状态、责任人、版本、隐私级别、标签等），支撑自动化管理、进度追踪与权限控制。
- 目录与命名规范：所有文件与文件夹应遵循**PARA 分区（Projects、Areas、Resources、Archive）**及统一命名规则（见后续章节），确保跨平台一致性。
- 附件管理：图片、PDF、音频、视频及其他二进制文件的命名、存储、引用方式。
- 脚本与自动化工具：包括 Templater 模板、Dataview 查询、批量操作脚本（如 Inbox 清理、状态审计）、Git 同步钩子等。
- 插件配置：所有核心插件（如 Dataview、Templater、Git 等）的启用、版本管理、配置文件标准。
- 版本控制与安全措施：Git 同步策略、加密流程、访问控制、审计日志。

简而言之，凡是与 Obsidian 知识库全生命周期相关的内容，均在本蓝皮书约束范围之内。

### 派生规范

考虑到不同使用者（如个人与团队）、不同领域（科研、产品、写作）在实践中存在差异，本蓝皮书引入派生规范机制，以兼顾统一性与灵活性。

规则如下：

1. 最高准则：蓝皮书为全局通用最高规范，所有笔记和操作必须遵循其基本原则（可发现性、可重用性、可演化性、可协作性）。
2. 领域派生规范：在蓝皮书框架下，可制定更具针对性的细化规范，
3. 继承与冲突处理：派生规范不得与蓝皮书核心原则相抵触。如出现冲突，建议以蓝皮书为准。
4. 修订与演进：蓝皮书及派生规范均需通过标准化流程（提案、评审、版本发布）进行修订。

### 核心价值观

本蓝皮书倡导以下价值观：

- 透明性：所有笔记和变更都可被追溯和解释。
- 一致性：无论个人或团队，始终遵循统一的结构与命名约定。
- 简洁性：避免不必要的复杂化，确保长期可维护性。
- 灵活性：通过派生规范与元数据，兼容不同场景和偏好。
- 进化性：鼓励持续完善，拥抱新工具（如 AI 自动标注、智能推荐、去中心化存储）。

## 目录与命名

目录与命名的本质，是用一致的结构和语义为笔记赋予位置与上下文，让内容在海量积累中始终可发现、可组合、可迁移。

良好的目录体系不是一成不变的分类法，而是一种帮助人和机器理解知识边界与关系的长期约定。通过清晰、有限、统一的命名与层级规则，知识库才能在扩展中保持有序，而非退化为混沌的信息堆。

### 核心理念

1. 层级清晰，语义明确：每一层目录都应表达唯一且清晰的概念，禁止混用主题、类型、时间等不同分类维度，确保路径在任何场景下都能一眼理解其含义。
2. 编号驱动与命名规范：所有目录和文件应采用两位编号 + kebab case命名方式，既能保证在多系统下排序一致，又提升可读性和脚本兼容性，避免因空格或大小写导致的问题。
3. 有限层级：目录深度建议不超过三层，防止路径冗长、迁移复杂和协作混乱。如需更细粒度的分类，优先通过标签或索引笔记而非增加层级。
4. 可迁移性与稳定性：命名与目录应保持跨平台和跨工具的兼容性，避免依赖特定软件或插件的私有逻辑，保障在不同环境下长期可用。
5. 演进与治理机制：目录结构和命名规范不是静态的，应定期审视与优化，确保在知识库成长时依然贴合实际使用需求，并保留向后兼容性。

### 目录规范

根目录采用数字编号 + 主题分组的命名方式，确保分类清晰、顺序一致，并便于未来扩展和维护。

    .
    ├── 00-knowledge             # 知识体系、风格指南、方法论
    ├── 10-formal-sciences       # 数理科学
    ├── 16-computer-science      # 计算机科学
    ├── 20-natural-sciences      # 自然科学
    ├── 30-social-sciences       # 社会科学
    ├── 40-professional          # 职业技能
    ├── 50-personal              # 个人生活
    ├── 60-writing               # 写作产出
    ├── 70-future                # 前沿探索
    ├── 80-project               # 项目与任务
    ├── 90-obsidian              # Obsidian 配置与模板
    ├── 91-attachments           # 附件（图片、音视频）
    ├── 92-archive               # 历史归档
    ├── 99-inbox                 # 临时收集
    └── README.md                # 仓库说明

#### 设计原则

一级目录建议使用整十编号优先（如 `10-`、`20-`、`30-`），为后续新增分类预留编号区间。

例如：`16-computer-science` 源自 `10-formal-sciences` 拆分，如果未来需要细分，可在 `11-19` 范围内插入新目录。同理，若 `40-professional` 下需增加细分类，可使用 `41-`、`42-` 等编号。

### 命名规范

为确保文件可预测、可检索、便于长期维护，务必遵循以下通用规则：

#### 通用规范

规则 | 说明
--- | ---
小写字母 | 仅使用 `a-z`、`0-9` 和短横线 `-`
不含空格 | 所有空格统一替换为短横线 `-`
无特殊字符 | 禁用 `_`、`#`、`@`、`&` 等特殊符号
可读性优先 | 避免不必要的缩写，保持清晰、直观
日期格式 | `YYYY-MM-DD` 或 `YYYY-MM-DDTHH:mm:ssZ`

#### 命名要素

要素 | 说明 | 示例
--- | --- | ---
大小写 | 文件名全部使用小写字母 | `zettelkasten-methodology-core.md`
分隔符 | 统一采用短横线 `-` 作为分隔符 | `python-virtualenv-overview.md`
短标识（slug） | 无日期的主题材料需使用简短标识，清晰表达主题及关键词 | `zettelkasten-methodology-core.md`
字符限制 | 文件名建议 ≤ 100 字符，slug 建议 ≤ 20 字符 | 遵循上述示例

## 元数据与 YAML

元数据的本质，是为笔记赋予机器可读的身份与语义，让其从纯文本演化为结构化、可计算的知识单元。通过 YAML Frontmatter，笔记不仅具备人类可读性，还能支持高效检索、自动分类、智能推荐和生命周期管理。

一个规范、演进的元数据体系，是任何第二大脑系统长期可扩展性的关键保障。

### 核心理念

1. 结构化信息：元数据将笔记从无结构文本提升为带结构的数据容器，让自动化工具（如 Dataview、Templater、搜索脚本）能够可靠地解析、处理与重组内容。
2. 多维度索引：YAML 字段支持按主题、日期、状态、隐私级别等多维度快速筛选和聚合，让笔记在海量内容中保持可发现性。
3. 语义可演化：元数据体系应随着知识库的发展不断演化：在保持向后兼容的前提下，逐步拓展新字段和约定，适配更多业务和使用场景。
4. 一致性与标准化：所有笔记应遵循统一的元数据字段、命名规范和数据格式，避免因随意扩展导致的语义混乱与工具解析失败。
5. 最小必要集：元数据应保持简洁，只包含当前必需的字段，避免冗余和复杂性；每新增一个字段都需明确其使用场景和维护责任。

### 核心字段

字段 | 作用 | 必须性
--- | --- | ---
`slug` | 永久 ID | ✅
`title` | 可读标题 | ✅
`tags` | 标签类型 | ✅
`status` | 生命周期 | ✅
`updated` | 时间戳 | ✅
`review` | 复审日期 | ⚙️
`author` | 作者数组 | ⚙️
`privacy` | 权限级别 | ⚙️
`source` | 信息来源 | 🌱
`related` | 关联笔记 | 🌱

### 字段规范

字段 | 类型 | 格式 / 可选值 | 说明 | 示例
--- | --- | --- | --- | ---
`slug` | string | `^[a-z0-9\-]{3,80}$`（全小写、连字符） | 永久唯一 ID | `deep-work-notes`
`title` | string | 1–160 字符，不含首尾空格 | 人类可读标题 | `深度工作读书笔记`
`tags` | string[] | 每项：`#分组/主题`，最多 8 个 | 类型/主题标签 | `["#type/book", "#topic/focus"]`
`status` | enum | `idea` · `draft` · `review` · `published` · `evergreen` · `archived` | 生命周期阶段 | `draft`
`updated` | datetime | ISO 日期：`YYYY-MM-DD` 或 `YYYY-MM-DDTHH:mm:ssZ` | 最近更新时间 | `2025-07-09T15:25:00Z`
`review` | date | ISO 日期：`YYYY-MM-DD` 或 `YYYY-MM-DDTHH:mm:ssZ` | 下次复审日期 | `2025-10-01`
`author` | string[] | 每项 1–50 字符，最多 5 个 | 作者/责任人 | `["Cal Newport"]`
`privacy` | enum | `public` · `internal` · `confidential` | 权限级别 | `internal`
`source` | string / object | 简写：`book: 名称` 或对象：`book:`、`url:` | 信息来源 | `book: Deep Work` `url: https://example.com`
`related` | link[] | Obsidian 内部链接格式：`[[笔记ID]]`，最多 10 个 | 关联笔记 | `["[[focus-habits]]", "[[time-blocking]]"]`

### 标准模板示例

    ---
    slug: deep-work-notes
    title: 深度工作读书笔记
    tags:
      - #type/book
      - #topic/focus
    status: draft
    updated: 2025-07-09T15:25:00Z
    review: 2025-10-01
    author:
      - Cal Newport
    privacy: internal
    source:
      book: Deep Work
      url: https://www.calnewport.com/books/deep-work/
    related:
      - [[focus-habits]]
      - [[time-blocking]]
    ---

## 链接与引用

链接与引用的本质，是让知识在时空中产生可验证的关联。

链接是知识库的血管，引用是流动其中的血液，二者共同构建了跨笔记、跨主题、跨时间的结构化网络。只有当链接体系具备一致性、可追溯性与长期稳定性，个人或团队的知识管理系统才能演化为可计算、可发现的动态图谱。

### 核心理念

1. 统一性：所有内部链接应统一使用 `[[相对路径/文件名]]` 格式，禁止混用绝对路径、裸文件名或扩展名，确保在多平台与多工具间稳定解析。
2. 上下文清晰：每条引用都必须在正文交代出处与用意，避免出现孤立的悬空链接，让后续阅读和检索具备明确语义。
3. 长期稳定性：链接应始终指向固定的文件名或锚点，文件改名需使用重命名并更新链接功能，保证历史引用不失效。
4. 可检索性：链接命名应兼顾人类可读性与机器可检索性，支持 Dataview、Graph View 等工具查询；外部链接一律使用 Markdown 标准格式。
5. 双向友好：当引用外部主题或关键笔记时，建议在目标笔记创建回链，形成双向链接，保持知识图谱的完整性与可探索性。

### 内部链接规范

#### 绝对根目录相对路径

    [[根目录/子目录/文件名]]

- 根目录起算：避免在不同文件夹层级出现多种相对标准
- 不得添加 `.md`：兼容移动端、博客生成器
- 改名自动更新：务必开启 `Settings ↦ Files & Links ↦ Automatically update links` 或使用 Advanced URI 批量脚本

### 外部链接规范

#### 主流 Markdown 形式

    [可读标题](https://example.com)

- 禁止裸 URL：阅读体验差，难以全文检索显示

- 可选标题别名：`[RFC 2119](https://www.rfc-editor.org/rfc/rfc2119)`

- 引用块格式（推荐）

      > 来源: [维基百科·微积分](https://zh.wikipedia.org/wiki/微积分)

### 引用段落

要素 | 说明 | 不合规示例 | 合规示例
--- | --- | --- | ---
显式来源 | 链接或内部引用必须在同一区块标明 | 只贴文字不注明出处 | `> 来源: [[zettelkasten-method]]`
上下文摘要 | 引用内容前需 1-2 句解释 为何引用 | 裸链接堆砌 | `> Zettelkasten 方法强调…`
二次加工 | 建议在引用后立即写批注，提升原创比例 | 无批注 | `> 💡我的思考：…`

### 跨主题引用

1. 检索意图明确

   - `CTRL/CMD + O` 打开目标笔记快速预览
   - 确认与当前主题 tag 不冲突

2. 插入引用块

       > 来源: [[10-formal-sciences/01-mathematics/calculus-overview#基本概念|基本概念]]
       > 微积分研究变化率与累积量…

3. 补充 YAML `related`（自动或手动）

       related:
         - [[calculus-overview]]

### 最佳实践

    ### 1 何为深度工作

    源起于 Cal Newport 的定义：

    > 来源: [[理论/生产力/深度工作笔记#定义|定义]]
    > 深度工作（Deep Work）是指…
    > *💡我的洞见：在 AI 时代，深度专注更显稀缺。*

    外部佐证：

    > 来源: [MIT Study (2024)](https://doi.org/10.1145/XXXX)
    > 对 2000 名知识工作者的实验表明…

    ---

    相关笔记
    - [[行为/专注习惯/focus-habits]]
    - [[工具/时间管理/time-blocking]]

## 标签

标签的本质，是为知识内容赋予可横向组合的语义坐标。

在目录负责物理归档的前提下，标签承担着跨主题检索、自动化聚合与智能推荐的关键角色。一套语义清晰、层级合理、演进友好的标签语言，能够显著提升笔记系统的可发现性与长期适应性。

### 核心理念

1. 语义清晰：每个标签都应明确表示主题或属性，而非目录位置。标签是内容的语义标记，不应混用物理归档概念，如用 `#machine-learning` 表示领域，而非 `#10-formal-sciences`。
2. 层级有限：标签层级最多保留两级，避免出现无限嵌套导致混乱。层级关系仅用于必要的上位—下位概念，如 `#project/active`。
3. 一事一义：每个标签只表达一个维度，避免含混不清的泛用标签。禁止使用如 `#todo` 等模糊标签，任务管理应通过专用插件或状态字段完成。
4. 演进与治理机制：标签体系不是一次性定义完毕，应随着知识库扩展定期审视、合并、废弃或新增，保持语义鲜明与适应性。
5. 最小必要集：标签数量应控制在能被人脑识别和运用的范围内，优先少而清晰，而非多而分散，确保长期可维护性。

### 命名规则

为保证一致性与脚本兼容，建议标签命名遵循以下规范：

规则 | 要点
--- | ---
全小写字母 | `machine-learning`
短横线分词 | `knowledge-management`
无空格 & 特符 | 禁用空格、`& @ $` 等
不用 emoji | 保持纯文本
二级以斜杠切分 | `#topic/data-science`

### 核心维度

维度 | 前缀范式 | 例子 | 场景
--- | --- | --- | ---
主题 | `#topic/` | `#topic/security` `#topic/docker` | 跨学科聚合
类型 | `#type/` | `#type/article` `#type/cheatsheet` | 文档形式、输出形态
状态 | `#status/` | `#status/draft` `#status/review` | 仅在你不想用独立 `status` 字段时
项目 | `#project/` | `#project/obsidian-wiki` | 多文件协作或时间绑定任务

### 扩展维度

维度 | 前缀范式 | 示例 | 适用场景
--- | --- | --- | ---
扩展 | `#ext/` | `#ext/experimental` `#ext/temp-2025` | 临时性、实验性、待定性或短期标签

## 模板与自动化

模板与自动化的本质，是将高频认知劳动转化为可复用的流程资产。

它不仅提升效率，更保证了内容质量的稳定性与团队协作的一致性。在知识库体系中，模板和脚本构成了结构化生产与持续改进的基础设施，是实现规模化、标准化与智能化的关键要素。

### 核心理念

1. 一致性优先：所有模板和脚本必须在命名、存放位置、字段定义上保持统一，确保任何成员使用相同输入都能得到一致输出，降低协作摩擦。
2. 可追溯性保障：每一个模板与脚本都应记录作者、版本、用途等元数据，确保在出错或需要优化时能快速定位责任与修改依据。
3. 自动化友好：所有模板需与 Templater、QuickAdd、Dataview 等核心插件兼容，脚本输出格式应保证可被后续流程解析，支持批量操作与持续改进。
4. 最小耦合性：模板与脚本尽量保持独立与通用，避免与特定笔记或个人习惯高度耦合，以增强可移植性和团队复用性。
5. 演进与复盘机制：模板和自动化脚本不是一劳永逸，需定期复盘其适配性、效率和易用性，根据反馈持续优化迭代。

### 目录结构

所有模板和脚本统一存放于：

    90-obsidian/
    ├── templates/         # 模板
    │   ├── daily.md
    │   ├── weekly.md
    │   ├── meeting.md
    │   ├── reading.md
    │   ├── project.md
    │   └── proposal.md
    ├── script/            # 自动化脚本
    │   ├── rename.js
    │   ├── update-metadata.js
    │   └── batch-move.py
    ├── marp/              # 幻灯片模板
    └── icon/              # 图标资源

### 必备模板

模板类型 | 主要作用
--- | ---
日报模板 | 记录每日行动、反思、重要事件，形成细颗粒度的行为数据积累
周报模板 | 总结本周进展与收获，规划下周目标，促进节奏与持续改进
读书模板 | 提炼书籍要点、个人见解与后续行动，沉淀系统化阅读资产
季报模板 | 战略性总结与方向调整，梳理季度目标达成情况
博客模板 | 支持结构化写作，输出对外内容，提升影响力
文档模板 | 记录和共享结构化资料，形成项目或知识的正式输出

## 生命周期

生命周期管理的本质，是把笔记视为持续演化的知识资产，而非一次性内容。

通过清晰的阶段划分、准入条件和流转标准，确保每条笔记在不同阶段都具备明确目标和时间约束，让知识始终处于最新、最优、最相关状态，避免沉没成本和陈旧信息的累积。

### 核心理念

1. 演进视角：所有笔记都是不完整的假设集合，需要在捕获、验证、沉淀、更新的周期中不断演进，而非一次性定稿。
2. 阶段明确：生命周期分为 Inbox、Draft、Review、Evergreen、Archive 五个阶段，每一阶段都有清晰的目标、准入条件和时限约束，避免状态混乱。
3. 周期性复核：任何笔记都需要定期复查其有效性与适用性，防止过时即真理，尤其是 Evergreen 笔记需每 180 天至少复核一次。
4. 可追溯与透明：每次状态变更都必须记录原因、执行人和时间，形成知识资产演化的完整轨迹，便于复盘与责任界定。
5. 最小必要活跃集：知识库不是越多越好，只有符合当前任务和长期价值的内容才应保留在活跃区，过时或无效内容应归档封存，降低认知负担。

### 生命周期阶段

每条笔记从产生到封存，严格分为五个阶段，各阶段目标、进入条件、时限如下：

阶段 | 目标 / 定义 | 关键内容 / 进入条件 | 时限与触发条件
--- | --- | --- | ---
Inbox | 捕获原始想法、资料，防止信息丢失 | 任何新内容都自动进入此状态，无需结构化内容；此阶段仅用于快速收集 | 无固定时限，但需在每周例行整理时清理
Draft | 初步成文，建立基础结构和内容骨架 | - 至少 30% 的主要内容 - 明确标题、摘要、关键词 - 作者确认笔记进入 Draft 状态 | 2 周内必须转入 Review，否则需重新评估重要性
Review | 内容完整但需验证、完善、核对 | - 已有完整内容 - 明确下一次复核日期（`review_date`） - 指定复核人 - 状态标记为 Review | 超过 `review_date` 90 天未更新需提醒复核
Evergreen | 经验证长期有效、可复用、质量上乘 | - 内容准确、无重大遗漏 - 结构完整（摘要、关键词、引用齐全） - 最近 90 天内更新过 - 至少 2 条其他笔记引用此内容 - 负责人确认通过 | 定期（每 180 天）需重新审视其有效性与适用性
Archive | 历史或无效内容，封存备查，不再活跃 | - 不再活跃或已被合并/废弃 - 无需再更新 - 状态变更需说明原因 | 无固定时限，如需恢复需按撤销归档流程

### 状态流转规范

笔记状态必须遵循下列严格流程：

    flowchart TD
        A[Inbox 捕获原始内容]
        B[Draft 初步成文]
        C[Review 待验证]
        D[Evergreen 长期有效]
        E[Archive 封存]

        A -->|开始整理| B
        B -->|完成初稿| C
        C -->|验证通过| D
        C -->|不再活跃| E
        C -->|需重大修改| B
        D -->|定期复核/失效| C
        D -->|主动封存| E

## 插件治理

插件治理的本质，是在自由扩展与可控演化之间取得平衡。

插件是 Obsidian 的创新引擎，也是第二大脑最敏感的依赖层：一旦无序引入、无限叠加，就会带来兼容性崩溃、安全风险和长期负债。治理的目标不是遏制创新，而是让创新在最小复杂性与最高可靠性框架下安全落地。

### 核心理念

1. 插件即基础设施：任何插件一旦纳入核心工作流，就应视为关键基础设施，而非可随意替换的工具。
2. 最小必需性：插件数量越多，复杂性与依赖性呈指数上升。优先使用原生功能和核心插件，避免功能重复或冗余。
3. 分层信任模型： 不同插件应有不同的信任级别：一级：官方核心插件、二级：知名社区维护、活跃更新、三级：个人作者、实验性插件。不同级别决定验证深度与更新频率。
4. 时间价值与依赖评估：所有插件都在价值 - 依赖 - 维护负担三轴上权衡。即便功能强大，如果依赖过深或作者已弃坑，需保留替代预案。
5. 可逆性优先：没有完美的插件组合。任何配置都应支持快速回滚和最小损失切换，保障知识库在最坏情况下依然可用。

### 推荐插件

插件 | 用途
--- | ---
Calendar | 日历视图
Excalidraw | 思维白板
Dataview | 数据查询
linter | Markdown 格式化
marp slides | 幻灯片生成
periodic-notes | 周期性笔记
Templater | 模板引擎
weread | 微信读书笔记同步

## 附件管理

附件管理的本质，是对笔记知识体系的资产治理，它不仅关乎存储有序，更关乎来源可溯、结构清晰、生命周期明确。

每一个附件，都是内容生态的一部分：它既是证据与上下文，也是潜在负债与风险。治理的目标，不是消灭冗余，而是在复杂性与可用性之间取得平衡，让所有附件都具备身份、路径、和生命轨迹。

### 核心理念

1. 附件即知识资产：任何附件都是笔记系统的长期资产，而非临时文件。它们承载着证据、语境和可复用价值，必须被系统化治理。
2. 可溯源性优先：附件命名、元数据、存放结构都应确保来源可查、用途可辨、关联清晰，避免日后出现孤儿文件。
3. 最小依赖性：所有附件应尽量本地化存储，不依赖外链或专有协议。文件与笔记相互独立，增强系统迁移与长期可用性。
4. 生命周期管理视角：附件应具备活跃—归档—清理全周期策略，避免存储膨胀和冗余堆积。

### 附件存放目录

附件统一置于 `/91-attachments/` 目录，并按类型分文件夹：

    91-attachments/
    ├── audio/        # 音频文件
    ├── documents/    # 文档（PDF、Word等）
    ├── drawings/     # 绘图、流程图
    ├── images/       # 图片
    ├── videos/       # 视频

### 命名规范

    <type>-<YYYYMMDD>-<slug>.<ext>

类型 | 前缀 | 示例
--- | --- | ---
图片 | img- | img-20250707-vault-overview.png
音频 | audio- | audio-20250707-interview.m4a
视频 | video- | video-20250707-demo.mp4
文档 | doc- | doc-20250707-governance.pdf
绘图 | draw- | draw-20250707-architecture.svg

### Git LFS

Git 仓库可选择启用Git LFS，如下可参考 `.gitattributes` 示例：

    *.png filter=lfs diff=lfs merge=lfs -text
    *.mp4 filter=lfs diff=lfs merge=lfs -text

## 排版与风格

排版与 Markdown 风格的本质，是知识表达的规范化。

它既是对内容美学的约束，也是对未来迁移性、自动化处理、长期可维护性的保障。排版不是装饰，而是结构化认知的容器，良好的排版体系让笔记在跨平台、多工具流转时依旧清晰、准确、可解析。

### 核心理念

1. 一致性优先：所有笔记遵循统一的排版规范，无论作者、主题或场景，风格都保持一致，避免因个人偏好导致阅读和维护成本上升。
2. 可移植性保障：Markdown 仅使用通用语法，确保在各类渲染器（Obsidian、Typora、GitHub、静态博客）显示一致。除必要的 Admonition 外，禁止依赖 Obsidian 私有格式。
3. 自动化友好：所有格式应满足自动化校验（如 Linter）和脚本解析要求，不产生语法错误或模糊表意，为后期批量处理与格式转换打下基础。
4. 结构化优先于装饰：强调通过清晰的标题、列表、表格、引用来表达逻辑，而非纯粹视觉美化，保证长期可维护性和内容可演化。
5. 最小惊讶原则：阅读者应能在任何笔记中预期相同的结构和格式，降低理解门槛，提升协作一致性。

## 版本控制

版本控制的本质，是为个人知识系统提供可验证的演化记录与安全冗余。

在分布式文件存储中，版本管理不仅防止意外丢失，更是协作、审计、和内容信任的基石。良好的版本治理让笔记的每一次修改都有迹可循、有据可查、可随时回滚，同时兼顾共享协作与私密安全。

### 核心理念

1. 审计可追溯：所有内容变更都必须形成可审计的记录，确保每一次修改都能溯源至责任人和变更原因，支撑长期可信的知识演进。
2. 分支清晰：不同工作流（功能开发、修复调整、发布同步）应在分支层面清晰隔离，避免内容冲突与错误覆盖，增强协作透明度。
3. 最小权限原则：公共内容与私密内容分区存储、分区同步，确保权限最小化，敏感信息不被错误公开或传播。
4. 自动化驱动：版本管理与同步流程应通过自动化工具驱动：提交前自动校验格式规范、自动备份到远程仓库、自动部署公开内容，降低人为操作失误。
5. 冗余与可逆性：同步机制需确保多地冗余存储和快速回滚能力，任何版本都能在数分钟内恢复到历史状态，保障知识安全。

## 安全与隐私

安全与隐私的本质，是在开放性与保护性之间取得平衡，让知识既能自由流通，又不失去对敏感内容的控制权。

在第二大脑体系中，安全治理不仅仅是防止外泄，更是对内容可信性、合法合规性、长期可用性的系统性保障。良好的安全框架必须覆盖分级分类、加密存储、权限控制与审计记录，并形成可持续演进的治理机制。

### 核心理念

1. 分级分类优先：所有内容先进行安全级别划分，再决定存储位置、加密方式和访问策略，避免一刀切导致安全过度或不足。
2. 默认保守原则：未明确分类的内容一律视为 `internal`，禁止默认公开，最大限度降低无意识泄露风险。
3. 加密优先：对于 `confidential` 等敏感数据，先加密再存储或同步，确保即使外部存储泄漏也无法直接读取。
4. 最小权限控制：仅对必要人员授权访问，分层分区配置权限，杜绝全库共享，避免权限膨胀。
5. 可审计与可回溯：所有访问与变更操作都应具备日志记录，能够在事后审计、复查和责任认定，保障安全事件的可追溯性。