feynman-read

第一步：读取文章

读取用户当前正在编辑或指定的文章全部内容。如果用户没有指定文章，询问用户要对哪篇文章执行费曼追问。

第二步：识别核心概念

扫描文章全文，识别出 3-5 个最核心、最难、最容易被误解的概念。选择标准：

• 该概念是文章的核心论点或关键技术点
• 该概念有一定复杂度，不是一句话就能说清楚的
• 该概念容易和其他相似概念混淆
• 跳过显而易见的、读者一看就懂的内容

列出你识别的概念清单，告诉用户"我从文章中找到了这些核心概念，现在开始逐个追问你"。

第三步：逐一追问

一次只问一个概念，等用户回答后再继续下一个。

每个概念的追问分两个阶段：

阶段一：小白追问

扮演一个对该领域完全不懂的读者，用朴素的问题发问：

• "这个东西是什么？能用最简单的话跟我说吗？"
• "为什么需要它？没有它会怎样？"
• "能举个具体的例子吗？"

阶段二：面试官追问

如果用户在阶段一答得出来，升级到更深入的问题。从以下角度中选择，不要每次都用同样的顺序：

• 边界情况："如果 XX 情况发生呢？"
• 对比差异："它和 YY 有什么区别？什么时候用哪个？"
• 底层原理："它底层是怎么实现的？为什么这样设计？"
• 实际场景："你在真实项目中会怎么用？什么时候不该用？"
• 比喻要求："如果你要向一个非程序员朋友解释这个概念，你会用什么比喻？"——让用户用自己的类比来解释，类比本身就是理解的证明
• 来源对比：针对当前概念去查阅资料，如果发现文章的说法和其他资料有差异或不同视角，以追问形式抛出："文章里说 X，但也有一种说法是 Y，你觉得哪个更准确？为什么？"——不是纠错，是让用户做判断
• 开放问题：如果该概念在业界有争议或没有定论，抛出来让用户思考："关于这个点，其实有不同的看法……你怎么看？"

答不上来的处理

当用户答不上来或回答有误时：

1. 第一次：给一个提示或缩小范围，让用户再想想。例如："想想 XX 的存储结构和 YY 有什么不同？"
2. 第二次：给更明确的线索。例如："关键在于 XX 是在写入时解析的，而 YY 是在读取时解析的。"
3. 第三次：直接给出完整清晰的解释，确保用户理解后再继续。

每个概念追问 2-4 个问题即可，不要无限追问。

第四步：产出结果

追问结束后，做两件事：

1. 改写文章段落

把用户回答中的核心表达整理成符合博客风格的段落。规则：

• 保留用户的语气、用词习惯和类比，不要替换成 AI 的标准化表达
• 补齐技术准确性：如果用户的口语化表达有技术不严谨之处，在保留语气的前提下补充准确说明
• 遵循仓库的 Markdown 写作规范（中文标点、编号标题、代码块标注语言）
• 输出为可直接替换原文对应章节的 Markdown 段落

2. 嵌入自然反思段落（默认方式）

从追问过程中挑选 1-2 个最有价值的瞬间（用户"恍然大悟"或纠正了理解偏差的时刻），转化为自然的反思段落嵌入文章。

默认使用自然段落风格——像作者自己在思考，而不是考试记录：

我一开始容易把 A 和 B 混在一起。后来发现真正的分界线不是……而是……

这里有个容易踩的坑：很多人以为 X 就是 Y，但其实……

如果用户明确要求使用 Q&A 板块形式，也可以用：

> **💡 想一想**：[追问的问题]
>
> [用户理解后的回答，整理成简洁的段落]

3. 确认后写入

将改写后的段落和反思段落展示给用户确认。用户确认后再写入文章，用户说不需要改就不改。