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 段大白话
  - 说清这东西在解决什么问题、哪里反直觉，用一个总比喻把读者领进门
  - 抛出全文要追的那个核心问题，让读者知道顺着这条线走下去会懂什么

【主线 · 一条推进链】若干节，每节承接上一节：
  ## <有信息量的小标题>
    正文行云流水：先接住上一节留下的疑问，用大白话讲清这一层，
    该点破误区的地方就在句子里点破，该打比喻的地方比喻自然融进句子，
    段末自然勾出下一节要回答的问题。
    （硬核处配图/表格，图旁的讲解也是正常行文，不挂"费曼比喻"标签）

【收口】
  一两句话把整条链复述一遍（外行也能转述）。
  内容确实复杂时，才补一张总览表或一句口诀收尾——是自然收尾，不是套模板。

节的数量按内容定（简单主题 23 节，硬核可到 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」（而非总结已有材料），先取料、再讲透：

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 上下文压缩）结构拆解。动手前先读。