---
name: learn-map
description: Use when user explicitly requests systematic learning of a topic via "学习"、"讲解"、"teach me"、"@learn-map" — generates a 6-stage Feynman-style learning map (hook → anchor → decompose → apply → extend → verify) for any technical, humanities, science, or business topic. Do NOT auto-trigger on casual questions, brief explanations, or general "how does X work" inquiries.
---

# 系统化学习任何主题

## Overview

运用费曼技巧 + 二八原则 + 6 段渐进结构。先用痛点和类比建立直觉，再深入原理与边界。每个核心子主题必须含**原理 + 反例 + 边界**，否则删除——宁可少而透，不可多而浅。

## ⚠️ 自检的归属（适用全文）

文档中所有标注 **⚠️ 强制自检 / ⚠️ 类比来源自检 / 提交前自检清单 / 触发条件自检** 等"自检"段落，都是 **作者写作时的内部检查动作**，**不是输出格式的一部分**。

- ❌ 不允许把"自检通过"、"匹配通过"、"已数 X 字"等检查结论作为段落写进最终输出。
- ❌ 不允许在文档末尾留"自检备注"列出**已知违规**作为交付。
- ✅ 自检发现违规 → **必须修** → 重新自检 → 直到全部通过才可输出。
- ✅ 读者只该看到检查通过后的成品，看不到检查过程。

**闭环规则**：自检不是报告，是修复触发器。"已知 1 字超标"、"临界超标"、"贴近上限"等措辞都不是借口——超就是超，必须拆。

## 目标

帮助用户——任何想快速建立新主题认知框架的学习者——在 10 分钟内建立**系统认知框架**，能够：
1. 用自己的话向他人解释这个概念
2. 识别常见误用场景
3. 知道下一步该学什么

---

## 输出哲学：二八原则（最高优先级）

聚焦核心子主题，**每个讲透**。

二八不是"数量少"，是"按高频高价值筛选后的全部"：
- 简单主题可能 5 个核心子主题，复杂主题可能 10+ 个，由主题本身决定，不预设数量。
- 选定的每个子主题必须含 **原理（为什么）+ 反例（什么时候不用）+ 边界（适用条件）**。
- 删除标准：边缘 / 冷门 / 离主线远 → 删；高频但讲不透 → 删；介于两者之间默认收。
- 不写"只有结论没有理由"的干瘪条目（best practice / 坑 / 术语都必须含"为什么"）。

写每一节前自问两件事：
1. **这是高频高价值的核心子主题吗？** 不是就删。
2. **如果是，我讲透了吗？**（含原理 + 反例 + 边界？）没讲透就补。

---

## 输出结构：6 段渐进式（严格按顺序输出）

```
1. 入门  — 抓住注意力，先把读者勾住
2. 核心  — 给一个能立住的最小理解
3. 详解  — 拆零件、划边界
4. 应用  — 上手做
5. 拓展  — 在知识网络中定位
6. 检验  — 内化检验
```

每段之间留一个钩子句，让阅读有连续下坠感。

---

### 1. 入门 (Hook)

#### 1.1 痛点开场（必需，≤2 句话，**每句严格 ≤ 40 字**）

**开场必须用痛点场景或提问**，绝对不能用"XX 是一种..."式定义。先抛出用户会遇到的具体问题，引发"这正是我遇到的"共鸣。

⚠️ **句长硬上限：每句 ≤ 40 字**（属于档位 B）。

⚠️ **禁止多场景复合句**——禁用"或者反过来"、"再或者"、"另一方面"等连接两个场景的句式。一个开场说**一个**最痛的场景就够，多个场景堆叠几乎必然超 40 字。如果你想到两个场景都很痛，**只挑最痛的那个**。

错误开场：
> "WebSocket 是一种全双工通信协议。"

错误开场（多场景复合，~60 字）：
> "你有没有遇到过页面需要实时更新数据却只能靠不停刷新？或者反过来，你想推送通知却被浏览器拦截？"

