别再做“收藏型笔记”了：我用一张流程图把学习变成产出
一只阿木木约 6 分钟别再做“收藏型笔记”了：我用一张流程图把学习变成产出（知识库 v1.0｜1/5）
你好，我是一只阿木木，后端程序员，用工程师思维折腾 Obsidian。
AI 时代，我不想只当更快的 coder，更想系统经营自己的认知资产。
这里我会用「AI + Obsidian + 产品思维」搭建个人知识系统：
• 收集：零散输入 → 结构化知识库 • 加工：学习/决策/复盘 → 可复用的认知模块 • 落地：真实案例 + 具体工作流，方法跑得起来
我会把打造「AI 第二大脑」的全过程拆给你看。
如果你也想让知识真正为自己打工，一起来。
开篇
我以前的学习是这样的：看到一篇好文章，觉得“以后肯定用得上”，顺手收藏；遇到一个坑，觉得“这次总算搞懂了”，写一篇笔记；过两周线上出问题/准备面试/要做方案评审——还是从头搜一遍。
不是因为我记得不够多，而是因为我的笔记没有接到“产出”上。
如果你也有这些症状：
• Obsidian 里笔记一堆，但写方案/写总结时找不到能直接用的内容 • 学了 Redis/并发/SQL，遇到真实问题还是凭感觉乱试 • 收藏夹越来越大，焦虑也越来越大
这篇我只讲一件事：把“学习”变成“可复用产出”，你只需要一条链路。
你不是不会学习，你是在做“收藏型笔记”
收藏型笔记最常见的结局有三种：
1. 只存不加工：收藏、剪藏、抄原文，信息很多，但没有自己的结论 2. 只记不连接：写了，但和项目、技能、问题没有链接，回头等于没写 3. 只整理不交付：花很多时间美化结构/折腾模板，却从不输出任何可交付成果
它们共同的问题：笔记没有“复用接口”。
你不是在做知识库，你是在做一个“私人互联网备份”。
反过来：把笔记当成生产线，而不是仓库
我把知识库从“收藏夹”改成“生产线”后，唯一做的变化是：给学习加了一条固定流程。
你可以把它画成一张图（建议你真的画出来，贴在知识库 Home 页）：
text
输入 Capture → 提炼 Distill → 连接 Link → 交付 Deliver → 复盘 Review这不是鸡汤，是工程化：每一步都只做最小动作，让系统能跑起来。
下面我逐步拆开讲。
Step 1｜Capture：先收集，别急着整理
最小动作：
• 看到好内容、踩到坑、想到点子，先扔进一个地方（比如 Inbox）• 不分类、不加标签、不美化
规则只有一条：收集要无摩擦。
你越是要求“当场整理”，越容易拖延，最后变成“我晚点再记”，然后就没有然后了。
Step 2｜Distill：补一句话结论 + 一点证据
收藏型笔记和可复用笔记的分水岭只有一个：
你有没有写出“一句话结论”。
最小动作（两行就够）：
• 一句话结论：我学到的核心是什么 • 证据/例子：支持这个结论的关键点（原文片段、数据、代码片段、对比例子）
举例（你不需要写得很长）：
一句话结论：慢 SQL 优化不要先加索引，先用
EXPLAIN确认是否走索引以及为什么没走。
证据：某次WHERE a = ? AND b > ? ORDER BY c，缺联合索引导致 filesort + 扫描行数巨大。
写不出来？那说明你还没真正“消化”。这不是坏事，它会反向逼你把问题弄清楚。
Step 3｜Link：把它挂回“入口”，否则迟早找不到
你需要给每条笔记一个“回家的地方”。
对程序员来说，入口通常只有两类：
• 技能入口：比如 “SQL 性能优化”“Java 并发”“Redis” • 项目入口：比如 “订单服务”“支付链路”“XX 重构”
最小动作：
• 给这条笔记加一个链接：指向某个技能页（MOC）或某个项目页
这一步的意义是：你不是在堆卡片，而是在建立一张“可走的路径”。
（下一篇我会讲最小结构怎么搭，先别急着把 Obsidian 搞复杂。）
Step 4｜Deliver：每周至少交付 1 个“可复用产出”
很多人知识库烂尾，不是因为不会记，而是因为没有交付。
我建议你把产出限定在程序员最实用的 4 类（越具体越容易坚持）：
1. 问题卡：某类问题的排查路径（排障/面试都能用） 2. 方案卡：方案对比与决策记录（评审/复盘能用） 3. 技能地图：一项技能的学习路径（系统学习能用） 4. 复盘卡：事故/踩坑的机制 + 改进清单（避免重犯）
最小动作：
• 每周只要求自己交付 1 个（一张卡也算） • 不求长，求能被复用
Step 5｜Review：复用率才是知识库的 KPI
知识库的终局不是“越来越多”，而是“越来越能复用”。
所以复盘只看两件事：
• 本周新增了哪些“可复用卡”？ • 本周这些卡被我用过几次？（写方案/排障/面试表达/写文章）
你会发现：当你开始统计“复用次数”，你会本能地减少无效收藏，转向更有价值的沉淀。
用一个真实例子：从收藏到产出，只差这 5 步
假设你今天读到一篇《慢 SQL 排查与优化》，你以前可能会：收藏 + 摘抄 + 结束。
现在按流程走一遍（最小版本）：
1）Capture
• 丢进 Inbox： 2025-xx-xx 慢SQL排查文章剪藏
2）Distill（两行）
• 一句话结论：慢 SQL 优化优先“定位瓶颈路径”，不是先猜索引。 • 证据： EXPLAIN里rows很大且Using filesort，说明排序/索引匹配有问题。
3）Link（回家）
• 链接到 [[SQL 性能优化 - MOC]]（技能入口）• 如果这次来自某个线上问题，再链接到 [[P-订单服务]]（项目入口）
4）Deliver（交付一张“问题卡”）
你交付这个就够了——它未来能反复用在排障/面试/分享：
Markdown
# 如何定位慢 SQL：一套排查路径（问题卡）## 一句话结论
先确认“慢在哪里”（扫描行数/排序/回表/锁等待），再决定“改 SQL、加索引还是改模型”。
## 排查清单（Checklist）
- [ ] 是否命中慢查询日志？（阈值与采样）
- [ ] EXPLAIN：是否走索引？type/rows/extra？
- [ ] 是否 filesort / temporary？
- [ ] 是否回表？是否能覆盖索引？
- [ ] 是否锁等待/事务过长？
- [ ] 是否参数/数据分布导致索引失效？
## 常见原因 → 对应动作
- 联合索引顺序不匹配 → 调整索引或改 SQL 条件顺序
- 排序 + 分页深翻页 → 延迟关联/记录游标
- 回表成本高 → 覆盖索引或减少返回列
## 适用边界
- 适用于 OLTP 常规表；大宽表/冷热分离需要额外策略
## 关联
- 技能：[[SQL 性能优化 - MOC]]
- 项目：[[P-订单服务]]（如适用）
5）Review（记录一次复用）
下次你排查慢 SQL，或者面试被问“慢查询怎么定位”，你直接打开这张卡，就不需要重新搜索一遍。
你可以直接复制的“学习产出协议”（建议贴在 Home 页）
把这段复制到你的 Obsidian 首页，强制自己“学就要交付”：
text
学习产出协议（v1.0）
我在学：________（技能/主题）
我要交付：问题卡 / 方案卡 / 复盘卡 / 技能地图（选1-2个）
本周最小交付：________（只要1个）
衡量指标：新增可复用卡 X 张；复用次数 Y 次本篇可执行清单（照做就行）
• [ ] 建一个 Inbox（无摩擦收集）• [ ] 任何笔记必须补：一句话结论 + 一条证据 • [ ] 每条笔记至少链接到：一个技能入口 或 一个项目入口 • [ ] 每周交付 1 张卡：问题卡/方案卡/复盘卡/技能地图 • [ ] 每周记录一次：本周复用次数（哪怕是 1 次）
下一篇（2/5）我会把流程落到 Obsidian：3个文件夹 + 2个索引页
流程有了，接下来就是让它“跑得起来”。下一篇我会给出我认为最不容易烂尾的最小结构：
3 个文件夹 + 2 个索引页，足够你从 0 用到进阶。
如果你想直接拿到：
• 学习产出协议（可打印版） • 问题卡/方案卡/复盘卡的最小模板合集
评论或私信关键词：v1.0。