这段时间很多人在研究 Claude Code、OpenClaw、各种 Agent 工具，讨论最多的是模型、插件、自动化流程。
真正决定效率上限的，却往往是一个被忽略的概念：Skills。
一句话解释：
Skills 就是把你的工作方法打包成一个可复用的能力模块，让 Agent 随时调用。
如果理解这一点，很多 AI 自动化体系会突然变得非常清晰。
Skills 本质是什么？
从工程结构看，Skills 其实就是一个标准化的文件夹。
里面通常包含几类非常明确的内容：
| 目录 | 含义 | 类比现实工作 |
|---|---|---|
SKILL.md |
描述这个 Skill 是干什么的 | 岗位说明书 |
scripts/ |
可执行脚本 | 常用工具软件 |
references/ |
业务资料 | 内部知识库 |
assets/ |
模板资源 | 工作模板库 |
当 Agent 工作时，它会自动读取这些内容，然后执行对应的流程。
换句话说：
你不再需要在每一次新对话里重新解释
"输出什么格式""用什么风格""按照什么步骤处理"。
只需要调用 Skill。
AI 就会按照既定流程执行。
一个经常被忽略的好处：Token 节省
在大模型交互里，有一个非常现实的问题：
上下文越长，成本越高，稳定性也会下降。
尤其是 Claude 这种上下文能力很强的模型，Token 的消耗往往非常明显。
传统使用方式通常是这样的：
用户解释背景
用户解释格式
用户解释流程
用户解释风格
模型开始执行每次都要重复一遍。
当对话积累到几十轮之后，上下文就会变得越来越复杂。
而 Skills 的做法完全不同：
大量背景知识被拆到 Skill 目录中。
主对话窗口只保留当前任务。
需要时，Agent 再去读取对应文件。
这就像把资料放进文件柜，而不是全部摊在桌面。
上下文保持干净，Token 使用效率明显提高。
什么情况下适合写 Skill？
有一个非常简单的判断标准：
任何你不想重复解释的事情，都值得做成 Skill。
官方文档通常把使用场景分成三类。
1 组织级工作流
例如：
- 品牌规范
- 法务流程
- 标准文档模板
- 公司内部 SOP
这些东西在企业里几乎每个人都会用到。
如果每次让 AI 帮忙时都重新解释一遍，效率会非常低。
把它们固化为 Skill，整个团队都可以复用。
2 专业领域经验
例如：
- Excel 分析套路
- 数据处理流程
- PDF 自动化脚本
- 代码规范
- 安全审计 checklist
这些通常是个人长期积累的经验。
写成 Skill 后，AI 可以直接按你的方式执行。
3 个人偏好
每个人都有自己的工作习惯。
例如：
- Markdown 笔记结构
- 代码风格
- 研究流程
- 写作模板
Skill 的一个重要作用，就是让 AI 适配你的工作方式。
而不是每次重新训练模型理解你。
如何安装和创建 Skills
常见方式有两种。
命令行安装
最简单的方式就是直接让 Claude 安装。
例如：
arduino
帮我安装这个 skill：
https://github.com/xxx/skill-projectClaude 会自动完成下载和配置。
手动安装
也可以直接放到本地目录：
javascript
~/.claude/skills把 Skill 文件夹复制进去即可。
创建自己的 Skill
常见有两种方式。
基础版（最适合新手）
直接让 Claude 引导创建。
例如：
我要创建一个 Skill
请一步一步带我完成Claude 会生成完整结构，最后输出 zip 包。
安装即可使用。
进阶版
Anthropic 官方提供了一个 Skill：
skill-creator
它可以自动设计 Skill 结构，生成更稳定的能力模块。
很多复杂 Skill 都是通过这个工具生成的。
一个被低估的玩法：把 GitHub 项目变成 Skill
在 Skills 生态里，有一个非常有意思的用法。
把整个 GitHub 项目封装成 Skill。
这个思路来自社区作者卡兹克。
传统使用开源工具通常是这样：
1 阅读文档
2 安装环境
3 运行命令
4 调试
而 Skill 的方式可以变成：
调用这个 Skill
完成 xxx 功能整个过程只需要一句话。
基本步骤
1 复制 GitHub 项目地址
2 告诉 Claude
把这个仓库打包成一个 Skill
实现 xxx 功能3 让 Claude 进入 plan 模式做设计
4 每次踩坑后，把经验更新回 Skill
这一点非常关键。
每一次问题解决，都会沉淀到 Skill。
久而久之，它会变成一个不断进化的工具。
Skills 不只是提示词
很多人以为 Skills 只是提示词集合。
实际远不止如此。
Skill 可以包含 可执行代码。
例如：
- Python
- Node
- Shell
这些脚本通常是提前写好、验证过的。
这样可以解决 AI 生成代码时常见的问题：
| 问题 | 表现 |
|---|---|
| 依赖不稳定 | 今天用 requests 明天换 axios |
| 输出结构不一致 | 每次生成代码都不同 |
| 调试成本高 | 同一个任务反复修改 |
Skill 中的脚本已经固定。
Agent 只负责调用。
结果稳定很多。
一个非常实用的方法论
社区作者宝玉 AI 提出过一个非常有意思的观点：
几乎所有 workflow，都可以用 Agent + Skills 实现。
背后的核心思想可以总结成五步。
第一步：拆分
把复杂工作流拆成多个 Skill 或 subagent。
每个模块只做一件事。
第二步：编排
在主 Skill 中用自然语言描述流程。
一个 Skill 可以调用另一个 Skill。
复杂流程就这样被组合出来。
第三步：存储
所有中间结果保存为文件。
避免长期占用上下文。
第四步：分摊
模块之间只传 文件路径。
不直接传内容。
这样上下文始终保持轻量。
第五步：迭代
Skill 可以持续优化。
当某个流程效果不好时，可以直接让 Claude 修改 Skill 的提示词。
甚至优化 subagent 的 system prompt。
整个系统会逐渐演化。
最重要的一条认知
研究 Skills 之后，最深的感受其实只有一句话：
Skills 固化的是经验。
它记录的是已经验证过的工作方法。
AI 的作用，是自动执行。
并不是替你发明流程。
当一个人拥有稳定的工作流，Skills 的价值会非常明显。
组织也是一样。
优秀团队会把经验沉淀为能力模块。
个人同样可以这样做。
我目前使用的 Skills
目前我安装和自制的 Skills 一共有 13 个，简单整理如下。
| Skill | 功能 |
|---|---|
| podcast-reader | 英文播客文字稿 → 中文结构化大纲 |
| github-to-skills | GitHub 仓库自动转换为 Skill |
| skill-manager | Skills 生命周期管理 |
| obsidian-markdown | Obsidian 风格 Markdown |
| PDF 读取、合并、分割 | |
| skill-evolution-manager | Skill 自动优化 |
| skill-creator | 官方 Skill 创建工具 |
| pptx | PowerPoint 处理 |
| obsidian-bases | Obsidian Bases 文件 |
| video-transcribe | 视频音频转写 |
| frontend-design | 生产级前端界面生成 |
| mcp-builder | MCP Server 构建指南 |
| json-canvas | JSON Canvas 文件 |
其中：
skill-creatorpdfpptxfrontend-designmcp-builder
来自 Anthropic 官方。
而：
github-to-skillsskill-managerskill-evolution-manager
来自社区作者卡兹克的实践。
最后
如果说 大模型是大脑，
那 Skills 更像神经系统。
模型负责思考。
Skills 负责执行。
当你的 Skills 库越来越丰富，Agent 的能力就会越来越稳定。
这时候，AI 才真正开始成为一个可以协作的"数字员工"。