concept-fable

name	concept-fable
description	当用户说「用故事解释」「讲个寓言」「打个比方」「通俗理解」某个概念时触发。用寓言故事诠释抽象概念，故事中不出现学名，结尾才揭晓。

寓言故事概念解释器

Overview

当用户想理解一个抽象概念时，不直接抛出教科书定义，而是创作一篇精心设计的寓言故事。读者沉浸其中，在临近结尾时才恍然大悟，然后附上专业释义。

核心原则：用故事让人"悟到"，而不是用定义让人"记住"。

Workflow

按以下 8 步执行：

Step 1 — 理解概念

1. 如果概念已充分掌握，直接进入下一步
2. 如果概念有模糊之处，搜索或查阅权威资料
3. 提炼出 2-3 个核心要素：关键矛盾、核心机制、为什么重要
4. 写出概念的因果链——一步步拆解概念的实际运作机制：什么触发了什么、按什么顺序、导致什么结果。这是情节蓝图：故事必须在情节层面复现这个因果序列，而非只蹭主题

核心要素与隐喻点的关系：每个核心要素必须有一个对应的隐喻点来映射它（这是底线）。额外的隐喻点（共 3-5 个，含 ≥2 个核心映射）用于丰富故事细节，但不能喧宾夺主。简单来说：核心要素 = 必须映射的（≥2 个），隐喻点总量 3-5 个。

Step 2 — 确认范围与场景（按需）

以下情况需向用户确认：

• 概念有多个分支或流派（如「一致性」在不同语境含义不同）
• 概念在不同领域有不同解读
• 用户表述模糊，可能有多种理解

确认概念理解：「这个概念我理解为 ______，核心要点是 ______，对吗？」

确认场景偏好——先判断概念本身，再决定是否问用户：

• 日常场景就能精准映射核心流程 → 不打扰用户，直接用日常场景
• 概念抽象、离日常经验较远 → 问一句：「这个概念比较抽象，你平时做什么工作、学什么专业？我挑一个你熟悉的场景来讲，更容易懂。」
• 概念虽日常，但用户的专业能提供更精准的隐喻 → 同上，简短问一句

Step 3 — 选择故事类型与语气

故事类型——根据概念的核心特征选择：

• 概念涉及两方博弈/冲突 → 古代寓言
• 概念是渐进累积的过程 → 日常生活
• 概念是系统行为/涌现现象 → 自然现象或机械装置
• 概念的核心是"表面 vs 实际"的反差 → 角色对话或说明书场景
• 概念的本质是"为了解决某个问题而存在"（工具/方案型，如 Node.js、缓存、依赖注入）→ 对比式结构：先展示「没有它」时的困境，再展示「有它」后的变化

选择标准：

• 故事的「冲突」或「转折」必须精准映射概念的核心矛盾
• 2-3 个角色，一个核心情节线

叙事语气——根据概念的情感色彩选择：

概念的情感色彩	推荐语气	示例场景
告诫/警示（如技术债务、死锁）	沉稳、略带惋惜	说书人风格，娓娓道来
揭示/反直觉（如抽象泄漏、幸存者偏差）	轻快、有反转感	像在讲一个"你猜怎么着"的故事
权衡/两难（如 CAP 定理）	中立、不偏袒	平实叙述，让读者自己判断
机制/原理（如依赖注入）	日常、接地气	生活化口吻，拉近距离

简单概念豁免：对于「什么是变量」「什么是循环」等基础概念，默认用日常接地气语气，不必逐条对照上表。表格主要用于需要情感引导的复杂/抽象概念。

Step 4 — 验证隐喻映射（写作前必做）

动笔之前，验证所选故事类型的冲突结构是否能忠实复现 Step 1 中写下的因果链：

1. 列出计划的隐喻点：列出 3-5 个计划使用的隐喻点，逐一标明映射到因果链的哪一环
2. 因果链覆盖检查：因果链的每一环都必须有对应的隐喻点。如果有哪一环没有映射 → 当前故事结构不适合这个概念，回到 Step 3 重选
3. 机制 vs 主题检查：故事的冲突映射的是实际的因果机制，还是只是结果的主题标签？「双方僵住了」是主题；「双方各自占着对方需要的东西，谁都不放手」才是机制。如果只映射到了主题 → 回到 Step 3 重选
4. 全部通过 → 进入 Step 5（写故事）

Step 5 — 写故事

三段式结构：

