Menu
当用户说「用故事解释」「讲个寓言」「打个比方」「通俗理解」某个概念时触发。用寓言故事诠释抽象概念，故事中不出现学名，结尾才揭晓。
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
| name | concept-fable |
| description | 当用户说「用故事解释」「讲个寓言」「打个比方」「通俗理解」某个概念时触发。用寓言故事诠释抽象概念，故事中不出现学名，结尾才揭晓。 |
当用户想理解一个抽象概念时，不直接抛出教科书定义，而是创作一篇精心设计的寓言故事。读者沉浸其中，在临近结尾时才恍然大悟，然后附上专业释义。
核心原则：用故事让人"悟到"，而不是用定义让人"记住"。
按以下 8 步执行：
核心要素与隐喻点的关系：每个核心要素必须有一个对应的隐喻点来映射它（这是底线）。额外的隐喻点（共 3-5 个，含 ≥2 个核心映射）用于丰富故事细节，但不能喧宾夺主。简单来说：核心要素 = 必须映射的（≥2 个），隐喻点总量 3-5 个。
以下情况需向用户确认：
确认概念理解：「这个概念我理解为 ______，核心要点是 ______，对吗？」
确认场景偏好——先判断概念本身，再决定是否问用户：
故事类型——根据概念的核心特征选择：
选择标准：
叙事语气——根据概念的情感色彩选择：
| 概念的情感色彩 | 推荐语气 | 示例场景 |
|---|---|---|
| 告诫/警示（如技术债务、死锁） | 沉稳、略带惋惜 | 说书人风格，娓娓道来 |
| 揭示/反直觉（如抽象泄漏、幸存者偏差） | 轻快、有反转感 | 像在讲一个"你猜怎么着"的故事 |
| 权衡/两难（如 CAP 定理） | 中立、不偏袒 | 平实叙述，让读者自己判断 |
| 机制/原理（如依赖注入） | 日常、接地气 | 生活化口吻，拉近距离 |
简单概念豁免：对于「什么是变量」「什么是循环」等基础概念，默认用日常接地气语气，不必逐条对照上表。表格主要用于需要情感引导的复杂/抽象概念。
动笔之前，验证所选故事类型的冲突结构是否能忠实复现 Step 1 中写下的因果链：
三段式结构：
写作原则：
隐喻具象化原则（硬性要求）：
隐喻载体必须是读者日常生活能直接感知的事物，遵守「奶奶测试」：
你的隐喻载体，你奶奶能不能一句话听懂是什么？ 能 → 可以用 不能 → 换一个
---
## 专业释义
### 【概念名】
**一句话定义：** [精准概括]
**为什么这个概念重要：** [1-2 句说明实际意义]
**核心要点：**
1. [是什么]
2. [为什么产生 / 为什么会这样]
3. [如何应对 / 如何应用]
**故事中的对应：**
| 故事元素 | 概念对应 |
|----------|---------|
| [角色/事件] | [概念要素] |
| [转折点] | [核心机制] |
**前置知识：** [如果释义中用了读者可能不熟悉的术语（如用「带宽」解释网络延迟时，顺带说明带宽是什么），在此处用 1-2 句简要说明。没有则省略此行。]
**延伸思考：** [1-2 句引导思考]
**故事续写（可选）：** [如果概念有天然紧密关联的概念（如 死锁→死锁预防、npm→依赖地狱），释义结束后用 2-3 句续写故事，引出关联概念。只给一句话定义，不展开完整释义。结尾问「需要展开讲吗？」。没有紧密关联概念则跳过。]
写完释义主体后，主动检查是否存在紧密关联的概念（问题→解决方案、工具→常见坑、现象→相邻现象），如果有，务必续写 2-3 句引出——这是 Skill 最有效的钩子之一，不要跳过。
续写约束：
故事写完后，逐条审视。最多重写 2 次，仍不通过则输出当前最佳版本，并诚实告知用户哪里不够满意：
概念寓言-{概念名}.md以下逻辑在用户对输出给出反馈后触发，不是工作流步骤：
以下逻辑在开始写作前判断，决定故事的策略：
以下是常见失败模式，创作时主动避让：
| 反模式 | 表现 | 为什么失败 | 正确做法 |
|---|---|---|---|
| 角色傀儡化 | 角色做出违背自身设定的事来配合隐喻 | 读者感觉人物「不真实」，故事崩塌 | 先构思角色的合理动机，再寻找与概念的巧合相似，而非反过来 |
| 隐喻过度 | 每个细节都对应概念，故事像密码本 | 变成说明书而非故事，失去趣味 | 只映射核心要素，其余细节为故事的生动性服务 |
| 揭晓过早 | 开头或故事中段就说「这就像 XXX 概念」 | 毁了悬念，读者不再去「悟」 | 忍住——让故事自己说完，揭晓部分放在最后 |
| 故事空洞 | 故事本身没有冲突、没有张力 | 读者记不住——没有情感就没有记忆 | 确保有明确的困境、选择或转折，让读者关心角色 |
| ⚠️ 概念曲解 | 为让故事好看，歪曲了概念的核心含义 | 最致命的错误——读者学到了错误的理解 | 写完故事后自检：如果读者只读故事不读释义，形成的理解是否正确？ |
| ⚠️ 隐喻比概念更抽象 | 用魔法符文解释抽象泄漏、用修仙体系解释设计模式 | 读者需要先解码隐喻本身，理解门槛不降反升 | 用「奶奶测试」：隐喻载体换成日常场景（万能遥控器、翻译器出错），确保载体本身不需要解释 |
如果某个概念确实不适合寓言形式（如过于抽象、无实体可类比），不要强行编造：
先尝试找到概念中最具体的那个侧面来写故事
如果实在没有好的故事角度，改用「场景类比」（短比喻而非完整故事）。例如：
解释「递归」→「就像你站在两面镜子之间，看到的是一层套一层的无限影像——每一层都和前一层一样，只是更小。但总有一个"最小"的你站在最深处，当光线到达那里时，反射开始一层层往回走。这就是递归。」
如果概念太宽泛（如「面向对象编程」），建议用户缩小范围（如「封装」「多态」）
如果找不到用户熟悉的合适场景，诚实告知而非硬编。例如：「这个概念我暂时没想到你熟悉的场景来类比，换一个更日常的场景来讲可以吗？」——用户宁可接受一个不太贴合的常规故事，也不想听一个别扭的强行类比
每条对应 Step 7 自检的具体检查项：
| 准则 | 检验方式 |
|---|---|
| 故事先于概念 | 自检第 3 条：故事是否本身可读？ |
| 含蓄但不隐晦 | 自检第 2 条：核心矛盾是否被精准映射？因果链是否贴合运作机制？ |
| 准确但不死板 | 自检第 1 条：角色行为是否自然？ |
| 尊重读者智力 | 自检第 4 条：揭晓时机是否恰当？ |
| 一场故事一个概念 | 自检第 5 条：有没有多余的隐喻或情节？ |
| 隐喻不增门槛 | 自检第 6 条：隐喻载体是否通过了「奶奶测试」？ |
| 解释不引新惑 | 自检第 7 条：新术语是否都有简要说明？ |