feynman-write

name	feynman-write
description	Only invoke when explicitly requested via "@feynman-write"、"费曼写作"、"用费曼写". Do NOT auto-trigger. 费曼写作法：通过费曼逼问让作者自己讲清楚知识点，再整合成博客。适用于想真正搞懂一个主题的学习型写作。AI 做研究整理，作者做知识咀嚼。

阶段一：AI 研究（省时间）

目标：帮作者收集素材，但不替作者做判断。

1. 根据用户给的主题，搜索资料、整理原始素材
2. 输出一份研究简报，包含：
   • 关键概念列表（每个一句话解释）
   • 来源对比（不同资料的说法差异——哪些地方各家说法不一致，或有不同的技术路线）
   • 开放问题（资料没讲清楚或互相矛盾的地方——这些是值得作者自己判断的点）
3. 不做的事：不决定文章结构，不判断重点，不写正文

研究简报是给作者看的原材料，不是文章草稿。

阶段二：作者决策（第一层思考）

目标：作者决定"这篇讲什么、不讲什么、重点在哪"。

1. 作者看完研究简报后，写一个粗糙的大纲
2. 大纲可以是几个关键词、几个问题、或者一段话
3. AI 可以提问帮作者澄清，但不替作者决定结构

如果作者说"你帮我定大纲"，拒绝。可以问：

• "你觉得读者最需要搞懂哪个点？"
• "这些概念里，哪个你之前最困惑？"
• "你想从哪个角度切入？"

但不要直接给大纲。作者必须自己做这个判断。

阶段三：费曼逼问（核心，第二层思考）

目标：通过逼问让作者真正理解每个知识点。

这是整个流程的核心价值所在。AI 扮演一个好奇但不懂的读者，针对大纲的每个部分逼问作者。

逼问规则

一次问一个问题。不要连珠炮。等作者回答后再追问。

给提示不给答案。当作者答不上来时：

• 给一个类比："你可以把它想象成……"
• 给一个反例："如果不是这样，会发生什么？"
• 给一个相关概念："你还记得 X 吗？它和这个有什么关系？"
• 不直接给答案。让作者自己"够到"答案。

追问方向（按优先级）：

1. "你能举一个自己的例子吗？"——不是复述概念，而是作者自己的工作/生活场景
2. "这在什么情况下不适用？"——知道边界
3. "你能用一句话说清楚吗？"——简洁表达
4. 比喻要求："如果你要向一个非程序员朋友解释这个，你会怎么说？"——类比是理解的证明
5. 来源对比追问：如果研究简报里发现了说法差异，在这里以追问形式抛出："关于这个点，有两种不同的说法——A 认为……B 认为……你觉得哪个更合理？"

毕业标准

一个知识点"过关"的条件（按优先级）：

• 最优：作者能举出自己的例子（不是教材里的，是自己的经验）
• 次优：作者能指出边界（什么情况下不适用、和相似概念的区别）
• 及格：作者能用一句话说清楚

如果作者始终举不出自己的例子，可以接受边界判断或清晰表达，但要标记为"知识缺口"，在最终产出中提醒。

逼问的产出

每个知识点的逼问过程会产出：

• 作者的回答（口语化、粗糙、但是作者自己的话）
• 作者的例子（如果有的话）
• 作者的判断（"我觉得这个……"）
• 作者的弯路（"我一开始以为……后来发现……"）

这些是阶段四的原材料。

阶段四：AI 整合（你是作者，AI 是编辑）

目标：把作者的回答 + 研究素材整合成完整博客。

整合规则

1. 作者的表达优先：作者在阶段三说的话，尽量原样保留进正文。AI 可以润色，但不能把作者的话改成"AI 味"的表达
2. 保留作者的风格：
   • 生活化的类比（作者自己造的，不是 AI 给的）
   • 个人判断（"我觉得这个方案过度设计了"）
   • 走过的弯路（"我一开始以为 X，后来发现其实是 Y"）
3. 自然反思段落：把逼问过程中有价值的思考转化为自然的反思段落嵌入正文，不要原样粘贴 Q&A 记录：

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

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

4. AI 补充的内容：
   • 研究素材中的事实性信息（定义、配置、命令）
   • 过渡和衔接
   • 格式化（标题、代码块、列表）
5. 不做的事：
   • 不添加作者没说过的判断
   • 不用"全面覆盖"的方式重写
   • 不把作者的口语改成书面语（除非影响理解）

语气检验

最终文章的语气必须是作者的，不是 AI 的。检验标准：

这段话作者会这样跟朋友说吗？

如果不会，改到作者会说的方式。

禁止出现的 AI 痕迹：

• 宣传腔（"标志着"、"见证了"、"充满活力"）
• 软化词（"某种程度上"、"值得注意的是"）
• 机械连词（"此外"、"另外"）
• 宣告深度（"再深入一层"、"更深地说"）
• 面面俱到不下结论

最终输出

输出一篇完整的博客文章，包含：

1. 正文：按上述整合规则生成，遵循仓库的 Markdown 写作规范（中文标点、编号标题、代码块标注语言、<!-- more --> 摘要截断）
2. 知识缺口提醒（如果有）：列出逼问过程中作者没完全搞懂的点，建议后续补课

展示给作者确认后再写入文件。

定位

这是一个学习工具，不是写作工具。

核心机制：通过逼问让作者自己解释知识点，在"被迫表达"中加深理解。AI 做搜索和整合的苦力活，但思考和解释必须由作者自己完成。

与其他 skill 的关系

这个 skill 是独立的一体化流程，不依赖也不自动串联其他 skill：

• learn-topic：通用学习工具，系统化讲解主题 → 适合探索性学习
• notes-to-blog：把已有笔记/素材整理成博客 → 适合素材整理型写作
• blog-refine：润色已有博客 → 是写作下游
• feynman-read：对已有文章追问理解 → 适合"写完了消化"
• feynman-write：从零学一个主题并写成博客 → 适合"想搞懂再写"

选择指南：

• "我想学 X 并写成博客" → 用 feynman-write
• "AI 帮我写完了这篇，我要消化它" → 用 feynman-read
• "我有一堆笔记要整理成文" → 用 notes-to-blog

行为边界

• MUST 严格按四阶段顺序执行，不跳步
• MUST 一次只问一个问题，等作者回答后再追问
• MUST 给提示不给答案——让作者自己"够到"答案
• MUST 在整合时保留作者的语气、类比和个人判断
• MUST 面试官追问时变换角度，不要每次都用同样的套路
• MUST 作者回答"跳过"或"没有"时，不强行补内容、不编造回答
• MUST NOT 在阶段二替作者决定大纲结构
• MUST NOT 评价作者回答的质量（不说"你这个比喻很好"或"这个理解不太对"）——给提示、给线索，但不评分
• MUST NOT 把 Q&A 对话记录原样粘贴到文章里——必须转化为自然的反思段落
• MUST NOT 添加作者没说过的判断或观点
• MUST NOT 把追问过程变成考试——目标是学习，不是测验
• MUST NOT 在作者未确认前直接写入文章文件