1. 铺垫（60%-70%）：引入角色和日常场景，看似与概念无关。情节自然展开，悄然埋入与概念的「神似」之处。让读者沉浸于故事，察觉不到这是在上课。
2. 矛盾显现（20%-30%）：故事出现转折、冲突或困境，精准映射概念要解决的核心问题。敏锐的读者开始有所察觉。
3. 揭晓（10%）：用「这就是我们今天要讲的概念——【概念名】」收束，一句话点破对应关系，点到为止。

写作原则：

• 全部简体中文，故事 300-800 字
• 不要过早暗示概念名——悬念是核心魅力
• 角色行为自然合理，不能为映射概念而扭曲人物
• 隐喻点控制在 3-5 个（其中核心要素对应的 ≥2 个），不要每个细节都对应
• 故事首先要有趣，教育性自然渗透
• 工具/方案型概念必须对比：故事中同时展示「没有它」和「有它」两个阶段，让读者自然感受到差异，价值通过反差浮现，而非说教
• 故事的因果链必须贴合概念的运作机制：不是只触碰「主题」，而是让情节的「因→果→困境」自然复现概念的核心流程。写完问自己：把故事的情节图翻译回技术术语，能不能还原出概念的关键步骤？不能 → 没贴住

隐喻具象化原则（硬性要求）：

隐喻载体必须是读者日常生活能直接感知的事物，遵守「奶奶测试」：

你的隐喻载体，你奶奶能不能一句话听懂是什么？ 能 → 可以用　　不能 → 换一个

• ✅ 做饭、开车、搬家、排队、取快递、修水管、超市结账、组装宜家家具、解开缠住的耳机线……
• ❌ 魔法符文、修仙体系、量子纠缠、第四维度、赛博空间……（读者需要先解码隐喻本身，理解门槛不降反升）
• 核心判断：隐喻的目的是降低理解门槛，如果隐喻本身比概念更难懂，就违背了初衷

Step 6 — 附专业释义

---

## 专业释义

### 【概念名】

**一句话定义：** [精准概括]

**为什么这个概念重要：** [1-2 句说明实际意义]

**核心要点：**
1. [是什么]
2. [为什么产生 / 为什么会这样]
3. [如何应对 / 如何应用]

**故事中的对应：**
| 故事元素 | 概念对应 |
|----------|---------|
| [角色/事件] | [概念要素] |
| [转折点] | [核心机制] |

**前置知识：** [如果释义中用了读者可能不熟悉的术语（如用「带宽」解释网络延迟时，顺带说明带宽是什么），在此处用 1-2 句简要说明。没有则省略此行。]

**延伸思考：** [1-2 句引导思考]

**故事续写（可选）：** [如果概念有天然紧密关联的概念（如 死锁→死锁预防、npm→依赖地狱），释义结束后用 2-3 句续写故事，引出关联概念。只给一句话定义，不展开完整释义。结尾问「需要展开讲吗？」。没有紧密关联概念则跳过。]

写完释义主体后，主动检查是否存在紧密关联的概念（问题→解决方案、工具→常见坑、现象→相邻现象），如果有，务必续写 2-3 句引出——这是 Skill 最有效的钩子之一，不要跳过。

续写约束：

• 复用原故事的角色和场景，可引入新角色推进情节，但不展开其背景或动机
• 关联概念只给一句话定义，不附带完整释义模板
• 「紧密关联」指：问题→解决方案、工具→常见坑、现象→相邻现象
• 用户要求展开 → 回到 Step 1 用完整流程单独讲关联概念

Step 7 — 自检

故事写完后，逐条审视。最多重写 2 次，仍不通过则输出当前最佳版本，并诚实告知用户哪里不够满意：

1. 角色自然度：如果去掉概念，角色的行为在故事逻辑里是否合理？如果角色为了隐喻做出了不合常理的举动 → 重写
2. 隐喻准确性：故事的核心冲突是否映射了概念的核心矛盾（而非边缘特性）？复核：实际写出的情节是否忠实复现了 Step 4 中确认的映射关系，写作过程中是否偏离？如果读者理解了故事却没理解概念 → 隐喻跑偏
3. 故事独立性：抛开概念，这篇故事本身是否有趣、可读？如果只是一篇「披着故事皮的说明书」 → 重写
4. 揭晓时机：概念名是否在故事自然结束后才出现？如果在开头或故事中途就提到了 → 太早了
5. 简洁度：隐喻点是否在 3-5 个范围内？（其中核心要素对应 ≥2 个。）有没有可以删掉的冗余情节？
6. 具象化：隐喻载体是否通过了「奶奶测试」？如果载体本身需要解释（魔法、修仙、科幻设定）→ 换成日常场景
7. 术语闭环：专业释义中是否引入了读者可能不熟悉的新术语？如果有 → 在释义末尾用 1-2 句简要说明

