从 0 开始学习 AI 测试 - SKILL的编写实战

先回顾：Rules 文件解决了什么

在上一篇教程里，我们用 Rules 文件解决了一个问题：让 AI 遵守我们的工程规范以及代码复用。

Rules 文件的本质，它是一段会被自动注入到每次对话里的提示词。比如我们写过：

纯文本

- 禁止在测试文件中直接调用 HTTP 客户端
- 优先使用 Service 层的公共方法
- 测试用例命名必须遵循 test_{场景描述} 格式

这些规则会在 AI 每次生成代码时生效，确保它不跑偏。其实就是cursor（或者其他AI辅助工具）会自动把rules文件中的提示词注入到你的对话中。

但 Rules 这种自动注入到对话中的形式，注定了它是一种常驻的形式，这样就不适合做一些特定的任务。它不擅长描述一套完整的、多步骤的操作流程。。

举个例子：如果你想让 AI 执行"把一个旧版本接口迁移到新版本"这种复杂任务，假射这个流程需要 8 个步骤，要跑脚本检查，要按特定顺序操作把这一大段流程塞进 Rules 文件里，就会带来一个问题：

• Rules 是常驻的，每次对话都加载，这么长的内容会浪费大量 Token。同时会污染你的常规对话。就是你本来不想让他做这事，但它自动把这些注入到你的对话里了。这套流程只在"做迁移"时才用得到，平时挂着纯属干扰。

这就是 Skill 登场的地方。

---

Rules 与 Skill：相同点与不同点

Rules 可以看作是一个最特殊的 Skill， 一个永远生效的"底线型技能"。 而正式的 Skill，是为特定场景封装的、按需唤起的"专家型技能"（平时不会被唤起）。

相同点

维度	说明
本质	两者底层都是结构化的提示词（Prompt Engineering），都是"写给 AI 看的说明书"
目的	都是为了让 AI 的行为更可控、更符合预期，减少跑偏
形式	都用 Markdown 编写，人类可读、可维护
价值	都能把"人脑里的经验"沉淀成"AI 可执行的指令"

不同点

这是理解二者关系的关键，请仔细看这张表：

维度	Rules（规则）	Skill（技能）
定位	底线、约束	技能、能力
生效方式	始终生效（常驻）	按需触发（用到才加载）
内容长度	宜短（几十行）	可长（几百行 + 脚本）
典型内容	编码规范、安全红线、命名约定	完整工作流、操作 SOP、模板
能否带工具	不能，纯文本	能，可以包含脚本、配置模板等
Token 成本	每次对话都消耗	不触发时零成本
打个比方	公司的《员工行为准则》	某个岗位的《标准作业手册》+ 工具箱

一张图看懂二者的关系

纯文本

                  都是"写给 AI 看的说明书"
                            │
            ┌───────────────┴───────────────┐
            │                               │
        ┌───▼────┐                     ┌────▼─────┐
        │ Rules  │                     │  Skill   │
        │ 规则   │                     │  技能    │
        └────────┘                     └──────────┘
        ·始终生效                       ·按需唤起
        ·短、纯文本                     ·可长、可带脚本工具
        ·定义"底线"                     ·封装"完整能力"
        ·例：不许硬编码 token           ·例：一键迁移接口版本
            │                               │
            └──── Rules 是特殊的 ─────────┘
                  那个"常驻 Skill"

理解了这层关系，我们就可以正式认识 Skill 了。

---

什么是真正的 Skill

一句话定义

Skill 是为特定场景封装的"技能包"，它是一组提示词和脚本工具的组合，专门用来让 AI 高质量地完成某一类任务。

拆开这句话的关键词：

• 特定场景：Skill 不是万能的，每个 Skill 只专注做好一件事（比如"生成单元测试""审查 SQL 安全性"）

• 提示词 + 脚本工具的组合：这是 Skill 区别于 Rules 的核心，skill可以（附带脚本，让 AI 真正执行检查、转换、验证等操作）

• 封装：把"做这件事需要的所有知识和工具"打包在一起

Skill 的三个要素

一个完整的 Skill 通常包含三类内容：

要素	英文	作用	举例
指令	Instructions	告诉 AI 怎么干、按什么步骤	"第一步检查环境，第二步生成代码，第三步运行验证"
上下文	Context	提供背景知识、团队规范	"我们项目用 pytest，断言风格是 XXX"
工具	Tools	辅助脚本、配置模板	一个 check_env.sh 脚本、一个测试文件模板

Skill 最大的价值：一人编写，所有人复用

这是 Skill 在团队中的核心意义：

纯文本

传统方式：
  老员工脑子里有一套"怎么写好接口测试"的经验
  → 新人来了要口头教、文档可能过期
  → 老员工离职，经验也跟着走了

