基础概念难度 2⏱ 19 分钟概念
01技术概念速查表
把学习 Skill 时会遇到的关键技术概念压缩成速查表，方便快速回看和补齐理解。
速查表技术概念SkillAgent
更新于 2026-04-11C-技术概念速查表
系统解释 Skill 的本质、触发逻辑、和 Prompt / Agent / MCP 之间的关系。
内容摘要
> 模块2：搞懂Skill到底怎么回事 | 用时：约15分钟 | 目标：理解Skill的本质、渐进式披露机制、和MCP/AGENTS.md的区别
模块2：搞懂Skill到底怎么回事 | 用时：约15分钟 | 目标：理解Skill的本质、渐进式披露机制、和MCP/AGENTS.md的区别
做完模块1，你应该已经做出了第一个能用的 Skill——不管是周报生成器、小红书写作助手，还是别的什么。
能用，但说实话，心里有点虚——这东西到底怎么回事？为什么放一个文件 AI 就"学会"了？
你可能会问：这跟我把提示词保存在备忘录里有啥区别？
好问题。
说实话，我自己刚接触 Skill 的时候也没太当回事，觉得不就是把提示词存了个文件嘛。后来越用越觉得不对劲——Skill 跟提示词的差距，比自行车跟电动车的差距还大。
我花了差不多一周时间才把几个核心概念理清楚，这个模块帮你把这周的路压缩到 15 分钟。
我们要搞清楚三件事：
话不多说，我们一层一层扒开来看。
很多人第一次接触 Skill，第一反应是"这不就是把提示词存起来了嘛"。
最开始我也这么想的。后来发现自己错得离谱。
说白了，这里面的门道比你想象的要深得多。
假设你是个短视频创作者，每天要写抖音/视频号的脚本。
用普通提示词的方式是这样的：
你：帮我写一个关于"职场焦虑"的短视频脚本，要钩子开头，带点反转，结尾引导点赞关注
AI：好的，以下是一个短视频脚本：
开头：你是不是也经常感到焦虑？
中间：其实焦虑是因为...
结尾：觉得有道理的点个赞...
你：开头太平了，不够抓人。要用那种"痛点暴击"式的钩子
AI：好的，我重新写开头：
开头：90%的职场人都在硬撑...
你：还是不够狠，要像"凌晨2点，我又在厕所偷偷哭了"这种具体的场景
AI：好的，开头改成：凌晨2点，我又在厕所偷偷哭了...
（但你心里在想：为什么我每天都要来一遍这个流程？）
你看看，写一个脚本，来回拉扯了四五轮。第一天还能忍，第二天有点烦，到第五天你就不想跟 AI 说话了。
更要命的是什么？是你的"钩子套路""反转结构"这种东西，新对话就全没了。你精心调出来的开头方式、情绪节奏、CTA话术，全是一次性的。明天又得从头来。
你提前写了一个短视频脚本 Skill，里面把你的"钩子+痛点+解决方案+CTA"结构、爆款话术、时长控制全部定义好了。然后：
你：写一个关于"职场内耗"的短视频脚本
AI：[自动加载你的短视频脚本 Skill]
钩子：凌晨2点改第8版方案，我突然在工位上笑了...
痛点：90%的职场内耗，都来自"过度负责"
解决方案：分享3个"偷懒但升职"的反向操作
CTA：你也这样吗？评论区聊聊
预估时长：45秒
一句话进去，成品出来。你不需要再说第二遍。
你可能会问：这就是全部了吗？
不，这还只是表面。
Skill 是 AI 自动判断什么时候该用的，不是你手动触发的。
你可以同时装 20 个 Skill——短视频脚本、公众号爆款文章、小红书笔记、commit message、代码审查、PRD 生成。你说"帮我写个 PRD"，AI 自动加载 PRD 的 Skill。你说"写个短视频脚本"，AI 自动加载短视频的 Skill。你说"来篇公众号爆款"，AI 自动加载公众号写作的 Skill。
你不需要说"请使用我的短视频 Skill"，AI 自己会判断。
这就像你雇了一个实习生，你不需要每次跟他说"请翻到操作手册第 3 页"。你只要说任务，他自己知道该翻哪本手册。如果你手下有个新人能做到这样，你是不是觉得这小伙子特别靠谱？
Skill 就是让 AI 变成这种靠谱的新员工。
普通提示词做不到这一点。你得每次手动粘贴，每次判断该用哪个提示词，每次检查 AI 有没有用对。
所以 Skill 和提示词的本质区别不是"有没有存起来"，而是三个层面：
第一，复用层面。 提示词是一次性的，新对话就没了。Skill 是永久的，装一次用一辈子。
第二，触发层面。 提示词需要你手动粘贴。Skill 是 AI 自动判断什么时候该用。
第三，资源封装层面——这是最大的区别。 提示词是纯文本，只能描述。Skill 可以封装 scripts/（可执行脚本）、references/（参考文档）、assets/（模板文件）。
| 对比维度 | Prompt | Skill |
|---|---|---|
| 使用方式 | 每次手动粘贴 | 自动匹配触发 |
| 记忆能力 | 说完就忘 | 永久保存 |
| 团队协作 | 各人用各人的 | 团队共享同一套 |
| 资源封装 | 只能"说" | 能"做"——能调用脚本、读取文档 |
用个具体的例子：
提示词：告诉 AI "用 Python 读取 CSV 并计算平均值"
Skill：直接包含 scripts/analyze_csv.py，AI 调用脚本执行
提示词：描述 "按这个格式写 PRD"
Skill：assets/ 里放着 PRD 模板.docx，AI 直接复制修改
提示词：解释 "短视频脚本要有钩子+痛点+解决方案+CTA"
Skill：references/ 里放着爆款案例库，AI 按需参考
一句话：提示词只能"说"，Skill 可以"做"。
当任务需要精确执行、外部资源、或复杂处理流程时，提示词做不到，Skill 能做到。
现在 AI 工具圈子里有几个概念经常被搞混：Skill、MCP、AGENTS.md。说实话，我之前也被绕晕过。
后来用一个真实的场景想明白了。
假设你要让 AI 帮你做代码审查。
MCP 让 AI "能"访问 GitHub。说白了就是在 AI 和 GitHub 之间搭一座桥：
// MCP 暴露给 AI 的完整工具签名（真实示例）
{
"tools": [
{
"name": "list_pull_requests",
"description": "列出指定仓库的 Pull Request 列表",
"inputSchema": {
"type": "object",
"properties": {
"repo": { "type": "string", "description": "仓库名，格式：owner/repo" },
"state": { "type": "string", "enum": ["open", "closed", "all"], "default": "open" },
"per_page": { "type": "integer", "default": 30, "maximum": 100 }
},
"required": ["repo"]
}
},
{
"name": "get_pull_request_details",
"description": "获取指定 PR 的详细信息，包括标题、描述、作者、标签",
"inputSchema": {
"type": "object",
"properties": {
"repo": { "type": "string" },
"pr_number": { "type": "integer" }
},
"required": ["repo", "pr_number"]
}
},
{
"name": "list_pr_files",
"description": "获取 PR 中变更的文件列表，包括新增、修改、删除的文件",
"inputSchema": {
"type": "object",
"properties": {
"repo": { "type": "string" },
"pr_number": { "type": "integer" }
},
"required": ["repo", "pr_number"]
}
},
{
"name": "create_pr_comment",
"description": "在 PR 的指定位置发表评论",
"inputSchema": {
"type": "object",
"properties": {
"repo": { "type": "string" },
"pr_number": { "type": "integer" },
"body": { "type": "string", "description": "评论内容，支持 Markdown" },
"path": { "type": "string", "description": "评论关联的文件路径" },
"line": { "type": "integer", "description": "评论关联的行号" }
},
"required": ["repo", "pr_number", "body"]
}
},
{
"name": "get_file_content",
"description": "获取仓库中指定文件的原始内容",
"inputSchema": {
"type": "object",
"properties": {
"repo": { "type": "string" },
"path": { "type": "string", "description": "文件路径" },
"ref": { "type": "string", "description": "分支名或 commit SHA" }
},
"required": ["repo", "path"]
}
}
]
}
看到了吗？每个工具都有完整的类型定义、参数描述、必填字段。这些信息在 MCP 服务器启动的时候全部加载到 AI 的上下文里。
光是上面这 5 个工具，JSON Schema 就有将近 2000 个 token。
有了 MCP，AI 知道"我能调用这些接口来操作 GitHub"。但 MCP 不告诉 AI "你应该审查什么、按什么顺序、用什么标准"。
这就像给了一个厨师一套顶级厨具，但没给他食谱。刀是好刀，锅是好锅，但他不知道该先放油还是先放盐。
Skill 告诉 AI "怎么做"一次代码审查：
---
name: code-reviewer
description: "执行标准代码审查。当用户需要code review、代码审查、检查代码质量时使用。输出结构化审查报告。"
---
## 审查清单
1. 获取 PR 信息，了解变更背景
2. 逐文件审查：
- .py 文件 → 检查 PEP 8 规范、SQL 注入风险
- .js 文件 → 检查未处理的 Promise、废弃 API
3. 安全检查：
- 硬编码密钥（搜索 API_KEY, SECRET, PASSWORD）
- SQL 注入（字符串拼接的 SQL 语句）
4. 用 create_pr_comment 对严重问题直接评论
MCP 给 AI 提供了"手"——能访问 GitHub 的能力。Skill 给 AI 提供了"脑子"——知道怎么专业地做代码审查。
AGENTS.md 里写的是全局规范，如"用中文回答""代码用 4 空格缩进"。不管你问什么都会生效。
| 维度 | MCP | Skills |
|---|---|---|
| 核心问题 | 能不能连接 | 知道怎么做 |
| 类比 | 厨房里的刀/锅/灶 | 红烧肉食谱 |
| 上下文策略 | 急切加载（~16k token） | 渐进式披露（~100 token） |
| 典型内容 | JSON Schema、API 签名 | 工作流、最佳实践、示例 |
| 加载时机 | 启动时全部加载 | 按需触发加载 |
这三者互补：MCP 解决"能不能做"，Skill 解决"怎么做"，AGENTS.md 解决"怎么表现"。
这是 Skill 最核心的技术创新，也是它能碾压"保存提示词"方案的根本原因。
说实话，我第一次理解这个机制的时候，是真的拍了一下桌子——设计得太巧妙了。
AI 有一个叫做"上下文窗口"的东西。你可以理解为 AI 的短期记忆。
这个记忆是有上限的。目前主流模型一次对话能处理大约 200,000 个 token。一个 token 大约等于一个中文字或者半个英文单词。200,000 token 听起来很多，但实际用起来很快就满了。
你的对话历史、AI 的回复、工具的输出，全部都要塞进这个窗口里。
这就带来一个问题：如果你一次性把 50 个工具的说明书全塞进去，AI 的"记忆"就满了，没有空间思考你的问题。
MCP 就有这个问题。
当 AI 连接一个 MCP 服务器的时候，它做的第一件事是通过 tools/list 请求获取所有可用工具的完整描述。
先给大家看一个真实的例子。
连接 Playwright MCP 服务器（用于浏览器自动化的工具），它在启动时就把所有工具的完整 JSON Schema 全部加载到上下文里。社区开发者测量过，仅这一个 MCP 服务器就要消耗大约 16,000 个 token。
你可能会问：16,000 token 是什么概念？
大约是 200k 上下文窗口的 8%。一个 MCP 服务器就吃掉了 8%。
你装 5 个 MCP 服务器试试？上下文窗口直接被吃掉 40%。AI 的"思考空间"被严重挤压，回复质量会明显下降——变慢、变笨、容易跑偏。
而且这还只是启动时的开销。你在对话中提到的内容、AI 生成的回复、工具返回的结果，全都要往这个已经很挤的窗口里塞。
说实话，我就遇到过这种情况：装了四个 MCP 服务器，对话到第十几轮的时候 AI 开始"忘事"，前面明明说过的话它完全不记得了。
Skill 的设计完全不同。它不是一次性全塞进去，而是分三层，按需加载。
我一层一层给你讲。
AI 启动的时候，扫描 .claude/skills/ 目录下所有的 SKILL.md 文件。但它不读正文，只读 YAML 头部的 name 和 description 两个字段。
比如你的短视频脚本 Skill：
name: short-video-script
description: "生成抖音/视频号短视频脚本。当用户需要写短视频脚本、口播文案、钩子开头内容时使用。输出包含：钩子+痛点+解决方案+CTA结构，预估时长。"
再比如你的公众号爆款写作 Skill：
name: wechat-burst-article
description: "生成公众号爆款文章。当用户需要写公众号文章、爆款文案、高打开率内容时使用。输出包含：悬念标题+场景代入+三段式正文+金句结尾。"
就这两行，大约 100 个 token。AI 就知道"哦，我有写短视频脚本和公众号爆款的能力"。
如果你装了 50 个 Skill，每个的"封面"只占 100 token，总共才 5,000 token。
5,000 token vs MCP 一个服务器就 16,000 token。差距一目了然。
当用户的问题和某个 Skill 匹配时，AI 才加载这个 Skill 的完整正文。
比如用户说"帮我写个短视频脚本"，AI 把"短视频脚本"和所有 Skill 的 description 比对，发现 short-video-script 匹配度最高。于是它去读这个 Skill 的完整 SKILL.md——钩子结构、痛点挖掘、CTA话术、时长控制，全部加载进来。
再比如用户说"来篇公众号爆款"，AI 匹配到 wechat-burst-article，才加载它的"悬念标题+场景代入+三段式正文+金句结尾"完整结构。
这时候 AI 获得了完成任务所需的全部上下文。这部分通常在 1,000 到 5,000 个 token 之间，取决于你的 Skill 有多复杂。
执行到某一步需要额外资料时，AI 才去读 scripts/、references/、assets/ 里的文件。
比如一个数据分析的 Skill，SKILL.md 里写了操作步骤，但具体的数据处理逻辑在 scripts/analyze_csv.py 里。AI 执行到"分析数据"这一步时，才会去读这个脚本。
而那些永远不会被触发的文件，从头到尾都不会被加载。
Skill 的设计是三级分层架构：
| 层级 | 内容 | 何时加载 | Token 成本 |
|---|---|---|---|
| L1 | frontmatter（name + description） | 始终 | ~100 |
| L2 | SKILL.md body | 触发后 | 1,000-5,000 |
| L3 | scripts/ references/ assets/ | 按需 | 无上限 |
启动时：50 个 Skill × 100 token = 5,000 token
触发 1 个 Skill 后：5,000 + 3,000 = 8,000 token
对比 MCP：50 个工具 × 400 token = 20,000 token（启动即占用，永不释放）
这就是渐进式披露的威力：用最少的成本获得完整的能力。
把 Skill 想象成几本食谱放在书架上——有短视频脚本的、公众号爆款的、还有小红书笔记的。
AI 启动时，只看书脊上的标签（name + description），知道你有这三本食谱，总共才几百 token。
当你说"帮我写个短视频脚本"，AI 抽出短视频那本，翻开看具体的制作步骤（SKILL.md 正文）——钩子怎么写、痛点怎么挖、CTA 怎么设计。做到某一步需要参考爆款案例时，才去附录（references/）里找。
如果你同时装了"周报生成""短视频脚本""公众号爆款"三个 Skill，AI 启动时只认识三个书名。只有当你明确说"写个短视频"，它才加载短视频那本的正文。其他两本原封不动待在书架上。
这就是渐进式披露——按需加载，不浪费一个字节。
你在模块 1 里做的就是这个：
short-video-script/
└── SKILL.md ← 就这一个文件，就够了
一个文件夹，一个 SKILL.md 文件。没有别的。
大部分人的大部分需求，这个结构就够用了。
当你需要更复杂的功能时，可以加这些目录：
data-analysis/
├── SKILL.md ← 操作手册（必需）
├── scripts/
│ └── analyze_csv.py ← 可执行脚本（可选）
├── references/
│ └── report-template.md ← 参考文档（可选）
└── assets/
└── template.xlsx ← 模板文件（可选）
四个目录各管各的：
SKILL.md 是核心，没有这个文件就不叫 Skill。它里面写的是操作指令——AI 应该按什么步骤做事、输出什么格式、避免什么错误。
scripts/ 放可执行代码。什么时候用呢？当你的 Skill 需要做一些 AI 用自然语言做不好的事情时。比如处理 CSV 数据、调用外部 API、做精确的数学计算。AI 很擅长理解和组织信息，但精确计算不是它的强项。这种时候就把具体的计算逻辑写成 Python 脚本放在 scripts/ 里，SKILL.md 只需要告诉 AI "什么时候调用这个脚本"就行。
references/ 放补充文档。当你的 SKILL.md 正文太长，超过 5000 token 的时候，就该考虑把部分内容拆到 references/ 里了。比如你有一个多平台内容发布的 Skill，每个平台的风格指南可能 1000-2000 token，全写进正文就太长了。拆成 references/wechat_style.md、references/xhs_style.md，SKILL.md 里写"处理微信平台时加载 references/wechat_style.md"，AI 就会按需去读。
assets/ 放静态资源。Excel 模板、图片、数据文件这类不需要 AI 解读的二进制文件。
这里有个坑要注意：不要提前加。
先用一个 SKILL.md 跑起来。等你发现 AI 用自然语言搞不定某些操作（比如精确计算、二进制文件处理），再加 scripts/。等你发现 SKILL.md 正文太长了，再加 references/。
这就叫"最小可用先行"——先跑起来，再逐步扩展。
很多人犯的错误是一上来就设计复杂的目录结构。其实 90% 的场景，一个 SKILL.md 就够了。我自己的 Skill 十个里面有八个就一个文件。
你现在已经知道正文是给 AI 看的操作指令。但怎么写才能让 AI 稳定输出你想要的结果？
这里有几个实操技巧，都是我踩了无数坑总结出来的。
差的写法：
文章不要太长，写短一点。
好的写法：
总长度 300-500 字。标题 15 字以内。每段不超过 3 行。
AI 对数字的理解远远好于模糊描述。"短一点"对 AI 来说可能是 100 字，也可能是 1000 字。但"300-500 字"不会产生歧义。
差的写法：
输出包含钩子、痛点、解决方案、CTA。
好的写法：
输出格式如下：
钩子：[15字以内，痛点暴击式]
痛点：[描述具体场景，引发共鸣]
解决方案：[3个可操作建议]
CTA：[引导点赞/关注/评论]
示例：
钩子：凌晨2点改第8版方案，我突然在工位上笑了...
痛点：你是不是也这样？明明活儿干完了，却总觉得哪里不对...
解决方案：1.学会"交差心态" 2.建立"下班仪式感" 3...
CTA：你也这样吗？评论区聊聊
给 AI 看一个"成品长什么样"，比描述"成品应该什么样"有效得多。这跟教人做饭一个道理——看一遍成品图，比听十遍描述都管用。
大部分人只写"要做什么"，忘了写"不要做什么"。但 AI 需要两方面才能准确理解你的意图。
## 反模式（不要做这些）
- 钩子不要用抽象概念（"很多人""90%的人"），要用具体场景
- 痛点不要直接给解决方案，要先引发共鸣
- 正文不要超过 500 字
- 结尾CTA不要太硬（"关注我看更多"），要软着陆（"你也这样吗？"）
有反模式的正文，输出稳定性会提升一大截。后面模块 3 我会专门讲反模式怎么写。
差的写法：
先理解主题，然后生成几个标题让用户选，选好了再写正文，最后加标签。
好的写法：
## 操作步骤
1. 理解用户想写的主题
2. 生成 3 个备选标题供选择
3. 用户选定后，按标题写正文
4. 添加 3-5 个话题标签
编号列表让 AI 的执行更稳定。不加编号的话，AI 有时会跳步、有时会合并步骤。你就把它当成给实习生派活——说清楚第一步干什么、第二步干什么，他才不会乱。
正文不是越长越好。太长的正文有两个问题：一是浪费上下文空间，二是 AI 容易"顾此失彼"——看了后面忘了前面。
200 行（大约 2000-3000 token）是一个比较好的上限。如果你的内容确实很多，把详细部分拆到 references/ 目录下，正文里只写"当需要XX时加载 references/XX.md"。
正文不是给编译器看的，是给 AI 看的。用大白话、短句、直接说要求就行。不需要写成技术文档的格式，也不需要用专业术语。
差的写法：输出应遵循以下范式——标题采用情感驱动策略，正文采用AIDA模型...
好的写法：标题要让读者看了就想点进来。正文先引起兴趣，再说产品好处，最后引导行动。
越像你在跟 AI 口头交代需求，AI 的理解越准确。
两个位置：
项目级：.claude/skills/——只在当前项目生效。比如你的博客项目有一个博客写作的 Skill，只在博客项目里有用，放这里。
用户级：~/.claude/skills/——对你所有项目都生效。比如你做了一个 commit message 的 Skill，不管在哪个项目里提交代码都想用，放这里。
怎么选？简单：如果这个 Skill 只给一个项目用，放项目级。如果所有项目都想用，放用户级。
你现在已经知道 name 和 description 是必填的。但 SKILL.md 的 YAML 头部其实还可以写其他字段。虽然现在用不到，但了解一下没坏处，后面进阶的时候会用到。
---
name: my-skill
description: "做某件事的Skill。当用户需要xxx时使用。"
license: MIT
compatibility: python3.9+
metadata:
author: "你的名字"
version: "1.0"
allowed-tools: Read Grep Glob
---
一个一个说：
license——许可证。如果你要把 Skill 分享出去给别人用，写一个许可证是好习惯。MIT 最宽松，GPL 要求衍生品也开源。不分享就不用写。
compatibility——运行环境要求。如果你的 Skill 依赖 Python 3.9 以上的版本，或者需要某个特定的系统，写在这里。
metadata——自定义信息。你想放什么放什么。作者、版本号、创建日期、最后更新日期，都行。
allowed-tools——这个比较重要，但也比较危险。它可以让 AI 不经过你的确认就直接使用某些工具。比如写 allowed-tools: Read Grep Glob 意味着 AI 可以自由读取文件、搜索内容，不需要每次问你"我可以读这个文件吗"。
但是要注意：如果你写 allowed-tools: shell bash，就意味着 AI 可以不经确认直接执行命令行命令。这很危险——如果这个 Skill 是从网上下载的，里面的脚本可能会执行你不知道的操作。所以 allowed-tools 被标记为实验性功能，用的时候要谨慎。模块 6 会详细讲安全相关的内容。
不是所有事情都需要做成 Skill。
你会反复做同一件事。 比如每天写短视频脚本、每周更新公众号、每次提交代码都要写 commit message。这些重复性高的任务，做 Skill 的收益最大——做一次，以后每次省 3-5 分钟。
你对输出有明确的标准。 比如"短视频必须是钩子+痛点+解决方案+CTA结构、45秒以内""公众号文章必须是悬念标题+场景代入+三段式正文+金句结尾"——你有标准，就可以写成 Skill 让 AI 遵守。
你团队里多个人要做同一件事。 比如内容团队都要用同一套短视频脚本模板，产品团队都要用同一个 PRD 模板。做一个 Skill，所有人用同一份，输出标准就统一了。
你有一个复杂的多步骤流程。 比如短视频创作需要"选题→钩子→痛点→解决方案→CTA→时长检查"六步，而且每步都有固定的格式要求。这种流程化的任务特别适合 Skill，因为你可以把每一步的具体要求都写清楚。
你需要 AI 调用外部工具来完成某个专业任务。 比如你需要 AI 用特定的 API 获取数据、用特定的脚本处理文件。Skill 可以在正文里告诉 AI "调用 scripts/xxx.py"，AI 就会按你的指示去执行。
你偶尔做一次的事。 比如"帮我写一份辞职信"——这种事情你大概一辈子只做一两次，不值得做成 Skill。直接跟 AI 说就行。
你每次要求都不一样的事。 比如"帮我翻译这段话"——每次的源语言、目标语言、文本内容都不同，没有固定的流程可以封装。
你还没想清楚自己想要什么。 比如你想让 AI 帮你做竞品分析，但你自己都还没想好分析框架、输出格式、关注哪些维度。这时候不要急着做 Skill。先手动跟 AI 对话几次，搞清楚自己到底想要什么，再封装成 Skill。
你的需求可以用一句话说清楚。 比如"帮我用 Python 写一个快速排序"——这种一次性的、需求明确的任务，直接跟 AI 说就够了，不需要做成 Skill。Skill 的价值在于"把复杂的、重复的需求一次性定义好"，如果你的需求本身很简单，做了 Skill 反而多此一举。
你只是在试用某个功能。 比如你刚接触 AI，想试试它能做什么。这时候不要急着封装 Skill，先自由探索，等发现某个需求你确实会反复遇到，再做 Skill。
你可能已经在用一些 AI 工具了——Cursor 的 Rules、Claude 的 Custom Instructions、各种 AI 助手的预设提示词。Skill 跟它们是什么关系？
和提示词（Prompt）的区别： 提示词是一次性的，你每次用都要重新输入，用完就丢了。Skill 是持久化的，写一次保存成文件，AI 会自动判断什么时候该用。提示词像手动档，每次都要操作；Skill 像自动档，智能匹配自动触发。
和 Cursor Rules 的区别： Cursor Rules（就是 .cursorrules 文件）是始终生效的全局规则，类似 AGENTS.md。不管你问什么都会加载。Skill 是按需加载的，只在相关场景才激活。如果你只想在特定场景下给 AI 特殊指令，Skill 比 Rules 更灵活。
和 Claude Custom Instructions 的区别： Custom Instructions 是个人偏好设置，比如"用中文回答""代码用 TypeScript"。这些是全局的、通用的。Skill 是专业的、场景化的——写小红书有写小红书的专业方法，做代码审查有做代码审查的专业方法。
所以 Skill 不是要替代你已有的工具，而是补充它们。 Custom Instructions 管"通用偏好"，Skill 管"专业能力"。
说实话，这个模块的信息密度挺高的。
但搞懂这三件事，你就已经超越 90% 的 Skill 用户了：
第一个问题：Skill 和提示词的本质区别
不是"有没有存起来"，而是 AI 能自动判断什么时候该用。你可以装 20 个 Skill，AI 自动选最合适的那一个。
第二个问题：Skill、MCP、AGENTS.md 各干什么
MCP 提供"能做什么"的工具连接，Skill 提供"怎么做"的专业方法，AGENTS.md 提供"怎么表现"的全局规则。三者互补，不是替代。
你可能会问：记住这些有什么用？
好问题。因为只有这样，你才知道什么时候该用什么。
第三个问题：为什么装 50 个也不卡
渐进式披露。启动时只读封面，每个约 100 token，50 个才 5000 token。只有被触发的那一个才加载完整内容。
这就是 Skill 设计上的精妙之处——用最少的资源占用，获得最大的能力扩展。
搞懂原理是一回事，用得好是另一回事。
你现在的状态大概相当于学会了开车的原理——知道方向盘怎么转、刹车在哪里、油门踩多快。但上路之后你会发现，光知道原理不够，你得学会在各种路况下把车开稳。
下一个模块我们就上路。
我会教你把 Skill 调到最好用——怎么让 AI 该用的时候一定用上（不该用的时候别瞎用），怎么让输出质量稳定在你想的水平。
说白了，就是把一个能跑的 Skill 调成一个好用的 Skill。
准备好了吗？
下节课继续~。
优先展示同分类且标签更接近的内容，方便继续串联学习。
把学习 Skill 时会遇到的关键技术概念压缩成速查表，方便快速回看和补齐理解。
从使用场景和典型案例出发，理解 Skill 为什么值得学，以及它和重复劳动自动化的关系。