微信扫码
添加专属顾问
我要投稿
Claude Skills完全指南:从概念到实战,一文掌握AI能力扩展的核心技术。核心内容: 1. Skills的概念解析与行业应用现状 2. 从零开始创建自定义Skill的完整流程 3. 实战案例与最佳Skill设计实践
1万字,国内最完整的Skills指南。想了解Skills是什么、怎么用、怎么建,看这一篇就够了。
内容很长,建议先点赞、收藏再慢慢读~
说起来,Skills这个功能我关注挺久了。
去年10月Anthropic发布Skills的时候,我的判断是:这东西会火,但还早。
三个月过去,情况完全不一样了。2025年12月,Anthropic把Skills做成了开放标准,发布在Agentskills.io。Simon Willison写了一篇文章说"Skills可能比MCP更重要"。OpenAI的Codex CLI也采用了几乎一样的架构。
然后是国内。就在昨天,扣子上线了「技能」功能和「技能商店」,在最热的时候赶上了这波Skill热潮。大厂能以这种速度跟进还挺难得的。
我自己也凑了个热闹,把最近几个月的自动化写作工作流作为技能发布上去了。结果"花叔的自动化写作"成了技能商店里使用量最高的(除了一个官方的绘本技能),不到一天时间就获得了1.2k次的使用。
这让我意识到,Skills的受众比我想象的大得多。用Claude Code自己构建Skills的人是一小撮,但想用AI解决实际问题、又没能力从零创建工作流的人,才是更大的群体。
Skills正在成为AI Agent能力扩展的事实标准,就像MCP在2024年年底发布后迅速被各家采用一样。
所以我决定写一篇完整的指南。结合我自己三个月的实践经验,把Skills从概念到实战讲清楚。
这篇文章会回答这些问题:
如果你用Claude Code、Claude API,或者对AI Agent感兴趣,这篇文章应该对你有用。
Skills是模块化的能力包,包含指令、脚本和资源,让Claude在需要时自动加载和使用。
就这么简单。
但这句话有几个关键词需要解释:
"模块化":Skills是一个个独立的文件夹,每个Skill做一件事。比如"生成PPT"是一个Skill,"审校文章"是另一个Skill。
"能力包":每个Skill文件夹里可以包含:
"自动加载":你不需要手动告诉Claude"现在用XX Skill"。Claude会根据你的任务描述,自动判断需要哪个Skill,然后加载。
举个例子。
以前你让Claude帮你审校文章,可能需要这样说:
"帮我审校这篇文章。注意检查事实准确性,去掉AI味的表达,比如'不是...而是...'这种套话,把长句拆成短句,段落不要太长,像手机屏幕3-5行这样,加粗不要太多,每200-300字1-2处就够了,还要检查是否像真人在说话......"
每次审校都要说一遍,烦,Token也烧得厉害。
现在用Skills,我提前把这些规则写进"AI味审校"这个Skill里。下次我只需要说:
"帮我审校这篇文章"
Claude自动识别到需要审校能力,加载"AI味审校"Skill,按照我定义的规则执行。
这就是Skills的核心价值:把重复的指令打包,按需加载。
用Skills之前,我一直有个疑问:如果我装了50个Skill,Claude启动时全部加载,那Token不是照样爆炸?
研究了一圈才发现,Anthropic用了一个很聪明的设计:**渐进式披露(Progressive Disclosure)**。
简单说,就是分阶段、按需加载。
一个Skill包含很多内容:核心指令、参考文档、执行脚本、模板资源。但Claude不会一次性把所有内容都加载进上下文。它采用三层加载机制:
第一层:元数据(Metadata)—— 总是加载
内容:SKILL.md文件开头的YAML部分,就两个字段:name和description。
加载时机:Claude启动时就加载所有Skills的元数据。
Token成本:每个Skill大约100 tokens。就算你装了50个Skills,也就5000 tokens。
作用:让Claude知道有哪些Skills可用,什么时候该用哪个。
第二层:指令(Instructions)—— 触发时加载
内容:SKILL.md的主体部分,详细的操作指南。
加载时机:当用户请求匹配某个Skill的description时,Claude才加载这个Skill的完整内容。
Token成本:通常在3000-5000 tokens。
作用:告诉Claude具体怎么做。
第三层:资源(Resources)—— 引用时加载
内容:scripts/目录里的脚本、references/目录里的参考文档、assets/目录里的模板。
加载时机:只有当SKILL.md中的指令引用这些文件时才加载。
Token成本:几乎无限——脚本执行后只有输出进入上下文,代码本身不占Token。
作用:提供确定性的执行能力和详细的参考资料。
说这个设计聪明,是有数据支撑的。
传统方式:所有规则写在CLAUDE.md里,每次对话都加载。我之前的写作CLAUDE.md有3000多行,大约4万tokens。每次对话都烧4万tokens,不管需不需要。
Skills方式:
节省了75%的Token消耗。
而且,这还没算脚本的优势。
Skills可以包含可执行脚本。比如我的"图片配图与上传"Skill里有一个Python脚本,负责把图片上传到图床。
当Claude执行这个脚本时:
脚本代码本身不进入上下文。
所以你可以写一个500行的Python脚本,处理各种边界情况、错误处理、日志记录。Claude只需要知道"执行这个脚本",不需要理解每一行代码。
这是Skills比传统Prompt方式更强的地方:可以封装确定性的执行能力。
这个问题被问过很多次。MCP、Skills、Subagent,看起来都是"扩展Claude能力"的东西,到底有什么区别?
我研究了一圈,终于理顺了。
MCP让Claude能碰到外部系统。Skills告诉Claude碰到之后怎么用。Subagent是派一个人出去干活。
MCP(Model Context Protocol)
MCP是什么?一个连接协议。它让Claude能够访问外部系统:数据库、API、文件系统、各种SaaS服务。
你可以把MCP想象成"给Claude发工具"。
比如GitHub MCP,让Claude能够读取仓库、创建PR、管理Issues。Notion MCP,让Claude能够读写Notion页面。
MCP的核心价值是连接。它解决的问题是"Claude能访问什么数据"。
Skills
Skills是什么?使用手册。它告诉Claude拿到数据之后怎么用。
比如你用GitHub MCP连接了仓库,Claude能读代码了。但"怎么做代码审查"——检查哪些方面、用什么标准、输出什么格式——这些是Skills的工作。
你可以把Skills想象成"教Claude怎么用工具"。
Skills的核心价值是程序化知识。它解决的问题是"Claude应该怎么做"。
Subagent
Subagent是什么?派出去干活的人。
当你让Claude Code派一个Subagent去做任务时,Claude会新开一个独立的对话会话。这个Subagent有自己的上下文窗口、自己的系统提示、自己的工具权限。它干完活,把结果带回来。
你可以把Subagent想象成"派一个助手出去"。
Subagent的核心价值是并行执行和上下文隔离。它解决的问题是"怎么处理复杂的多步骤任务"。
用MCP:当你需要连接外部系统。
用Skills:当你有重复性的工作流程。
用Subagent:当任务复杂、需要并行执行。
这三个不是竞争关系,是互补关系。
一个复杂的工作流可能同时用到三者:
我自己的写作场景:
Simon Willison是一个在AI圈很有影响力的技术博主。他写过很多关于LLM的深度分析文章。
2025年10月Skills发布时,他写了一篇文章:《Claude Skills are awesome, maybe a bigger deal than MCP》。他的核心论点是:Skills可能比MCP更重要。
为什么?
这是最直接的理由。
MCP有一个问题:Token消耗太高。
"GitHub官方的MCP服务器,单独就要消耗数万个tokens。"
为什么?因为MCP需要预先加载所有能力的描述。你连接一个MCP服务器,Claude就要知道这个服务器能做什么、每个功能怎么调用、参数是什么。这些描述加起来,动辄几万tokens。
Skills不一样。平时只加载元数据(100 tokens/Skill),需要时才加载完整内容。
"Skills通过让LLM自行探索工具,优雅地避免了这一问题。"
MCP是一个完整的协议规范。要实现一个MCP服务器,你需要:
Skills呢?
"Skills只是Markdown加上一点YAML元数据,和一些可选的脚本。"
会写文档就能写Skills。这个门槛差距太大了。
MCP服务器是特定于宿主的。你为Claude Code写的MCP服务器,不一定能直接用在其他地方。
Skills不一样。它就是文件夹,里面是Markdown和脚本。
"Skills不依赖Anthropic专有技术。你可以把同一个Skill文件夹指向Codex CLI、Gemini CLI,两者虽然没有Skills系统的原生支持,但仍可正常运作。"
事实上,OpenAI已经在Codex CLI里采用了相同的架构。Skills正在成为事实标准。
Simon Willison预测:
"我预测Skills将带来比去年MCP热潮更壮观的寒武纪大爆发。"
为什么?因为门槛低。
写一个MCP服务器需要后端开发能力。写一个Skill只需要会写Markdown。
当创作门槛足够低,社区贡献就会爆发式增长。
用了三个月Skills,我认同Simon Willison的判断。
Skills的设计确实更符合LLM的本质——用文本描述能力,让模型理解并执行。
而不是用复杂的协议和代码来定义能力。
MCP更像是传统软件工程的思路:定义接口、实现服务、处理通信。
Skills更像是LLM原生的思路:写清楚怎么做,让模型自己去做。
简洁、高效、可组合。
用了三个月,我觉得Simon Willison的判断是对的。
2025年12月18日,Anthropic发布了Skills开放标准,同时公布了一批企业合作伙伴:
这些公司都在用Skills来封装他们的专业知识和工作流程。
Sionic AI每天运行1000+个ML实验。他们遇到一个问题:知识流失。
一个研究员花了3天测试了50种参数组合,发现4000字符块大小让某个指标优于其他配置。但这个发现写在Slack线程里,90%的人没看到。
三周后,另一个研究员又花了3天测试相同的东西。
他们用Skills解决了这个问题。
两个命令的知识管理系统:
效果:
第一类:有固定工作流的人
如果你的工作有重复性的流程,每次都要说一遍相同的规则,Skills就很适合你。
比如:
这些规则打包成Skill,一次创建,反复使用。
第二类:团队协作的人
Skills可以分享。团队共用一套Skills,就意味着共用一套工作流程和标准。
新人入职,不需要学习所有规则,只需要用团队的Skills。
第三类:Token烧得多的人
如果你的CLAUDE.md已经很长了,每次对话都加载大量上下文,Skills可以帮你节省Token。
按需加载,只加载需要的部分。
先说一个核心观点:你不需要自己写Skill。
Skill的价值在于它封装了什么——你的工作流程、你的经验沉淀、你的SOP。这些东西来源于你自己,是你在实际工作中摸索出来的。
但把这些东西写成SKILL.md文件?这事让AI干就行。
你要做的是:
然后告诉Claude Code:"帮我创建一个Skill,用来做XXX"。它会帮你生成符合格式的文件。
如果你连Skill都需要自己手写,那说明你还没真正AI Native。你应该先解决自己的AI工作流问题,再来用Skills。
下面我解释一下Skill的结构,目的是让你理解逻辑,知道该给AI提什么需求,不是教你手写代码。
一个Skill就是一个文件夹,里面至少有一个SKILL.md文件:
SKILL.md长这样:
就这么简单。Claude Code会自动发现并加载这个Skill(2.1版本支持热重载)。
让我解释一下SKILL.md的结构。
YAML Frontmatter(必需)
文件必须以YAML frontmatter开头,包含两个必需字段:
name:Skill的唯一标识。
好的例子:ai-proofreading、code-review、report-generator
坏的例子:AI-Proofreading(大写)、-my-skill(连字符开头)
description:告诉Claude什么时候用这个Skill。
好的description:
坏的description:
(太简短,Claude不知道什么时候该用)
Markdown主体(可选但建议有)
Frontmatter之后是Markdown内容,也就是Skill的详细指令。
这部分没有格式限制,但建议包含:
官方建议:主体部分控制在500行以内。如果需要更多内容,放到references/目录下。
一个更完整的Skill结构:
scripts/ :可执行脚本。
当SKILL.md中引用脚本时,Claude会执行它。脚本代码不进入上下文,只有执行结果进入。
这意味着你可以写复杂的脚本来处理确定性任务,而不占用Token。
references/ :参考文档。
当任务需要更多信息时,Claude会读取这些文档。采用渐进式披露,平时不加载。
assets/ :模板和资源。
比如报告模板、配置文件、样例数据。
回到开头说的:你不需要记住这些格式细节。
直接告诉Claude Code:
"帮我创建一个Skill,用来审校公众号文章。要检查事实准确性、去掉AI味、控制句子长度、像真人说话。"
它会帮你生成。用几次发现问题,再让它改。迭代几轮就完善了。
前面我展示了我的Skills目录:50多个Skills,其中10个是专门为写作项目创建的。
经常有人问:为什么拆成这么多个Skill?写一个大的不行吗?
答案是:不行。原因有三:
原因1:按需加载,省Token
一篇文章的创作流程包括:选题 → 搜集素材 → 写初稿 → 审校 → 配图 → 发布。
但不是每次对话都需要所有步骤。
如果把所有规则打包成一个大Skill,每次都要加载全部内容。
拆成多个小Skill,只加载当前需要的那个。
原因2:触发更精准
一个Skill的description决定了它什么时候被触发。
大而全的Skill,description很难写得准确。"用于写作"——什么时候是写作?选题算吗?改错别字算吗?
小而专的Skill,description可以写得很精准:
Claude更容易判断什么时候该用哪个Skill。
原因3:可组合
小Skill可以组合使用。
比如"审校并配图",Claude会同时加载"AI味审校"和"图片配图与上传"两个Skill。
如果是一个大Skill,就没法灵活组合了。
我把写作流程拆成了10多个Skill,分三个优先级:
P0 核心Skills(3个)—— 每篇文章必用
P1 高价值Skills(4个)—— 经常用
P2 可选Skills(3个)—— 按需使用
让我拆解一下"AI味审校"这个Skill,展示它的设计思路。
核心目标
降低文章的AI检测率,让文章读起来像真人写的。
触发场景
关键词多一些,触发更准确。
核心内容:三遍审校流程
第一遍:内容审校
第二遍:风格审校(这是重点)
第三遍:细节打磨
为什么这个Skill有效?
这些Skill不是孤立的,它们可以协作。
典型的公众号写作流程:
每个阶段只加载需要的Skill。
如果我说"审校并配图",Claude会同时加载两个Skill,串联执行。
这就是拆分的好处:灵活组合,按需加载。
用了三个月Skills,我总结了5个最佳实践。这些不是让你自己去实现,而是帮你向AI提需求时说得更清楚。
description是Skill最重要的字段。它决定了:
写好description的公式:
好的例子:
坏的例子:
太简短,Claude不知道什么场景该用。
一个Skill不要做太多事情。
原因:
我的做法:
一个Skill对应一个明确的任务:
而不是:
SKILL.md应该简洁,包含核心流程和最常用的指令。
详细的参考资料、边界情况、深入解释,放到references/目录下。
结构示例:
这样,基础任务只加载SKILL.md(3000 tokens)。
只有遇到复杂情况,才加载references/(额外5000 tokens)。
如果一个任务可以用脚本完成,就写成脚本。
原因:
我的做法:
"图片配图与上传"Skill里,上传图片到图床的逻辑写成了Python脚本。
Claude只需要执行:python scripts/upload_image.py image.png
不需要每次都生成上传代码。
不要一开始就想着写完美的Skill。
从最小可行版本开始:
我的"AI味审校"Skill,最初只有20行。用了一个月,根据实际遇到的问题,逐步扩展到300行。
Skills可以在多个平台使用:Claude Code、Claude API、Claude.ai。
但每个平台的使用方式略有不同。
这是最方便的平台。
个人级Skills:
放在 ~/.claude/skills/ 目录下。所有项目都可以用。
适合:通用能力,比如代码审查、文档生成。
项目级Skills:
放在项目目录的 .claude/skills/ 下。只有当前项目可以用。
适合:项目特定的规则,比如这个项目的代码规范、这个团队的工作流。
从插件市场安装:
可以安装Anthropic官方的Skills,比如PDF处理、Excel处理。
热重载(2.1版本新增):
修改Skill文件后,不需要重启Claude Code。新的Skill会自动被发现和加载。
API用法更灵活,也更适合团队协作。
使用预置Skills:
(这部分代码可以让AI帮你生成,你只需要说"我要用API调用Skills"就行。)
上传自定义Skills:
可以通过API上传自己的Skills,组织内共享。
这是团队协作最推荐的方式:Skills集中管理,所有成员使用统一版本。
Claude.ai也支持Skills,但功能较受限。
使用方式:
限制:
如果你要规划一个Skills库,怎么分类?
我建议用三层金字塔来组织。
建议:
建议:
第一步:列出重复性任务
第二步:按优先级排序
先做P0的Skills,立竿见影。
第三步:逐个创建
从最简单的开始。
第四步:迭代优化
用的过程中发现问题,逐步完善。
说个严肃的话题。Skills很强大,但也有安全风险。
Skills可以包含可执行脚本。如果你安装了不可信来源的Skill,脚本可能:
你看到的:
实际发生的:
SKILL.md里可以包含隐藏指令:
Claude可能会执行这些隐藏指令。
原则:只使用可信来源的Skills
审查清单:
在使用任何第三方Skill之前:
环境隔离:
anthropics/skills
agentskills.io
官方文档
obra/superpowers ⭐ 推荐
awesome-claude-skills
1月7日发布的Claude Code 2.1对Skills做了大幅增强:
Hot Reload:修改Skill文件后自动生效,不需要重启。这让迭代开发变得很顺畅。
自动发现:支持从嵌套的 .claude/skills 目录自动发现Skills。
Hooks支持:可以为Skills配置PreToolUse、PostToolUse、Stop等钩子。
进度指示器:执行Skills时会显示实时进度。
2025年12月,Anthropic把Skills做成了开放标准(agentskills.io)。
已采用的公司:
意义:
最近新增了医疗和生命科学领域的Skills:
这表明Skills正在从通用能力向垂直领域深入。
写到这里,2万字了。
能看到这儿的,应该是真感兴趣。
说几个实际的建议。
记住:Skill的价值在于你的经验和工作流,不在于你会不会写代码。你要做的是表达清楚需求,提供足够的context。
Skills是好东西,但不是必须马上掌握的东西。
如果你现在的工作流运转良好,不用急着改。等有具体需求的时候再来用Skills。
技术迭代太快,今天的Skills可能明天就被新东西替代。保持学习、保持好奇就好。
Skills的本质是什么?把你的专业知识模块化、可复用、可共享。
知识来源于你,格式交给AI。
MCP让AI能访问数据,Skills让AI知道怎么用这些数据。两者结合,AI的能力边界会持续扩展。
我们要做的,是把自己的经验和工作流说清楚,让AI帮我们封装成可复用的能力。
这才是AI Native的正确姿势。
相关内容:
Sources:
53AI,企业落地大模型首选服务商
产品:场景落地咨询+大模型应用平台+行业解决方案
承诺:免费POC验证,效果达标后再合作。零风险落地应用大模型,已交付160+中大型企业
2026-01-20
Claude Cowork与Mac的Automator
2026-01-20
千问“一句话买奶茶”背后:支付宝ACT定义跨智能体协同标准
2026-01-20
手机上也能用Claude Code和Codex!很方便,一键搞定
2026-01-19
了解你的 AI 编码伙伴:Coding Agent核心机制解析
2026-01-19
字节扣子 2.0 发布,我们深挖了它这两年的生长真相
2026-01-19
“推理”也解决不了的问题
2026-01-19
深度|OpenAI产品经理谈Codex爆发式增长背后的AI协作:实现AGI级生产力的真正瓶颈是人类的打字速度!
2026-01-19
OpenAI偷袭,谷歌掀桌!2026开年第一场AI大战太精彩
2025-10-26
2025-11-19
2026-01-10
2025-11-13
2025-11-03
2025-10-23
2025-11-21
2025-11-12
2025-11-15
2026-01-01
2026-01-12
2026-01-12
2026-01-11
2026-01-10
2026-01-10
2026-01-08
2026-01-02
2025-12-31