Skills 到底是什么

很多人以为 Skills 就是一个 markdown 文件，写点提示词就完事了。但实际上，Skills 是一个文件夹——里面可以放脚本、参考资料、数据文件、配置模板，Claude 会在需要的时候自己去翻阅和使用这些内容。

换句话说，Skills 更像是你给 Claude 准备的一个"工具箱"，而不是一张"说明书"。

九种值得做的 Skills 类型

Anthropic 团队梳理了内部几百个 Skills 后，发现最好用的那些都清晰地落在某一个类别里，而让人困惑的 Skills 往往横跨了好几个类别。以下是他们总结的九大类型：

1. 库与 API 参考

帮 Claude 正确使用某个库、CLI 工具或 SDK。特别适合内部库，或者 Claude 偶尔会用错的第三方库。通常包含一个参考代码片段文件夹，加上一份"踩坑点"列表。

比如：你的内部计费库有哪些边界情况、内部 CLI 工具每个子命令怎么用、你的设计系统有哪些规范。

2. 产品验证

描述如何测试或验证代码是否正常工作。通常搭配 Playwright、tmux 等工具来完成验证。

Anthropic 的建议是：验证类 Skills 值得安排一个工程师花一整周来打磨。你可以让 Claude 录制测试过程的视频，这样能看到它到底验证了什么；也可以在每一步强制执行程序化的状态断言。

比如：在无头浏览器里跑完注册→邮件验证→引导流程，每步插入断言；用 Stripe 测试卡跑结账流程，验证发票状态是否正确。

3. 数据获取与分析

连接你的数据和监控体系。这类 Skills 可能包含数据获取的凭证、仪表盘 ID、常用查询模式等。

比如："要看注册→激活→付费的转化漏斗，需要关联哪些事件表？"或者 Grafana 数据源 UID 和集群名称的对照表。

4. 业务流程与团队自动化

把重复性工作流变成一条命令。这类 Skills 指令通常比较简单，但可能会调用其他 Skills 或 MCP 服务。一个小技巧：把之前的执行结果保存在日志文件里，Claude 下次运行时就能知道"上次做到哪了"。

比如：自动汇总任务追踪器和 GitHub 活动生成站会汇报；自动创建工单并通知审查者；自动生成包含已合并 PR 和已关闭工单的周报。

5. 代码脚手架与模板

为特定功能生成框架样板代码。当你的脚手架需求有自然语言的成分、不能纯靠代码生成器覆盖时，这类 Skills 特别好用。

比如：用你的注解搭建新的服务或工作流；数据库迁移文件模板加上常见踩坑点；新建内部应用并预配好认证、日志和部署。

6. 代码质量与审查

在团队内部执行代码质量标准。可以包含确定性的脚本来保证可靠性，也可以作为钩子自动运行，或放在 GitHub Action 里执行。

一个特别有意思的做法：生成一个全新的子智能体来做代码审查——因为这个新实例"没见过这段代码"，不会有原来那个实例的思维惯性，能真正挑出问题来。

7. CI/CD 与部署

帮你管理代码从提交到上线的全过程。比如：监控一个 PR，自动重试不稳定的 CI，解决合并冲突，启用自动合并；或者构建→冒烟测试→渐进式流量切换→指标恶化时自动回滚。

8. 运维手册

接收一个现象（一条告警、一个错误），引导你走完排查流程，最后输出结构化报告。比如：拉取告警→检查常见原因→格式化输出排查结论；或者给定一个请求 ID，从所有相关系统中拉取匹配日志。

9. 基础设施运维

执行日常维护和运维操作，其中一些涉及破坏性操作，需要安全护栏。比如：找到孤立的 Pod 或 Volume，发到 Slack 等用户确认后再清理；或者排查"存储费用为什么突然涨了"。

写好 Skills 的七个实战技巧

确定了做什么类型之后，怎么写才能写好？以下是 Anthropic 内部总结的关键方法。

不要说 Claude 已经知道的事。 Claude 对代码库和编程本身已经很了解了。如果你的 Skills 主要是提供知识，把重点放在能打破 Claude 默认思维模式的信息上。Anthropic 有个 frontend design 的 Skill，就是专门避免 Claude 默认会用的那些"典型套路"——比如 Inter 字体和紫色渐变。

建一个踩坑点章节。 任何 Skill 中信息量最大的部分就是踩坑点。这些应该根据 Claude 在实际使用中遇到的常见失败点逐步积累。不是一次写完，而是持续更新。

利用文件系统做渐进式披露。 不要把所有信息塞进一个 markdown 文件里。把详细的 API 签名拆到 references/api.md，把输出模板放在 assets/ 目录下，让 Claude 在需要时再去读取。这样既节省上下文窗口，又保证信息随时可用。

不要把 Claude 限制得太死。 Skills 的复用性很强，如果指令写得太具体，到了不同场景就不适用了。给 Claude 必要的信息，但留给它适应具体情况的灵活性。

考虑好初始设置。 有些 Skills 需要用户提供配置信息。好的做法是把这些设置存在 Skill 目录下的 config.json 里。如果配置还没设好，Claude 就会主动问用户。

description 字段是给模型看的。 Claude 启动会话时会扫描所有 Skills 的描述来判断"这个请求该用哪个 Skill"。所以 description 不是功能说明，而是触发条件——写法应该更像"当用户要做 X 的时候使用"，而不是"这个 Skill 能做 X"。

给 Claude 提供脚本和代码库。 你能给 Claude 的最强大工具就是代码。提供现成的脚本和函数库，让 Claude 把精力花在编排和组合上，而不是重新造轮子。比如在数据分析的 Skill 里放一组从事件源获取数据的函数，Claude 就能即时生成脚本来组合这些功能，回答"周二发生了什么"这样的问题。

按需钩子：一个巧妙的用法

Skills 可以包含只在被调用时才激活的钩子，并在整个会话期间保持生效。这适合那些有用但不该一直开着的功能。

两个例子：

  • /careful — 拦截 rm -rf、DROP TABLE、force-push、kubectl delete 等危险命令。只在操作生产环境时才需要开启。
  • /freeze — 阻止对特定目录之外的任何编辑操作。调试时特别有用："我只想加日志，别让 Claude 顺手'修'了不相关的代码。"

怎么在团队里推广

分享 Skills 有两种方式：提交到代码仓库的 .claude/skills 目录下，或者搭建一个内部插件市场。

小团队直接提交到仓库就够了。但要注意，每个提交进去的 Skill 都会给模型的上下文增加一点负担。团队规模大了之后，内部插件市场能让大家自己决定安装哪些。

Anthropic 的做法是不设专门的审核团队，而是让最有用的 Skills 自然涌现。有人做了一个新 Skill，先放到一个沙盒文件夹里让大家试用，获得足够关注后再正式提交。但他们也提醒：创建质量差或重复的 Skills 很容易，正式发布前一定要有审核机制。

要衡量 Skills 的效果，可以用 PreToolUse 钩子记录使用情况，看哪些 Skills 受欢迎、哪些触发频率低于预期。

这套方法论的核心其实很简单：先从几行文字和一个踩坑点开始，在实际使用中不断补充 Claude 遇到的新边界情况，让 Skill 自然生长。不需要一开始就追求完美，重要的是动手做起来，然后持续迭代。