--- title: "搞懂 Skill 到底怎么回事" wiki: skills category: "基础概念" slug: M02-搞懂Skill到底怎么回事 url: https://learnagent.wiki/skills/cards/M02-搞懂Skill到底怎么回事 tags: ["Skill 原理", "Prompt", "Agent", "MCP"] last_updated: 2026-04-11 reading_time: 28 --- > > 模块2：搞懂Skill到底怎么回事 | 用时：约15分钟 | 目标：理解Skill的本质、渐进式披露机制、和MCP/AGENTS.md的区别 # Skill 从小白到高手系列课 > 模块2：搞懂Skill到底怎么回事 | 用时：约15分钟 | 目标：理解Skill的本质、渐进式披露机制、和MCP/AGENTS.md的区别 --- 做完模块1，你应该已经做出了第一个能用的 Skill——不管是周报生成器、小红书写作助手，还是别的什么。 能用，但说实话，心里有点虚——这东西到底怎么回事？为什么放一个文件 AI 就"学会"了？ 你可能会问：这跟我把提示词保存在备忘录里有啥区别？ 好问题。 说实话，我自己刚接触 Skill 的时候也没太当回事，觉得不就是把提示词存了个文件嘛。后来越用越觉得不对劲——Skill 跟提示词的差距，比自行车跟电动车的差距还大。 我花了差不多一周时间才把几个核心概念理清楚，这个模块帮你把这周的路压缩到 15 分钟。 我们要搞清楚三件事： - Skill 和你平时用的提示词到底有什么本质区别？ - Skill、MCP、AGENTS.md 这几个概念怎么区分？ - 为什么装 50 个 Skill 也不会卡？ 话不多说，我们一层一层扒开来看。 --- ## 先给大家看：Skill 不是"保存了一个提示词" 很多人第一次接触 Skill，第一反应是"这不就是把提示词存起来了嘛"。 最开始我也这么想的。后来发现自己错得离谱。 说白了，这里面的门道比你想象的要深得多。 ### 用个真实案例，你就懂了 假设你是个短视频创作者，每天要写抖音/视频号的脚本。 用普通提示词的方式是这样的： ``` 你：帮我写一个关于"职场焦虑"的短视频脚本，要钩子开头，带点反转，结尾引导点赞关注 AI：好的，以下是一个短视频脚本： 开头：你是不是也经常感到焦虑？ 中间：其实焦虑是因为... 结尾：觉得有道理的点个赞... 你：开头太平了，不够抓人。要用那种"痛点暴击"式的钩子 AI：好的，我重新写开头： 开头：90%的职场人都在硬撑... 你：还是不够狠，要像"凌晨2点，我又在厕所偷偷哭了"这种具体的场景 AI：好的，开头改成：凌晨2点，我又在厕所偷偷哭了... （但你心里在想：为什么我每天都要来一遍这个流程？） ``` 你看看，写一个脚本，来回拉扯了四五轮。第一天还能忍，第二天有点烦，到第五天你就不想跟 AI 说话了。 更要命的是什么？是你的"钩子套路""反转结构"这种东西，新对话就全没了。你精心调出来的开头方式、情绪节奏、CTA话术，全是一次性的。明天又得从头来。 ### 换成 Skill 之后呢？ 你提前写了一个短视频脚本 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 能做到。 --- ## Skill、MCP、AGENTS.md — 到底谁干什么 现在 AI 工具圈子里有几个概念经常被搞混：Skill、MCP、AGENTS.md。说实话，我之前也被绕晕过。 后来用一个真实的场景想明白了。 假设你要让 AI 帮你做代码审查。 ### MCP 干的事——提供工具连接 MCP 让 AI "能"访问 GitHub。说白了就是在 AI 和 GitHub 之间搭一座桥： ```json // 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 干的事——提供专业方法 Skill 告诉 AI "怎么做"一次代码审查： ```markdown --- 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 干的事——通用行为规则 AGENTS.md 里写的是全局规范，如"用中文回答""代码用 4 空格缩进"。不管你问什么都会生效。 ### 一句话总结：MCP 让模型能够做，Skill 告诉模型怎么做。 | 维度 | MCP | Skills | |------|-----|--------| | 核心问题 | 能不能连接 | 知道怎么做 | | 类比 | 厨房里的刀/锅/灶 | 红烧肉食谱 | | 上下文策略 | 急切加载（~16k token） | 渐进式披露（~100 token） | | 典型内容 | JSON Schema、API 签名 | 工作流、最佳实践、示例 | | 加载时机 | 启动时全部加载 | 按需触发加载 | 这三者互补：MCP 解决"能不能做"，Skill 解决"怎么做"，AGENTS.md 解决"怎么表现"。 --- ## 渐进式披露——Skill 最聪明的设计 这是 Skill 最核心的技术创新，也是它能碾压"保存提示词"方案的根本原因。 说实话，我第一次理解这个机制的时候，是真的拍了一下桌子——设计得太巧妙了。 ### 先给大家看：AI 的"记忆"是有限的 AI 有一个叫做"上下文窗口"的东西。你可以理解为 AI 的短期记忆。 这个记忆是有上限的。目前主流模型一次对话能处理大约 200,000 个 token。一个 token 大约等于一个中文字或者半个英文单词。200,000 token 听起来很多，但实际用起来很快就满了。 你的对话历史、AI 的回复、工具的输出，全部都要塞进这个窗口里。 这就带来一个问题：**如果你一次性把 50 个工具的说明书全塞进去，AI 的"记忆"就满了，没有空间思考你的问题。** MCP 就有这个问题。 ### 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 的加载方式：渐进式披露 Skill 的设计完全不同。**它不是一次性全塞进去，而是分三层，按需加载。** 我一层一层给你讲。 #### 第一层：只看封面——大约 100 token AI 启动的时候，扫描 `.claude/skills/` 目录下所有的 SKILL.md 文件。但它不读正文，只读 YAML 头部的 `name` 和 `description` 两个字段。 比如你的短视频脚本 Skill： ```yaml name: short-video-script description: "生成抖音/视频号短视频脚本。当用户需要写短视频脚本、口播文案、钩子开头内容时使用。输出包含：钩子+痛点+解决方案+CTA结构，预估时长。" ``` 再比如你的公众号爆款写作 Skill： ```yaml name: wechat-burst-article description: "生成公众号爆款文章。当用户需要写公众号文章、爆款文案、高打开率内容时使用。输出包含：悬念标题+场景代入+三段式正文+金句结尾。" ``` 就这两行，大约 100 个 token。AI 就知道"哦，我有写短视频脚本和公众号爆款的能力"。 如果你装了 50 个 Skill，每个的"封面"只占 100 token，总共才 5,000 token。 **5,000 token vs MCP 一个服务器就 16,000 token。差距一目了然。** #### 第二层：翻开看内容——大约 1,000-5,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 启动时只认识三个书名。只有当你明确说"写个短视频"，它才加载短视频那本的正文。其他两本原封不动待在书架上。 **这就是渐进式披露——按需加载，不浪费一个字节。** --- ## Skill 的文件长什么样 ### 最简形式 你在模块 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 解读的二进制文件。 ### 说实话：什么时候加 scripts/ 和 references/ 这里有个坑要注意：**不要提前加。** 先用一个 SKILL.md 跑起来。等你发现 AI 用自然语言搞不定某些操作（比如精确计算、二进制文件处理），再加 scripts/。等你发现 SKILL.md 正文太长了，再加 references/。 这就叫"最小可用先行"——先跑起来，再逐步扩展。 很多人犯的错误是一上来就设计复杂的目录结构。其实 90% 的场景，一个 SKILL.md 就够了。我自己的 Skill 十个里面有八个就一个文件。 --- ## SKILL.md 正文写作技巧 你现在已经知道正文是给 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 有时会跳步、有时会合并步骤。你就把它当成给实习生派活——说清楚第一步干什么、第二步干什么，他才不会乱。 ### 技巧五：正文控制在 200 行以内 正文不是越长越好。太长的正文有两个问题：一是浪费上下文空间，二是 AI 容易"顾此失彼"——看了后面忘了前面。 200 行（大约 2000-3000 token）是一个比较好的上限。如果你的内容确实很多，把详细部分拆到 references/ 目录下，正文里只写"当需要XX时加载 references/XX.md"。 ### 技巧六：用你平时说话的方式写 正文不是给编译器看的，是给 AI 看的。用大白话、短句、直接说要求就行。不需要写成技术文档的格式，也不需要用专业术语。 ``` 差的写法：输出应遵循以下范式——标题采用情感驱动策略，正文采用AIDA模型... 好的写法：标题要让读者看了就想点进来。正文先引起兴趣，再说产品好处，最后引导行动。 ``` 越像你在跟 AI 口头交代需求，AI 的理解越准确。 --- ## Skill 存放在哪里 两个位置： **项目级**：`.claude/skills/`——只在当前项目生效。比如你的博客项目有一个博客写作的 Skill，只在博客项目里有用，放这里。 **用户级**：`~/.claude/skills/`——对你所有项目都生效。比如你做了一个 commit message 的 Skill，不管在哪个项目里提交代码都想用，放这里。 怎么选？简单：**如果这个 Skill 只给一个项目用，放项目级。如果所有项目都想用，放用户级。** --- ## 补充：YAML 头部的完整字段说明 你现在已经知道 name 和 description 是必填的。但 SKILL.md 的 YAML 头部其实还可以写其他字段。虽然现在用不到，但了解一下没坏处，后面进阶的时候会用到。 ```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，什么时候不该用 不是所有事情都需要做成 Skill。 ### 适合做 Skill 的场景： **你会反复做同一件事。** 比如每天写短视频脚本、每周更新公众号、每次提交代码都要写 commit message。这些重复性高的任务，做 Skill 的收益最大——做一次，以后每次省 3-5 分钟。 **你对输出有明确的标准。** 比如"短视频必须是钩子+痛点+解决方案+CTA结构、45秒以内""公众号文章必须是悬念标题+场景代入+三段式正文+金句结尾"——你有标准，就可以写成 Skill 让 AI 遵守。 **你团队里多个人要做同一件事。** 比如内容团队都要用同一套短视频脚本模板，产品团队都要用同一个 PRD 模板。做一个 Skill，所有人用同一份，输出标准就统一了。 **你有一个复杂的多步骤流程。** 比如短视频创作需要"选题→钩子→痛点→解决方案→CTA→时长检查"六步，而且每步都有固定的格式要求。这种流程化的任务特别适合 Skill，因为你可以把每一步的具体要求都写清楚。 **你需要 AI 调用外部工具来完成某个专业任务。** 比如你需要 AI 用特定的 API 获取数据、用特定的脚本处理文件。Skill 可以在正文里告诉 AI "调用 scripts/xxx.py"，AI 就会按你的指示去执行。 ### 不适合做 Skill 的场景： **你偶尔做一次的事。** 比如"帮我写一份辞职信"——这种事情你大概一辈子只做一两次，不值得做成 Skill。直接跟 AI 说就行。 **你每次要求都不一样的事。** 比如"帮我翻译这段话"——每次的源语言、目标语言、文本内容都不同，没有固定的流程可以封装。 **你还没想清楚自己想要什么。** 比如你想让 AI 帮你做竞品分析，但你自己都还没想好分析框架、输出格式、关注哪些维度。这时候不要急着做 Skill。先手动跟 AI 对话几次，搞清楚自己到底想要什么，再封装成 Skill。 **你的需求可以用一句话说清楚。** 比如"帮我用 Python 写一个快速排序"——这种一次性的、需求明确的任务，直接跟 AI 说就够了，不需要做成 Skill。Skill 的价值在于"把复杂的、重复的需求一次性定义好"，如果你的需求本身很简单，做了 Skill 反而多此一举。 **你只是在试用某个功能。** 比如你刚接触 AI，想试试它能做什么。这时候不要急着封装 Skill，先自由探索，等发现某个需求你确实会反复遇到，再做 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。 准备好了吗？ --- *下节课继续~。* --- *Source: https://learnagent.wiki/skills/cards/M02-搞懂Skill到底怎么回事* *Markdown mirror of https://learnagent.wiki, served as text/markdown for LLM ingestion.*