nanlis 寓言式概念讲解器
把一个概念先藏进故事里，再在结尾把真相轻轻揭开。这个 skill 的目标不是“把术语换成比喻”，而是让读者先感到情境、冲突和代价，最后才意识到：原来故事一直在讲这个概念。
适用场景
当用户说出下面这类需求时，优先使用这个 skill：
- “写一个寓言来讲清楚某个概念”
- “不要直说，绕着讲，最后再揭晓”
- “从某个领域里选一个研究生水平的概念，写成故事”
- “结合高质量信源，把这个概念讲明白”
如果用户只给了一个领域，没有给具体概念，就替他们挑一个最适合寓言表达的概念。优先选那些带有隐藏信息、激励、反馈、阈值、策略互动、传导链条或状态转移的概念，因为这类概念最容易在故事里自然展开。
默认保留用户想要的那种节奏：前面先用故事把读者带进去，直到非常接近结尾时才慢慢露出概念名；在揭示之前，至少先完成一轮完整的情境铺垫和冲突推进。后面再用一小段解释把概念对齐清楚。不要把它写成先讲完定义再讲故事的科普文。
工作流程
1. 先定概念
先判断用户给的是领域还是已经指定了概念。
- 如果概念已经指定，不要改题，只调整讲法。
- 如果只有领域，就从这个领域里挑一个更适合叙事转译的研究生水平概念。
- 选择概念时，优先考虑：
- 结构清晰，但不太基础
- 能用少量角色讲出来
- 能在故事中体现“看不见的机制”
- 有可靠的公开资料可查
如果有多个候选概念，优先选“最容易被权威信源讲清楚”的那个，而不是最花哨的那个。这个 skill 的叙事目标很重要，但信源质量同样重要；两者都要满足时，故事才不会飘。
2. 再找信源
写作前先查 3-5 个高质量来源，优先级如下：
- 原始论文、官方讲座、奖项演讲、机构报告
- 大学课程讲义、教授公开课笔记、教材章节
- 权威综述或百科类机构页面
- 只有在前 3 类都不够时，才考虑高质量媒体的解释性文章
每次都尽量凑齐以下四种信息：
- 一个正式定义
- 一个核心机制或定理
- 一个经典例子
- 一个限制、边界条件或常见误解
如果不同来源对概念的表述略有差异，最终解释里要轻描淡写地指出这种差异，不要假装只有一种说法。若存在“常见直觉”和“严格定义”不一致的情况，优先按严格定义写，故事再去帮助读者理解直觉。
3. 写寓言
故事要像真正的寓言，而不是“套壳的定义题”。
- 前 70% 到 80% 的篇幅不要直接说出概念名
- 用具体的人、动物、物件、规则和后果来推进
- 让读者先看到现象，再慢慢感到背后的机制
- 结尾前再埋一个几乎可以猜到的提示
- 最后几句才完成揭示
故事里最好有这些层次：
- 表层事件：谁在做什么
- 中层冲突：为什么会这样
- 深层机制：这个世界真正的规则是什么
4. 讲解概念
故事后面必须再补一段清楚的解释，结构固定为：
- 这个故事真正讲的是哪个概念
- 故事里的角色、事件分别对应什么形式结构
- 这个概念为什么重要
- 它在现实里通常出现在哪里
这一段要比故事更精确，但不能突然变成论文口吻。目标是“看完故事后，读者能把抽象概念在脑子里搭起来”。
解释段默认短一些，优先做“对齐”和“校准”，不要做长篇综述。它的任务是把读者从寓言里轻轻带回概念本体，而不是重新把整篇内容拉回学术写作。
如果故事足够完整，可以把“概念揭示”压到最后一两句，让读者先有一点“原来如此”的顿悟，再进入解释段。
5. 输出前先做信源笔记
在开始正文前，先在内部整理一份简短的信源笔记。它不一定要完整展示给用户，但会帮助你避免写偏。
至少记下：
- 概念的一句话定义
- 2-3 个关键术语
- 1 个核心机制、定理或经典例子
- 1 个边界条件、限制或常见误解
- 2-4 个可点击来源链接
如果来源之间存在冲突，优先保留最严格、最规范的定义；故事负责帮助理解，不负责篡改概念。
6. 默认输出骨架
如果用户没有指定格式，就按这个骨架写：
- 标题
- 寓言正文
- 概念揭示
- 解释
- 信源
在“信源”部分，把最关键的来源按优先级列出来，并在每条后面写一句它支持了什么：
definition：支持正式定义mechanism：支持核心机制example：支持经典例子caveat：支持边界或限制
这样读者既能跟着故事走，也能很快确认你不是在空讲。
6. 先做信源笔记，再动笔
在正式写故事之前，先把信源整理成一个小笔记，至少包含：
- 概念名和一句话定义
- 2-3 个关键术语
- 1 个能讲成故事的经典机制
- 1 个要避免的误解
- 2-4 个引用链接
这个小笔记不一定要对用户展示，但它会让故事更稳，也方便最后那段解释不跑偏。
7. 保持故事优先
默认把正文写成故事，而不是“讲义 + 故事”的混合体。
- 正文优先用日常词，避免过早抛出术语。
- 术语只在概念揭示时集中出现，别在故事中途反复打断叙事。
- 类比和寓言只能负责“让人懂”，不能抢“它是什么”的位置。
- 如果某个严谨表述会明显削弱故事感，先保留故事，再在解释段补正式说法。
- 参考来源用来校准事实，不要把来源列表写得比故事还长。
输出格式
默认按这个顺序输出：
- 标题
- 寓言正文
- 概念揭示
- 讲解
- 信源
写作风格
- 故事部分：含蓄、具体、有画面感
- 揭示部分：清楚、简洁、准确
- 信源部分：列出可点击链接，尽量来自权威机构或原始文献
- 如果用户要求“更像童话 / 更像黑暗寓言 / 更像学术故事”，就在故事语气上调整，但不要改变最后的解释结构
参考文件
在正式写作前，先读 references/sources.md，再按 references/source-packs.md 里给出的领域示例去找材料。