正确开场（技术主题）：
> "你有没有遇到过页面需要实时更新数据，却只能靠不停刷新？"

正确开场（非技术主题）：
> "你有没有想过，为什么明知该做的事却拖到最后一刻？"

#### 1.2 一句话类比（必需，按主题类型分流）

用一个类比让读者 3 秒抓住核心思想。**类比来源按主题类型分流**：

| 主题类型 | 类比来源 | 示例 |
|----------|----------|------|
| 强技术主题（协议/架构/系统/算法） | 程序员熟悉的概念：缓存、队列、递归、事务、线程池、管道、回调 | "Kafka 就像一个超大号的消息队列，但加了持久化和回放" |
| 复杂抽象概念（哲学/心理学/经济学/数学思想） | 幼儿园式比喻：积木、食物、小动物、玩具 | "认知失调像两块拼不上的积木硬塞进同一个盒子" |
| 通用主题（业务/工具/方法论/文化） | 日常生活场景：排队、快递、餐厅点餐、菜市场砍价 | "OAuth 就像酒店前台给你的房卡——能开门，但不知道你是谁" |

**铁律**：
- 比喻必须**精准贴切**，不强行套用。
- 若主题难以类比（如纯数学公式、纯语法），**直接说明"此概念难以用 XX 类比，原因是…"**，然后用最简定义替代。
- 跨领域主题可叠加多个类比来源（如"用程序员的事务 + 餐厅点餐"双重解释）。

#### ⚠️ 类比来源自检（写完类比后立即问）

写完类比后，根据主题类型自问：

- **强技术主题**：你的类比里有"线程池 / 锁 / 缓存 / 队列 / 管道 / 事务 / 回调 / 哈希表"这类**程序员词汇**吗？没有 → 重写。**不可用"工厂流水线"、"分拣车间"、"快递员"等通用比喻替代程序员熟概念**——读者本就是程序员，绕一圈反而费解。
- **抽象概念**：你的类比里有"积木 / 食物 / 玩具 / 小动物"这类**幼儿园词汇**吗？没有 → 重写。
- **通用主题**：你的类比里有"排队 / 餐厅 / 快递 / 砍价"这类**日常生活场景**吗？没有 → 重写。

匹配不上就是失败。换一个类比。

> 钩子（1 → 2）：直觉有了，接下来给一个能立住的最小理解。

---

### 2. 核心 (Anchor)

#### 2.1 核心定义（必需，≤2 句话）

精准、克制的定义。在痛点和类比建立直觉后，用最简洁的语言钉住"它是什么"。

要求：
- 不超过 2 句话。
- 不堆术语，必要术语在 3.1 速查表里展开。
- 一句"是什么"，一句"做什么"。

示例：
> Kafka 是一个分布式、可持久化、可回放的消息日志系统。它让生产者写一次、多个消费者按需读取。

#### 2.2 全景架构图（必需）

基于 **MECE 原则** 生成 Mermaid 图表，可视化知识结构。

**执行步骤**：
1. 调用 `@mermaid-generator` skill 处理图表生成（语法、引号、布局由它负责，learn-map 不重复管）。
2. 根据知识点类型选择图表：
   - 流程/步骤 → `flowchart`
   - 组件关系 → `block-beta` 或 `classDiagram`
   - 状态转换 → `stateDiagram-v2`
   - 时间序列 → `sequenceDiagram`
   - 抽象概念/思想体系 → `mindmap`
   - 历史/演进/发展脉络 → `timeline`

> 钩子（2 → 3）：核心立住了，下一步是拆零件、划边界。

---

### 3. 详解 (Decompose)

本段三个子模块都是**条件触发**——主题需要才出，否则跳过，避免凑数。

#### 3.1 核心术语速查表

**触发条件**：主题包含 **≥ 5 个**新术语时使用。

精选 **5-8 个**最核心术语（按出现频率或重要性筛选），4 列：

| 术语 | 人话解释（≤15字） | 类比 | 常见误解（≤20字） |
|------|-------------------|------|-------------------|
| ... | ... | ... | ... |