Skill 方式：
  老员工把经验写成一个 Skill（一次性投入）
  → 提交到团队仓库
  → 所有人（包括新人）的 AI 都能立刻用上这套经验
  → 人走了，Skill 还在，知识留下来了

Skill 可以"主动被唤起"

和 Rules"被动常驻"不同，Skill 可以根据用户的意图主动唤起执行。

比如你对 AI 说：

纯文本

帮我给 order_service.py 这个文件生成单元测试

如果团队里有一个叫"生成单元测试"的 Skill，AI 会自动识别到你的意图与这个 Skill 匹配，于是自动加载并按照 Skill 里定义的流程执行。

这种"按意图自动唤起"的能力，是 Skill 体系最优雅的地方。

当然也可以由用户主动唤起， 我们在对话框中 使用 "/" 这个符号来唤起 Skill。它会显示出当前所有的skill，用户可以主动选择使用哪一个 Skill。

Skill 长什么样：目录与文件结构

纯文本

my-first-skill/          ← 一个文件夹
└── SKILL.md             ← 唯一必需的文件（里面就是提示词）

没错，最简单的 Skill 只需要一个 SKILL.md 文件。这个文件就是整个 Skill 的"说明书"，其实就是你需要它干什么的提示词。

复杂一点的 Skill：带上脚本和资源

当 Skill 需要附带工具时，目录会丰富起来：

纯文本

generate-unit-test/      ← Skill 文件夹
├── SKILL.md             ← 核心说明书（必需）
├── scripts/             ← 脚本工具目录
│   ├── check_env.sh     ← 环境检查脚本
│   └── run_coverage.sh  ← 覆盖率检查脚本
├── references/          ← 参考文档目录
│   └── test-patterns.md ← 详细的测试模式说明
└── assets/              ← 静态资源目录
    └── test_template.py ← 测试文件模板

目录	用途	是否必需
SKILL.md	核心说明书	必需
scripts/	可执行脚本（检查、转换、验证等）有些任务可提前沉淀下来脚本，保证每次都稳定正确的运行，毕竟让大模型每次都自己发挥，太不可控了	可选
references/	详细参考文档（避免把 SKILL.md 撑太长） 很多任务需要一些知识才能完成，你可以认为这是skill的知识库	可选
assets/	模板、配置等静态资源，也包括一些运行结果	可选

SKILL.md 的内部结构

SKILL.md 由两部分组成：**YAML 头信息** + **Markdown 正文**。

Markdown

---
name: generate-unit-test
description: 为指定的源代码文件自动生成 pytest 单元测试。当用户要求"写单元测试""生成测试""补测试覆盖"时触发。
---

# 生成单元测试

## 概述
本 Skill 帮助你为 Python 源文件自动生成符合项目规范的 pytest 单元测试。

## 前置条件
- 项目已安装 pytest
- 存在 conftest.py

## 处理步骤
1. 读取目标源文件，理解其函数和类
2. 识别需要测试的公共方法
3. 为每个方法生成正常、边界、异常三类测试
4. 运行 pytest 验证生成的测试可以通过

## 代码示例
（这里放 代码 示例，一般是references目录下的文件）

## 验证清单
- [ ] 所有测试可以被 pytest 收集
- [ ] 测试全部通过
- [ ] 覆盖率达到 80% 以上
- [ ] 调用scripts/check.sh 检查代码规范

• YAML 头 （--- 之间的部分）：定义 Skill 的元信息，最关键的是 name 和 description

• Markdown 正文：详细的指令、上下文、示例、验证清单等

划重点 ：description 字段极其重要------它决定了 AI 能否在合适的时机"想起"这个 Skill。后面第8章会专门讲怎么写好它。

Skill 存放在哪里

以 Cursor / Claude Code 类工具为例，Skill 通常有两个存放位置：

位置	路径示例	作用范围
用户级	~/.claude/skills/ 或 ~/.cursor/skills/	所有项目都能用
项目级	项目根目录/.claude/skills/ 或 .cursor/skills/	只在当前项目生效

注意：不同 AI 工具的具体路径和机制略有差异，请以你使用的工具官方文档为准。本系列以通用机制讲解。

当然最简单的创建方式， 是直接在Agent对话中，告诉大模型，我想创建一个项目级的 Skill，然后输入名称和描述即可。

---

尝试写出第一个 Skill

理论讲完了，我们动手做一个真正能用的 Skill。目标：做一个"为接口测试工程自动生成测试用例"的 Skill，把我们前两篇的经验沉淀进去。

第一步：明确这个 Skill 要解决什么

在动手前，先想清楚三个问题：

问题	我们的答案
这个 Skill 做什么？	为接口生成符合三层架构规范的 pytest 测试用例
什么时候触发？	用户说"写接口测试""生成测试用例""给 XX 接口补测试"时
做完怎么算成功？	测试能被 pytest 收集 + 全部通过 + 符合代码规范

第二步：用对话让大模型创建 Skill 骨架

