7.1 让我们看到了 Skill 的最小结构。这一节回答更靠前的内容问题：正文里的方法和规则，应该从哪里来？
本节对应 Best practices 的 Start from real expertise，包括从一次真实任务提炼，以及从已有项目材料整理这两种来源。
下面分成三个小节：先理解经验、SOP 与 Skill 的关系，再分别学习从真实任务和已有项目材料中提炼。最后用一份完整的最小 Skill 串起这些做法。
7.2.1 从真实经验出发：理解 SOP 与 Skill 的关系
这里的真实经验，是实际任务中积累的有效做法、纠正和约束。只让模型凭通用知识生成 Skill，容易得到“妥善处理错误”“遵循最佳实践”这样的笼统要求；提供项目实际使用的接口、遇到的边界情况和既有约定，才能把要求写成具体动作。
可以把这一类 Skill 理解为：把已经有效的工作方法整理出来，让 Agent 下次遇到同类任务时能够复用。
对工作流型 Skill，可以从“把有效的 SOP 交给 Agent 复用”来理解。SOP 是标准操作流程（Standard Operating Procedure）。整理成 Skill 时，还要交代适用场景、所需输入，以及过程中需要判断的条件。
| 层次 | 它记录什么 | 本站写作中的例子 |
|---|---|---|
| 一次任务的经过 | 这次做了什么、哪里被纠正 | 编写 7.1 时改用官网掷骰子例子、补充 d20 解释与中文版本 |
| 可复用的方法 / SOP | 下次同类任务也有用的步骤与条件 | 核对指定来源，展示完整例子，解释必要术语，再验证页面 |
| Skill | 方法的名称、适用场景和执行指令 | 一份指导本站学习小节编写的 SKILL.md |
从“经过”到“方法”，需要提炼。例如，“解释 d20”是这次的具体动作；“解释当前例子中影响理解的陌生术语”才是可用于其他小节的规则。
本节关注工作流型 Skill。Skill 也可以提供参考知识和项目约定；它的正文可以包含判断与分支，不要求所有任务都执行完全相同的步骤。
7.2.2 从一次真实任务中提炼
原文的 Extract from a hands-on task 建议观察四类材料：
| 观察什么 | 从中提取什么 |
|---|---|
| 有效步骤 | 哪些动作帮助任务完成，先后关系是什么 |
| 用户纠正 | 哪种做法需要调整，用户实际期望什么 |
| 输入与输出 | 开始时需要哪些材料，完成时应交付什么 |
| 用户补充的背景 | 项目特有的约定、限制和偏好 |
编写 7.1 时的具体要求就提供了这些信息：
| 这次任务中的具体要求 | 可以提炼的规则 |
|---|---|
| 使用官网 Quickstart 的 roll-dice，而不是另换例子 | 先核对用户指定的来源与示例 |
| 解释 d20 是二十面骰子 | 解释读者理解当前例子必需的术语 |
| 同时给出中文版本 | 引用英文例子时提供中文对照，名称与命令保持一致 |
| 先完成一个阶段，不预先塞入后续内容 | 每次围绕当前学习目标完成一个小单元 |
这样，每条规则都能指出来历。某条要求如果只适用于这一次，就放进本次任务输入；只有对同类任务仍然适用的部分，才提炼进复用方法。
例如，章节编号“7.1”和术语“d20”不应成为所有学习小节都必须使用的内容。
7.2.3 从已有项目材料中整理
不一定要等一次新对话结束，才能开始写 Skill。原文的 Synthesize from existing project artifacts 提供了另一种来源：项目已经积累的资料。
| 项目材料 | 主要寻找什么 |
|---|---|
| 内部文档、操作手册、写作规范 | 已经约定的流程与完成要求 |
| API 文档、数据结构、配置文件 | 实际接口、字段与运行条件 |
| 代码审查意见、问题记录 | 反复出现的检查重点 |
| 提交历史、修复补丁 | 为什么要改变原来的做法 |
| 失败案例与处理记录 | 触发条件、诊断方法与恢复步骤 |
本项目的 AGENTS.md 和 docs/learn-claude-code-writing-rules.md 就属于这类材料：它们说明了页面修改前的本地预览、章节组织、来源标注和验证要求。
整理时要读出具体约束。例如“写完检查质量”还不能指导执行；“修改前确认本地预览可访问，完成后检查相关页面与导航”就有了明确动作。
历史资料也需要核对是否仍然适用。不要把已经废弃的操作或仅针对一次故障的绕行方法，直接变成所有任务的固定步骤。
综合练习：把经验与资料写成最小 Skill
整理成完整文件
下面换到“编写学习小节”这个真实任务，展示上述材料怎样进入文件。它用于说明经验提炼，roll-dice 仍是 7.1 学习基本结构的例子。
这是依据上述写作要求与项目约定整理的教学稿：
---
name: write-learning-unit
description: 为本站编写或修改一个技术学习小节时使用。依据用户指定的资料，用完整最小示例解释当前知识点。
---
## 输入
确认本节学习目标、用户指定的来源，以及要修改的页面。
阅读项目已有的写作约定，确认本地预览可以访问。
## 工作步骤
1. 阅读指定资料，核对要讲解的例子和本节范围。
2. 先展示一份完整的最小示例，再按组成部分解释。
3. 英文原例附上中文对照，保留相同的程序名称与命令。
4. 解释理解当前示例必需的术语，每次只展开当前学习点。
5. 检查说明与代码是否一致，并验证相关页面和导航。
## 交付
给出可查看的页面链接，说明本节完成了什么。
对应关系可以逐项检查：
description把方法限制在本站技术学习小节，说明什么时候使用。- “输入”保留每次都会变化的学习目标、来源和页面。
- “工作步骤”承接刚才提炼出的有效做法与用户要求。
- “交付”给出下一次执行者也能理解的完成结果。
这些内容不需要来自一份现成的正式 SOP。先从经验和资料整理出可重复的方法，再逐步改进，也是在形成 SOP。
换一个任务，看看方法是否仍然成立
假设下一次要解释另一个工具的最小使用示例。可以检查这份 Skill：
- 是否能接收新的资料和学习目标，而没有继续要求讲 d20？
- 是否仍能指导完整示例、必要术语和中英对照？
- 是否保留项目要求的预览与检查步骤？
- 哪些步骤在新任务里不适用，需要增加条件或删除？
这是一组待验证的问题，不是已经取得的跨任务评测成绩。下次运行时应查看实际过程和产物，再修正方法。
这里需要建立的联系是：经验与项目资料提供依据，SOP 整理工作方法，Skill 把方法写成可按需采用的指令。 正文写好之后，实际行动仍由 Agent 和工具完成。
下一节再判断：这些材料和规则中，哪些值得留在 Skill 的上下文里。