#### 3.2 5W2H 全景分析

**触发条件**：主题为复合主题（流派/方法/系统/工具/学派/概念体系），纯定义/语法/单一事实类跳过。

| 维度 | 问题 | 答案 |
|------|------|------|
| What | 是什么？ | 见 2.1 核心定义，此处不重复 |
| Why | 解决什么问题？ | 核心痛点 |
| Who | 谁在用？ | 典型用户画像 |
| When | 何时使用？ | 适用场景 |
| Where | 处在领域中的什么位置？ | 学科/技术栈定位 |
| How | 核心工作机制？ | 一句话原理 |
| How much | 学习/使用成本？ | 时间/资源估算 |

#### 3.3 易混淆概念对比

**触发条件（否定通过制）**：你必须能想出**真实场景**中"有人因为分不清 A 和 B 而踩过坑"的具体例子（教学经验、Stack Overflow 高票问题、文档 FAQ、生产事故复盘）。

- ✅ 通过：`git rebase vs merge` —— 新人因混淆历史改写 vs 合并而误删提交，是高频踩坑。
- ✅ 通过：`at-least-once vs exactly-once 投递语义` —— 误以为开了某个开关就 exactly-once，导致数据重复写下游。
- ❌ 不通过：`消费者组 vs 多个独立消费者` —— 这两个概念在**正常学习路径**里不会混淆，强行写出来就是凑数。

**铁律**：想不出"谁因为分不清翻过车"的具体场景 → **整段跳过 3.3**，不要凑。凑出来的对比反而稀释整篇质量。

⚠️ **格式硬规则**：3.3 **不允许在表格前写散文导言**。表格前最多 1 行**对比标题**（≤15 字），格式：`**易混点**：A vs B`。表格本身已经能传达对比，论证你脑子里有就够了，不要写出来。

❌ **失败示范（散文导言，~50 字 + 红旗 em-dash + 3 逗号）**：
> "新人常把 at-least-once 当成 exactly-once——以为开了幂等生产者就万事大吉，结果消费者重启重读，下游数据库被重复写。"

✅ **正确示范（标题 + 表格，无导言）**：
> **易混点**：at-least-once vs exactly-once
>
> | 维度 | at-least-once | exactly-once |
> | ... |

| 维度 | 概念 A | 概念 B |
|------|--------|--------|
| 定义 | ... | ... |
| 适用场景 | ... | ... |
| 优缺点 | ... | ... |

> 钩子（3 → 4）：零件清楚了，就该上手做。

---

### 4. 应用 (Apply)

#### 4.1 最佳实践 Top 5（必需）

列出 **5 条**最重要的使用建议。每条**必须**含两部分：

```
✅ Do: [规则，≤25 字]
   → 为什么：[原理或机制，≤40 字]
```

不允许只写"✅ Do: 规则"而不写"为什么"。"为什么"是这个模块的核心价值——让读者理解原理而非死记规则。

示例：
```
✅ Do: Kafka 消费者数量必须 ≤ 分区数。
   → 为什么：每个分区只能被组内一个消费者读，多余的会闲置浪费资源。
```

#### 4.2 新手五大坑（必需）

列出 **5 个**初学者最常犯的错误。每个用以下格式（必须 4 行齐全）：

```
❌ 错误：[具体行为，≤25 字]
💥 后果：[会导致什么问题，≤25 字]
✅ 正解：[正确做法，≤25 字]
🧠 为什么会踩：[背后的认知盲点或机制，≤40 字]
```

"🧠 为什么会踩"是重点——只说"别这么做"治标，讲清"为什么人会这么想"才治本。

#### 4.3 5 分钟微型实践（必需）

按主题类型分流，给出一个**不超过 5 分钟**的练习任务：

**技术主题**：
- ≤10 行代码 / ≤5 个操作步骤
- 验证方式：运行后应输出 XXX

**非技术主题**：
- ≤5 步思考练习 / 识别任务 / 一段写作
- 自检标准：完成后能回答 XXX，或写出的内容包含 XXX 三要素

