我只用4种模板：把任何学习都沉淀成可复用产出

我只用4种模板：把任何学习都沉淀成可复用产出（知识库 v1.0｜4/5）

你好，我是一只阿木木，后端程序员，用工程师思维折腾 Obsidian。

AI 时代，我不想只当更快的 coder，更想系统经营自己的认知资产。

这里我会用「AI + Obsidian + 产品思维」搭建个人知识系统：

• • 收集：零散输入 → 结构化知识库
• • 加工：学习/决策/复盘 → 可复用的认知模块
• • 落地：真实案例 + 具体工作流，方法跑得起来

我会把打造「AI 第二大脑」的全过程拆给你看。
如果你也想让知识真正为自己打工，一起来。

开篇

你可能也写过这种笔记：

• • “今天看了线程池/Redis/慢 SQL，感觉懂了。”
• • 复制几段原文，贴几张图。
• • 过两周线上故障、做方案评审、准备面试——打开笔记：没有结论、没有路径、没有边界。

这类笔记我把它叫做“流水账”。它最大的问题不是难看，而是无法复用：你在需要的时候，没法把它直接拿来解决问题或支撑表达。

我后来做了一个极简但有效的改动：不追求记全，只追求可复用交付。方法就是——我只写 4 种卡片模板。

你学任何东西（概念、排障、方案、复盘）都能落到这 4 种卡里，并且每一张都能直接用在：
线上排障 / 方案评审 / 面试表达 / 写作输出。

先立 3 条硬规则：模板才会真的帮你

模板不是为了“统一格式”，而是为了把你从“随手记”推进到“可复用”。

我的 v1.0 三条硬规则：

1. 1. 每张卡必须有「一句话结论」
    没结论的笔记，未来只会让你二次学习。
2. 2. 每张卡必须挂回一个入口（技能 MOC 或项目页）
    没链接的笔记，迟早找不到。
3. 3. 字段越少越好，5 分钟能写完
    写不完就缩小范围：先写“最小可用版本”，后续迭代。

模板 1：问题卡 Problem Card（排障/面试最强复用）

你遇到一次线上问题，如果没沉淀成“问题卡”，下次大概率还会从头开始。

把排障写成卡片的目标是：把经验变成路径。

可复制模板

Markdown

# （问题卡）{{问题标题：症状 → 目标}}
## 一句话结论
{{先做什么，再做什么；判断依据是什么}}
## 触发场景
- 现象：{{超时/CPU飙高/慢SQL/错误率上升...}}
- 影响：{{哪些接口/用户/范围}}
- 环境：{{JVM/容器/版本/依赖}}
## 排查路径（Checklist）
- [ ] 先确认范围：是全局还是单机？是持续还是偶发？
- [ ] 先确认瓶颈类型：CPU / 内存 / IO / 网络 / 锁 / 下游
- [ ] 再定位到组件：线程池/GC/数据库/缓存/消息队列
- [ ] 最后定位到代码路径：堆栈/火焰图/日志trace
## 常见原因 → 对应动作
- 原因A：{{...}} → 动作：{{...}}
- 原因B：{{...}} → 动作：{{...}}
## 适用边界（非常重要）
- 适用于：{{哪些系统/条件}}
- 不适用于：{{哪些情况会误判}}
## 关联入口
- 技能：[[{{某技能-MOC}}]]
- 项目：[[{{P-项目-首页}}]]

示例（你可以直接替换成自己的真实案例）

Markdown

# （问题卡）接口超时：如何判断是线程池耗尽还是下游变慢
## 一句话结论
先看线程池队列/活跃线程/拒绝次数与 RT 同步变化；若线程池指标先爆，再看下游；若下游 RT 先升，再回头看线程池是否被拖死。
## 触发场景
- 现象：接口 RT 从 50ms 升到 2s，错误率上升
- 影响：下单接口
- 环境：Spring Boot + Tomcat + 自定义业务线程池
## 排查路径（Checklist）
- [ ] 是否只有少数实例超时？（可能是单机热点/GC）
- [ ] 线程池 active/queue/reject 是否异常？（耗尽信号）
- [ ] 下游依赖 RT 是否先升高？（依赖拖慢）
- [ ] 是否发生线程阻塞：锁等待/IO等待/连接池耗尽
- [ ] 结合 trace 定位最慢的 span
## 常见原因 → 对应动作
- 下游变慢 → 增加超时保护/隔离/降级，做依赖压测与容量评估
- 线程池参数不合理 → 调整 core/max/queue，补拒绝策略与监控
- 连接池耗尽 → 检查连接泄漏与超时配置，限制并发
## 适用边界
- 适用于：典型同步调用链
- 不适用于：异步链路/事件驱动需换一套指标判断
## 关联入口
- 技能：[[可观测性-监控日志链路-MOC]]
- 项目：[[P-订单服务-首页]]

