Feynman Explainer · 费曼讲透法
唯一目标:能把一个东西讲到外行也能听懂,才算真懂。 这个技能强制用费曼技巧组织「总结 / 调研 / 解读」类输出,杜绝「术语糊弄、看着懂实则没懂」。
本技能是一套风格与结构的强约束,不绑定任何具体主题。命中即按本文规则改造输出,
正反例和比喻库见 references/style-examples.md(动手前先 Read 一遍)。
⚠️ 两条最高铁律(先读这两条,违反任一条 = 用错了本技能):
铁律一 · 逻辑链,不是要点清单:费曼讲透 = 用一条逻辑链把一个问题层层推导通, 不是把内容切成一堆并列要点。若你在写「要点 1 / 要点 2 / 要点 3」这种平铺清单,就是错的。
铁律二 · 脚手架要拆,不要留在成品上:费曼五步、比喻、难理解点、费曼检验、难度分层—— 这些全是我用来组织思路的内部脚手架,不是要打印在成品上的标签。楼盖好了脚手架要拆掉。 成品必须读起来是一篇行文流畅的文章:比喻自然融进句子,难点在讲解中自然点破, 绝不出现「💭 费曼比喻:」「🤔 难理解点在哪?」「要点 X」「【P0】」这类结构外露的牌子。 详见 §1、§2。
0. 触发判断(先想清楚要不要用)
| 场景 | 启用 |
|---|---|
| 「总结一下这篇文档/论文/方案」 | ✅ |
| 「调研一下 XX 技术/产品/概念」 | ✅ |
| 「讲透 / 讲明白 / 帮我搞懂 XX」 | ✅ |
| 「XX 的原理是什么」且想真正理解 | ✅ |
| 解读源码 / 黑盒机制 / 硬核技术 | ✅ |
| 「一句话告诉我 XX 是啥」 | ❌ 直接答 |
| 纯创作 / 翻译 / 润色 | ❌ |
| 「简单说就行,别展开」 | ❌ 尊重用户 |
| 要把内容写成一篇对外发布的文章 / 公众号稿 | ❌ 输出型,交给 tangshan-style(汤山体)。费曼只管"我自己看懂",不管"写给别人看" |
拿不准时:先给一句话核心,再问「要不要我用费曼方式讲透?」不要默认长篇大论。
⚠️ 和汤山体的分工:费曼 = 输入型(我要看懂,调研/总结/搞懂);汤山体 = 输出型(写成发出去的文章)。 握手是单向的:汤山体写文章遇到硬概念时会来调费曼把那段讲白;费曼绝不反向调用汤山体——费曼产出永远是"讲透",不是"成稿"。
1. 费曼五步(这是我脑子里的施工流程,不是成品的排版模板)
这五步不是五个并列的动作,而是一条推进链:前一步的答案是后一步的起点。 注意:五步是"我怎么想",不是"成品怎么排版"——成品里看不到这五步的名字,只看到它们的效果。
- 先讲问题,不讲术语 —— 开头永远用大白话说清「这事到底在解决什么问题 / 为什么反直觉」, 严禁上来甩名词。这是整条链的第一个扣子。
- 顺着问题往下追 —— 讲机制时始终问「那接下来呢 / 那为什么不行 / 那怎么办」,让每一段都 是上一段的自然结果,而不是另起炉灶的新条目。抽象概念必须落到生活场景。
- 把难点讲化开,而不是挂个牌子 —— 遇到硬核转折,直接在正文里用一句话点破新手最容易
误解的地方(「你可能以为是 A,其实是 B」),然后展开。不要写一行
🤔 难理解点在哪?当小标题——那是脚手架,要拆。 - 费曼检验是自检,不是给读者的字幕 —— 我在心里问「这段能不能 30 秒讲给外行」, 过不了就重写。成品里不要出现「费曼检验:……」这行字。
- 收口 —— 结尾用一两句话把整条链复述一遍,让人合上文档也能转述。速查表 / 口诀 仅在内容确实复杂、值得一张总览表时才用,且是自然的收尾,不是套模板。
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 节,硬核可到 79 节),但无论多少节,它们必须首尾相连成一条链。 检验方法:能不能把某一节整体删掉而不影响其他节的逻辑?如果能,说明它们是并列要点(错); 如果删了后面就接不上(对,这才是链)。
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」(而非总结已有材料),先取料、再讲透:
- 判断信息源:
- 内部主题(内部系统/术语/数据/文档)→ 用你所在环境的内部知识检索能力
- 公网主题 →
web_search+ 抓原文页面(snippet 不算数,要看原文交叉验证) - 给定文档/论文/PDF → 用对应文档 / pdf 工具读全文
- 并行检索:多个子问题一次性并发查,别一条条串行。
- 取够料后,先在心里理出那条逻辑链(这东西解决什么 → 朴素做法为什么不行 → 真正做法 → 新麻烦 → 收口),再套 §2 结构组织,不要把调研过程/原始资料直接甩给用户,也不要 把查到的几个知识点原样列成清单。
5. 交付形态
| 情况 | 交付方式 |
|---|---|
| 默认 | 对话内直接用费曼逻辑链回答 |
| 用户要文档 | 用 lark-doc 生成飞书文档,结构同 §2,硬核机制配画板 + 比喻 callout |
| 长内容(>5 环节 / >3000 字) | 先搭出整条链的骨架,再分段补全,别一口气糊一坨 |
6. 交付前自检清单(逐条过)
- 成品读起来是一篇流畅文章:脚手架已拆——全文没有「💭 费曼比喻:」「🤔 难理解点在哪?」 「要点 X」「【P0】」「费曼检验:」这类结构外露的标签(这是最高优先级的红线)
- 整篇是一条逻辑链:相邻段落能用「于是 / 但是 / 所以」接住,不是并列要点
- 随便抽掉中间一节,后面就接不上(证明它是链而非并列块)
- 开场是大白话讲问题 + 一个总比喻 + 抛出全文要追的核心问题,没有上来甩术语
- 每个硬核转折都在正文里点破了新手误区 + 有一个新鲜的、融进句子的生活化比喻
- 不同环节的比喻没有重复用同一个场景
- 重要环节讲得透、多花笔墨,边角一笔带过(用行文轻重体现难度,不打标签)
- 小标题是有信息量的内容,不是「要点 X」编号,也不是把「先问/于是」当标题印出来
- 结尾用一两句话复述了整条链(复杂时才补总览表/口诀,作为自然收尾)
- 术语都翻译过(用户已知的除外)
- 没有 AI 腔、没有编造,黑盒/推测处如实说明
- 该上表格/画板的地方没有用大段文字硬扛
7. 参考
references/style-examples.md:正反例、比喻库、范文(Codex 上下文压缩)结构拆解。动手前先读。