#### ⚠️ 4.3 前置环境硬约束

**"5 分钟"必须包含一切前置准备**。读者打开文档到完成验证的总时间 ≤ 5 分钟。

- ❌ 失败：练习写"运行 `kafka-console-consumer ...`"，**默认本地已装并启动 Kafka**。零基础读者光装 Kafka 就要半小时。
- ✅ 通过路径 1：用**在线沙盒**（如 SQLFiddle、Go Playground、CyberChef）替代本地环境，链接直给。
- ✅ 通过路径 2：改成**纸笔思考练习**（如"画出 X 时序图"、"列出 Y 的 3 种可能"）。
- ✅ 通过路径 3：明确写出"如果你没装 X，先做 Y（≤ 2 分钟）"，且 Y 必须真能 2 分钟搞定。

**判断**：把这个练习交给一个**完全没接触过本主题的人**，他能 5 分钟内完成吗？不能 → 改。

> 钩子（4 → 5）：会用了，问问它从哪来、又通向哪。

---

### 5. 拓展 (Extend)

#### 5.1 同领域脉络（必需，水平：前置 → 当前 → 后续）

**3-5 个前置 + 3-5 个后续**，都在**同一学科内**做上下游延伸。每条必须用列表格式，附 **一句话说明"为什么先学/后学"**：

```
前置：
- A：[为什么是前置，≤30 字]
- B：[...]
- C：[...]

后续：
- D：[为什么是后续，≤30 字]
- E：[...]
- F：[...]
```

示例（React）：
- 前置：
  - JavaScript 语法：React 是 JS 库，语法不熟无法上手。
  - DOM：React 的 vDOM 概念建立在原生 DOM 之上。
  - HTTP/Fetch：组件几乎都要发请求拿数据。
- 后续：
  - 状态管理（Redux/Zustand）：跨组件共享状态的下一步。
  - SSR（Next.js）：性能与 SEO 的进阶问题。
  - React Native：同一套思想跨到移动端。

#### 5.2 跨维度根系（必需，垂直：向下钻到更基本的解释层）

```
当前主题 → 更底层学科 → 再底层 → ... → 最终落点
```

朝向永远是**更基本**：社会学 → 心理学 → 生物学 → 物理学 → 数学 → 逻辑。

跳几级因主题而异，目标是让读者看到"**这个主题的根扎在哪里**"。

示例：
- React → 事件驱动编程 → 状态机 → 离散数学
- 拖延症 → 边缘系统 vs 前额叶博弈 → 神经经济学 → 决策论
- 斯多葛主义 → 认知行为心理学 → 大脑可塑性

⚠️ **格式硬规则**：链路图下方**禁止散文式简述**。改用**分跳列表**——每跳独立一行，**每行 ≤ 25 字**。

❌ **失败示范（散文，~60 字红旗）**：
> "消费者组本质是一群进程对一组资源的协调分配，再往下是分布式协调和共识，最终落到状态机理论。"

✅ **正确示范（分跳列表，每行独立短句）**：
> - 消费者组 → 分布式协调：本质是资源独占分配。
> - 分布式协调 → 共识算法：成员管理依赖一致性。
> - 共识 → 离散数学：根扎在状态机理论。

#### 5.3 真实世界案例（必需）

列举 **2-3 个**案例，类型可选：知名应用/公司/项目、历史人物/学派/流派、代表作品/经典文献、典型场景/真实事件。

⚠️ **具体性硬规则**：**每个案例必须含 ≥ 2 项**以下具体性元素：

| 元素 | 示例 |
|------|------|
| (a) **具体数字** | QPS、用户量、规模、版本号、年限 |
| (b) **具体技术细节 / 方法** | 用了什么组件、解决什么独特问题 |
| (c) **具体时间点 / 年份** | 1957 年、2020 年代、Go 1.19 |
| (d) **引用的人名 / 团队** | Festinger、Eran Hammer、Stockdale、Tim Ferriss |