模板 2：概念卡 Concept Card（把“懂了”变成“能讲清”）

概念卡不是抄定义，而是让你未来能做到三件事：
解释清楚、识别误区、写出最小示例。

可复制模板

Markdown

# （概念卡）{{概念名}}
## 一句话结论
{{用你自己的话解释它是什么}}
## 我自己的解释（禁止抄定义）
- {{用类比/场景把它讲清楚}}
## 何时用 / 何时不用
- 用：{{场景}}
- 不用：{{反例}}
## 常见误区
- 误区1：{{...}} → 正解：{{...}}
- 误区2：{{...}} → 正解：{{...}}
## 最小示例
```txt
{{代码/SQL/伪码/流程}}

关联入口

• • 技能：[[{{某技能-MOC}}]]

text

### 示例（概念卡：缓存一致性）
```markdown
# （概念卡）缓存一致性：先保证“可接受的不一致”，再谈“强一致”
## 一句话结论
缓存一致性不是追求绝对同步，而是明确业务能接受的不一致窗口，然后用失效/更新策略把风险控制在窗口内。
## 我自己的解释（禁止抄定义）
缓存是“用空间换时间”。一致性问题本质是：数据有两份（DB/Cache），它们更新顺序与失败路径会产生分叉。
## 何时用 / 何时不用
- 用：读多写少、容忍短暂不一致的业务
- 不用：强一致要求极高且写多的核心账务（需要更强的架构手段）
## 常见误区
- 误区1：先更新缓存再更新数据库更快 → 正解：失败会导致脏数据更难清理
- 误区2：删缓存就一定安全 → 正解：并发下仍可能出现回写旧值，需要配合版本/锁/延迟双删等策略
## 最小示例
```txt
推荐思路（最常见）：
写：更新DB → 删除Cache（必要时延迟双删）
读：Cache miss → 查DB → 回填Cache（注意热点与穿透）

关联入口

• • 技能：[[Redis-缓存与一致性-MOC]]

text

---
## 模板 3：方案卡 Decision Card（把“拍脑袋”变成可追溯决策）
程序员的成长很大一部分来自“决策质量”。  
但多数人方案评审之后，只剩一句：“当时就这么定了。”
方案卡的目标是：未来你能复盘“为什么这么选”，并且把 trade-off 复用到下一次。
### 可复制模板
```markdown
# （方案卡）{{主题：在什么约束下解决什么问题}}
## 一句话结论
{{最终选择了方案X，因为约束A/B下它的收益最大，风险可控}}
## 背景与约束
- 业务目标：{{...}}
- 约束：成本/工期/稳定性/一致性/可观测性/团队能力
## 方案对比（至少2个）
### 方案A
- 优点：
- 缺点：
- 风险：
- 适用条件：
### 方案B
- 优点：
- 缺点：
- 风险：
- 适用条件：
## 决策
- 选择：{{A/B}}
- 关键理由（Trade-off）：{{3条以内}}
## 落地计划
- 灰度/回滚：
- 监控指标：
- 验收标准：
## 关联入口
- 技能：[[{{某技能-MOC}}]]
- 项目：[[{{P-项目-首页}}]]

示例（方案卡：缓存改造）

Markdown

# （方案卡）订单查询缓存：在高峰期降低 DB 压力（可回滚）
## 一句话结论
选择 Redis + 失效策略 + 热点保护，因为对读性能收益最大且可灰度回滚；一致性用“可接受不一致窗口”控制风险。
## 背景与约束
- 目标：高峰期查询 RT < 100ms，DB CPU 降到 60% 以下
- 约束：两周内上线；必须可灰度；可观测性要补齐
## 方案对比
### 方案A：本地缓存
- 优点：极低延迟，开发简单
- 缺点：实例多时一致性差；重启抖动
- 风险：热点导致单机抖动
- 适用：少实例/弱一致要求
### 方案B：Redis 缓存
- 优点：跨实例共享；可控容量与淘汰
- 缺点：引入外部依赖；一致性需要设计
- 风险：穿透/击穿/雪崩
- 适用：读多写少，允许短暂不一致
## 决策
- 选择：Redis
- 关键理由：
  1) 跨实例共享，收益覆盖全链路
  2) 可灰度与快速回滚
  3) 风险可用热点保护与监控控制
