
上个月，团队里一个测试新人跑来找我，表情有点委屈。

“哥，我在项目里放了一个 SKILL.md，为什么 Claude Code 还是不会干活？”

我让他把文件打开。里面写着一段话：“你是资深测试工程师，请帮我生成测试用例，覆盖正常和异常场景。”

我看完就笑了。我说：“你这不是 Skill，是许愿。”

他愣了一下：“SKILL.md 不就是写提示词吗？”

**这是大多数测试人刚接触 Agent Skills 时的第一个误解。**

SKILL.md 不是提示词。它是一份结构化的操作手册。你写“帮我生成用例”，Agent 只会给你一段文本。你写清楚“第一步读什么、第二步拆什么、第三步输出什么格式、遇到异常怎么处理”，Agent 才知道该怎么干活。

今天这篇文章，我从零拆一个测试人最常用的 Skill——**测试用例生成**。看完你就能自己写第一个。


## 一、为什么测试 Agent 总是“落不了地”？

过去一年，很多团队都在尝试用 AI 做测试。但真正跑起来的没几个。

问题出在哪？不是模型不行，是**你给它的东西，根本不是一个“能力单元”**。

我们过去用 AI 做测试，基本套路就是写一段系统提示词：“你是资深测试工程师，请按照以下步骤执行回归测试……”然后期待它自己搞定一切。

这个思路有一个根本性缺陷：**LLM 是语言模型，不是操作系统的内核。**

它可以告诉你“应该先登录再查询”，但面对动态验证码、偶尔超时的 API、需要滑动解锁的按钮，纯文本推理能力完全不够用。

Prompt 是说明书，告诉 Agent“拧开螺丝”。但真实任务执行，需要知道螺丝刀在哪个抽屉、顺时针拧几圈、遇到滑丝怎么处理——这些确定性操作流程，Prompt 给不了。

Agent Skills 解决的就是这个问题。


## 二、Agent Skills 到底是什么？一句话说清楚

Anthropic 官方对 Skill 的定义很干脆：**一个 Skill 就是一个文件夹**。里面必须有一个 `SKILL.md` 文件，还可以放脚本（`scripts/`）、参考资料（`references/`）、静态资源（`assets/`）。

用大白话说：**Skill 就是把“资深测试工程师怎么做一件事”的完整经验，封装成一个 Agent 能随时调用的能力包。**

它和 MCP 的区别是什么？MCP 解决“模型能用什么工具”——连数据库、接 GitHub、操作浏览器。Skill 解决“模型该怎么用这些工具”——按什么步骤、什么格式、什么标准。MCP 给 Agent 提供手，Skill 给 Agent 提供操作手册。

**没有 Skill，Agent 有手也不知道怎么干活。**


## 三、技能包如何让测试 Agent 真正落地？

一个能落地的测试 Skill，必须包含三样东西：**触发机制、流程编排、执行能力**。

### 触发机制：description 决定 Agent 什么时候用它

Claude 会把所有 Skill 的 description 预加载进上下文，用来判断该不该触发这个 Skill。

你写“帮助测试”，它永远不知道什么时候该用。你写“当用户提到生成测试用例、编写测试、测试覆盖、测试场景时触发”，它就知道。

**description 是 Skill 的“门牌号”，不是广告词。**

### 流程编排：SKILL.md 正文告诉 Agent 怎么做

正文就是操作手册。要写清楚：第一步做什么、第二步做什么、每一步的输入输出是什么、遇到异常怎么处理。

**不要写“验证数据是否正确”，要写“调用 GET /api/order/{id}，检查返回的 status 字段是否为‘已取消’”。**

### 执行能力：scripts 和 references 让 Agent 真能干活

纯文本的 Skill 只能做“建议”。加上 scripts 和 references，它才能做“执行”。

- `scripts/` 放可执行代码——格式化用例、调用接口、生成报告
- `references/` 放按需加载的长文档——用例模板、业务规则库、历史 Bug 模式


## 四、手把手：写一个“测试用例生成”Skill

拿测试人最常用的场景举例。目录结构是这样的：

```
.claude/skills/test-case-generator/
├── SKILL.md
├── references/
│   └── test-case-template.md
└── scripts/
    └── format_cases.py
```

关键规则：`SKILL.md` 文件名必须全大写。文件夹命名必须用 kebab-case，比如 `test-case-generator`，不能写成 `Test Case Generator`。

### 头信息：决定 Agent 什么时候用它

```yaml
---
name: test-case-generator
description: 根据功能描述或需求文档生成覆盖正常流程、异常场景、边界条件和权限校验的结构化测试用例。当用户提到“生成测试用例”“编写测试”“测试覆盖”“测试场景”时自动触发。
when_to_use: 用户需要从需求文档或功能描述生成测试用例时使用。适用于功能测试、回归测试、接口测试的用例设计阶段。
---
```

### 正文：告诉 Agent 具体怎么做