只写"X 用了 Y"是**不及格**的——必须落到具体。

**反例（失败，仅 1 项）**：
> ❌ "Uber 用 Kafka 做实时定价。"

**正例（通过，≥ 2 项）**：
> ✅ "**Uber**：用 Kafka 串联订单、定价、调度（b 技术）。每秒百万级司机位置事件流入 Kafka（a 数字），下游 Flink 消费做秒级动态调价（b 技术）。"

**正例（通过，≥ 3 项）**：
> ✅ "**詹姆斯·斯托克代尔**（d 人名）：越战美军飞行员，被关 7 年半（a 数字 + c 时间）。靠《爱比克泰德手册》撑过酷刑（b 方法），后总结出'斯多葛悖论'。"

⚠️ **关于 `(a 数字)`、`(b 技术)`、`(c 时间)`、`(d 人名)` 标注**：这些**仅用于本 skill 的评估说明**，让你判断案例是否含 ≥2 项具体性元素。**写入实际输出时必须去掉**。读者不应该看到这些标注。

⚠️ **案例格式硬规则**：每个案例**必须用 bullet 结构**，禁止散文堆叠。每行独立一句，**每行 ≤ 25 字**。

模板：
```
**[公司 / 团队 / 人物名]**
- 规模：[数字 / 用户量 / 时间点，≤25字]
- 用法：[具体技术 / 方法，≤25字]
- 结果：[效果 / 关键事件 / 踩坑，≤25字]
```

❌ **失败示范（散文堆叠，~50 字 + 红旗 3 个逗号）**：
> "Uber：用 Kafka 串联订单、定价、调度。每秒百万级司机位置事件流入 Kafka，下游 Flink 消费做秒级动态调价。"

✅ **正确示范（bullet 结构）**：
> **Uber**
> - 规模：每秒百万级司机位置事件。
> - 用法：Kafka 串联订单、定价、调度链路。
> - 结果：下游 Flink 做秒级动态调价。

> **詹姆斯·斯托克代尔**
> - 规模：越战美军飞行员，被关 7 年半。
> - 用法：靠《爱比克泰德手册》撑过酷刑。
> - 结果：后总结出"斯托克代尔悖论"。

#### 5.4 专家级冷知识（条件触发，1-2 条）

**触发条件**：主题确实有反直觉的"高手才知道"（设计权衡 / 作者争议 / 颠覆常识），不是百科首段就有的事实。没有就跳过，不凑数。

⚠️ **格式硬规则**：每条冷知识用 **3 行 bullet**，禁止散文。每行独立一句，**每行 ≤ 25 字**。

模板：
```
**[3-5 字标签]**
- 旧认知：[大家通常以为的，≤25字]
- 真相：[实际机制 / 反直觉点，≤25字]
- 含义：[为什么重要 / 何时遇到，≤25字]
```

❌ **失败示范（散文，~50 字红旗）**：
> "Kafka 2.4 引入 Static Membership 能让消费者重启跳过 rebalance——只要在 session.timeout 内回来，协调者就当它没走过。"

✅ **正确示范（bullet 结构）**：
> **Static Membership（Kafka 2.4+）**
> - 旧认知：消费者重启必触发 rebalance。
> - 真相：配 group.instance.id，超时内不算变更。
> - 含义：滚动发布不再引发组停顿。

⚠️ **凑不出 ≤25 字的 bullet** = 这条冷知识本身过于复杂，**重选**或跳过整段，不放宽字数。

> 钩子（5 → 6）：知识连成网了，能否用自己的话讲清楚？

---

### 6. 检验 (Verify)

#### 6.1 理解检验（必需，2-3 题）

提出 2-3 个问题，类型包括：
- 概念辨析题（"X 和 Y 的区别是？"）
- 场景应用题（"遇到 Z 情况该怎么办？"）

---

## 输出保存

每次生成的学习内容需保存为 markdown 文件：

