Claude正式推出「Skills」指南：普通人也能创作自己的工作流

前几天，Claude 官方面向开发者发布了一篇长文，系统讲清楚了一个概念：Skills（技能）。如果你平时也在用 Claude，但大多数时候还停留在“丢一个问题、等一个回答”的模式，那这篇文章，其实是在邀请你升级到下一阶段——不再只是用 AI，而是开始“教” AI。

Claude Skills

这篇指南不短，信息量也挺大。我试着把它拆解成三个问题来聊：

Claude 口中的 Skills 到底是什么？

这篇官方文章想教大家什么用法？

对于个人用户，我们应该怎么学、怎么练？

一、Skill 到底是什么？一句话版和认真版

先给一个一句话版的理解：Skill 就是把你的一套固定做事方法，打包成一个 Claude 能看得懂、能复用的小“能力包”。

平时我们用 Claude，更多是这样：

“帮我写一个周报。”

“帮我整理一份访谈纪要。”

“帮我把这段代码优化一下。”

每次都是一次性的对话，你要反复讲背景、讲偏好、讲格式要求。Claude 很聪明，但你很累。

而在官方的定义里，一个 Skill 是一个文件夹，通常至少包含几类东西：

1， SKILL.md：写清楚“这是什么技能”“什么时候用”“怎么用”的说明书；

2， scripts/：如果需要，可以放上一些脚本代码，做固定的数据处理、校验等；

3， references/、assets/：模板、范文、参考文档、图片资源等等。

更重要的是，它有一个很有意思的设计——“渐进式暴露”：

— 最上面那段 YAML frontmatter，是 Claude 一直会读到的“名片”，用来判断什么时候该把这个技能叫出来；

— 真正的详细说明在 SKILL.md 里，只在相关时才会被加载；

— 特别长的文档、细节和模板，再放到 references/ 里，Claude 需要时再打开。

你可以把它想象成：“我把自己这套做事方法写成一本小册子，放在 Claude 触手可及的地方。以后只要对话触发到这个主题，Claude 就会自动翻我的‘小册子’。”

Skills 结构

二、这篇官方指南，其实在教三件事

那 Claude 这篇《The Complete Guide to Building Skills for Claude》到底讲了什么？我把它拆成三大块。

1. 先想清楚：你到底想用 Skill 解决什么？

文章一上来就强调一件事：不要一上来就写代码、写配置，而是先想清楚 2–3 个具体用例。

比如：

— “帮我做一次完整的 Sprint 规划”；

— “帮我把访谈录音整理成结构化调研报告”；

— “每次写需求评审文档时，都帮我按照团队固定模板来。”

一个好的用例，至少要能回答清楚：

— 用户想完成什么结果？

— 这件事通常分几步？

— 中间要用到哪些工具（内置的，还是 MCP 提供的）？

— 有哪些“经验性判断”和“坑”，是你希望 AI 也能学会的？

只有问题足够具体，后面的 Skill 才有东西可以“固化”。

2. Skill 要长什么样：结构和“触发逻辑”

第二块内容，是在教你“Skill 长什么样”。

从技术结构上看，其实很简单：

— 一个以 kebab-case 命名的文件夹（如 sprint-planning）；

— 一个严格命名为 SKILL.md 的主文件；

— 可选的一些 scripts/、references/、assets/ 子目录。

但真正关键的是 SKILL.md 里的两部分。

第一部分是 YAML frontmatter，也就是那段：

— name：技能名（要规范地用 kebab-case）；

— description：一句清晰的话，既说明“做什么”，又说明“什么时候用”，最好顺带把用户可能说出口的触发语写进去；

— 其他可选字段：版本、作者、关联的 MCP 服务器、标签等。

这一段决定了：Claude 在什么样的问题下，认为“哦，现在可以把这个 Skill 叫出来了”。

第二部分是正文说明，也就是你和 Claude 的“约法三章”：

— 先写清楚适用场景、输入输出的大致形态；

— 再把步骤拆开，哪一步需要问用户问题、哪一步要调用工具、遇到错误怎么处理；

— 长文档、模板、规范不要全部堆在这里，而是移动到 references/ 等目录，用链接指过去。

官方在文中给了很多“好描述”和“坏描述”的例子，核心就一句话：

— 好的 description，是一个同时说清“我是谁”和“什么时候找我”的自我介绍；

— 坏的 description，要么太抽象（听起来什么都能做），要么没有触发语（Claude 不知道什么时候该想起你）。

3. 不只是“能跑就行”，还要会测、会迭代