```markdown
## 任务
根据用户提供的功能描述或需求文档，生成覆盖正常流程、异常操作、边界条件和权限校验四大类场景的测试用例。

## 执行步骤

### 步骤1：理解需求
读取用户提供的功能描述，提取：
- 核心功能是什么
- 输入参数和约束条件
- 业务规则和状态流转
- 权限和角色要求

### 步骤2：识别测试场景
基于需求分析，系统性地列出所有测试场景：

**正常流程**：至少覆盖1条完整的 Happy Path。
**异常场景**：参数缺失、格式错误、业务规则违反、依赖服务超时。
**边界条件**：数值边界、状态边界、时间窗口边界。
**权限校验**：未授权访问、越权操作。

### 步骤3：生成用例
为每个场景生成结构化用例，包含：
- 用例编号：{模块}-{类型}-{序号}
- 测试场景：一句话描述
- 前置条件：执行前必须满足的条件
- 测试步骤：编号列表，每步具体可执行
- 预期结果：执行后的期望结果
- 优先级：P0/P1/P2

### 步骤4：自检
对照场景分类检查是否有遗漏：
- [ ] 每个功能点是否有至少1条正向用例？
- [ ] 每个输入参数是否有异常场景覆盖？
- [ ] 边界值是否覆盖了上下界？
- [ ] 不同角色权限是否都有验证？

## 输出格式
Markdown 表格，可直接复制到 Excel 或测试管理工具。

## 注意事项
- 不臆造需求中不存在的功能
- 如果信息不明确，标注“需确认”而不是猜测
- 每个功能点至少生成1条正向用例 + 3条异常/边界场景
```

写好之后，在 Claude Code 里输入 `/test-case-generator`，然后把需求文档粘贴进去。Agent 会自动加载 Skill 的规则，按你定义的四步走。

我让那个新人把原来的“许愿式”SKILL.md 换成了这个模板。他试了一下，回来跟我说：“哥，之前它给我生成的东西像网上抄的，现在生成的东西像我自己写的。”

区别在哪？之前他给的是“目标”，现在他给的是“流程”。


## 五、进阶：用 scripts 和 references 扩展能力

Skill 真正的威力在于可扩展。

**references/ 放长文档。** 比如详细的用例模板、历史 Bug 模式库、业务规则说明。SKILL.md 里只引用文件名，Claude 只在需要时才去读。这样不会把上下文撑爆。

**scripts/ 放可执行代码。** 比如把生成的用例表格转成 Excel、校验用例完整性、生成 Allure 报告。Claude 不看代码内容，只看执行结果。

一个简单判断：需要**执行**才能得到结果 → 放 `scripts/`。只需要**阅读**参考 → 放 `references/`。


## 六、避坑指南

**坑一：description 写得太空。** “帮助生成测试用例”——这句话等于没说。要写清楚触发条件：用户说什么话、什么场景下用这个 Skill。

**坑二：SKILL.md 写成百科全书。** 超过 500 行就开始浪费 Token。把详细内容移到 references 目录，SKILL.md 只留核心流程。

**坑三：只写指令，不写脚本和参考。** 纯文本的 Skill 只能做“建议”。加上 scripts 和 references，它才能做“执行”。

**坑四：建完不迭代。** 业务在变、需求在变，Skill 也需要更新。每次使用后记录“哪里漏了场景”“哪里判断错了”，定期更新 SKILL.md。

**坑五：忽略 Skill 的回归测试。** 模型版本一变，Skill 行为可能漂移。阿里开源的 skill-up 就是干这个的——用声明式 YAML 写评测用例，跨引擎跑评测，发现退化及时修复。


## 最后

**SKILL.md 不是提示词，是操作手册。**

你写“帮我生成用例”，Agent 只能给你一段文字。你写清楚第一步读什么、第二步拆什么、第三步输出什么格式，Agent 才知道该怎么干活。

一个 SKILL.md 确实能让 Agent 干活。前提是，你得把它写成一个真正的“技能”，而不是一张许愿条。

测试人的经验，值得被封装成 Skill。你今天花 30 分钟写一个“测试用例生成”的 Skill，以后每一个项目都能复用。

**别只写提示词了。写一个 SKILL.md，让 Agent 真正替你干活。**

>**本文部分内容参考了霍格沃兹测试开发学社整理的相关技术资料，主要涉及软件测试、自动化测试、测试开发及 AI 测试等内容，侧重测试实践、工具应用与工程经验整理。**


“哥，我在项目里放了一个 SKILL.md，为什么 Claude Code 还是不会干活？”

Agent Skills 入门：技能包如何让测试 Agent 真正落地？

测试

编程语言

人工智能

SKILL.md不是提示词，而是结构化操作手册。一个能落地的测试Skill需包含触发机制、流程编排、执行能力三要素。本文手把手教你从零构建"测试用例生成"Skill，涵盖目录结构、SKILL.md写法、避坑指南，帮你把测试经验封装成可复用的Agent能力包。

软件测试

回归测试

代码解释

验证码

数据库

GitHub

Agent

2026上云采购 | AI焕新·智启新局

coding

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

Agent Skills 入门：技能包如何让测试 Agent 真正落地？-腾讯云开发者社区-腾讯云

Agent Skills 入门：技能包如何让测试 Agent 真正落地？

Agent Skills 入门：技能包如何让测试 Agent 真正落地？

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