1. **保存目录**：在用户当前工作目录下创建 `learn-map_outputs/`（若不存在则创建）。不要写到 skill 安装目录或 home 根目录。
2. **文件命名**：`{YYYY-MM-DD}_{学习主题}.md`
   - 技术示例：`2026-02-08_Go内存模型.md`
   - 非技术示例：`2026-02-08_斯多葛主义.md`
3. **冲突处理**：若同名文件已存在，追加序号后缀 `_v2`、`_v3`，不要覆盖。
4. **完成后**：告知用户绝对路径，方便用户直接打开。

---

## 语言风格

| 维度 | ❌ 不要 | ✅ 要 |
|------|---------|------|
| **开场** | "XX 是一种..." | "你有没有遇到过...？" 或直接抛出痛点场景 |
| **解释** | 直接抛术语 | 先类比 → 再定义 → 最后细节 |
| **句式** | 见下文"句式硬性要求" | — |
| **代码** | 超过 15 行 | ≤ 10 行，关键行必须加注释 |
| **Emoji** | 每段都有 | 仅用于关键警告（⚠️❌✅）和 4.2 的 🧠 标记 |

### 模块衔接：层间留钩子

6 段之间不要硬切换。每段结尾留一个钩子句——抛一个问题或矛盾，自然引出下一段。

钩子模板（已嵌入各段末尾）：
- 1 → 2：直觉有了，接下来给一个能立住的最小理解。
- 2 → 3：核心立住了，下一步是拆零件、划边界。
- 3 → 4：零件清楚了，就该上手做。
- 4 → 5：会用了，问问它从哪来、又通向哪。
- 5 → 6：知识连成网了，能否用自己的话讲清楚？

钩子要轻、一行解决，不破坏模块独立性。

### ⚠️ 句式硬性要求（分级规则）

句长按**内容类型分两档**：

#### 档位 A：严格 ≤ 25 字（扫读型内容）

适用：表格内的格子、bullet 列表、checklist、术语解释、最佳实践规则、坑的"❌错误/💥后果/✅正解"三行、5W2H 答案。

> 这些内容是**扫读**的，长句破坏扫描节奏。

错误示范（38 字）：
> "Redis 持久化是把内存中的数据写到磁盘上，防止重启或宕机后数据丢失。"

正确示范（拆成两句，各不超过 25 字）：
> "Redis 持久化把内存数据写到磁盘。这样重启或宕机后数据不会丢。"

技巧：一个逗号通常意味着该拆句。用句号替代逗号。

#### 档位 B：放宽 ≤ 40 字（叙事/推理型内容）

适用：1.1 痛点开场、1.2 类比叙述、4.1 的"→ 为什么"、4.2 的"🧠 为什么会踩"、5.1/5.2 中"为什么先学/后学"和跨维度根系推理、5.3 真实案例的具体描述、5.4 冷知识。

> 这些内容是**讲述**的，需要句子有最低长度才能完整表达因果或场景。但仍以紧凑为目标，能 25 字讲完就别撑到 40。

#### ⚠️ 强制自检（写每一段叙事后**立即**做，不可延后）

**写完一段叙事/推理类内容（1.1 / 1.2 / 4.1 → 为什么 / 4.2 🧠 / 5.1 为什么 / 5.2 推理 / 5.3 案例 / 5.4 冷知识）后，先别写下一段，立刻自检**：

1. **数字数**：从句号回数到上一个句号，数中文字符数（标点也算）。
2. **看红旗**：句子里有以下任意一个就高度可疑——
   - **≥ 2 个逗号** → 大概率超 40
   - **em-dash（——）+ 括号（）** 同时出现 → 几乎必然超 40
   - **两个分句用"而"/"但"/"且"连接** → 应直接拆成两句
   - **句子里同时有冒号 + 逗号** → 大概率超 40
3. **超了就拆**：拆点优先选逗号位置，用句号替代。

⚠️ **不允许"先写完整篇再统一自检"**。整篇写完再回头修，意味着你会因沉没成本而放过一些违规。**段末即查**是硬规则。

#### 真实失败示范（来自历史输出，必须避免）

