从「用 AI 写复习资料」到「提炼 AI 工作流」：一次意外的方法论之旅

本文由 AI（Claude Code）生成总结，可能包含不准确的内容。
文中对用户意图的解读、对过程的描述均基于 AI 对对话记录的理解，不代表用户的原始表述。

---

起因

期末将至，大学物理需要一份能快速翻阅的复习资料。手写笔记散乱，教科书太厚，网上资料风格不一。于是我想：能不能让 AI 帮我生成一份？

需求很简单：

• 覆盖质点运动学、质点动力学、刚体力学、简谐振动、波动、热力学基础六章
• 适合只有高中物理基础的人
• 既能当速查手册，又能当入门学习指南

用的工具是 Claude Code——Anthropic 的命令行 AI 编程助手。它能读写文件、执行命令、操作 Git，适合这种「边写边改」的文档工程。

第一阶段：生成内容

提纲先行

我没有直接让它写完整内容。第一步是生成提纲。

你现在的任务只有一个：为大学物理复习资料生成详细的 Markdown 提纲框架。

提纲的好处是便宜——一次生成就能看到整体结构是否合理，调整成本低。实际上提纲确实经历了一次修改：最初的第五章是「分子动理论」，是因为我看错了教材目录。后来才改成了「波动」，再补上「热力学基础」作为第六章。如果一开始就写完整内容，这次调整的浪费会大得多。

逐章展开

有了提纲后，逐章生成。每章写入独立文件（chapter1.md ~ chapter6.md），最后合并为一个完整文件。

每章的内部结构固定：

1. 概念讲解——从已知出发建立直觉
2. 核心公式——独立成行，说明意义
3. 符号说明——表格统一术语
4. 应用场景——连接现实
5. 章末公式速查表——方便翻阅

这个结构不是一开始就想好的。第一章写完后，我让它从第一章中提炼格式规范，写入项目的 CLAUDE.md（Claude Code 的项目配置文件），后续章节自动遵循。

第二阶段：例题讲解的风格迭代

内容写完后，我请它为前两章添加例题。这里经历了一次重要的风格转变。

第一版：标准答案式

最初写出的例题是标准教科书风格：

解：
(1) 由公式 $v = \omega R$…
(2) 由 $a_n = v^2/R$…

能用，但像在看答案，不像在学东西。

反馈与转变

我给了两条反馈：

1. 「侧重俯瞰和大局观」——在动手计算之前，先用一段话把这道题的全貌讲清楚：本质是什么、关键思路是什么、和之前学过的什么有关。
2. 「不要使用教条化的标准解题步骤，而是融入思路和这么做的动机和原理」——每引入一个公式时，解释为什么选它；在关键节点做翻译，把数学操作用物理语言重新表述。

改写后的风格变成了这样：

整体分析：这道题本质是圆周运动的运动学问题。已知速率变化规律，求任意时刻的速度和加速度。关键在于认识到速率 $v = 4t$ 是时间的函数，所以切向加速度恒定，法向加速度随时间变化。

详解：速率 $v = 4t$，意味着每秒增加 4 m/s——这就是切向加速度的物理意义…

这个转变不只影响了例题。我意识到这种「先建立全局认知，再深入细节」的思路，应该成为整份资料的底层哲学。

第三阶段：从物理到通用

写完物理资料后，我想到：这套方法能不能复用到其他学科？

第一版：还是物理味

最初让它写通用指引（instruction.md），结果写出来的东西满篇都是「公式」「符号」「速查表」。我指出：

毛概哪来的公式？Java 哪来的符号？

AI 默认模仿了它看到的范本——物理资料的格式。要让它写出真正通用的东西，需要抽象出更底层的原则。

认知哲学的提炼

重写后的指引不再提「公式」「符号」，而是四条认知哲学：

原则	含义
理解先于定义	先让读者感受到「为什么需要这个概念」，定义才自然出现
直觉先于形式	公式、代码、条文是精确表达的手段，不是理解的起点
为什么先于怎么做	每一步操作都要有动机
具体先于抽象	先给例子，再从中提炼规律

这四条原则适用于任何学科：

• 物理：先讲「物体为什么会动」，再讲 $F=ma$
• 编程：先讲「为什么要用循环」，再讲 for 语法
• 法学：先讲「这个法条要解决什么社会问题」，再讲条文

封装为 Skill

Claude Code 有一个叫 Skill 的机制——把一套工作流打包成可复用的指令，以后输入一个 /skill-name 就能调用。

