学习型知识笔记设计

在不破坏原子笔记边界的前提下，把 Thought Forest 笔记设计成可学习、可提取、可验证的知识节点：正文负责知识，学习层负责问题、边界与掌握验收。

#howto #growing #knowledge-base #learning

[!info] related notes

规范前置: [[knowledge-map-and-atomic-note-spec|知识地图与原子笔记规范]]、[[knowledge-base-metadata-reference|知识笔记元数据规范]]

相关 MOC: 学习与掌握 MOC、Obsidian MOC

学习机制: 学习中的掌握、主动提取、学习中的自我解释

实践流程: 如何学习一个知识并达到掌握

学习型知识笔记设计

目标

让知识笔记不仅“方便以后查”，还能够直接支持：

初次理解；
主动提取；
辨别边界；
实际应用；
延迟复习；
掌握度验收。

同时必须保持 Thought Forest 的原子化原则：

一篇稳定笔记只回答一个主要问题；学习性增强不能成为把所有相关知识塞进同一篇笔记的理由。

默认执行策略

从现在开始，对新建或实质性优化的长期知识笔记，默认按下面方式处理：

concept / synthesis / howto / debug：默认加入简短的“学习检查”；
存在明显能力阶梯时，再加入“掌握验收”；
resource：只有当理解和选型本身值得学习时加入，不为纯资源卡机械出题；
moc：负责路径和导航，不维护第二份练习答案或 mastery；
course：本身已经承担完整教学与练习，不机械重复轻量学习层；
snippet / journal / 纯查表内容：按需，不强制。

这是渐进式规范：以后新建和正在维护的笔记遵循即可，不为形式统一一次性重写历史库。

成功状态

一次笔记优化完成后，至少应能观察到四件事：

角色明确：读标题、frontmatter 和正文开头，就能判断它是 concept、synthesis、howto、debug 还是其他角色；
边界稳定：正文只解释当前节点自己的问题，较长对比、导航和操作过程没有继续膨胀进来；
学习可执行：读者可以闭卷回答少量高质量问题，必要时还有可观察的掌握验收；
图谱可追踪：前置、所属 MOC、关系笔记或实践入口至少有一条真实链接，而不是只靠目录位置猜上下文。

如果只是“章节更多、字数更多”，但这四项没有改善，就不算一次有效优化。

两层结构：知识层 + 学习层

一篇长期知识笔记建议理解成两层。

知识层

回答：

这个节点本身需要长期保存什么？

例如 concept：

定义
→ 背景
→ 核心机制
→ 最小例子
→ 边界

学习层

回答：

我如何证明自己真的会了？

通常只需要：

学习检查
+
掌握验收

学习层不应该复制另一个概念的正文。

原子化的判断标准

不是“笔记越短越原子”。

真正标准是：

它是否围绕一个可以稳定命名、可以独立引用的问题？

应该留在同一篇

DoH 笔记中的：

一句话定义；
为什么需要加密 DNS；
DoH 请求如何封装；
DoH 保护哪一段；
一个最小请求场景。

这些都在回答：

DoH 是什么、为什么这样工作？

应该拆出去

如果开始详细讨论：

DoH 与 DoT 谁在哪些层不同；
DoH 与 VPN 的关系；
浏览器 Secure DNS 为什么绕过系统 DNS；
如何排查 Chrome DoH 导致的解析差异；

这些已经分别是独立问题。

因此应该形成：

concept: [[dns-over-https-doh|DoH]]
concept: [[dns-over-tls-dot|DoT]]
synthesis: [[doh-vs-dot|DoH vs DoT]]
concept: [[browser-secure-dns|浏览器安全 DNS]]
howto: [[dns-systematic-diagnosis|系统化 DNS 诊断流程]]

不要给所有笔记强塞 20 个固定章节

“学习友好”不等于模板越长越好。

不同笔记角色应该保留自己的正文契约，再添加轻量学习层。

concept 应该怎样写

核心目标：

建立一个稳定心智模型。

推荐结构：

## 一句话定义
## 为什么需要它 / 使用语境
## 核心机制或不变量
## 最小例子
## 边界与常见误解
## 学习检查
## 掌握验收（需要时）

如果“与 A 的区别”超过几句话，就创建 synthesis。

concept 的学习检查

问题从低到高：

定义：它是什么？
机制：为什么这样工作？
边界：什么情况下不成立？
辨别：它容易和什么混淆？
应用：给一个真实场景。
迁移：条件变化后会怎样？

synthesis 应该怎样写

核心目标：

解释多个稳定节点之间的关系。

推荐结构：

## 范围
## 为什么需要一起理解
## 关系模型
## 关键差异 / 协作 / 演进
## 一条具体场景
## 决策规则或辨别线索
## 学习检查

例如 DoH vs DoT 本身应该是一篇 synthesis，而不是 DoH 和 DoT 两篇各复制一张对比表。

synthesis 的学习检查

重点不是分别背两边定义，而是：

给场景判断属于哪一种；
解释选择依据；
改一个条件，看判断是否改变；
找共同点和真正分歧。

howto 应该怎样写

核心目标：

脱离作者也能得到一个可验证结果。

推荐结构：

## 目标 / 成功状态
## 前置条件
## 步骤
## 每一步为什么
## 验证
## 失败与恢复
## 无提示执行检查

学习型 howto 不应该只让人复制命令。

最后应能测试：

不看文档，我是否知道下一步做什么，以及为什么？

debug 应该怎样写

核心目标：

从现象到证据再到根因。

推荐结构：

## 现象
## 快速判断
## 假设
## 区分假设的证据
## 根因
## 修复
## 回归验证
## 新案例判断