第三块，是在讲 Skill 怎么测试、怎么打磨。

他们提出了几个维度：

— 触发是否准确：

— 在该触发的请求上，大多数时候能自动出现；

— 在明显无关的请求上，不要频繁乱入。

— 功能是否可靠：

— 多次尝试，输出结构稳定；

— 调用了外部工具时，错误可以被识别和处理，而不是静静失败。

— 是否真正“省事”：

— 同一个任务，用 Skill 比不用 Skill，是不是能少聊几轮、少踩几次坑？

这部分的潜台词是：Skill 不是“写完就上传”，而是一个可以迭代的“活文档”。你在真实使用中遇到的问题，应该不断回流到 SKILL.md 里，变成更明确的说明和更可靠的流程。

流程

三、个人用户可以怎么学、怎么练？

这些听起来很“工程师”，但其实个人也完全用得上。我的建议是分三步走。

1. 先从“认知升级”开始

先把自己从“提示词玩家”的身份里拉出来，换一个视角看 Claude：

— 提示词，是一次性的“口头吩咐”；

— Skill，是一份可存档、可复用的“操作手册 + 模板 + 经验”。

所以，下次你在用 Claude 的时候，可以多问一句：

“这件事情，我是不是已经做了很多遍？能不能把我现在这套做法，写成一个 Skill，以后就不用每次重新讲了？”

当你开始这么想的时候，其实已经在用 Skill 的思维了。

2. 挑 1–2 个自己最熟的场景，照着指南做一遍

不用贪多，就选一个你最常做、最烦重复解释的任务：

比如“写周报”，你可以：

— 写清楚周报的固定结构、语气、字数；

— 告诉 Claude 哪些信息是必须问你的（比如本周关键成果、下周重点）；

— 把你喜欢的模板、过往的好例子，放到 references/ 里。

又比如“整理访谈纪要”，你可以：

— 固定一个提纲：背景、关键信息、用户原话、洞察、后续问题；

— 写清楚：先粗整理，再结构化，再提炼观点；

— 把你常用的格式要求、注意事项也写进去（比如敏感信息要脱敏）。

然后，就按照官方指南提的几个步骤，走完一遍：

— 先写出 2–3 个清晰用例；

— 写一个“说人话”的 description；

— 在 SKILL.md 里把流程拆开写清楚；

— 在 Claude 里实际触发几次，看看什么时候会把这个 Skill 叫出来，不合适的地方再改。

你会发现，这个过程本身，就是在逼你把“模糊的经验”变成“清晰的步骤”，顺手也把自己的方法论梳理了一遍。

3. 如果你有工具接入，再慢慢往 MCP 方向扩展

对普通个人来说，其实只用“纯说明型”的 Skill 就已经很够用。但如果你恰好也有接入一些工具（比如 Notion、日程、任务管理、代码仓库等 MCP），那可以慢慢往下一步走：

— 先想清楚：在这些工具之上，你最常做的“成套动作”是什么？

— 然后在 Skill 里，用自然语言写清楚：

— 第一步调用哪个工具、拿什么数据；

— 第二步怎么分析、过滤；

— 第三步把结果写回哪个系统。

这时候，Skill 不再只是“帮你写文档”，而是在帮你“调度一整套工具”。你会明显感觉到，Claude 从一个聊天助手，变成了一个“会照你流程办事的数字实习生”。

四、写在最后的总结

本文主要参考自 Anthropic 官方发布的《The Complete Guide to Building Skills for Claude》。这是一篇面向开发者的 Skills 构建指南，系统介绍了 Skills 的概念、结构、常见模式以及测试和分发方法。感兴趣的话，可以在 Claude / Anthropic 的官方文档与开发者博客中找到完整版英文原文。

Skills主要做了两件事：

1，封装了使用者重复的工作流，也就是说需要重复调用的内容或功能，都可以封装成Skill；

2，Skill中涵盖了脚本，可以自己去创建当做一个子Agent让AI调用；

3，Skill中可以加入自己的知识文档、模板等资源文件，让AI知道你、知道你的输入输出习惯，更了解你，从而给你更精准的东西。

等用了skills后，也许你会发现，你和“会写工具的人”之间，其实只差一份 SKILL.md。

附：文档是英文的，我也做了翻译：

译文出处：

https://resources.anthropic.com/hubfs/The-Complete-Guide-to-Building-Skill-for-Claude.pdf

原文出处：

通过网盘分享的文件：

https://pan.baidu.com/s/1kZanf9XUvDVHXDtlG9WiCQ?pwd=njbx