Skill 是什么：一篇给开发者的入门文章

Skill（或 Skills）可以理解为给 AI Agent 准备的“可复用技能包”。它通常是一个文件夹，里面放着任务说明、脚本、模板和参考资料，AI 在处理相关任务时会按需加载这些内容，从而更稳定、可重复地完成特定工作。

对开发者来说，Skill 的价值不在“写一个更长的 Prompt”，而在于把反复出现的经验、流程和规范沉淀下来。这样一来，AI 不只是“知道要做什么”，还更清楚“应该按什么步骤做、产出什么结果、遵守哪些约束”。

先说最基础的规范

刚开始入门，Skill 不用写得太复杂，先抓住几个最关键、最常用的部分就够了。Skill 的核心是一个目录，里面至少要有说明文件，复杂一点的 Skill 再附加脚本和资源。

一个适合新手采用的最小结构可以是：

my-skill/
├─ SKILL.md
├─ scripts/
├─ assets/
└─ references/

这里最关键的是 SKILL.md。它作为Skill 的入口文件，通常包含两部分：一是头部元信息，例如 name 和 description；二是正文说明，用来写触发场景、执行步骤、输出要求和示例。

先遵守这几条基础规范：

• 一个 Skill 只解决一类问题，不要把太多目标混进同一个 Skill。

• 目录名和 name 尽量清晰具体，例如 nextjs-docker-dev、api-testcase-generator，不要使用过于宽泛的名字。

• description 直接写清“适合什么场景、解决什么问题”，方便 AI 判断什么时候该用它。

• SKILL.md 里至少写清四件事：何时触发、需要哪些输入、分几步执行、最后输出什么。

• 有固定模板或脚本时，再放进 assets/ 和 scripts/，不要把所有细节都堆在 Markdown 里。

如果想看更完整的规范和进阶实践，可以直接参考官方文档与官方资料：Anthropic 帮助中心的“什么是技能”页面、官方工程博客关于 Agent Skills 的文章，以及官方 PDF《The Complete Guide to Building Skills for Claude》。

• 官方帮助中心：<https://support.claude.com/zh-CN/articles/12512176-什么是技能>

• 官方工程文章：<https://www.anthropic.com/engineering/equipping-agents-for-the-real-world-with-agent-skills>

• 官方 PDF 指南：<https://resources.anthropic.com/hubfs/The-Complete-Guide-to-Building-Skill-for-Claude.pdf>

Skill 和 Prompt 的区别

很多人第一次接触 Skill，会觉得它只是“Prompt 的升级版”。这种理解不能算错，但还不够准确。Prompt 更像一次性的口头指令，而 Skill 更像一份可长期复用的 SOP，里面不仅有任务要求，还可能带脚本、模板和参考资料。

Prompt 的优点是轻量、直接，适合临时任务；Skill 的优点是稳定、可重复，适合经常出现、质量标准明确的工作。

Anthropic 的帮助中心明确把 Skill 描述为包含指令、脚本和资源的文件夹，并强调 Claude 会动态加载这些内容来提升专业任务表现。

什么场景适合用 Skill

不是所有事情都值得做成 Skill。最适合 Skill 的，通常是那些“重复频繁、步骤明确、输出可验证”的任务，因为这类工作最容易从标准化里获得收益。

常见适用场景包括：

• 本地开发环境搭建，例如为某个项目生成 Docker 开发配置。

• 代码生成或脚手架初始化，例如创建模块模板、页面模板、测试模板。

• 测试设计与测试代码骨架生成，例如自动整理 API 测试点。

• 文档整理、发布说明、PR 描述生成等格式比较固定的工作。

反过来说，一次性任务、流程还没稳定下来的任务，或者高度依赖灵感发散的任务，通常不必急着做成 Skill。先用普通对话把流程跑顺，再决定是否沉淀成 Skill，往往更高效。

一个好的 Skill 应该具备什么

一个好 Skill 不一定复杂，但通常都具备几个共同点：边界清晰、说明具体、输出明确、能复用。官方资料和实践文章都强调，Skill 的目标不是写得“宏大”，而是让 AI 在特定问题上稳定发挥。

最基础的判断标准可以很简单：

• 名称具体，能看出用途。

• 描述明确，能看出触发场景。

• 步骤清楚，AI 知道先做什么、后做什么。

• 输出固定，便于检查结果是否达标。

• 有模板、脚本或示例时能一起打包，减少 AI 每次重新猜测。

对于团队协作来说，这一点尤其有意义。因为 Skill 本质上是在把原本散落在 README、Wiki、口头传承里的做事方法，变成 AI 可以执行的标准流程。

案例一：Next.js 本地 Docker 开发环境

这是最适合做成 Skill 的开发类任务之一。因为本地环境搭建几乎每个项目都会遇到，而且对新人最容易造成阻塞：依赖服务怎么起、环境变量怎么配、Node 版本怎么统一、数据库怎么初始化，这些问题通常都重复出现。

如果把它做成 Skill，目标并不是只生成一个 docker-compose.yml，而是让 AI 能围绕整个“本地开发环境”给出完整结果。比如它应该能识别项目的包管理器、Next.js 启动方式、是否依赖 Postgres/Redis，并在缺少信息时继续追问，再输出一套可运行的 Docker 配置和说明文档。

一个典型的输出可以包括：

• Dockerfile，定义 Node 环境和应用启动方式。

• docker-compose.yml，把 app、数据库、缓存等服务串起来。