我让它把物理项目中的所有经验——方法论、工作流程、格式规范——提炼成一个通用 Skill：

.claude/skills/create-learning-material/SKILL.md

这个 Skill 分三部分：

1. 方法论：认知哲学、内容骨架、写作原则、例题讲解方法、常见陷阱
2. 工作流程：需求采集 → 提纲生成 → 逐章展开 → 整合校对 → 交付（五个阶段，每个阶段有必须确认的检查项）
3. 排版规范：标题层级的语义、格式元素的含义、不同学科的形式化工具对照表

第四阶段：整理与收敛

项目一度出现了内容重叠的问题：

• CLAUDE.md 里写了方法论
• instruction.md 里也写了方法论
• SKILL.md 里又写了方法论

三份文件互相引用，每份都只有部分内容，但合起来又有很多重复。读一份文件需要跳转到另一份才能获得完整信息，浪费 token 也浪费注意力。

最终的解决方案是职责分离：

文件	职责	内容
SKILL.md	通用方法论与工作流	认知哲学、内容骨架、写作原则、五阶段工作流、排版规范
CLAUDE.md	本项目特化配置	学科为物理、6章范围、读者为高中基础、物理符号规范
instruction.md	删除	内容已合并入 SKILL.md

原则很简单：同一份信息只出现在一个地方。SKILL.md 是任何学科都能用的通用方法论，CLAUDE.md 只写这个物理项目特有的几行配置。

回顾：我学到了什么

1. AI 需要反馈循环，不是一次性指令

整个过程不是「写一个 prompt → 得到完美结果」。提纲改了一次，例题风格改了两三次，通用指引重写了一次，文件结构整理了两次。每一次「翻车」都是因为 AI 的输出和我脑中的标准有差距——而发现这个差距本身就需要先看到一个版本。

2. 具体经验比抽象原则更容易提炼

方法论不是凭空想出来的。先在物理这个具体场景中跑通全流程，遇到问题、修正、再遇到问题、再修正，然后回头看「我们到底在修正什么」——这时候才能提炼出真正有用的抽象原则。

如果一开始就让它写「通用学习资料方法论」，大概率会得到一堆正确的废话。

3. Skill 的本质是「把偶然变成必然」

这次项目中很多好的做法——比如先写提纲再展开、比如例题先俯瞰再详解——都是在过程中偶然发现或被反馈逼出来的。如果没有刻意记录，下次做类似项目时很可能忘记其中某些做法。

Skill 的作用就是把这些「偶然发现的好做法」变成「下次一定会执行的流程」。

4. 文档工程也是工程

一份 2000+ 行的 Markdown 文档，涉及 6 个章节、多种格式、前后一致性——这本质上是一个小型文档工程。版本控制（Git）、模块化（分章节文件）、配置管理（CLAUDE.md）、代码复用（Skill）这些软件工程的思想，在文档工程中同样适用。

---

附：项目结构

大物复习/
├── outline.md                    — 提纲
├── chapter1.md ~ chapter6.md     — 各章独立文件
├── 大学物理复习资料.md              — 合并后的完整资料
├── CLAUDE.md                     — Claude Code 项目配置
├── .claude/skills/
│   └── create-learning-material/
│       └── SKILL.md              — 提炼出的通用 Skill
└── .git/                         — 版本控制（16 次提交）

附：Git 提交历史（按时间顺序）

979e7a5 init: 大物复习资料骨架（提纲 + 前4章）
7bff481 feat: 第五章 波动
0a99f51 feat: 第六章 热力学基础
155ede8 merge: 整合全部6章为完整单文件
cfa5175 feat: 第一章增加2道例题与详解
d99b90a feat: 第一章例题（新风格：俯瞰分析 + 嵌入式思路讲解）
3ddbb3c docs: CLAUDE.md 增加例题讲解风格规范
818b0ee feat: 第二章例题
2d2740e fix: 例题2第(2)问修正（能量守恒法替代错误的动能定理）
2df598c docs: 新增 instruction.md
93a27a5 rewrite: instruction.md 重写为通用版（聚焦认知哲学）
3ae8bce feat: 创建 create-learning-material skill
00631e0 docs: CLAUDE.md 引用 instruction.md 和 skill
6ab396c refactor: 合并 instruction.md 到 SKILL.md，CLAUDE.md 精简
4049a67 refactor: 整理目录结构

16 次提交，记录了从「写一份物理笔记」到「提炼一套可复用方法论」的完整路径。