# Feynman Explainer > 用费曼技巧把复杂的东西「讲透」。核心是用一条「问题→为什么→于是→但是→所以」的逻辑链把主题层层推导讲通，而不是拆成互不相干的「要点1/要点2」清单。把大白话、生活化比喻、点破难点、费曼自检这套方法内化成流畅行文让外行也能懂——脚手架只用来组织思路，绝不把「费曼比喻/难理解点/要点X/P0」这类标签印在成品上。当用户说「总结/调研/讲透/搞懂 XX」「XX 原理是什么」并希望真正理解（而非一句话带过）时触发，也适用于解读文档、论文、源码、技术方案、产品机制。触发词：费曼、讲透、讲明白、总结、调研、搞懂、通俗解释、深入浅出。DO NOT USE WHEN: 只要一句话快答、纯创作/翻译/润色、或明确说「简单说别展开」；要写对外发布的文章/公众号稿（输出型，交给 tangshan-style 汤山体）。 - Skill: `job-yang/feynman-explainer` (Agent Skill, multi-file: 4 files) - Install (CLI): `npx skillmds@latest add job-yang/feynman-explainer` - Raw SKILL.md: https://api.skillmd.com/api/skills/job-yang/feynman-explainer/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: Job-Yang (https://skillmd.com/u/job-yang) - Updated: 2026-09-22 - Page: https://skillmd.com/skills/job-yang/feynman-explainer --- # Feynman Explainer · 费曼讲透法 > **唯一目标**：能把一个东西讲到外行也能听懂，才算真懂。 > 这个技能强制用费曼技巧组织「总结 / 调研 / 解读」类输出，杜绝「术语糊弄、看着懂实则没懂」。 本技能是一套**风格与结构的强约束**，不绑定任何具体主题。命中即按本文规则改造输出， 正反例和比喻库见 `references/style-examples.md`（动手前先 Read 一遍）。 > ⚠️ **两条最高铁律（先读这两条，违反任一条 = 用错了本技能）**： > > **铁律一 · 逻辑链，不是要点清单**：费曼讲透 = 用一条逻辑链把一个问题层层推导通， > 不是把内容切成一堆并列要点。若你在写「要点 1 / 要点 2 / 要点 3」这种平铺清单，就是错的。 > > **铁律二 · 脚手架要拆，不要留在成品上**：费曼五步、比喻、难理解点、费曼检验、难度分层—— > 这些全是**我用来组织思路的内部脚手架，不是要打印在成品上的标签**。楼盖好了脚手架要拆掉。 > 成品必须读起来是**一篇行文流畅的文章**：比喻自然融进句子，难点在讲解中自然点破， > **绝不出现**「💭 费曼比喻：」「🤔 难理解点在哪？」「要点 X」「【P0】」这类结构外露的牌子。 > 详见 §1、§2。 --- ## 0. 触发判断（先想清楚要不要用） | 场景 | 启用 | |------|------| | 「总结一下这篇文档/论文/方案」 | ✅ | | 「调研一下 XX 技术/产品/概念」 | ✅ | | 「讲透 / 讲明白 / 帮我搞懂 XX」 | ✅ | | 「XX 的原理是什么」且想真正理解 | ✅ | | 解读源码 / 黑盒机制 / 硬核技术 | ✅ | | 「一句话告诉我 XX 是啥」 | ❌ 直接答 | | 纯创作 / 翻译 / 润色 | ❌ | | 「简单说就行，别展开」 | ❌ 尊重用户 | | **要把内容写成一篇对外发布的文章 / 公众号稿** | ❌ **输出型，交给 `tangshan-style`（汤山体）**。费曼只管"我自己看懂"，不管"写给别人看" | > 拿不准时：先给一句话核心，再问「要不要我用费曼方式讲透？」不要默认长篇大论。 > > ⚠️ **和汤山体的分工**：费曼 = 输入型（我要看懂，调研/总结/搞懂）；汤山体 = 输出型（写成发出去的文章）。 > 握手是**单向**的：汤山体写文章遇到硬概念时会来调费曼把那段讲白；**费曼绝不反向调用汤山体**——费曼产出永远是"讲透"，不是"成稿"。 --- ## 1. 费曼五步（这是我脑子里的施工流程，不是成品的排版模板） 这五步**不是五个并列的动作，而是一条推进链**：前一步的答案是后一步的起点。 **注意：五步是"我怎么想"，不是"成品怎么排版"——成品里看不到这五步的名字，只看到它们的效果。** 1. **先讲问题，不讲术语** —— 开头永远用大白话说清「这事到底在解决什么问题 / 为什么反直觉」， 严禁上来甩名词。这是整条链的**第一个扣子**。 2. **顺着问题往下追** —— 讲机制时始终问「那接下来呢 / 那为什么不行 / 那怎么办」，让每一段都 是上一段的**自然结果**，而不是另起炉灶的新条目。抽象概念必须落到生活场景。 3. **把难点讲化开，而不是挂个牌子** —— 遇到硬核转折，直接在正文里用一句话点破新手最容易 误解的地方（「你可能以为是 A，其实是 B」），然后展开。**不要**写一行 `🤔 难理解点在哪？` 当小标题——那是脚手架，要拆。 4. **费曼检验是自检，不是给读者的字幕** —— 我在心里问「这段能不能 30 秒讲给外行」， 过不了就重写。**成品里不要出现「费曼检验：……」这行字**。 5. **收口** —— 结尾用一两句话把整条链复述一遍，让人合上文档也能转述。速查表 / 口诀 仅在内容确实复杂、值得一张总览表时才用，且是自然的收尾，不是套模板。 --- ## 2. 标准输出结构：逻辑链，不是要点清单（强制套用） ### 2.1 核心原则：讲一条链，不摆一堆点 **费曼讲透的骨架是一条因果推导链，不是并列的知识条目。** 一个主题应该像剥洋葱、 像追问一个侦探问题那样，一层推出下一层： ``` 这东西想解决什么问题？ → 最朴素的做法是什么？为什么它不够用？ （制造张力） → 于是真正的做法是什么？它怎么解决了上面的问题？ （给出机制） → 但这么做又带来什么新麻烦 / 反直觉的地方？ （深入） → 所以最终是怎么收口的？我该记住什么？ （闭环） ``` **每一段都要接得住上一段**：上一段抛出的疑问，正是这一段要回答的；这一段讲完又自然 勾出下一段的疑问。读者是被一根线**牵着往前走**，而不是被丢进一个有 7 个抽屉的柜子里 自己乱翻。 ### 2.2 反面模式（一旦出现就是写错了） ❌ **要点平铺**：把主题拆成「要点 1 / 要点 2 / 要点 3……」，每个要点各讲各的、互不咬合， 读者读完记住 7 个孤立的知识块，却说不出它们之间是什么关系。**这是本技能明令禁止的模式。** ❌ **清单式总结**：`XX 有以下几个特点：1. …… 2. …… 3. ……` —— 这是词条，不是讲透。 ❌ **脚手架外露**：把「💭 费曼比喻：」「🤔 难理解点在哪？」「要点 X」「【P0】」「费曼检验：」 这些**组织工具本身当排版元素印在成品上**。读者不需要看到我的施工方法，只需要读到一篇顺的文章。 比喻要**化进句子**（「这就像你把保险箱密码念给了陌生人」），而不是挂一个「费曼比喻」的牌子再说。 > 判断标准：把你写的相邻两段之间加一句「那……呢？」或「于是……」，如果读着别扭、接不上， > 说明它们只是并列条目，没有构成逻辑链，**必须重写**。 ### 2.3 脚手架 vs 成品（这是本技能的关键区分） | 脚手架（我脑子里用来组织，**不上成品**） | 成品里应该长成什么样 | |------|------| | 「难理解点在哪？」这一步 | 正文里一句自然的话点破误区：「很多人以为泄露和劫持是一回事，其实前者攻内容、后者攻控制流。」 | | 「费曼比喻」这一步 | 比喻直接写进句子：「泄露型就像哄保险箱把密码念出来。」不写「💭 费曼比喻：」 | | 「费曼检验」这一步 | 我自己默默检查过就行，成品不留字幕 | | 「难度标签 P0/P1」 | 用行文轻重体现：命脉的地方讲透、多花笔墨；边角的地方一笔带过。**不打标签** | | 「要点 1 / 要点 2」编号 | 用**有信息量的小标题**或直接用过渡句串联，标题是内容不是序号 | ### 2.4 推荐骨架（一篇流畅文章的样子） 标题**是有内容的短语或问句**（例如「泄露与劫持:同一个漏洞的两张脸」）， 不要用「要点 X」这种编号壳子，也不要把「先问/于是/但是」这类连接词直接当标题印出来 （那些是段落间的过渡逻辑，写进行文里，不是当标签挂）： ``` 【开场】1~2 段大白话 - 说清这东西在解决什么问题、哪里反直觉，用一个总比喻把读者领进门 - 抛出全文要追的那个核心问题，让读者知道顺着这条线走下去会懂什么 【主线 · 一条推进链】若干节，每节承接上一节： ## <有信息量的小标题> 正文行云流水：先接住上一节留下的疑问，用大白话讲清这一层， 该点破误区的地方就在句子里点破，该打比喻的地方比喻自然融进句子， 段末自然勾出下一节要回答的问题。 （硬核处配图/表格，图旁的讲解也是正常行文，不挂"费曼比喻"标签） 【收口】 一两句话把整条链复述一遍（外行也能转述）。 内容确实复杂时，才补一张总览表或一句口诀收尾——是自然收尾，不是套模板。 ``` > 节的数量按内容定（简单主题 2~3 节，硬核可到 7~9 节），但**无论多少节，它们必须首尾相连成一条链**。 > 检验方法：能不能把某一节整体删掉而不影响其他节的逻辑？如果能，说明它们是并列要点（错）； > 如果删了后面就接不上（对，这才是链）。 --- ## 3. 风格硬约束（违反任一条 = 不合格） > **写完后调用 `haohao-shuohua` 轻档做 lint**。费曼产出通常是长文，容易掺入 AI 腔（后缀病、名词化、破折号泛滥、段末打钉）。写完让 haohao-shuohua 轻档扫一遍，只挑最刺眼的改，不动费曼的骨架。 > **例外**：费曼的比喻是命根子（§3.2），不受 haohao-shuohua「比喻红线」约束——haohao-shuohua 已在自己的比喻红线里明确豁免费曼场景。费曼的过渡词「那么/于是/但是/所以」也不受 haohao-shuohua「反车轱辘话」的过渡句删除规则约束，是逻辑链的关节。 ### 3.1 语言风格 - **禁止 AI 腔**：不堆砌排比、不浮夸、不空话套话。像老朋友坐你对面把一件事掰扯明白。 - **术语即翻译**：任何术语第一次出现，紧跟一句大白话解释它「干嘛用的」。 - 例外：用户已知的术语不必解释（如已知用户懂 AST，就别解释 AST）。 - **短句优先**：能一句说清不写三句；少用从句套从句。 - **段落之间要有连接词**：多用「那么 / 于是 / 但问题是 / 所以 / 这就带来一个新麻烦」， 让逻辑链的关节显式露出来。禁止段与段之间毫无过渡地硬切。 ### 3.2 比喻规则（这是费曼的命根子） - **每个硬核转折至少一个比喻**，且**不同环节换不同生活场景**，不要全程一个比喻用到底。 - 比喻要能**承载机制**，不是装饰。好比喻能让读者自己推导出下一步。 - **比喻直接写进正文句子**（「泄露型就像哄保险箱把密码念出来」），**不要**单独挂一个 「💭 费曼比喻：」的标签块再说——那是脚手架外露（见 §2.2、§2.3）。 - 常用素材池（可扩展）：开车/加油、搬家打包、装修房子、印刷厂排版、保险箱与钥匙、 便利贴 vs 保险箱、米其林菜谱 vs 厨房、神庙的柱子与地基、工作日记。 - 复杂关系（多方对比、流程、层级）可以用「一个延展比喻」贯穿一节（如「三家搬家公司」 对应三条路径），但跨节要换。 ### 3.3 诚实约束 - **承认黑盒**：讲不清的、资料没有的，老实说「这块是黑盒 / 没查到」，**绝不编造**。 - **区分事实与推测**：作者/资料的确定结论 vs 合理假设，要分开说（「这是确证的」/「这是几个合理猜测」）。 - 引用外部资料时按平台规则内联引用 `[[标题]](url)`。 ### 3.4 可视化优先 - 能用表格说清的对比（≥3 项 × ≥2 维度），不写大段文字。 - 涉及流程 / 层级 / 架构 / 时序，优先配图（mermaid / plantuml 画板）。**画图正好能体现逻辑链的 推进方向**（用箭头串起来），比并列要点更适合费曼。 - 出飞书文档时，硬核机制每张图旁配一段讲解——这段讲解是**正常行文**（自然把比喻融进去）， 不是挂一个「费曼比喻」标签块。 --- ## 4. 调研类任务的前置动作 当任务是「调研 XX」（而非总结已有材料），先取料、再讲透： 1. **判断信息源**： - 内部主题（内部系统/术语/数据/文档）→ 用你所在环境的内部知识检索能力 - 公网主题 → `web_search` + 抓原文页面（snippet 不算数，要看原文交叉验证） - 给定文档/论文/PDF → 用对应文档 / pdf 工具读全文 2. **并行检索**：多个子问题一次性并发查，别一条条串行。 3. 取够料后，**先在心里理出那条逻辑链**（这东西解决什么 → 朴素做法为什么不行 → 真正做法 → 新麻烦 → 收口），再套 §2 结构组织，**不要把调研过程/原始资料直接甩给用户**，也不要 把查到的几个知识点原样列成清单。 --- ## 5. 交付形态 | 情况 | 交付方式 | |------|---------| | 默认 | 对话内直接用费曼逻辑链回答 | | 用户要文档 | 用 `lark-doc` 生成飞书文档，结构同 §2，硬核机制配画板 + 比喻 callout | | 长内容（>5 环节 / >3000 字）| 先搭出整条链的骨架，再分段补全，别一口气糊一坨 | --- ## 6. 交付前自检清单（逐条过） - [ ] **成品读起来是一篇流畅文章**：脚手架已拆——全文没有「💭 费曼比喻：」「🤔 难理解点在哪？」 「要点 X」「【P0】」「费曼检验：」这类结构外露的标签（这是最高优先级的红线） - [ ] **整篇是一条逻辑链**：相邻段落能用「于是 / 但是 / 所以」接住，不是并列要点 - [ ] 随便抽掉中间一节，后面就接不上（证明它是链而非并列块） - [ ] 开场是大白话讲问题 + 一个总比喻 + 抛出全文要追的核心问题，没有上来甩术语 - [ ] 每个硬核转折都在正文里点破了新手误区 + 有一个**新鲜**的、融进句子的生活化比喻 - [ ] 不同环节的比喻没有重复用同一个场景 - [ ] 重要环节讲得透、多花笔墨，边角一笔带过（用行文轻重体现难度，不打标签） - [ ] 小标题是有信息量的内容，不是「要点 X」编号，也不是把「先问/于是」当标题印出来 - [ ] 结尾用一两句话复述了整条链（复杂时才补总览表/口诀，作为自然收尾） - [ ] 术语都翻译过（用户已知的除外） - [ ] 没有 AI 腔、没有编造，黑盒/推测处如实说明 - [ ] 该上表格/画板的地方没有用大段文字硬扛 --- ## 7. 参考 - `references/style-examples.md`：正反例、比喻库、范文（Codex 上下文压缩）结构拆解。动手前先读。