raw 是原料，wiki 是成品——为什么你的知识库必须分层（附完整架构模板）

🗂️ raw 是原料，wiki 是成品——为什么你的知识库必须分层（附完整架构模板）

🪝 

为什么知识库必须分层？

Inbox → raw → wiki 这个三层结构，如果你只是把它当成「一种文件夹分法」，你就错过了它背后最重要的东西：

这不是一种文件夹分法，这是一套「知识消化系统」的设计原则。

这篇文章，我想彻底讲透这个最基础、但也是最核心的设计原则——以及一套可以直接复用的完整知识库架构模板，让你从一开始就把底层结构建对。

「底层结构建对了，上面的一切才能自然生长；底层结构建错了，折腾多少工具都是在搬家，不是在建系统。」

🧪 Part 1：用一个类比彻底讲清楚「分层」的逻辑

想象你开了一家餐厅。

餐厅的运转，有三个截然不同的空间：

text

① 仓库（原料区）
  → 刚从市场买回来的食材
  → 可能有些已经洗干净了，可能有些还是泥
  → 质量参差不齐，但都是可用的原材料
② 厨房（加工区）
  → 正在处理的食材
  → 有人在切菜，有人在调味，有人在热锅
  → 半成品状态，正在被转化
③ 出餐口（成品区）
  → 已经做好可以端出去的菜
  → 高质量，已经经过完整加工
  → 任何一桌客人叫这道菜，直接端出去

你的知识库，也需要这三个空间：

为什么不能混在一起？

因为每个空间的「处理逻辑」完全不同：

• 仓库：追求「快进快出」，不要积压
• 厨房：追求「处理到位」，不要马虎
• 出餐口：追求「质量稳定」，不要随便改

如果你把原材料直接放进出餐口，客人拿到的是一盘没炒熟的菜。

如果你的厨房永远处于混乱状态，出餐口永远空着，你的餐厅就关门了。

知识库的失败，通常就是这三个空间的边界模糊——所有东西堆在一起，找不到，也用不上。

🔬 Part 2：认知科学视角——大脑是怎么分层处理信息的

这套分层设计，其实有对应的认知科学基础。

人类大脑在处理新信息时，也是分层次的：

text

工作记忆（Working Memory）
  → 暂时储存当下的信息
  → 容量极小（7±2 个组块）
  → 如果不处理，很快消失
长期记忆 — 陈述性记忆（Declarative Memory）
  → 情景记忆：发生了什么事（具体经历）
  → 语义记忆：概念和原则（抽象知识）
自动化知识（Procedural Memory）
  → 已经内化，不需要主动回忆
  → 可以自动调用的技能和直觉

对应到知识库：

知识管理失败的本质，是把工作记忆（Inbox）和长期记忆（raw/wiki）混在了一起。

工作记忆是「暂存」，不是「归档」。

你把所有东西都塞进一个文件夹，相当于让你的大脑把工作记忆和长期记忆放在同一个区域——结果就是两边都乱，什么都找不到。

「分层不是强迫症，是对「信息处理需要时间」这件事的尊重。原料不会自动变成成品，中间需要一个消化过程。」

🏗️ Part 3：完整的知识库架构模板

基于这套分层逻辑，以下是我经过 3 个月迭代后的完整 Vault 架构，可以直接复用：

完整文件夹结构

text

MyBrain/                          ← Vault 根目录
│
├── AGENTS.md                     ← 系统配置，Codex 启动时读取
├── README.md                     ← 知识库使用说明（写给未来的自己）
│
├── Inbox/                        ← 第一层：原料区（快进快出）
│   ├── clippings/                ← 网页剪藏
│   ├── voice/                    ← 语音转文字
│   └── manual/                   ← 手动输入的想法
│
├── raw/                          ← 第二层：加工区（结构化整理）
│   ├── reading/                  ← 读书笔记
│   ├── articles/                 ← 文章摘要
│   ├── meetings/                 ← 会议记录
│   ├── thinking/                 ← 个人思考草稿
│   └── processed/                ← Inbox 处理完归档到这里
│
├── wiki/                         ← 第三层：成品区（成熟知识）
│   ├── concepts/                 ← 核心概念页
│   ├── methods/                  ← 方法论页
│   ├── people/                   ← 人物/书单页
│   └── projects/                 ← 项目知识页
│
├── daily/                        ← 日常区（每日笔记）
│   ├── 2026-01.md ~ 2026-12.md   ← 每日笔记
│   └── weekly/                   ← 每周复盘
│       └── 2026-W01.md ~ ...
│
├── projects/                     ← 项目区（具体在做的事）
│   ├── series-01/                ← 系列一：搭建篇文章
│   ├── series-03/                ← 系列三：PKM工作流
│   └── personal-growth/          ← 个人成长记录
│
└── archive/                      ← 归档区（旧内容/legacy）
    └── pre-2026/                 ← 系统建立前的旧笔记

每一层的核心规则

Inbox 规则（原料区）

Markdown

Inbox 的唯一原则：「快进快出，不要积压」
✅ 允许：
  - 任何格式，不要求 frontmatter
  - 不完整的想法
  - 直接粘贴的原文
  - 语音转文字的口语内容
❌ 禁止：
  - 在 Inbox 里「整理」
  - 在 Inbox 里建子文件夹分类
  - 让任何一条笔记在 Inbox 里超过 3 天（超过 3 天 = 系统提醒我处理）

raw 规则（加工区）

Markdown

raw 的核心原则：「结构化，但允许不完美」
✅ 必须有：
  - frontmatter（date/tags/status/source）
  - 基本的内容结构（标题/要点/来源）
  - status 追踪（draft/reviewing/published）