❌ **过长（46 字）**：
> "OAuth 就像酒店前台给你的房卡——能开你的房间门，但前台不知道你长啥样，房卡也只在退房前有效，丢了还能挂失重发。"

✅ **修复（拆 3 句，全 ≤ 25 字）**：
> "OAuth 就像酒店前台给你的房卡。房卡能开你的房间门，但前台不知道你长啥样。房卡只在退房前有效，丢了还能挂失重发。"

#### 通用原则

- 不存在"档位 C"——超过 40 字必须拆。
- A 档（≤ 25）是**默认**；只有上面列出的几个位置才用 B 档（≤ 40）。其他一律 A 档。

### ⚠️ 代码块硬性要求（仅当涉及代码时）

**若内容涉及代码**，遵守以下规则。非技术主题无代码，整段跳过。

**单个代码块不得超过 15 行（包括空行和注释）。** 这是硬性规则。

对于需要 `package`/`import` 声明的语言（如 Go、Java），在代码块前用文字说明依赖，代码块只写核心逻辑。

---

## 🔴 提交前自检清单（必做，不通过禁止输出）

每项不通过 → 回去修。

### 自检 1：结构齐全（grep 即可）

```
□ 6 段标题按 1→2→3→4→5→6 顺序出现？
□ 必需小节全到：1.1 / 1.2 / 2.1 / 2.2 / 4.1 / 4.2 / 4.3 / 5.1 / 5.2 / 5.3 / 6.1？
□ 5 处段间钩子句（1→2 / 2→3 / 3→4 / 4→5 / 5→6）出现？
```

### 自检 2：句长（grep 红旗优先）

```
□ grep `——` 和 `（）`：同一句两个标点 → 几乎必超 40，拆。
□ grep 含 ≥ 2 个逗号的句子 → 大概率超 40，拆。
□ 抽 3 条扫读区（表格 / bullet / 4.1 Do / 4.2 三行）逐字数：≤ 25？
□ 抽 3 条叙事区（痛点 / 类比 / 案例 / 4.1 → 为什么 / 4.2 🧠）逐字数：≤ 40？
```

### 自检 3：最易翻车点

```
□ 1.1 是痛点场景或提问，不是 "XX 是一种..."？
□ 1.1 没用"或者反过来"等连接词把两个场景堆在一起？
□ 1.2 类比来源匹配主题类型（技术→程序员 / 抽象→幼儿园 / 通用→生活）？
□ 4.1 / 4.2 各 5 条且每条含"为什么"行（4.1 两行齐 / 4.2 四行齐）？
□ 3.3 表格前**没有散文导言**（最多 1 行 ≤15 字的对比标题）？
□ 5.1 前置 3-5 + 后续 3-5，每条带"为什么先 / 后学"？
□ 5.2 链路图后用**分跳列表**（每跳一行 ≤25 字），不是散文简述？
□ 5.3 每个案例用 **bullet 模板**（标题 + 规模 + 用法 + 结果），不是散文堆叠？
□ 5.3 每个案例 ≥ 2 项具体性元素（数字 / 技术 / 年份 / 人名）？
□ 5.3 案例里**没有 (a 数字)、(b 技术)、(c 时间)、(d 人名) 等评估标注**？
□ 5.4 冷知识用 **3 行 bullet**（旧认知 + 真相 + 含义），不是散文？
□ 4.3 练习 5 分钟内可完成（含环境准备）？
□ 文档里**没有任何"自检结果"段落**（如"类比来源自检"、"匹配通过"等）？
□ 文档末尾**没有"自检备注"列已知违规**作为交付？
```

### 自检 4：闭环（最后一关）

```
□ 上面任意一项不通过 → 已经修了，不是只标记？
□ 修完后是否回头重跑自检 1/2/3 直到全过？
□ 整篇文档是"通过自检后的成品"，不是"带病交付 + 自检备注"？
```

⚠️ 不允许跳过自检 4。**自检的价值不在发现问题，在修完问题**。