用产品思维设计个人知识库：我的架构图分享
一
一只阿木木约 8 分钟
一只阿木木约 8 分钟用产品思维设计个人知识库：我的架构图分享
你好，我是一只阿木木，一名后端程序员。
先说个反常识的观点
大多数人的知识库，根本不是「库」，是「垃圾堆」。
别急着反驳，看看是不是你：
• 想记点东西，新建一篇笔记，往里面写 • 下次又想记，再新建一篇，继续写 • 一年后，几百条笔记躺在那里 • 互不关联，找不到，用不上
这不是知识库，这是信息坟场。
我之前也这样。
三年前我开始用 Obsidian，用得可勤快了，一年写了 600 多条笔记。
结果呢？
有一次项目上要用到「分布式事务」的方案，我明明记得自己学过、记过。
翻了半小时，没找到。
最后还是重新搜了一遍、重新学了一遍、重新记了一遍。
那一刻我悟了：
没有系统的知识积累，不叫积累，叫重复劳动。
后来我换了一个思路：
不把知识库当笔记本，把它当产品来设计。
用产品思维画架构、定流程、分模块。
今天把我的设计思路和完整架构图分享给你。
一、为什么要用「产品思维」？
1.1 普通人 vs 产品经理的知识库
看一个对比：
text
┌────────────────────────────────────────────────────────────┐
│ 普通人的知识库 vs 产品经理的知识库 │
├────────────────────────────────────────────────────────────┤
│ │
│ 普通人 产品经理 │
│ ────── ────────── │
│ │
│ 想到哪写到哪 先想清楚「这东西干嘛用」 │
│ 写完就不管了 设计「用户旅程」 │
│ 堆了一堆笔记 有清晰的「信息架构」 │
│ 找不到、用不上 10 秒找到任何东西 │
│ │
│ 本质区别： │
│ ───────── │
│ 普通人：随手记 → 随便存 → 再也不看 │
│ 产品经理：设计 → 收集 → 加工 → 存储 → 检索 → 输出 │
│ │
└────────────────────────────────────────────────────────────┘1.2 产品思维的三个核心问题
设计任何产品，都要先回答三个问题：
text
Q1：这个产品是给谁用的？
Q2：用户用它来解决什么问题？
Q3：用户的核心使用场景是什么？套到知识库上：
text
Q1：给谁用？
→ 给未来的自己用Q2：解决什么问题？
→ 快速找到需要的知识，辅助思考和输出
Q3：核心使用场景？
→ 写文章时、做方案时、学新东西时、回顾复习时
想清楚这三个问题，再动手搭建，事半功倍。
二、我的知识库架构设计
2.1 全景架构图
先看全貌：
text
┌──────────────────────────────────────────────────────────────────┐
│ │
│ 🧠 我的第二大脑 │
│ ──────────────── │
│ │
│ ┌─────────────────────────────────────────────────────────────┐ │
│ │ 入口层 │ │
│ │ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ │
│ │ │ 微信文章 │ │ 网页内容 │ │ 播客/视频 │ │ 灵感碎片 │ │ │
│ │ └────┬─────┘ └────┬─────┘ └────┬─────┘ └────┬─────┘ │ │
│ │ │ │ │ │ │ │
│ │ └────────────┴─────┬──────┴────────────┘ │ │
│ │ ▼ │ │
│ │ ┌──────────┐ │ │
│ │ │ Inbox │ ← 统一入口 │ │
│ │ └────┬─────┘ │ │
│ └─────────────────────────┼───────────────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌─────────────────────────────────────────────────────────────┐ │
│ │ 加工层 │ │
│ │ │ │
│ │ ┌──────────────────────────────────┐ │ │
│ │ │ 处理流程 │ │ │
│ │ │ ┌─────┐ ┌─────┐ ┌─────┐ │ │ │
│ │ │ │判断 │→ │拆解 │→ │连接 │ │ │ │
│ │ │ │价值 │ │原子 │ │网络 │ │ │ │
│ │ │ └─────┘ └─────┘ └─────┘ │ │ │
│ │ └──────────────────────────────────┘ │ │
│ │ │ │ │
│ └──────────────────────────┼──────────────────────────────────┘ │
│ ▼ │
│ ┌─────────────────────────────────────────────────────────────┐ │
│ │ 存储层 │ │
│ │ │ │
│ │ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ │
│ │ │ 卡片库 │ │ MOC │ │ 项目库 │ │ │
│ │ │ (原子化) │ │ (索引层) │ │ (在进行) │ │ │
│ │ └──────────┘ └──────────┘ └──────────┘ │ │
│ │ │ │
│ │ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ │
│ │ │ 日志库 │ │ 复盘库 │ │ 归档库 │ │ │
│ │ │ (每日) │ │ (周/月) │ │ (已完成) │ │ │
│ │ └──────────┘ └──────────┘ └──────────┘ │ │
│ │ │ │
│ └─────────────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌─────────────────────────────────────────────────────────────┐ │
│ │ 输出层 │ │
│ │ │ │
│ │ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ │
│ │ │ 写文章 │ │ 做方案 │ │ 讲分享 │ │ │
│ │ └──────────┘ └──────────┘ └──────────┘ │ │
│ │ │ │
│ └─────────────────────────────────────────────────────────────┘ │
│ │
└──────────────────────────────────────────────────────────────────┘2.2 四层架构解读
| 入口层 | ||
| 加工层 | ||
| 存储层 | ||
| 输出层 |
核心理念：知识库是一个加工厂，不是仓库。
text
信息 → 入口 → 加工 → 存储 → 输出
│ │
│ │
└─────── 流动 ────────┘知识不流动，就会死掉。
三、每一层的详细设计
3.1 入口层：零摩擦收集
设计原则：收集的动作要快到无法拒绝。
text
┌────────────────────────────────────────────────────────────┐
│ 入口层设计 │
├────────────────────────────────────────────────────────────┤
│ │
│ 核心原则：所有信息，统一进 Inbox │
│ ───────────────────────────── │
│ │
│ 我的收集入口： │
│ │
│ ┌──────────────┬───────────────┬────────────────────┐ │
│ │ 来源 │ 工具 │ 去向 │ │
│ ├──────────────┼───────────────┼────────────────────┤ │
│ │ 微信文章 │ 简悦 │ → Inbox │ │
│ │ 网页内容 │ Obsidian Web │ → Inbox │ │
│ │ 手机灵感 │ 快捷指令 │ → Inbox │ │
│ │ 电脑灵感 │ Cmd+N │ → Inbox │ │
│ │ 语音备忘 │ 讯飞 → 文字 │ → Inbox │ │
│ │ 阅读笔记 │ Readwise │ → Inbox │ │
│ └──────────────┴───────────────┴────────────────────┘ │
│ │
│ ⚠️ 关键点： │
│ 1. 入口必须唯一（只有一个 Inbox） │
│ 2. 操作必须快（3 秒内完成） │
│ 3. 不在收集时思考（先收再说） │
│ │
└────────────────────────────────────────────────────────────┘我的 Inbox 规则：
Markdown
## Inbox 的纪律✅ 允许：
- 任何想记的东西
- 任何感兴趣的链接
- 任何灵感碎片
❌ 不允许：
- 在 Inbox 待超过 7 天
- 直接在 Inbox 里整理
- Inbox 条目超过 20 条
每日必做：
- 清空 Inbox（移走或删除）
3.2 加工层：把信息变成知识
设计原则：信息不加工，永远是信息。
text
┌────────────────────────────────────────────────────────────┐
│ 加工层设计 │
├────────────────────────────────────────────────────────────┤
│ │
│ 加工流程（每天 15 分钟）： │
│ │
│ ┌──────────────────────────────────────┐ │
│ │ 拿出一条 Inbox │ │
│ └──────────────┬───────────────────────┘ │
│ ▼ │
│ ┌─────────────────┐ │
│ │ 问：这有用吗？ │ │
│ └────────┬────────┘ │
│ │ │
│ ┌─────────────┼─────────────┐ │
│ ▼ ▼ ▼ │
│ 没用 有点用 很有用 │
│ │ │ │ │
│ ▼ ▼ ▼ │
│ 删除 存原文 深度加工 │
│ 打标签 拆成卡片 │
│ 建立连接 │
│ │
│ ───────────────────────────────────────────────────── │
│ │
│ 深度加工三步： │
│ │
│ Step 1：拆原子 │
│ ───────────── │
│ 把一篇内容拆成多个独立知识点 │
│ 每个知识点 = 一张卡片 │
│ │
│ Step 2：用自己的话写「一句话总结」 │
│ ────────────────────────────────── │
│ 不是复制粘贴，是翻译成自己能懂的话 │
│ │
│ Step 3：建立连接 │
│ ───────────── │
│ 这张卡片和哪些已有卡片相关？ │
│ 用双向链接 [[]] 连起来 │
│ │
└────────────────────────────────────────────────────────────┘加工的核心动作：
| 判断 | ||
| 拆解 | ||
| 翻译 | ||
| 连接 |
3.3 存储层：结构化存放
设计原则：文件夹管位置，标签管检索，MOC 管导航。
text
┌────────────────────────────────────────────────────────────┐
│ 存储层设计 │
├────────────────────────────────────────────────────────────┤
│ │
│ 三套系统，各有分工： │
│ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 1. 文件夹系统（管「在哪」） │ │
│ │ ───────────────────────── │ │
│ │ │ │
│ │ 📁 00-Inbox # 收集箱 │ │
│ │ 📁 01-Projects # 进行中的项目 │ │
│ │ 📁 02-Areas # 持续关注的领域 │ │
│ │ 📁 03-Resources # 资源/卡片库 │ │
│ │ 📁 04-Archives # 归档 │ │
│ │ 📁 05-Daily # 日志 │ │
│ │ 📁 06-Templates # 模板 │ │
│ │ │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 2. 标签系统（管「怎么找」） │ │
│ │ ───────────────────────── │ │
│ │ │ │
│ │ topic/后端 topic/redis topic/架构 ← 什么领域 │ │
│ │ type/方案 type/原理 type/代码 ← 什么类型 │ │
│ │ scene/面试 scene/写作 scene/方案 ← 什么场景用 │ │
│ │ │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 3. MOC 系统（管「导航」） │ │
│ │ ───────────────────── │ │
│ │ │ │
│ │ MOC = Map of Content = 内容地图 │ │
│ │ │ │
│ │ 作用：某个主题的「目录页」 │ │
│ │ │ │
│ │ 示例：[[Redis 知识地图]] │ │
│ │ ├── 基础概念 │ │
│ │ │ ├── [[Redis 数据类型]] │ │
│ │ │ └── [[Redis 持久化]] │ │
│ │ ├── 缓存问题 │ │
│ │ │ ├── [[缓存穿透]] │ │
│ │ │ ├── [[缓存击穿]] │ │
│ │ │ └── [[缓存雪崩]] │ │
│ │ └── 实战应用 │ │
│ │ ├── [[Redis 分布式锁]] │ │
│ │ └── [[Redis 消息队列]] │ │
│ │ │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
└────────────────────────────────────────────────────────────┘三套系统的配合：
我的经验：三套都用，各司其职。
3.4 输出层：把知识变成成果
设计原则：知识不输出，价值为零。
text
┌────────────────────────────────────────────────────────────┐
│ 输出层设计 │
├────────────────────────────────────────────────────────────┤
│ │
│ 输出类型： │
│ │
│ ┌──────────────┬───────────────────────────────────┐ │
│ │ 类型 │ 说明 │ │
│ ├──────────────┼───────────────────────────────────┤ │
│ │ 写文章 │ 公众号、技术博客、内部文档 │ │
│ │ 做方案 │ 技术方案、架构设计 │ │
│ │ 讲分享 │ 团队分享、技术演讲 │ │
│ │ 做产品 │ 课程、咨询服务 │ │
│ └──────────────┴───────────────────────────────────┘ │
│ │
│ 输出工作流： │
│ │
│ ┌──────────────────────────────────────┐ │
│ │ 1. 从 MOC 选一个主题 │ │
│ └─────────────┬────────────────────────┘ │
│ ▼ │
│ ┌──────────────────────────────────────┐ │
│ │ 2. 把相关卡片拉到一个草稿文件 │ │
│ └─────────────┬────────────────────────┘ │
│ ▼ │
│ ┌──────────────────────────────────────┐ │
│ │ 3. 用 AI 辅助串联成初稿 │ │
│ └─────────────┬────────────────────────┘ │
│ ▼ │
│ ┌──────────────────────────────────────┐ │
│ │ 4. 人工修改、补充、润色 │ │
│ └─────────────┬────────────────────────┘ │
│ ▼ │
│ ┌──────────────────────────────────────┐ │
│ │ 5. 发布，并把新知识点反哺回知识库 │ │
│ └──────────────────────────────────────┘ │
│ │
│ 关键：输出本身也会产生新知识，要回流到知识库 │
│ │
└────────────────────────────────────────────────────────────┘输出驱动学习：
text
传统路径：学 → 学 → 学 → 学 → 忘光了正确路径：学一点 → 输出 → 发现不懂 → 再学 → 再输出
公式：
输出倒逼输入，输入服务输出
四、知识卡片设计
知识卡片是整个系统的「最小单元」。
4.1 卡片模板
Markdown
---
title: [卡片标题]
created: [创建日期]
tags:
- topic/[领域]
- type/[类型]
- scene/[场景]
source: [来源]
---## 一句话总结
> [用自己的话，一句话说清楚]
## 详细内容
[核心内容，3-5 句话]
## 关键要点
- 要点 1
- 要点 2
- 要点 3
## 我的思考
[自己的理解、疑问、联想]
## 使用场景
- 场景 1：什么时候会用到
- 场景 2：
## 关联卡片
- [[相关卡片 1]]
- [[相关卡片 2]]
4.2 卡片示例
Markdown
---
title: 布隆过滤器
created: 2024-01-15
tags:
- topic/数据结构
- topic/redis
- type/原理
- scene/方案设计
- scene/面试
source: Redis 官方文档
---## 一句话总结
> 用位数组 + 多个哈希，快速判断元素「一定不存在」或「可能存在」。
## 详细内容
布隆过滤器是一种概率型数据结构。
添加元素时，用 k 个哈希函数算出 k 个位置，全部置为 1。
查询时，k 个位置都是 1 = 可能存在；有一个 0 = 肯定不存在。
## 关键要点
- 优点：空间效率极高，查询 O(k)
- 缺点：有假阳性，不能删除
- 典型场景：缓存穿透防护、海量数据去重
## 我的思考
本质是用少量误判换取极高的空间和时间效率。
「肯定不存在」这一点很好用。
## 使用场景
- 场景 1：设计缓存方案，防止缓存穿透
- 场景 2：面试被问数据结构
## 关联卡片
- [[缓存穿透]]
- [[位图算法]]
- [[概率型数据结构]]
五、完整文件夹结构
text
📁 我的知识库
│
├── 📁 00-Inbox # 收集箱
│ └── (待处理的所有内容)
│
├── 📁 01-Projects # 进行中的项目
│ ├── 📁 PRJ-商城重构
│ ├── 📁 PRJ-公众号运营
│ └── 📁 PRJ-新课程开发
│
├── 📁 02-Areas # 持续关注的领域
│ ├── 📁 后端技术
│ ├── 📁 知识管理
│ ├── 📁 一人公司
│ └── 📁 AI 应用
│
├── 📁 03-Resources # 资源/卡片库
│ ├── 📁 技术卡片
│ ├── 📁 思维模型
│ ├── 📁 素材库
│ └── 📁 工具配置
│
├── 📁 04-Archives # 归档
│ ├── 📁 2023
│ └── 📁 已完成项目
│
├── 📁 05-Daily # 日志
│ ├── 📁 2024
│ │ ├── 📁 01-Jan
│ │ └── 📁 02-Feb
│ └── (日记、周记、月记)
│
├── 📁 06-Templates # 模板
│ ├── tpl-daily.md # 日记模板
│ ├── tpl-card.md # 卡片模板
│ ├── tpl-project.md # 项目模板
│ └── tpl-weekly.md # 周报模板
│
└── 📁 07-MOC # 内容地图
├── MOC-Redis.md
├── MOC-分布式.md
├── MOC-知识管理.md
└── MOC-一人公司.md六、我的日常使用流程
6.1 每日流程
text
┌────────────────────────────────────────────────────────────┐
│ 每日流程 │
├────────────────────────────────────────────────────────────┤
│ │
│ ☀️ 早上（15 分钟） │
│ ───────────────── │
│ 1. 打开 Daily Note，写今日 TOP 3 任务 │
│ 2. 扫一眼 Inbox，超过 7 天的删掉或强制处理 │
│ │
│ 🌤️ 白天（随时） │
│ ───────────── │
│ 1. 遇到有用信息 → 丢进 Inbox │
│ 2. 产生灵感 → 丢进 Inbox │
│ 3. 完成一个任务 → 记录在 Daily Note │
│ │
│ 🌙 晚上（15 分钟） │
│ ───────────────── │
│ 1. 处理 Inbox：判断、拆解、连接 │
│ 2. 目标：Inbox 条目 ≤ 10 │
│ 3. 在 Daily Note 写今日收获 │
│ │
└────────────────────────────────────────────────────────────┘6.2 每周流程
text
┌────────────────────────────────────────────────────────────┐
│ 每周流程 │
├────────────────────────────────────────────────────────────┤
│ │
│ 周日晚上（30 分钟） │
│ ───────────────── │
│ │
│ 1. 清空 Inbox（强制清零） │
│ │
│ 2. 更新 MOC │
│ - 本周新增的卡片，有没有要加到某个 MOC？ │
│ - 有没有新的主题，需要新建 MOC？ │
│ │
│ 3. 写周复盘 │
│ - 本周学到什么？ │
│ - 输出了什么？ │
│ - 下周重点是什么？ │
│ │
│ 4. 检查项目进度 │
│ - Projects 里的项目，进展如何？ │
│ - 有没有要归档的？ │
│ │
└────────────────────────────────────────────────────────────┘七、避坑指南
7.1 三个常见的坑
text
┌────────────────────────────────────────────────────────────┐
│ 避坑指南 │
├────────────────────────────────────────────────────────────┤
│ │
│ 坑 1：追求完美系统 │
│ ───────────────── │
│ 症状：花三个月设计系统，一条笔记没写 │
│ 解法：先跑起来，用起来，再迭代 │
│ 口诀：Done is better than perfect │
│ │
│ 坑 2：只收集不加工 │
│ ───────────────── │
│ 症状：Inbox 几百条，从来不处理 │
│ 解法：设置 Inbox 上限（比如 20 条） │
│ 口诀：不加工的信息是负债 │
│ │
│ 坑 3：只输入不输出 │
│ ───────────────── │
│ 症状：知识库很大，但没有产出任何内容 │
│ 解法：每周至少一次输出（哪怕是内部分享） │
│ 口诀：输出倒逼输入 │
│ │
└────────────────────────────────────────────────────────────┘7.2 我踩过的坑
坑 1：文件夹层级太深
以前我的文件夹有 5 层深，找个文件要点半天。
现在最多 3 层，宁可用标签也不加层级。
坑 2：标签太随意
以前随便打标签，一年后有 200 多个标签，一半只用过一次。
现在有标签体系，总共 50 个标签，够用。
坑 3：MOC 不更新
以前只管记笔记，MOC 半年不更新，失去了导航作用。
现在每周更新一次 MOC，确保它是活的。
八、核心要点
text
┌────────────────────────────────────────────────────────────┐
│ 今天记住这几点 │
├────────────────────────────────────────────────────────────┤
│ │
│ 1. 知识库是产品，不是垃圾堆 │
│ → 用产品思维设计：入口、加工、存储、输出 │
│ │
│ 2. 四层架构 │
│ → 入口层：统一收集 │
│ → 加工层：判断、拆解、连接 │
│ → 存储层：文件夹 + 标签 + MOC │
│ → 输出层：写文章、做方案、讲分享 │
│ │
│ 3. 知识要流动 │
│ → 收集 → 加工 → 存储 → 输出 → 再收集 │
│ → 不流动的知识是死的 │
│ │
│ 4. 先跑起来，再迭代 │
│ → 不要追求完美系统 │
│ → 用的过程中自然会优化 │
│ │
└────────────────────────────────────────────────────────────┘一句话总结：
把知识库当产品来设计，入口要统一，加工要到位，存储要结构化，输出要持续。
最后
我是一只阿木木，后端程序员。
10 年写代码，3 年做一人公司。
这套知识库架构，是我重构了三次后的版本。真正在用，真正有效。
如果这篇对你有帮助：
• 收藏：搭建自己知识库时对着用 • 转发：分享给那个笔记混乱的朋友 • 评论：说说你的知识库长什么样
互动话题
你的知识库现在是什么状态？
A. 没有知识库，到处乱记
B. 有，但是一团乱
C. 有，而且还挺顺手
评论区选一个，看看大家的情况 👇