✅ 允许：
  - 内容不完整（mark 为 draft）
  - 观点还没确定
  - 结构还在迭代
❌ 禁止：
  - 没有 frontmatter 的裸文件
  - 内容完全照搬原文，没有任何处理

wiki 规则（成品区）

Markdown

wiki 的核心原则：「高质量，可直接引用」
✅ 必须有：
  - 完整的 frontmatter（status=published）
  - 清晰的「一句话定义」（这个概念/方法是什么）
  - 至少 1 个双向链接（和其他 wiki 页面相连）
  - 适用场景说明（什么时候用这个知识）
✅ 应该有：
  - 个人实践案例（不只是理论描述）
  - 和其他概念的关系（异同、关联）
  - 最后更新日期（知识需要随时间迭代）
❌ 禁止：
  - 在没有告知我的情况下修改已发布内容
  - 只有摘抄，没有自己的理解

知识在三层之间的流动机制

text

信息输入
    ↓
┌─────────────────────────────┐
│         Inbox               │
│  新文章/想法/语音备忘录进来  │
│  Codex 每 3 天自动扫描提醒  │
└──────────────┬──────────────┘
               │ Codex 处理（inbox-triage）
               │ ↓ 提炼观点 + 生成摘要 + 推荐关联
               ↓
┌─────────────────────────────┐
│          raw/               │
│  status=draft               │
│  有结构，有 frontmatter      │
│  Codex 每周检查晋升候选      │
└──────────────┬──────────────┘
               │ 手动确认晋升（note-promotion）
               │ 条件：被多次引用 / 内容成熟 / 反复用到
               ↓
┌─────────────────────────────┐
│          wiki/              │
│  status=published           │
│  高质量，有双向链接          │
│  可被任何笔记直接引用        │
└─────────────────────────────┘
               │
               ↓
        输出到实际工作
   （文章/决策/创作/学习）

🔑 Part 4：「分层」的最高级用法——让知识自动「晋升」

大多数人的知识库，是「人推着系统走」的：

你要主动去整理，主动去建连接，主动去判断哪些内容值得保留。一旦你不推，系统就停。

真正好用的系统，应该是「系统带着你走」：

它告诉你什么需要整理，什么值得晋升，什么需要更新——你只做判断，不做机械操作。

实现这个的关键，是**「晋升机制」**。

什么样的 raw 笔记应该晋升到 wiki？

我设计了一套「晋升判断标准」，让 Codex 每周自动帮我扫描：

Markdown

## 晋升标准（满足任意 2 条即提醒晋升）
□ 这篇笔记被其他至少 3 篇笔记引用过
□ 这篇笔记里的概念，我在过去 2 周内主动想起来过 2 次以上
□ 这篇笔记的内容，我在实际工作中用上过
□ 这篇笔记 status=reviewing 已经超过 2 周
□ 这篇笔记和 3 个以上不同主题的笔记都有关联

Codex 的自动扫描命令：

text

扫描 raw/ 下所有 status=draft 或 status=reviewing 的笔记，
对每篇笔记检查以下晋升标准：
1. 被引用次数（通过反向链接统计）
2. 最后更新日期
3. 关联笔记数量
输出「晋升候选清单」，按晋升优先级排序，附上每篇的晋升理由。

这个机制最重要的效果：

你的 wiki 不再是「你主动整理进去的内容」，而是「系统通过使用频率自然筛选出来的内容」。

用得最多的知识，被提炼成最高质量的知识页。

这才是知识复利真正的运作方式。

📊 Part 5：三层结构的常见问题解答

Q1：raw 和 wiki 的边界在哪？什么时候算「成熟」？

我的判断标准很简单： 如果你能用 1-2 句话清晰解释这个概念，并且有一个真实的使用案例，它就成熟了。

如果你还在反复修改它的核心定义，说明它还是 raw 阶段的草稿。

Q2：如果一篇笔记同时属于多个主题，放 raw 还是 wiki？

放 raw，然后用双向链接连接到多个相关的 wiki 页面。

wiki 是概念的「主页」，raw 是这个概念在某个具体场景下的「应用记录」。两者不互斥，raw 里的应用案例，反过来会丰富 wiki 页面的内容。

Q3：daily/ 的笔记要不要整理进 raw 或 wiki？

不需要每一条都整理。

每周复盘的时候，Codex 会帮你从本周的 daily/ 里提炼值得保留的内容，推荐进入 raw/。大多数 daily 笔记的使命，就是「记录当时的状态」，完成使命后不需要更高级别的处理。

Q4：项目文件夹（projects/）和 wiki/ 有什么区别？

projects/ 是「过程文件」，wiki/ 是「结论文件」。

做一个项目的过程中，素材、草稿、讨论记录放 projects/；项目结束后，提炼出来的通用方法论和经验总结放 wiki/。

projects/ 的内容会随项目结束而「封存」，wiki/ 的内容永远是活的、可以被引用的。

Q5：多久清理一次 archive/？

我一年做一次。年底把这一年里确认不再需要的旧内容移进 archive/，不是删除，是封存。

archive/ 存在的意义不是「你会回去翻」，而是「你不会有删掉有用内容的焦虑」。

🌱 收官：你已经建好了地基

走到这里，系列一的 8 篇内容，覆盖了搭建一套 AI 知识库所需要的所有基础：

地基建好了，接下来是什么？

是让这套系统开始真正「运转」起来。

系列「PKM 工作流实操篇」，我们会把 7 个 Agent Skill 逐个拆解——每一个 Skill，都是让这台机器「多转一个齿轮」的关键零件。

当所有齿轮都咬合，你的知识库就不再需要你每天「推」着它走，它会自己转。

「建好三层结构，是给知识准备好了土壤。接下来，是给土壤通水、通光——让知识自己长。」