• .env.example，列出本地开发所需环境变量。

• scripts/dev-init.sh，执行初始化、迁移或 seed。

• README-docker.md，告诉团队怎么启动、怎么排错。

这个 Skill 的核心步骤通常是：先检查仓库现状，再识别技术栈和依赖服务，然后在缺失信息时追问，最后生成文件并附上使用说明。这样的结构比一句“帮我写个 Docker 配置”可靠得多，因为它把上下文收集、文件生成和交付说明统一放进了一个固定流程。

一个非常简化的 SKILL.md 开头可以写成这样：

---
name: nextjs-docker-dev
description: 为 Next.js 项目生成本地 Docker 开发环境，包括 app、数据库、缓存、环境变量模板和启动说明。
---

当用户希望为 Next.js 项目补充本地 Docker 开发配置时使用本 Skill。

步骤：
1. 检查项目是否已有 Dockerfile 或 compose 文件。
2. 识别包管理器、Node 版本、启动脚本。
3. 询问是否需要 Postgres、Redis、热更新。
4. 生成 Dockerfile、docker-compose.yml、.env.example。
5. 输出启动命令、常见故障和排查说明。

这个例子说明了 Skill 的本质：不是把所有知识都堆在一段 Prompt 里，而是把一个任务的常见决策路径明确下来，方便 AI 反复使用。

案例二：自动生成 API 测试用例

第二个非常适合 Skill 的案例，是自动生成 API 测试用例。因为接口测试天然有固定套路：正常路径、参数校验、权限校验、边界条件、错误处理、幂等性和响应结构检查，这些内容非常适合标准化。

如果只靠一次性 Prompt，AI 虽然也能列出一些测试点，但输出质量常常依赖你提问是否完整。把它做成 Skill 之后，就可以提前规定：先读取 API 定义，再按统一维度列出测试点，然后按指定框架输出测试代码骨架，最后标出不确定项等待人工确认。

这个 Skill 的输入通常包括：

• OpenAPI / Swagger 文档或接口定义。

• 鉴权方式，例如 Bearer Token 或 Session。

• 使用的测试框架，例如 Jest、Pytest、Playwright API。

• 环境信息，例如 dev 或 staging 的 base URL。

输出则可以分为两层：第一层是结构化测试点，第二层是自动化测试代码模板。对于“创建订单”这类接口，一个较完整的 Skill 至少会引导 AI 覆盖正常创建、缺失参数、权限失效、库存不足、重复提交是否幂等等关键情况。

一个简化版 SKILL.md 可以这样写：

---
name: api-testcase-generator
description: 根据 API 定义生成结构化测试点和自动化测试代码骨架，适用于 REST API 接口测试。
---

当用户希望为 API 自动生成测试用例、补齐边界测试或生成测试代码模板时使用本 Skill。

步骤：
1. 读取 API 定义，包括路径、方法、参数、响应和鉴权方式。
2. 生成正常路径、参数异常、权限异常、边界值、幂等性等测试点。
3. 按用户指定框架输出测试代码骨架。
4. 对不确定的业务规则标记“需要确认”。

这种 Skill 的价值不只是提速，更重要的是帮助团队把“测试经验”显式化。原本依赖资深同学脑中的隐性知识，现在可以变成 AI 可重复调用的工作流。

怎么用 AI 帮自己做 Skill

做 Skill 最常见的误区，是一开始就试图设计一套特别完整的规范。更高效的做法通常是先拿一个真实任务，让 AI 和你一起跑通，再把其中稳定、重复的部分提炼出来。

一个实用做法是按四步走：

1. 先完成一次真实任务，观察 AI 缺什么信息、哪里容易出错。

2. 把这个任务拆成固定步骤，整理出输入、追问点、输出物。

3. 把高频模板、脚本、说明文档放进 Skill 目录。

4. 用真实 bad case 持续修正 Skill，而不是一次写完就不管了。

这种方法特别适合开发团队，因为很多流程本来就已经存在，只是散落在不同地方。Skill 做的事情，其实是把这些分散知识重新组织成 AI 可执行的形态。

在工作中怎么把 Skill 用好

Skill 真正产生价值，不是因为“概念先进”，而是因为它能进入日常工作流。官方资料提到，Skill 的重要用途之一是承载组织知识和专业工作流，这对开发团队尤其有现实意义。

在工作中更容易落地的做法通常有三条：

• 从小任务开始，先做一个高频、边界清晰、容易验证效果的 Skill。

• 把 Skill 当作团队知识的可执行版本，而不只是静态文档。

• 像维护代码一样维护 Skill，持续根据失败案例修正它。

对很多团队来说，一个“本地 Docker 开发环境” Skill，或者一个“API 测试用例生成” Skill，就已经足够作为起点。因为这两类任务同时满足了重复频繁、流程稳定、价值直观三个条件，很适合快速看见收益。

结语

如果要用一句话解释 Skill，可以说：它是把经验、规范、流程和资源打包成 AI 可反复调用的工作手册。Anthropic 的官方定义也明确指出，Skill 是由指令、脚本和资源组成的文件夹，Claude 会在相关任务中动态加载它们，以改进专业任务表现。

对开发者来说，Skill 最值得投入的地方，不是“能不能做得很复杂”，而是“能不能把一个重复任务做得稳定、好用、可交接”。从 Next.js 本地 Docker 开发环境，到自动生成 API 测试用例，这些都是非常适合入门的起点。