🎈 想读易懂版？

本章有易懂版（大白话讲重点，10 分钟读完）：[第 5 章 加载一个真正用得上的 Skill（易懂版）](../../easy/第5章 加载一个真正用得上的 Skill（易懂版）.md)

第 5 章 加载一个真正用得上的 Skill

本章目标：理解 Skill 的本质——把"一次成功的做法"封装成可随时调用的技能。学会加载、判断、评估 Skill，让重复劳动从此消失。

5.1 什么是 Skill

Skill 是把"一次成功的做法"打包成可随时调用的技能。它类似电脑里的快捷方式：不用每次重讲方法，喊名字就能用。

Skill = 明确的使用方法 + 执行步骤 + 输入输出约定

5.1.1 生活中的类比

想想新员工入职：公司不会让新人每次报销都重新研究流程，而是给一本《报销 SOP》——照着做就行。Skill 就是我的 SOP 手册。

5.1.2 Skill 解决的问题

同一件事，每次都按最佳实践做，而不是每次从头想。

• 没有 Skill：每次写报告都重新纠结结构；
• 有 Skill：一句话调用，格式、结构、规范全部就位。

5.2 我身上的 Skill 长什么样

我身上就挂着一些 Skill，比如提交代码（commit）、评审 PR（review-pr）、处理 PDF（pdf）等。一个 Skill 通常包含四个部分：

部分	内容	示例（commit）
名称	调用名	commit
说明	什么时候用	"提交代码前，先看 diff 再提交"
步骤	执行流程	查状态 → 看改动 → 写规范 commit message → 提交
约定	约束与边界	不强制 push、不用 --no-verify

5.2.1 标准 Skill 的结构示例

# commit 技能
## 用途
提交代码时使用，确保每次提交规范、可回溯。

## 触发条件
用户要求"提交代码"、"commit"时。

## 执行步骤
1. git status 查看改动文件
2. 逐个文件过 diff，理解改动内容
3. 写规范的 commit message（类型 + 摘要 + 说明）
4. 提交（不 push，除非用户明确要求）

## 边界
- 不强制 push
- 不使用 --no-verify
- 不 amend 历史提交（除非用户要求）

5.3 怎么加载一个 Skill

两步走：

5.3.1 第一步：报技能名 + 目标

你：用 commit 技能，帮我提交这次的改动
我：（加载 commit Skill）先 git status 看改动 → 逐个文件过 diff → 写规范的提交信息 → 提交

5.3.2 第二步：想不起名字就描述目标

你：帮我提交代码  ← 没提技能名
我：（自动匹配 commit Skill）好的，按提交规范来。

记忆技巧

技能名想不起来完全没关系，描述目标即可，我会自动匹配。 想知道有什么技能，直接问"你有哪些技能"。

5.4 Skill 的正确使用场景

5.4.1 该用 Skill 的判断标准

这件事你（或团队）会反复做吗？

判断	结论
会，且每次做法一致	✅ 值得做成/调用 Skill
会，但每次差异大	⚠️ 做成 Skill 时保留参数化空间
一次性、不重复	❌ 直接对话即可

5.4.2 什么时候别用 Skill

• 一次性、不重复的任务：直接对话即可，加载 Skill 反而绕；
• 需要即兴发挥的任务：Skill 反而束缚（如"帮我头脑风暴 10 个点子"）；
• 超出技能边界的任务：Skill 会明确告诉我做不了——这也是好事，边界清晰。

重要认知

Skill 是锦上添花，不是银弹。 它是"经验封装"，不是"能力上限"。判断标准只有一个：这件事你会反复做吗？

5.5 评估一个 Skill 好不好

用三个问题评估：

问题	好 Skill	差 Skill
触发条件清楚吗？	知道何时该用	含糊，靠猜
步骤可执行吗？	每步都是动作	抽象、跳过关键细节
边界明确吗？	知道什么不做	无限扩张、越权

评估结论反过来就是设计原则——第 17 章"打造 Skill"会带你亲手做一个。

5.6 本章练习

1. 让我列出当前可用的全部 Skill，并逐个说明用途。
2. 挑一个与你的工作相关的 Skill，实际调用一次。
3. 记录：这个 Skill 解决了我什么问题？省了多少时间？
4. 用 5.5 节的三个问题，评估你刚调用的 Skill 好不好，并把结论告诉我。

---

小结：Skill 的本质是经验的封装——用别人的 Skill 是抄作业，做自己的 Skill 是写教材。加载 Skill 是本章的内容，打造 Skill 在第 17 章。 下一章，我们让 AI 记住你——记忆系统。