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

<what-to-do>

## 阶段一：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 记录：
   ```markdown
   我一开始容易把 A 和 B 混在一起。后来发现真正的分界线不是……而是……
   ```
   ```markdown
   这里有个容易踩的坑：很多人以为 X 就是 Y，但其实……
   ```
4. **AI 补充的内容**：
   - 研究素材中的事实性信息（定义、配置、命令）
   - 过渡和衔接
   - 格式化（标题、代码块、列表）
5. **不做的事**：
   - 不添加作者没说过的判断
   - 不用"全面覆盖"的方式重写
   - 不把作者的口语改成书面语（除非影响理解）

### 语气检验

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

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

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

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

### 最终输出

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

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

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

</what-to-do>

<supporting-info>

## 定位

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

核心机制：通过逼问让作者自己解释知识点，在"被迫表达"中加深理解。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` 在作者未确认前直接写入文章文件

</supporting-info>