Step 8 — 输出

• 默认直接在对话中输出故事和释义
• 输出结束后，简短问一句：「讲清楚了吗？有不明白的地方、或者想换个场景讲，告诉我。」
• 如果用户要求保存，写为 概念寓言-{概念名}.md

---

后置处理（输出后触发）

处理用户反馈

以下逻辑在用户对输出给出反馈后触发，不是工作流步骤：

1. 「隐喻不太准确」 → 回到 Step 1，重新确认概念的核心矛盾是否理解正确，调整隐喻映射
2. 「这个故事不太好/换一个」 → 回到 Step 3，换一种故事类型和语气重新创作
3. 「太隐晦/太直白」 → 调整三段式结构中揭晓时机的早晚，或增减铺垫篇幅
4. 「故事太长/太短」 → 调整铺垫部分的细节量，不改变核心结构

---

前置判断（写作前触发）

处理多概念请求

以下逻辑在开始写作前判断，决定故事的策略：

• 概念之间存在对比关系 → 可以用一个故事串两个概念（如两个角色分别代表概念 A 和 B，通过不同结局体现差异），但仍然在结尾分别揭晓
• 概念之间无直接关联 → 建议分开讲两个故事
• 不确定时 → 先向用户确认：「这两个概念我用一个对比故事来讲，还是分开讲？」

---

反模式：避免这些写法

以下是常见失败模式，创作时主动避让：

反模式	表现	为什么失败	正确做法
角色傀儡化	角色做出违背自身设定的事来配合隐喻	读者感觉人物「不真实」，故事崩塌	先构思角色的合理动机，再寻找与概念的巧合相似，而非反过来
隐喻过度	每个细节都对应概念，故事像密码本	变成说明书而非故事，失去趣味	只映射核心要素，其余细节为故事的生动性服务
揭晓过早	开头或故事中段就说「这就像 XXX 概念」	毁了悬念，读者不再去「悟」	忍住——让故事自己说完，揭晓部分放在最后
故事空洞	故事本身没有冲突、没有张力	读者记不住——没有情感就没有记忆	确保有明确的困境、选择或转折，让读者关心角色
⚠️ 概念曲解	为让故事好看，歪曲了概念的核心含义	最致命的错误——读者学到了错误的理解	写完故事后自检：如果读者只读故事不读释义，形成的理解是否正确？
⚠️ 隐喻比概念更抽象	用魔法符文解释抽象泄漏、用修仙体系解释设计模式	读者需要先解码隐喻本身，理解门槛不降反升	用「奶奶测试」：隐喻载体换成日常场景（万能遥控器、翻译器出错），确保载体本身不需要解释

降级策略

如果某个概念确实不适合寓言形式（如过于抽象、无实体可类比），不要强行编造：

1. 先尝试找到概念中最具体的那个侧面来写故事

2. 如果实在没有好的故事角度，改用「场景类比」（短比喻而非完整故事）。例如：

   解释「递归」→「就像你站在两面镜子之间，看到的是一层套一层的无限影像——每一层都和前一层一样，只是更小。但总有一个"最小"的你站在最深处，当光线到达那里时，反射开始一层层往回走。这就是递归。」

3. 如果概念太宽泛（如「面向对象编程」），建议用户缩小范围（如「封装」「多态」）

4. 如果找不到用户熟悉的合适场景，诚实告知而非硬编。例如：「这个概念我暂时没想到你熟悉的场景来类比，换一个更日常的场景来讲可以吗？」——用户宁可接受一个不太贴合的常规故事，也不想听一个别扭的强行类比

---

质量准则

每条对应 Step 7 自检的具体检查项：

准则	检验方式
故事先于概念	自检第 3 条：故事是否本身可读？
含蓄但不隐晦	自检第 2 条：核心矛盾是否被精准映射？因果链是否贴合运作机制？
准确但不死板	自检第 1 条：角色行为是否自然？
尊重读者智力	自检第 4 条：揭晓时机是否恰当？
一场故事一个概念	自检第 5 条：有没有多余的隐喻或情节？
隐喻不增门槛	自检第 6 条：隐喻载体是否通过了「奶奶测试」？
解释不引新惑	自检第 7 条：新术语是否都有简要说明？