上个月，团队里一个测试新人跑来找我，表情有点委屈。
“哥，我在项目里放了一个 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 什么时候用它
name: test-case-generator
description: 根据功能描述或需求文档生成覆盖正常流程、异常场景、边界条件和权限校验的结构化测试用例。当用户提到“生成测试用例”“编写测试”“测试覆盖”“测试场景”时自动触发。
when_to_use: 用户需要从需求文档或功能描述生成测试用例时使用。适用于功能测试、回归测试、接口测试的用例设计阶段。
正文：告诉 Agent 具体怎么做
任务
根据用户提供的功能描述或需求文档，生成覆盖正常流程、异常操作、边界条件和权限校验四大类场景的测试用例。
执行步骤
步骤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 真正替你干活。
