Menü
当用户说「用故事解释」「讲个寓言」「打个比方」「通俗理解」某个概念时触发。用寓言故事诠释抽象概念，故事中不出现学名，结尾才揭晓。
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Basierend auf der SOC-Berufsklassifikation
| 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 条：新术语是否都有简要说明？ |