上个月，团队里一个测试新人跑来找我，表情有点委屈。
“哥，我在项目里放了一个 SKILL.md，为什么 Claude Code 还是不会干活？”
我让他把文件打开。里面写着一段话：“你是资深测试工程师，请帮我生成测试用例，覆盖正常和异常场景。”
我看完就笑了。我说：“你这不是 Skill，是许愿。”
他愣了一下：“SKILL.md 不就是写提示词吗？”
这是大多数测试人刚接触 Agent Skills 时的第一个误解。
SKILL.md 不是提示词。它是一份结构化的操作手册。你写“帮我生成用例”，Agent 只会给你一段文本。你写清楚“第一步读什么、第二步拆什么、第三步输出什么格式、遇到异常怎么处理”，Agent 才知道该怎么干活。
今天这篇文章，我从零拆一个测试人最常用的 Skill——测试用例生成。看完你就能自己写第一个。
一、Skill 到底是什么？一句话说清楚
Anthropic 官方对 Skill 的定义很干脆：一个 Skill 就是一个文件夹。里面必须有一个 SKILL.md 文件，还可以放脚本、参考资料、静态资源。
用大白话说：Skill 就是把“资深测试工程师怎么做一件事”的完整经验，封装成一个 Agent 能随时调用的能力包。
它和 MCP 的区别是什么？MCP 解决“模型能用什么工具”——连数据库、接 GitHub、操作浏览器。Skill 解决“模型该怎么用这些工具”——按什么步骤、什么格式、什么标准。MCP 给 Agent 提供手，Skill 给 Agent 提供操作手册。
没有 Skill，Agent 有手也不知道怎么干活。
二、一个测试人可用的 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。
三、SKILL.md 怎么写？直接复制这个模板
SKILL.md 分两部分：YAML 头信息 + Markdown 正文。
头信息：决定 Agent 什么时候用它
name: test-case-generator
description: 根据功能描述或需求文档生成覆盖正常流程、异常场景、边界条件和权限校验的结构化测试用例。当用户提到“生成测试用例”“编写测试”“测试覆盖”“测试场景”时自动触发。
when_to_use: 用户需要从需求文档或功能描述生成测试用例时使用。适用于功能测试、回归测试、接口测试的用例设计阶段。
description 是最重要的字段。 Claude 会把所有 Skill 的 description 预加载进上下文，用来判断该不该触发这个 Skill。你写“帮助测试”，它永远不知道什么时候该用。你写“当用户提到生成测试用例、编写测试时触发”，它就知道。
正文：告诉 Agent 具体怎么做
任务
根据用户提供的功能描述或需求文档，生成覆盖正常流程、异常操作、边界条件和权限校验四大类场景的测试用例。
执行步骤
步骤1：理解需求
读取用户提供的功能描述，提取：
- 核心功能是什么
- 输入参数和约束条件
- 业务规则和状态流转
- 权限和角色要求
步骤2：识别测试场景
基于需求分析，系统性地列出所有测试场景：
正常流程：至少覆盖1条完整的 Happy Path。
异常场景：参数缺失、格式错误、业务规则违反、依赖服务超时。
边界条件：数值边界、状态边界、时间窗口边界。
权限校验：未授权访问、越权操作。
步骤3：生成用例
为每个场景生成结构化用例，包含：
- 用例编号：{模块}-{类型}-{序号}
- 测试场景：一句话描述
- 前置条件：执行前必须满足的条件
- 测试步骤：编号列表，每步具体可执行
- 预期结果：执行后的期望结果
- 优先级：P0/P1/P2
步骤4：自检
对照场景分类检查是否有遗漏：
- [ ] 每个功能点是否有至少1条正向用例？
- [ ] 每个输入参数是否有异常场景覆盖？
- [ ] 边界值是否覆盖了上下界？
- [ ] 不同角色权限是否都有验证？
输出格式
Markdown 表格，可直接复制到 Excel 或测试管理工具。
注意事项
- 不臆造需求中不存在的功能
- 如果信息不明确，标注“需确认”而不是猜测
- 每个功能点至少生成1条正向用例 + 3条异常/边界场景
三个写正文的原则：
步骤具体可执行。 不要写“验证数据是否正确”，要写“调用 GET /api/order/{id}，检查返回的 status 字段是否为‘已取消’”。
SKILL.md 控制在 500 行以内。 超过 500 行，把详细内容移到 references/ 目录。
用祈使句。 “运行脚本”“检查输出”，不要用第二人称。
四、怎么用？三个字：直接调
写好之后，在 Claude Code 里输入 /test-case-generator，然后把需求文档粘贴进去。或者直接用自然语言：“用 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.md 不是提示词，是操作手册。
你写“帮我生成用例”，Agent 只能给你一段文字。你写清楚第一步读什么、第二步拆什么、第三步输出什么格式，Agent 才知道该怎么干活。
一个 SKILL.md 确实能让 Agent 干活。前提是，你得把它写成一个真正的“技能”，而不是一张许愿条。
测试人的经验，值得被封装成 Skill。你今天花 30 分钟写一个“测试用例生成”的 Skill，以后每一个项目都能复用。
别只写提示词了。写一个 SKILL.md，让 Agent 真正替你干活。
