Introduction to Agent Skills
Agent Skills 让你把某类任务的标准做法、规范和参考资料打包成可复用的「专长包」，需要时让 Claude 自动调用。本课带你认识 Skills 并构建你的第一个 Skill。
在互动学院中学习（含测验与进度保存）→Agent Skill 是一个可复用的「专长包」：把某类任务的标准做法、规范和参考资料打包好，需要时让 Claude 自动调用，从而稳定、专业地完成这类工作。
一个 Skill 通常是一个文件夹，核心是一份 SKILL.md 说明文件，里面写清楚：这个 Skill 是做什么的、什么时候该用、具体怎么做。还可以附带脚本、模板等资源。
Skill 把特定任务的规范、流程和资料封装成可复用的包，让 Claude 稳定、专业地完成这类工作。
Skills 的一个关键设计是「渐进式披露」（progressive disclosure）：Claude 不会一次性加载所有细节，而是先看简短的描述，判断需要时再读取更详细的内容。
上下文窗口是有限的。如果把每个 Skill 的全部细节都塞进去，会很快占满。渐进式披露让 Claude 先用一句话的简介判断「这个 Skill 现在用得上吗」，用得上才深入，从而节省上下文、保持高效。
渐进式披露让 Claude 先读简介、需要时再深入，避免一次性占满有限的上下文窗口。
一个 Skill 文件就是一个普通的 Markdown 文件，但它的结构决定了 Claude 能否准确理解并执行你的意图。本课带你解剖一个完整的 Skill 文件。
将 Markdown 文件放入 .claude/commands/ 目录后，文件名（不含 .md 后缀）就成为对应的斜杠命令。例如 review.md 对应 /review，deploy-env.md 对应 /deploy-env。文件内容会作为系统消息注入 Claude 的上下文。
一个规范的 Skill 文件包含三个关键部分：描述（description）说明该 Skill 做什么；使用时机（when-to-use）帮助 Claude 判断何时触发；步骤与说明（steps/instructions）是执行的具体指令。
# /review — 代码审查 Skill ## 描述 对当前改动执行全面的代码审查，输出结构化的审查报告。 ## 使用时机 当用户请求代码审查、想在提交前检查代码质量，或需要找出潜在 bug 时使用。 ## 步骤 1. 读取用户指定的文件或最近的 git diff 2. 检查以下维度：正确性、可读性、性能、安全性 3. 对每个问题给出：问题描述、严重程度（高/中/低）、改进建议 4. 最后给出总体评分和优先改进项
文件名去掉 .md 后缀即为命令名，路径不会出现在命令中。
好的 Skill 说明能让 Claude 精准执行你的意图。模糊的指令会导致不一致的输出，而清晰的示例则能大幅提升 Skill 的质量。
避免使用"好好检查代码"这样模糊的表述。应当明确说明：检查什么、按什么标准、输出什么格式。Claude 会严格按照你的指令行事，模糊的指令带来不可预期的结果。
在 Skill 文件中使用 $ARGUMENTS 占位符，Claude 会将用户在斜杠命令后输入的内容替换到此处。例如用户输入 /review src/api.py，$ARGUMENTS 就变成 src/api.py。
# /review — Python 代码审查 ## 描述 审查指定的 Python 文件，重点关注 PEP 8 规范、类型注解和异常处理。 ## 指令 审查以下文件：$ARGUMENTS 请按顺序执行： 1. 检查 PEP 8 命名规范（变量、函数、类名） 2. 检查是否缺少类型注解（函数参数和返回值） 3. 检查异常处理：是否有裸 except、是否记录了错误日志 4. 输出格式：每个问题单独一行，格式为 [严重度] 行号: 问题描述 5. 最后汇总：发现 N 个问题，其中高危 X 个 ## 示例输出 [高] 第 23 行: 裸 except 会捕获所有异常包括 KeyboardInterrupt [中] 第 45 行: 函数 process_data 缺少返回类型注解 [低] 第 12 行: 变量名 Temp 应改为小写 temp
在 Skill 文件中提供示例输入和期望输出，可以让 Claude 更好地校准自己的行为。示例充当了"少样本学习"的作用，特别适合输出格式要求严格的场景。
$ARGUMENTS 会被替换为斜杠命令名之后的所有内容，即用户传入的参数。
有些 Skill 需要辅助脚本、模板文件或参考文档才能正常工作。本课介绍如何将这些资源与 Skill 文件一起组织，以及何时应该保持 Skill 精简。
你可以在 .claude/commands/ 目录下创建子文件夹，将辅助文件放在同一位置。在 Skill 的指令中，告诉 Claude 读取这些文件的路径。Claude 具备文件读取能力，可以在执行 Skill 时自动加载相关内容。
当 Skill 需要执行特定格式的输出、引用固定的检查项列表，或需要运行一段脚本时，打包辅助文件是合理的。但不应把所有相关内容都打包进来——过多的文件会增加 Claude 读取的上下文，降低响应速度。
如果 Skill 的逻辑可以用一页 Markdown 说清楚，就不需要辅助文件。精简的 Skill 加载更快，更容易维护，也更容易与团队分享。当你发现需要用很多文件才能解释清楚一件事，考虑是否应该将其拆分为多个更小的 Skill。
固定的检查清单是典型的打包场景，它内容稳定、会被反复引用，放在独立文件中便于维护。
并非所有任务都适合封装成 Skill。判断清楚"何时该用、何时不该用"，能让你的 Skill 库保持精简高效。
当你发现自己或团队重复输入相同的指令超过三次，这就是创建 Skill 的信号。Skill 最擅长的是：标准化重复工作流、在团队间共享一致的操作规范、以及编码包含多个步骤的复杂流程。
好的 Skill 名称应该能让人一眼看出它做什么。推荐使用"动词-名词"格式：review-code、deploy-env、generate-changelog、summarize-pr。避免使用过于宽泛的名称如 helper 或 tools，也避免使用缩写。
一次性任务不值得封装：如果你只需要执行某个操作一次，直接告诉 Claude 就好。高度依赖上下文的任务也不适合 Skill——当任务每次都不同，通用的 Skill 反而会限制灵活性。
重复的、多步骤的、团队共用的发布检查流程是 Skill 的典型使用场景。
很多 Skill 因为几个常见错误而效果不佳。了解这些误区，能帮你从一开始就写出高质量的 Skill。
如果一个 Skill 叫 /help 或 /analyze，Claude 无法判断何时该用它、该做什么。过于宽泛的 Skill 会导致 Claude 的行为不一致，每次执行结果都不同。解决方法：明确 Skill 的边界，每个 Skill 只做一件事。
Skill 文件过长会占用大量 context window，可能导致 Claude 遗漏后续对话的重要信息。如果你的 Skill 超过 500 字，考虑拆分成两个更专注的 Skill，或者将重复内容提取到辅助文件中按需引用。
过长的 Skill 文件会占用宝贵的 context window 空间，可能导致 Claude 在处理后续对话时遗漏重要信息。
想要测验互动、进度自动保存的完整体验？
进入 AI 学院互动版 →