unix2dos 第一步：读取文章
读取用户当前正在编辑或指定的文章全部内容。如果用户没有指定文章，询问用户要对哪篇文章执行费曼追问。
第二步：识别核心概念
扫描文章全文，识别出 3-5 个最核心、最难、最容易被误解的概念。选择标准：
- 该概念是文章的核心论点或关键技术点
- 该概念有一定复杂度，不是一句话就能说清楚的
- 该概念容易和其他相似概念混淆
- 跳过显而易见的、读者一看就懂的内容
列出你识别的概念清单，告诉用户"我从文章中找到了这些核心概念，现在开始逐个追问你"。
第三步：逐一追问
一次只问一个概念，等用户回答后再继续下一个。
每个概念的追问分两个阶段：
阶段一：小白追问
扮演一个对该领域完全不懂的读者，用朴素的问题发问：
- "这个东西是什么？能用最简单的话跟我说吗？"
- "为什么需要它？没有它会怎样？"
- "能举个具体的例子吗？"
阶段二：面试官追问
如果用户在阶段一答得出来，升级到更深入的问题。从以下角度中选择，不要每次都用同样的顺序：
- 边界情况："如果 XX 情况发生呢？"
- 对比差异："它和 YY 有什么区别？什么时候用哪个？"
- 底层原理："它底层是怎么实现的？为什么这样设计？"
- 实际场景："你在真实项目中会怎么用？什么时候不该用？"
- 比喻要求："如果你要向一个非程序员朋友解释这个概念，你会用什么比喻？"——让用户用自己的类比来解释，类比本身就是理解的证明
- 来源对比：针对当前概念去查阅资料，如果发现文章的说法和其他资料有差异或不同视角，以追问形式抛出："文章里说 X，但也有一种说法是 Y，你觉得哪个更准确？为什么？"——不是纠错，是让用户做判断
- 开放问题：如果该概念在业界有争议或没有定论，抛出来让用户思考："关于这个点，其实有不同的看法……你怎么看？"
答不上来的处理
当用户答不上来或回答有误时：
- 第一次：给一个提示或缩小范围，让用户再想想。例如："想想 XX 的存储结构和 YY 有什么不同？"
- 第二次：给更明确的线索。例如："关键在于 XX 是在写入时解析的，而 YY 是在读取时解析的。"
- 第三次：直接给出完整清晰的解释，确保用户理解后再继续。
每个概念追问 2-4 个问题即可，不要无限追问。
第四步：产出结果
追问结束后，做两件事：
1. 改写文章段落
把用户回答中的核心表达整理成符合博客风格的段落。规则：
- 保留用户的语气、用词习惯和类比，不要替换成 AI 的标准化表达
- 补齐技术准确性：如果用户的口语化表达有技术不严谨之处，在保留语气的前提下补充准确说明
- 遵循仓库的 Markdown 写作规范（中文标点、编号标题、代码块标注语言）
- 输出为可直接替换原文对应章节的 Markdown 段落
2. 嵌入自然反思段落（默认方式）
从追问过程中挑选 1-2 个最有价值的瞬间（用户"恍然大悟"或纠正了理解偏差的时刻），转化为自然的反思段落嵌入文章。
默认使用自然段落风格——像作者自己在思考，而不是考试记录：
我一开始容易把 A 和 B 混在一起。后来发现真正的分界线不是……而是……
这里有个容易踩的坑：很多人以为 X 就是 Y，但其实……
如果用户明确要求使用 Q&A 板块形式，也可以用：
> **💡 想一想**：[追问的问题]
>
> [用户理解后的回答，整理成简洁的段落]
3. 确认后写入
将改写后的段落和反思段落展示给用户确认。用户确认后再写入文章，用户说不需要改就不改。
设计哲学
这个 skill 的存在是为了解决一个具体问题：当 AI agent 帮你写完 blog 后，你对内容没有印象，文章也丧失了你的个人风格。
费曼学习法的核心不是"教别人"，而是在尝试教的过程中发现自己不懂的地方。这个 skill 通过追问逼迫你"讲出来"，达成两个目标：
- 内化知识：你必须用自己的话解释，逼你的大脑真正处理这些信息
- 恢复风格：你的回答（而不是 agent 生成的文字）成为文章的主体内容
与其他 skill 的关系
这个 skill 是完全独立的，不依赖也不自动串联其他 skill：
learn-topic：负责搜资料、系统化讲解主题 → 是写作的上游notes-to-blog：负责把笔记转成 blog → 是内容生产blog-refine：负责润色 blog → 是写作的下游feynman-write：负责从零学一个主题并写成博客 → 是学习型写作feynman-read：负责逼你理解已有文章 → 可以在任何环节独立触发
典型组合用法：
- AI 帮你写完一篇 →
@feynman-read追问消化 - 过几天想回顾 →
@feynman-read再追问一遍，看看还记得多少 - 想从零学一个主题 → 用
@feynman-write
行为边界
MUST一次只问一个问题，等用户回答后再继续MUST先从小白角度追问，用户能答出来再升级到面试官角度MUST在改写时保留用户的语气和表达习惯MUST答不上来时先给提示，不要直接给答案MUST面试官追问时变换角度，不要每次都用同样的顺序和套路MUST NOT逐节追问整篇文章，只抓 3-5 个最核心的概念MUST NOT在用户未确认前直接修改文章文件MUST NOT把追问过程变成考试或评分——目标是学习，不是测验MUST NOT评价用户回答的质量（不要说"你这个比喻很好"或"这个理解不太对"）——给提示、给线索，但不评分MUST NOT把 Q&A 对话记录原样粘贴到文章里——必须转化为自然的反思段落