## 落地计划
- 灰度/回滚：按用户维度灰度；开关控制缓存读写；异常即切回直读DB
- 监控指标：cache hit ratio、下游 RT、错误率、Redis QPS、热点 key
- 验收标准：高峰 DB CPU < 60%，接口 RT < 100ms
## 关联入口
- 技能：[[Redis-缓存与一致性-MOC]]
- 项目：[[P-订单服务-首页]]

模板 4：复盘卡 Retrospective Card（把事故变成“规则与清单”）

复盘的价值不在“写得很长”，而在你能不能沉淀出：
下次不再靠运气。

我用的最小复盘结构是 3 问法：事实、机制、改进。够硬、够短、够能复用。

可复制模板

Markdown

# （复盘卡）{{事件标题}}
## 一句话结论
{{根因是什么；最关键的改进是什么}}
## 事实（发生了什么）
- 时间线（3-5条）：
- 影响范围：
- 发现方式：
## 机制（为什么会这样）
- 根因：
- 诱因/放大器：
- 为什么没提前发现（监控/告警/流程）：
## 改进（下次怎么做）
### 规则/清单（可复用）
- [ ] {{规则1}}
- [ ] {{规则2}}
### 行动项（带负责人/截止时间更好）
- [ ] {{行动项1}}
- [ ] {{行动项2}}
## 关联入口
- 技能：[[{{某技能-MOC}}]]
- 项目：[[{{P-项目-首页}}]]

这 4 种模板如何对齐上一篇的 MOC（让知识库“自动长结构”）

你现在应该能把它们串起来了：

• • 写完一张 问题卡/概念卡/方案卡/复盘卡
• • 顺手挂回：
• • 一个 技能 MOC（例如 [[SQL-性能优化-MOC]]）
• • 或一个 项目首页（例如 [[P-订单服务-首页]]）

只要你坚持“新增卡必回挂”，你的知识库就会从碎片长成体系，而不是靠整理欲硬堆结构。

AI 怎么用才不跑偏（只做“加工”，不做“替你思考”）

如果你想引入 AI（可选），我建议把它定位为：把你已有材料加工成卡片初稿，而不是让它凭空编。

你可以用这条通用提示词（复制即可）：

text

你是我的“知识卡片编辑器”。请仅基于我提供的材料生成一张卡片初稿，不要编造不存在的事实。
输出要求：
1）先给“一句话结论”
2）再按我指定的模板字段填充
3）如果信息不足，用【缺信息：…】标注需要我补充的点
模板类型：问题卡/概念卡/方案卡/复盘卡（我会指定）
材料如下：
---
（粘贴你的日志、原文摘录、讨论结论、数据）
---

这样做的好处是：AI 帮你省“格式化与改写”的时间，但结论与边界仍由你负责。

本篇交付：10 分钟把模板装进 Obsidian（可复制步骤）

• • [ ]  新建文件夹：99-Templates/
• • [ ]  新建 4 个模板文件：T-问题卡.md、T-概念卡.md、T-方案卡.md、T-复盘卡.md，把上面的模板粘进去
• • [ ]  从今天起，任何学习/排障/方案/事故，强制落到这 4 种卡之一
• • [ ]  每写完一张卡，做 1 个动作：挂回 技能MOC 或 项目首页

你会明显感觉到：笔记数量可能变少，但“能用的东西”变多。

下一篇（5/5）：知识库的终局不是“越来越多”，而是“越来越能复用”

最后一篇我会讲：我如何用 每周 30 分钟维护 让知识库长期不崩，包括：

• • Inbox 清空 SOP
• • 复用率指标怎么记
• • 归档/删除规则（让库不膨胀）
• • 如何把卡片变成稳定输出（文章/分享/面试表达）

如果你想把这 4 个模板打包成一份“可直接导入 Obsidian 的模板库”（含命名规则 + 示例卡片），评论或私信关键词：v1.0。