# Parable Concept Explainer

> 把指定领域里的一个研究生水平概念写成“先埋伏笔、后揭示”的寓言故事，并在结尾用清晰解释和高质量互联网信源把概念讲透。Use when the user asks for a fable, parable, indirect story, or delayed-reveal explanation of a concept from a field, especially when they want the answer grounded in authoritative sources.

- Skill: `nanlis/parable-concept-explainer` (Agent Skill, multi-file: 4 files)
- Install (CLI): `npx skillmds@latest add nanlis/parable-concept-explainer`
- Raw SKILL.md: https://api.skillmd.com/api/skills/nanlis/parable-concept-explainer/raw
- Safety review: pending (external: skill-scanner PASS, skillspector PASS)
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: nanlis (https://skillmd.com/u/nanlis)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/nanlis/parable-concept-explainer

---


# 寓言式概念讲解器

把一个概念先藏进故事里，再在结尾把真相轻轻揭开。这个 skill 的目标不是“把术语换成比喻”，而是让读者先感到情境、冲突和代价，最后才意识到：原来故事一直在讲这个概念。

## 适用场景

当用户说出下面这类需求时，优先使用这个 skill：

- “写一个寓言来讲清楚某个概念”
- “不要直说，绕着讲，最后再揭晓”
- “从某个领域里选一个研究生水平的概念，写成故事”
- “结合高质量信源，把这个概念讲明白”

如果用户只给了一个领域，没有给具体概念，就替他们挑一个最适合寓言表达的概念。优先选那些带有隐藏信息、激励、反馈、阈值、策略互动、传导链条或状态转移的概念，因为这类概念最容易在故事里自然展开。

默认保留用户想要的那种节奏：前面先用故事把读者带进去，直到非常接近结尾时才慢慢露出概念名；在揭示之前，至少先完成一轮完整的情境铺垫和冲突推进。后面再用一小段解释把概念对齐清楚。不要把它写成先讲完定义再讲故事的科普文。

## 工作流程

### 1. 先定概念

先判断用户给的是领域还是已经指定了概念。

- 如果概念已经指定，不要改题，只调整讲法。
- 如果只有领域，就从这个领域里挑一个更适合叙事转译的研究生水平概念。
- 选择概念时，优先考虑：
  - 结构清晰，但不太基础
  - 能用少量角色讲出来
  - 能在故事中体现“看不见的机制”
  - 有可靠的公开资料可查

如果有多个候选概念，优先选“最容易被权威信源讲清楚”的那个，而不是最花哨的那个。这个 skill 的叙事目标很重要，但信源质量同样重要；两者都要满足时，故事才不会飘。

### 2. 再找信源

写作前先查 3-5 个高质量来源，优先级如下：

1. 原始论文、官方讲座、奖项演讲、机构报告
2. 大学课程讲义、教授公开课笔记、教材章节
3. 权威综述或百科类机构页面
4. 只有在前 3 类都不够时，才考虑高质量媒体的解释性文章

每次都尽量凑齐以下四种信息：

- 一个正式定义
- 一个核心机制或定理
- 一个经典例子
- 一个限制、边界条件或常见误解

如果不同来源对概念的表述略有差异，最终解释里要轻描淡写地指出这种差异，不要假装只有一种说法。若存在“常见直觉”和“严格定义”不一致的情况，优先按严格定义写，故事再去帮助读者理解直觉。

### 3. 写寓言

故事要像真正的寓言，而不是“套壳的定义题”。

- 前 70% 到 80% 的篇幅不要直接说出概念名
- 用具体的人、动物、物件、规则和后果来推进
- 让读者先看到现象，再慢慢感到背后的机制
- 结尾前再埋一个几乎可以猜到的提示
- 最后几句才完成揭示

故事里最好有这些层次：

- 表层事件：谁在做什么
- 中层冲突：为什么会这样
- 深层机制：这个世界真正的规则是什么

### 4. 讲解概念

故事后面必须再补一段清楚的解释，结构固定为：

- 这个故事真正讲的是哪个概念
- 故事里的角色、事件分别对应什么形式结构
- 这个概念为什么重要
- 它在现实里通常出现在哪里

这一段要比故事更精确，但不能突然变成论文口吻。目标是“看完故事后，读者能把抽象概念在脑子里搭起来”。

解释段默认短一些，优先做“对齐”和“校准”，不要做长篇综述。它的任务是把读者从寓言里轻轻带回概念本体，而不是重新把整篇内容拉回学术写作。

如果故事足够完整，可以把“概念揭示”压到最后一两句，让读者先有一点“原来如此”的顿悟，再进入解释段。

### 5. 输出前先做信源笔记

在开始正文前，先在内部整理一份简短的信源笔记。它不一定要完整展示给用户，但会帮助你避免写偏。

至少记下：

- 概念的一句话定义
- 2-3 个关键术语
- 1 个核心机制、定理或经典例子
- 1 个边界条件、限制或常见误解
- 2-4 个可点击来源链接

如果来源之间存在冲突，优先保留最严格、最规范的定义；故事负责帮助理解，不负责篡改概念。

### 6. 默认输出骨架

如果用户没有指定格式，就按这个骨架写：

1. 标题
2. 寓言正文
3. 概念揭示
4. 解释
5. 信源

在“信源”部分，把最关键的来源按优先级列出来，并在每条后面写一句它支持了什么：

- `definition`：支持正式定义
- `mechanism`：支持核心机制
- `example`：支持经典例子
- `caveat`：支持边界或限制

这样读者既能跟着故事走，也能很快确认你不是在空讲。

### 6. 先做信源笔记，再动笔

在正式写故事之前，先把信源整理成一个小笔记，至少包含：

- 概念名和一句话定义
- 2-3 个关键术语
- 1 个能讲成故事的经典机制
- 1 个要避免的误解
- 2-4 个引用链接

这个小笔记不一定要对用户展示，但它会让故事更稳，也方便最后那段解释不跑偏。

### 7. 保持故事优先

默认把正文写成故事，而不是“讲义 + 故事”的混合体。

- 正文优先用日常词，避免过早抛出术语。
- 术语只在概念揭示时集中出现，别在故事中途反复打断叙事。
- 类比和寓言只能负责“让人懂”，不能抢“它是什么”的位置。
- 如果某个严谨表述会明显削弱故事感，先保留故事，再在解释段补正式说法。
- 参考来源用来校准事实，不要把来源列表写得比故事还长。

## 输出格式

默认按这个顺序输出：

1. 标题
2. 寓言正文
3. 概念揭示
4. 讲解
5. 信源

## 写作风格

- 故事部分：含蓄、具体、有画面感
- 揭示部分：清楚、简洁、准确
- 信源部分：列出可点击链接，尽量来自权威机构或原始文献
- 如果用户要求“更像童话 / 更像黑暗寓言 / 更像学术故事”，就在故事语气上调整，但不要改变最后的解释结构

## 参考文件

在正式写作前，先读 `references/sources.md`，再按 `references/source-packs.md` 里给出的领域示例去找材料。