当前位置：首页 > news >正文

Claude Skills 高阶玩法：让你的 Skill 从“能用“变成“好用“

news 2026/7/4 22:58:14

📖 前置阅读：
Claude Skills 入门指南：5分钟掌握 AI 的新超能力
从零到一：手撸一个让队友追着夸的 Claude Skill

前言：一个 Skill 引发的"血案"

我有个朋友（真的是朋友，不是我），写了一个处理 PDF 的 Skill。功能很全，表单填充、文本提取、合并拆分一应俱全。

问题是——这玩意儿太"胖"了。

SKILL.md 写了 800 多行，把所有功能的说明、示例、边界情况全塞进一个文件。结果每次 Claude 需要处理 PDF，都要把这 800 行全读一遍。

上下文？挤爆了。
响应速度？慢了一拍。
Token 费用？月底看账单脸都绿了。

后来他学了一招叫"渐进式披露"，把 Skill 拆成了多个文件，根据需要动态加载。

效果？同样的功能，Token 消耗砍掉了 60%。

今天这篇，就是要教你这些"从能用到好用"的进阶技巧。

一、渐进式披露：Skills 的核武器级设计

什么叫"渐进式披露"？

简单说，就是不要一股脑把所有东西都塞给 Claude。

想象一下去餐厅点菜：

❌传统方式：服务员把整本菜单念一遍，包括你根本不想吃的闽南小碗菜和西北大盘鸡

✅渐进式：服务员先问"吃川菜还是粤菜？"，你说川菜，他再给你看川菜那页

Skills 的设计也是这个思路：

┌──────────────────────────────────────────┐ │ 第1层：名字 + 简介 │ │ → 永远加载，就像菜单的目录 │ │ → 只花 ~50 个 tokens │ ├──────────────────────────────────────────┤ │ 第2层：SKILL.md 主体 │ │ → Claude 判断需要时才读 │ │ → 花 500-2000 个 tokens │ ├──────────────────────────────────────────┤ │ 第3层：额外文件（reference.md 等） │ │ → 处理特定子任务时才读 │ │ → 可以无限扩展 │ └──────────────────────────────────────────┘

这设计有多牛逼？

来算笔账：

方式	装 100 个 Skill	用 1 个 Skill
传统（全加载）	~100,000 tokens	-
渐进式	~5,000 tokens	再加 500-2000

省了 95%！

这意味着你可以给 Claude 装一个"百科全书式"的技能库，但日常对话轻如羽毛。

什么时候该拆文件？

当你的 SKILL.md 有这些症状：

信号	诊断	处方
超过 500 行	太胖了	拆分到多个文件
A 和 B 不会同时用到	互斥内容	分别放独立文件
大段 API 文档	参考资料过重	移到 reference.md
示例比正文还长	示例喧宾夺主	移到 examples.md

二、脚本的艺术：什么该代码化

Skills 里的代码有两种用法：

用法	说明
当工具用	Claude 直接执行脚本
当文档读	Claude 读代码学习用法

什么任务该写成脚本？

记住一个原则：确定性的事情交给脚本，创造性的事情交给 Claude。

场景	用脚本？	理由
校验文件格式	✅ 是	规则确定，代码更快更准
数据格式转换	✅ 是	专业库比 LLM 可靠
复杂计算	✅ 是	代码算得又快又对
写营销文案	❌ 否	LLM 更擅长
生成代码	❌ 否	LLM 更灵活

Python 还是 Bash？

需要复杂逻辑？ └─ 是 → Python（强类型、丰富的库、更好的错误处理） └─ 否 → 需要调用命令行工具？ └─ 是 → Bash（直接、简洁） └─ 否 → 不需要脚本

脚本设计的黄金法则

写给 Claude 用的脚本，要遵循这几条：

1. 输出用 JSON

# ❌ 人类友好但 Claude 难解析print("处理了 5 个文件")# ✅ Claude 友好print(json.dumps({"success":True,"files_processed":5,"error":None}))