学习检查应该给一个相似但不完全相同的新故障，让读者决定下一条证据，而不是背“这次最后用了什么命令”。

resource 应该怎样写

核心目标：

知道这个外部对象是什么、何时值得使用、边界在哪里。

学习层重点：

它解决什么问题？
不适合什么？
和邻近工具是什么关系？
给一个需求，能否判断是否应该考虑它？

不要把资源笔记写成所有相关 howto 的合集。

MOC 应该怎样写

MOC 的学习价值来自导航和顺序，而不是在里面重复讲所有知识。

MOC 应回答：

先学什么？
前置依赖是什么？
哪些概念是一组？
哪些 synthesis 用来建立关系？
哪些 howto / debug 用来实践？

学习检查、掌握度属于实际知识节点，不应在 MOC 维护第二份。

course 应该怎样写

course 是例外。

课程的职责本来就是“怎么学”，因此可以为了连续教学重复稳定定义，并包含：

前置回顾；
逐步教学；
Worked Example；
Prediction；
折叠答案；
Lab；
Explain-back；
阶段验收。

课程结束后，稳定知识仍应链接回 concept / synthesis / howto / debug。

学习检查应该放什么

推荐最多 3–7 个高质量问题，不追求题量。

一个 concept 可以使用：

## 学习检查

不看上文回答：

1. X 是什么？
2. 为什么需要 X？
3. 画出 X 的最小工作模型。
4. X 不解决什么问题？
5. 条件 Y 改变后会怎样？

不要把问题写成可以靠原句关键词直接扫描答案的“阅读理解”。

是否应该把答案写在下面

有两种使用模式。

模式 A：笔记本身已经包含答案

学习检查只是提示你：

先别往上看，自己回答。

适合稳定 concept。

模式 B：题目需要独立解析

使用折叠 callout：

> [!question]- 解析
> ...

适合 course、复杂推导或故障案例。

不要为每个简单问题重复复制整段正文。

掌握验收应该怎样写

不是所有笔记都需要长 checklist。

只有当知识存在明显能力阶梯时，再增加：

## 掌握验收

- [ ] 能闭卷解释核心模型
- [ ] 能指出至少一个边界
- [ ] 能完成典型任务
- [ ] 能处理一个变式
- [ ] 延迟后仍能提取

具体 mastery: 1–5 的语义统一参考学习中的掌握，不要每篇笔记自创评分含义。

正例、反例与边界怎样组织

一个 concept 通常只保留最小正例和最关键边界。

当反例本身成为稳定知识时拆出独立 concept。

当正反两者之间的关系需要持续解释时建立 synthesis。

也就是说：

例子服务于理解当前节点
关系服务于连接多个节点
MOC 服务于导航整个主题

AI 生成笔记时的默认流程

1. 先确认笔记角色

问：

一个概念？
多个概念的关系？
一张地图？
一个操作？
一个排障？
一个资源？

2. 查重与找邻居

先搜索：

同义标题；
英文名 / 缩写；
相邻 concept；
已有 synthesis；
MOC。

3. 只写当前节点自己的知识

发现另一个稳定问题时：

链接或拆分，不复制展开。

4. 给正文加入学习层

至少考虑：

是否有一个好的最小例子？
是否写清边界？
能不能生成 3–5 个闭卷问题？
有没有可观察的掌握标准？

5. 用关系笔记承担对比

例如用户说：

DoH 和 DoT 有什么区别？

优先：

[[dns-over-https-doh]]
+
[[dns-over-tls-dot]]
+
[[doh-vs-dot]]

而不是同时把两篇 concept 都扩写成重复的百科。

AI 生成一篇学习型 concept 的提示模板

请按 Thought Forest 原子笔记规范生成/优化 [概念]：

1. 先查重并判断笔记角色；
2. 只回答这个概念本身，不把独立关系问题塞进正文；
3. 正文包含：
   - 一句话定义
   - 为什么需要它 / 使用语境
   - 核心心智模型或机制
   - 最小例子
   - 边界、失败条件、常见误解
4. 与其他概念的较长对比拆成独立 synthesis；
5. 文末加入 3–7 个主动提取问题；
6. 如存在明显能力阶梯，加入简短掌握验收；
7. 链接前置 concept、关系 synthesis、实践 howto/debug；
8. 不为了完整而重复其他笔记正文。

失败与恢复

失败模式	典型信号	恢复动作
为了完整不断扩写	concept 同时开始承担比较、教程和导航	把关系拆到 synthesis，把步骤拆到 howto/debug，把索引留给 MOC
学习检查退化成阅读理解	看着上文就能逐字抄出答案	改成闭卷定义、边界判断、场景选择或条件变化题
mastery 语义漂移	每篇笔记都自己解释 1–5 分	删除局部评分定义，统一链接 [[mastery-in-learning
MOC 与正文重复	MOC 出现大段概念解释和答案	MOC 只保留路径、分组和关系说明，知识回到实际节点
AI 生成重复 canonical 节点	同义标题或 alias 已经存在	先按标题、alias、英文名和近邻链接查重，再决定更新还是新建

无提示执行检查

随机挑一篇正在维护的 concept，不看本页正文，完成一次小型重构：

先说出它唯一的核心问题；
指出一段应该留在本页的内容，以及一段应该拆出去的内容；
写 3 个不能靠扫描原文回答的学习检查题；
补上至少一个真实的 MOC、前置或关系链接；
最后说明你会用什么证据判断这次优化真的提升了“可学、可提取、可验证”。

质量验收

一篇学习型知识笔记完成前检查：