PS：就不用古法编程了，直接用对话让大模型帮你生成 Skill。

在 Cursor的Agent对话里直接这样说：

纯文本

帮我在当前项目里创建一个项目级 Skill，名字叫 api-test-generator。

它的作用是：为接口生成符合三层架构（api层 / service层 / tests层）规范的
pytest 测试用例。当用户说"写接口测试""生成测试用例""给某接口补测试覆盖"时
应该触发它。技术栈是 pytest + requests。

请先帮我把 Skill 的目录和 SKILL.md 骨架建好，YAML 头信息里的
name 和 description 帮我写好，description 要写清"做什么 + 何时触发 + 技术关键词"。

大模型会自动帮你：

1. 创建 .cursor/skills/api-test-generator/ 目录

2. 生成 SKILL.md 文件

3. 写好 YAML 头信息

你会得到类似这样的骨架（这是大模型生成的，不是你手敲的）：

YAML

---
name: api-test-generator
description: 为接口生成符合三层架构（api层/service层/tests层）规范的 pytest 测试用例。当用户要求"写接口测试""生成测试用例""给某接口补测试覆盖"时触发。适用于使用 pytest + requests 的接口自动化工程。
---

第三步：用对话把"流程经验"喂给大模型，让它补全正文

骨架有了，接下来是---处理步骤、示例、验证清单。同样不用手写，你只要把脑子里的"该怎么做"用大白话讲给大模型，让它整理成规范的 SKILL.md 正文。

继续对话：

纯文本

现在帮我把这个 SKILL.md 的正文补充完整，按下面我说的流程来整理：

【概述】
说明这个 Skill 会生成符合三层架构规范的 pytest 测试，
自动遵循"api 层定义接口、service 层封装流程、tests 层只写测试逻辑"的约定。

【前置条件】
开始前要确认：项目有 api/ services/ tests/ 三个目录、装了 pytest 和 requests、
有 conftest.py 且定义了 api_client fixture。不满足就提示用户。

【处理步骤】要分成这几步：
1. 通过语义检索，找到满足当前测试用例需要的方法和API。如果项目里没有定义好接口，那需要收集接口信息（路径、方法、必填/可选参数、成功响应字段、业务功能）
2. 检查 api 层是否已有该接口，没有就先在 {模块}_api.py 里补接口定义
3. 检查 service 层有没有可复用的流程（比如"先创建订单"这种前置数据）
4. 生成测试用例，要覆盖正常、边界、异常三类场景
5. 运行 pytest 验证测试能收集且通过

【示例】给一个创建订单接口的例子，展示生成的代码长什么样。

【验证清单】列出完成后要检查的点：命名规范、不能在测试里直接拼接口路径、
三类场景齐全、pytest 能通过。

大模型会把你这段口语化的描述，整理成结构清晰的 SKILL.md 正文。你拿到后通读一遍，发现哪里不对就继续让它调整

第四步：让大模型顺便补一个脚本工具

如果你希望这个 Skill 带一个"环境检查脚本"，也不用自己写 shell，直接说：

纯文本

再帮这个 Skill 加一个环境检查脚本，放在 scripts/check_env.sh，
功能是检查当前产品的测试环境是否健康，是否可访问。毕竟如果环境有问题，我们的测试用例也一定会失败。 这时候就不要去运行验证了。

大模型会自动创建 scripts/check_env.sh 并在 SKILL.md 里加上引用。你只要看一眼脚本逻辑对不对即可。

第五步：测试你的 Skill

Skill 建好后，在 Cursor 中重新打开项目（让它重新加载 Skill），然后对 AI 说一句日常需求：

纯文本

给查询订单列表接口写测试，GET /api/v2/orders，支持 page、page_size、status 参数

如果 Skill 写得好，AI 会自动识别意图、加载你刚建的 Skill、按照里面定义的步骤生成符合规范的测试用例------你甚至不用提"用 api-test-generator"，它自己就唤起了。

恭喜，你的第一个 Skill 就这样"聊"出来了！

---

总结

这里可能有些同学会说，我这个项目就是用来做接口自动化的，我直接使用rules文件不可以么？ 短期看是可以的， 但其实在AI时代下，一个接口自动化工程， 可不是只为了接口自动化而存在，而是为了整个项目自动化而存在。后面我要讲如何用AI来生成和执行性能测试场景，高可用测试场景，生成手工测试用例场景，生成需求分析报告场景等等。 我们总不能把这些所有的东西都放在一个rules文件里吧？毕竟我们有一种现象叫上下文腐坏，过多的上下文会让大模型幻觉，跳步，自欺欺人等。这里也再重申一下 **Everything in git ** 的设计哲学。这些所有的代码和文档都是我们项目的知识，这些知识为我们后续编写各种skill来完成特定任务都是有帮助的。

最后在推荐一下我的知识星球， 更多教程内容会在上面更新：