2. 必须有成功/失败标志

{"success":True,# 或 False"data":{...},"error":None# 或 "具体错误信息"}

3. 错误信息要详细

# ❌ 这叫糊弄"error":"失败了"# ✅ 这叫专业"error":"找不到文件 /path/to/file.pdf，请确认路径是否正确"

4. 开头写文档字符串

#!/usr/bin/env python3""" 脚本: extract_text.py 功能: 从 PDF 提取文本 用法: python extract_text.py <input.pdf> [--page N] 输出格式: JSON """

这样 Claude 读一下开头就知道怎么用。

三、权限控制：让 Skill 有边界

allowed-tools 是什么？

Skill 的 frontmatter 里可以加一个allowed-tools字段，限制这个 Skill 能用哪些工具。

为什么需要这个？

想象一下：你写了一个"代码审查"Skill，它的任务是看代码提建议。

如果不加限制，Claude 可能"好心办坏事"——直接上手改了你的代码。

加上allowed-tools，就能确保它只读不写。

常用工具及风险级别

工具	干嘛的	风险
`Read`	读文件	🟢 低
`Grep`	搜索内容	🟢 低
`Glob`	找文件	🟢 低
`Write`	写文件	🟡 中
`Edit`	编辑文件	🟡 中
`Bash`	跑命令	🔴 高
`WebSearch`	上网搜	🟡 中

只读 Skill 模板

--- name: code-reviewer description: 审查代码质量，只看不改。 allowed-tools: Read, Grep, Glob --- # 代码审查助手 ## 我能做的 ✅ - 读取和分析源代码 - 搜索代码中的模式 - 查找特定文件 ## 我不能做的 ❌ - 修改任何文件 - 执行命令 - 发网络请求 ## 这样设计的原因 代码审查就应该是纯观察行为。 如果审查的时候还能改代码，谁知道审出来的是"发现问题"还是"制造问题"？

安全敏感场景示例

处理生产日志时：

--- name: log-analyzer description: 分析应用日志，只读操作，可安全用于生产环境。 allowed-tools: Read, Grep --- # 日志分析器 ⚠️ **安全说明**：这个 Skill 故意只开放只读权限，确保不会对生产日志有任何误操作。

四、Skills + MCP：左右互搏术

它们是什么关系？

很多人问：Skills 和 MCP 是不是竞争关系？

不是。它们是"搭档"。

MCP：给 Claude 提供"API 接口"
Skills：教 Claude 怎么高效地用这些接口

打个比方：

MCP 是给你一把瑞士军刀。
Skills 是给你一本《瑞士军刀使用指南》。

刀再好，不会用也是白搭。

协作架构

┌─────────────────────────────────────────────────┐ │ │ │ MCP Server Skill │ │ ┌──────────┐ ┌──────────┐ │ │ │ GitHub │◄── 教用法 ─┤ GitHub │ │ │ │ API │ │ Workflow │ │ │ └──────────┘ └──────────┘ │ │ │ │ │ │ └──────────┬───────────┘ │ │ │ │ │ ▼ │ │ Claude Agent │ │ │ └─────────────────────────────────────────────────┘

实战：用 Skill 指导 MCP

假设你装了 GitHub MCP，可以调用 GitHub API。但是——

API 能调用 ≠ 调用得好。

比如创建 Issue，Claude 可能：

忘了检查有没有重复 Issue
不知道该加什么标签
不会关联相关 PR

这时候，一个 “github-workflow” Skill 就派上用场了：

--- name: github-workflow description: GitHub 操作的最佳实践，配合 GitHub MCP 使用。 --- # GitHub 工作流指南 这个 Skill 教你如何高效使用 GitHub MCP。 ## 创建 Issue 的正确姿势 1. **先搜有没有类似的** `github.search_issues(query="关键词")` 2. **创建时带上标签** `github.create_issue(title, body, labels=["bug"/"enhancement"])` 3. **关联相关内容** 如果有相关 PR，在评论里 @一下 ## PR 审查流程 1. 先拿 diff（数据量小） 2. 有问题再看完整文件 3. 批量操作尽量合并 ## 省 Token 的小技巧 - 尽量用 `list` 而不是 `get` - 服务端能过滤的别客户端过滤 - 分页，别一次拉全部

这样，Claude 在使用 GitHub MCP 的时候，就有"方法论"可循了。

五、性能优化：让 Skill 跑更快

优化1：精简 description

description 是每次对话都会加载的，要惜字如金。

# ❌ 啰嗦description:This skill helps you process PDF files. It can extract text from PDFs,fill out PDF forms,merge multiple PDFs together,split PDFs into pages,add annotations and comments,extract images,and much more. Use this skill whenever you need to work with PDF documents.# ✅ 精炼description:处理 PDF-提取文本、填表单、合并拆分、加批注。有 PDF 任务就用它。

优化2：延迟加载非核心内容

SKILL.md 只放核心流程，复杂细节放别的文件：

# 核心指令 ## 基本流程 [写在这里] ## 高级功能 复杂场景详见 [advanced.md](advanced.md) ## API 参考 完整文档详见 [reference.md](reference.md)

优化3：用脚本替代长描述

# ❌ 用文字描述输出格式 输出应该是 JSON 格式，包含以下字段： - success (布尔值) - data (对象，包含字段 a, b, c) - error (字符串或null) ... # ✅ 丢给脚本 运行 `python validate_output.py` 可以检查输出格式。 具体格式定义见脚本源码。

如何监控 Token 消耗？

在对话中问 Claude：

这个对话目前用了多少 tokens？

对比使用 Skill 前后的 Token 消耗，确保优化有效。

六、安全最佳实践

上线前 Checklist

在你把 Skill 分享出去之前，逐项检查：

□ YAML frontmatter 格式正确 □ 没有硬编码的敏感信息（API Key、密码） □ 脚本里没有危险操作（rm -rf、格式化磁盘） □ 网络访问有限制或有明确说明 □ 文件操作范围受限 □ 依赖的库来自可信源

代码审查重点

# ✅ 标准库 - 放心用importjsonimportosimportsys# ⚠️ 第三方库 - 看看来源importrequests# PyPI 官方包，OKimportsome_random_lib# 查一下是啥# ❌ 危险操作 - 三思importsubprocess# 可能执行任意命令os.system("...")# 同上，小心

网络访问声明

如果 Skill 会联网，要在文档里写清楚：

## 网络访问说明 这个 Skill 会访问： - api.example.com（内部 API） - data.gov（公开数据） ⚠️ 请在可信环境下使用。 请勿用于： - 不受信任的 URL - 用户直接输入的地址 - 外部文件下载

七、与 Claude 一起迭代

Anthropic 官方的建议是：让 Claude 参与 Skill 的改进。

迭代工作流

1. 用 Skill 执行任务 │ ▼ 2. 观察结果 ├─ 成功？记录有效模式 └─ 失败？分析原因 │ ▼ 3. 问 Claude："这个任务哪里可以做得更好？" │ ▼ 4. 根据建议更新 Skill │ └── 回到第1步 ───┘

实际操作：

你：用了 git-commit-helper 这个 Skill 生成 commit message， 但有时候它会把 refactor 和 feat 搞混。有什么改进建议？ Claude：可以在 Skill 里加一个判断标准...

把 Claude 的好建议直接更新到 SKILL.md 里。让 AI 教你怎么教 AI。

八、总结

进阶技能树

领域	核心技巧
架构设计	渐进式披露、多文件组织、按需加载
脚本开发	JSON输出、错误处理、文档字符串
权限控制	allowed-tools、只读设计
MCP 协同	Skill 教用法，MCP 提供能力
性能优化	精简描述、延迟加载、脚本替代
安全实践	审计清单、依赖审查、网络声明